openBackhaul
commented
3 years ago Proposal to the 5G-xhaul-call on 9th of June 2021:
(Vendors are kindly asked to double check, whether their device types are actually implementing a discrete value range at the EthernetContainerConfiguration::maximumInformationRate attribute.)
The attributes EthernetContainerCapability::informationRateMin and EthernetContainerCapability::informationRateMax are replaced by a leaf-list EthernetContainerCapability::supportedMaximumInformationRateList : Integer [1..*]= -1.
The min-elements statement gets the value 1 (UML multiplicity: 1..*), to force the interface implementation to express the default-value -1 in case configuring the maximum information rate would not be supported by the hardware at all. The description in EthernetContainerConfiguration::maximumInformationRate attribute must be updated.
The description of the leaf-list "supportedMaximumInformationRateList " must explain the following information for implementation on device, mediator and SDN-app level.
The "supportedMaximumInformationRateList " must exclusively contain values, which are actually configurable at the hardware (except of the default value -1, in case maximum information rate cannot be configured at all).
The values listed in "supportedMaximumInformationRateList" might be all or a subset of values actually configurable at the hardware. To allow configuring the device according to its full capabilities, the values entered into the EthernetContainerConfiguration::maximumInformationRate attribute are not limited to the ones stated in EthernetContainerCapability::supportedMaximumInformationRateList. This means the maximumInformationRate attribute must be a bare integer and no leaf-ref.
If a value, which is supported by the hardware, but not listed in the "supportedMaximumInformationRateList", would be tried to be configured, the device-software or mediator-software shall successfully validate (and operate) it.
If a value, which is not supported by the hardware, would be tried to be configured, the device-software or mediator-software might implementation specifically react. It could either respond with operation-failed tag and error message "...Configuration value out of range of hardware capabilities..." or it could map the sent configuration value on the closest value, which is actually supported by the hardware. Vendors are free to chose according to the existing capabilities of their devices.
Configuration attempts with values lower than the minimum value or higher than the maximum value of the "supportedMaximumInformationRateList" must be answered with operation-failed tag and the error message "...Configuration value out of range of hardware capabilities...".
Devices might support only a subset of values between minimum and maximum value of the range. PUT requests will fail when attempting to configure some value inside the range, but not coinciding with one of the supported values.
Potential solutions: a) Capability attribute representing a list of allowed values (maybe subset of supported values) b) Device/Mediator automatically choosing the closest value
(A similar problem (queue-depth) has been covered in issue#28 by choosing option a). Option b) could be generic solution that avoids further Capability attributes.)