Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • #38: Header compression
Skip to end of metadata
Go to start of metadata
StatusEXECUTED
Stakeholders
Outcome
Due date2018/07/31
OwnerDanilo Pala 

Decision

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.

Background

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:

  • layer2
  • vlan
  • QinQ
  • mpls
  • layer3   (IPv4 / IPv6)
  • layer4
  • everything (takes in account also further headers like RTP, GTP and so on)

2. Defining a type TypeDefinitions::CompressionProfileType thats groups the following attributes:

  • maxHeaderCompressed of TypeDefinitions::CompressionHeaderType data type
  • maxNumberOfBytesCompressed of 'Integer' data type

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:

  • Layer3OrEoMPLS (automatic selection between IPv4 / IPv6 - if Control Word is not present - or EoMPLS)
  • EoMpls (Without Control Word)
  • Layer3  (IPv4/IPv6 regardless the ControWord)
  • notApplicable    

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.

 

Example:

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

EthernetContainer::EthernetContainerCapability::compressionProfileList :

maxHeaderCompressed [1] = QinQ

maxNumberOfBytesCompressed [1] = 14+10x4 = 54

maxHeaderCompressed [2] = layer4

maxNumberOfBytesCompressed [2] = 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:

DescriptionSome 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).

2 Comments

  1. Thorsten Heinze

    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.

  2. Danilo Pala

    To cover as many implementations as possible, we shouldn't chose a set of parameters that impose a specific hardware configurability ant therefore a specific hardware implementation, but rather we should choose a set of parameters that allow each vendor to declare how its header compressor works.
     
    By the way, optimization levels could be more than one. The device should declare as capability what it is able to compress in each level. Perhaps a human readeable description of what is compressed in each level could be sufficient. For example, by defining 4 optimization level you could map the following compressions:

    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.
    Instead, an object that shows if the header compressor is up and running could be added.

    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.
      
    In summary, it would be necessary:
     
    - an object to select a compression level (configuration)
    - an object that specifies the MPLS payload (configuration)
    - 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).