1 / 10

Do J. Byun John Border Roderick Ragland

Header Compression over Unidirectional Lightweight Encryption (ULE) draft-byun-ipdvb-ule-header-comp. Do J. Byun John Border Roderick Ragland. I-D Problem/Background.

eddien
Télécharger la présentation

Do J. Byun John Border Roderick Ragland

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Header Compression over Unidirectional Lightweight Encryption (ULE)draft-byun-ipdvb-ule-header-comp Do J. Byun John Border Roderick 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

  6. Incapable Decompressor Example

  7. Incompatible Compressor Example

  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 based 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?

More Related