Header Compression over Unidirectional Lightweight Encryption (ULE)

draft-byun-ipdvb-ule-header-comp

Do J. ByunJohn BorderRoderick Ragland

2

I-D Problem/Background

Multi-Protocol Encapsulation (MPE) over DVB-S and DVB-S2 networks is not flexible enough to carry new payload formats such as a header-compressed payload. No extra bit in the MPE header is available to indicate whether or not the payload has a compressed header.

– Unidirectional Lightweight Encryption (ULE) does provide sufficient flexibility.

There is currently no EtherType that (generically) indicates the payload is header-compressed. The existing EtherType implies a specific algorithm, TCP/IP Header Compression [RFC1144].

– If reused, might cause some confusion with existing header compression implementations.

3

Objective of the I-D

Propose a generic mechanism to signal receivers that payloads are or are not header-compressed using ULE.

Illustrate how such a mechanism can be used for any standard (e.g. ROHC) or proprietary header compression algorithms.

4

Signaling Method

Pretty simple… The EtherType field of the ULE header is used to indicate the payload is header-compressed or not.

The actual value of the new EtherType will be assigned by IANA.

5

Compression Example

Decompressor Compressor

EtherType = IPv4, Uncompressed Header Payload

EtherType = IPv4, Compression Request

EtherType = IPv4, Compression ACK

EtherType = HC IPv4, Compressed Header Payload

EtherType = HC IPv4, Compressed Header Payload

EtherType = HC IPv4, Compressed Header Payload

EtherType = IPv4, Compression Error

EtherType = IPv4, Uncompressed Header Payload

XSomething

BadHappens

6

Incapable Decompressor Example

IncapableDecompressor Compressor

EtherType = IPv4, Uncompressed Header PayloadWaiting for

CompressionRequest

EtherType = IPv4, Uncompressed Header Payload

EtherType = IPv4, Payload

EtherType = IPv4, Uncompressed Header Payload

EtherType = IPv4, Uncompressed Header Payload

EtherType = IPv4, Uncompressed Header Payload

7

Incompatible Compressor Example

IncompatibleDecompressor

IncompatibleCompressor

EtherType = IPv4, Uncompressed Header Payload

DetectsIncompatible

Decompressor

EtherType = IPv4, Compression Request

EtherType = IPv4, Uncompressed Header Payload

EtherType = IPv4, Uncompressed Header Payload

EtherType = IPv4, Uncompressed Header Payload

EtherType = IPv4, Uncompressed Header Payload

8

I-D Summary

The I-D defines a generic mechanism to indicate that the payload is header-compressed by utilizing ULE over IP-DVB networks.

The proposed mechanism is generic enough that it can be used for any standard (e.g. ROHC) or proprietary header compression algorithms.

The proposed mechanism assumes that compressors and decompressors are synchronized by an out-of-band mechanism.

9

I-D Open Issues/Discussion

The I-D currently (unnecessarily) excludes multicast and broadcast support. The proposed signaling mechanism can also be used for multicast and broadcast header compression if the compressors and decompressors are synchronized by an out-of-band mechanism.

The I-D currently assumes IPv4 and needs to be updated to discuss IPv4 and IPv6.

10

Other Discussion Topics

The I-D assumes an out-of-band mechanism for synchronizing compressors and decompressors. Is there a need to define a ULE specific signaling path to be used to do this?– Our initial thoughts are that this communication will be IP ba

sed and, therefore, there is no need to define anything ULE specific.

Do we need/want an I-D which specifically discusses the use of ROHC over ULE?– Yes, but are experts available to help write it?