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).
Just enabling the header compression and leaving it to the algorithm to search for optimal configuration ist already supported. Comment of the EthernetContainerConfiguration::packetCompressionIsOn attribute says: "In case packet compression is activated, but no type is activated, it is assumed that the device chooses the optimum."
A status value just saying the device is/not working in optimal configuration seems being insufficient.
level 1: layer2
level 2: layer2 + VLAN + QinQ
level 3: layer2 + VLAN + QinQ + MPLS + IPV4
level 4: layer2 + VLAN + QinQ + MPLS + IPV4 / IPV6 + Layer4
Looking at the problem from another point of view, for example, the four levels could also be mapped as:
level 1: compress all headers in the first 16 bytes of packet
level 2: compress all headers in the first 32 bytes of packet
level 3: compress all headers in the first 64 bytes of packet
level 4: compress all headers in the first 128 bytes of packet
The four levels would be more generic, so you can map multiple implementations and in the future you will not need to make any changes to the model if you need to add more headers to compres (for example, PBB / mac-in-mac, RTP, GTP-U and so on) .
The state of the optimization would no longer be necessary as it would coincide with the configured level.
MPLS payload compression requires some consideration. As mentioned in RFC-4448 (chapter 4.6 The Control Word), the MPLS or PW traffic payload is not easily recognizable. As with ECMP implementations (Equal-cost multi-path routing) the compressor should examine the first payload nibble to understand its type. If it finds 0x4 or 0x6 the payload should be of type IPv4 or IPv6, if it finds 0x0 it should be the Control Word (CW) of a PW. The CW is added to solve the packets misordering problem. Since the CW is oprional and autonegotiated, even PW traffic may not have it and therefore we would confuse EoMPLS packets (inside the PW) whose destination MACs start with 0x4 or 0x6. Therefore a configuration parameter is needed to help the header compressor to recognize the payload transported by MPLS / PW. By default, it could take IPv4 / IPv6 traffic in the absence of CW and EoMPLS in the presence of CW. The possibility of having IPv4 / IPv6 traffic with and without CW and EoMPLS without CW should also be configurable.
- an object for each supported level that describe the behavior of the header compressor (capability).
- a state that reports if header compression is up and running (status).