There was not enough time for discussing and deciding about the issue
Additional attributes for header compression will not be part of TR-532 v1.1
Issue#38 remains open.
The proposal for header compression contains the same concepts applied to the transmission modes defined for the air interfaces.
The capabilities declare a set of compression profiles from which to choose the operational one. So, the device is able to declare as many compression profiles (mode) as it supports. Devices supporting only the enable/disable of the header compression shall declare at least one profile. The profile contains the higher compressed layer (assuming the all underlying layers are compressed as well) and the maximum number of bytes that wll be compressed, taking in account the molteplicity of the compressed headers.
To achieve this configurability, it is necessary to perform the following operations.
1. Defining a type TypeDefinitions::CompressionHeaderType thats enums the following values:
2. Defining a type TypeDefinitions::CompressionProfileType thats groups the following attributes:
maxNumberOfBytesCompressed states how many bytes will be compressed, taking in account the multeplicity of the headers, for example if the compressor is able to compress up to 10 VLAN tag, the size of the ' vlan' header will be 10 x sizeof (vlan tag) = 40 bytes.
3. Defining a type TypeDefinitions::mplsPayloadType thats enums the following values:
4. Adding the list EthernetContainer::EthernetContainerCapability::compressionProfileList (with at least one element, if the header compression is supported) of typeDefinitions::CompressionProfileType data type for declaring the header compressor capabilities
5. Adding the attribute EthernetContainer::EthernetContainerConfiguration::CompressionProfileType of TypeDefinitions::CompressionProfileType data type for configuring the compression mode according to the definition in the capability information.
6. Adding the attribute EthernetContainer::EthernetContainerConfiguration::mplsPayload of TypeDefinitions::mplsPayloadType data type for configuring the payload of MPLS.
7. Marking all the existing TypeDefinitions: EthernetContainerCapability::*CompressionIsAvail attributes except packeCompressionIsAvail to be "deprecated".
8. Marking all the existing TypeDefinitions: EthernetContainerConfiguration::*CompressionIsOn attributes except packeCompressionIsOn to be "deprecated".
The proposal is backward compatible.
Assuming a device able to compress headers up to QinQ or up to layer4 and it is able to compress up to 10 VLANs and up to 2 MPLS lables.
The device shall declare in the capabilities:
EthernetContainer::EthernetContainerCapability::packetCompressionIsAvail = TRUE
maxHeaderCompressed  = QinQ
maxNumberOfBytesCompressed  = 14+10x4 = 54
maxHeaderCompressed  = layer4
maxNumberOfBytesCompressed  = 14+10x4+2x4+20+4 = 86 (only 4 bytes of the UDP/TCP header are compressible)
The SDN controller shall confgure the header compressor setting the following attributes:
EthernetContainer::EthernetContainerConfiguration::packetCompressionIsOn = TRUE (or FALSE)
EthernetContainer::EthernetContainerConfiguration::compressionProfile::maxHeaderCompressed = QinQ (or layer4)
EthernetContainer::EthernetContainerConfiguration::compressionProfile::maxNumberOfBytesCompressed = 54 (or 86)
EthernetContainer::EthernetContainerConfiguration::mplsPayloadType = notApplicable (or Layer3OrEoMPLS )
Content of the Mantis Bug Tracker:
|Description||Some device have different way (with different detail) to configure the header compression feature. The proposal is to make as easy as possible the configuration.|
A potential solution might be to provide only an enable and allow the device to choose the optimal configuration.
An operational state may report the information on how the compression is working, for example in optimal configuration or not (e.g.:. because a different reconfiguration from an other management interface).