Ethernet compression on Radio Link

[DanielaSpreafico]

The need is to enable and define the compression of the Ethernet Header data on top of a Radio Link. A new attribute could be added to RLT interface: -- rw header-compression-mode

[jrebiffe]

Modelisation of header compression in YANG make sense.

On our 3 layers (virtEth, RTL, CT), I wonder what the appropriate level: RTL or virtEth. Even if I acknowledge that the is no microwave interoperability (Both endpoints of a Microwave are always same brand) and hence implementation donot have to follow a standardized header compression. But maybe it is a features which belong to our virtEth layer. To which layer should it belong?

Other technologies also have header compression features: RObust Header Compression (ROHC) is an effort to share that. Since RFC5795 abstract says "It is designed to operate efficiently and robustly over various link technologies with different characteristics." and in introduction "For many types of networks, reducing the deployment and operational costs by improving the usage of the bandwidth resources is of vital importance.": I don't know what are these link technology (RFC just mentions "wireless" but doesnot describe it, Several pages later briefly mentions "PPP" in parenthesis). On these link technologies, where do header compression apply: RTL-like or vrtEth? Is there a YANG module sharable with these technologies?

[DanielaSpreafico]

I think the RFC5795 defines/suggests how to 'compress' data on a link basis on a node. This is in order to not lose information on compressing/decompressing and to share a common algorithm in a link. This RFC doesn't define a management of the compression , so no yang module is shared. On Radio MW link where the end points are of the same vendor there is no need to have a common algorithm. We need in any case to discuss the correct layer : vEth or RLT

[samans]

Instead of boolean, one option is to use an IdentityRef. We define the base in the radio-link module, and allow/describe how to add identityrefs for the vendor specific compress algorithms.

[samans]

Need to provide the options for modeling. Some implementations have multiple compression options per interface.

How to identify that the node has the ability to support compression?

[samans]

Please provide suggested yang for compression modes for RLT/CT for discussion.

[niloda]

I added parameters (for RLT) in the yang file to handle header compression, just as an example to start the discussion.

A boolean attribute has been added just to activate/deactivate the functionality.

+--rw header-compression-enabled? boolean

For devices that require more complex configuration, I added a list of profiles, each composed of a list of protocol headers to compress or composed of the size of the area at the beginning of the packet where all included headers are compressed.

    +--ro header-compression-profile-list* [header-compression-profile-name] {hc-profile}?
    |  +--ro header-compression-profile-name         string
    |  +--ro (header-compression)?
    |     +--:(protocol-based)
    |     |  +--ro compressed-protocol-layer-list*   mw-types:protocol-layer
    |     |  +--ro mpls-payload-kind-list*           mw-types:mpls-payload
    |     +--:(header-length-based)
    |        +--ro compressed-header-length?         int16

A configuration attribute selects the profile to use.

+--rw header-compression-profile? -> ../header-compression-profile-list/header-compression-profile-name {hc-profile}?

(not sure if the path is correct)

A feature hc-profile has been added to include or exclude the header compression profile support.

  feature hc-profile {
    description
      "Indicates that the device supports Header Compression profiles.";
  }

The added code is wrapped inside a couple of markers:

/* HC - begin */
   <added code>
/* HC - end */

rfc8651-bis-yang-header-compression.zip