INTERNET-DRAFT Do J. Byun October 16, 2006 John Border Category: Experimental Roderick Ragland Expiration: March 19, 2007 Header Compression over Unidirectional Lightweight Encryption (ULE) draft-byun-ipdvb-ule-header-comp-00.txt Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Intellectual Property Right By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Multi-Protocol Encapsulation (MPE) is widely deployed in DVB-S and DVB-S2 networks [DVB-S2]. Replacing MPE with Unidirectional Lightweight Encryption (ULE) has been proposed to gain flexibility and reduce overhead. This paper introduces a signaling method for sending header-compressed unicast packets over satellite networks using ULE, taking advantage of ULE's increased flexibility. Ed. Note: This is a quick first draft to get the discussion going. Byun, Border and Ragland Experimental [Page 1]
Header Compression over ULE October 2006 Table of Contents 1. Introduction ...................................................1 2. Terminology ....................................................1 3. Signaling Method ...............................................3 3.1. SNDU Format ...............................................3 3.2. Header Compression Algorithm ..............................4 3.3. Multicast and Broadcast Traffic ...........................5 4. Summary ........................................................5 5. Acknowledgements ...............................................6 6. Security Considerations ........................................6 7. IANA Considerations ............................................6 8. References .....................................................6 1. Introduction Header compression is a mechanism that compresses the header fields that do not change or change in predictable ways. RFC 3095 defines "Robust Header Compression (ROHC)" as a standard for compressing RTP/UDP/IP, UDP/IP and ESP/IP headers. [RFC3095]. There could be other proprietary compression schemes besides ROHC. To support header compression, the link-layer has to be flexible enough to indicate whether the payload is header-compressed or not. Such indication has been difficult with MPE due to its limited flexibility in its header format. Unidirectional Lightweight Encryption has been proposed to overcome this shortcoming of MPE and there had been numerous proposals to standardize one as the link-layer protocol of DVB-S2 [GSE]. This document describes how ULE is used to support header compression over ISO MPEG-2 transport streams [ISO-MPEG2, RFC4259] for peer-to-peer traffic. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. DVB Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2]. MAC Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). Byun, Border and Ragland Experimental [Page 2]
Header Compression over ULE October 2006 MPE Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. A scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel. MPEG-2 A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]). PSI Program Specific Information [ISO-MPEG2]. Tables used to convey information about the service carried in a TS Multiplex. The information is carried in one of four specifically identified Table Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table. PDU Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. Receiver Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer). SI Table Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections; however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2]. SNDU SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit. TS Transport stream (TS) is a format specified in MPEG-2 Part 1, Systems (ISO/IEC standard 13818-1). Its design goal is to allow multiplexing of digital video and audio and to synchronize the output. Transport stream offers features for error correction for transportation over unreliable media, and is used in broadcast applications such as DVB and ATSC. ULE Stream An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2]. Byun, Border and Ragland Experimental [Page 3]
Header Compression over ULE October 2006 3. Signaling Method Header compression shall be indicated by the EtherType field of the ULE header. i.e.) When this this field is set to header compression type, the payload is header-compressed. The actual type of header compression is determined during the context establishment between two peers (one compressor and one decompressor). Therefore, the method by which the payload is compressed and decompressed is part of the compression context. Moreover, compression context control messages can also be header-compressed but their context will be different from the one for the actual user data. Decompressor Compressor | | | <----- (EtherType=IPv4) Uncompressed payload ------ | | ------ (EtherType=IPv4) Compression Request -----> | | <----- (EtherType=IPv4) Compression Ack ------ | | <----- (EtherType=Comp) Compressed payload ------ | | <----- (EtherType=Comp) Compressed payload ------ | | <----- (EtherType=Comp) Compressed payload ------ | | ------ (EtherType=IPv4) Compression Error -----> | | <----- (EtherType=IPv4) Uncompressed payload ------ | | <----- (EtherType=IPv4) Uncompressed payload ------ | Figure 1: Header compression example Figure 1 illustrates an example where control messages (that signal and synchronize peers to compress/decompress) are not header-compressed but the user data messages are. When EtherType is set to 'Comp' whose hex value is TBD, the MPEG-2 payload contains header-compressed user data messages. The EtherType of TBD will be a newly registered IANA EtherType number that indicates a compression algorithm that is agreed by both the sender and receiver. In other words, it could any proprietary header compression algorithm as long as the receiver knows how to decompress it. EtherType of 0x876B (TCP/IP Compression [RFC1144]) was intentionally not used because it is currently defined to imply a specific header-compression algorithm. 3.1. SNDU Format This section describes the SNDU format of MPEG-2 PDU with ULE where headers for PDU are compressed. < ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | Type | Dest Address* | PDU | CRC-32 | +-+-------------------------------------------------------+--------+ Figure 2: SNDU Encapsulation (* optional Destination Address) Byun, Border and Ragland Experimental [Page 4]
Header Compression over ULE October 2006 Definition of all the fields in Figure 2 stays the same as the definition in [RFC4326]. The 16-bit type field will have a new EtherType to indicate the PDU is header-compressed with an algorithm that both sender and received agreed on. The hex value for this type is TBD. Note that the new header-compressed PDU EtherType does not indicate a specific header-compression algorithm. It is the sender and receiver's responsibility to make sure the algorithm is synchronized. Ed. Note: This is one of the main points we want to discuss on the mailing list. 3.2. Header Compression Algorithm In order to use the proposed EtherType to indicate the PDU is header-compressed, both the send and receiver have to agree with the compression algorithm. This is not an issue because such synchronization is always required in peer-to-peer header compression anyway. Incapable Incompatible Decompressor Compressor | | | <----- (EtherType=IPv4) Uncompressed payload ------ | | Waiting for | Comp Request | <----- (EtherType=IPv4) Uncompressed payload ------ | | Waiting for | Comp Request | <----- (EtherType=IPv4) Uncompressed payload ------ | | Waiting for | Comp Request | | Figure 3: Incapable decompressor Figure 3 illustrates a scenario where the decompressor (receiver) is not capable of decompressing the packets that the compressor (sender) sent. The decompressor does not send any compression request to the compressor and the compressor continues to send uncompressed headers to the decompressor with non-header-compression EtherType. Byun, Border and Ragland Experimental [Page 5]
Header Compression over ULE October 2006 Incompatible Incompatible Decompressor Compressor | | | <----- (EtherType=IPv4) Uncompressed payload ------ | | ------ (EtherType=IPv4) Compression Request -----> | | detects | incompatible | decompressor | <----- (EtherType=IPv4) Uncompressed payload ------ | | <----- (EtherType=IPv4) Uncompressed payload ------ | | <----- (EtherType=IPv4) Uncompressed payload ------ | | | Figure 4: Incompatible compressor and decompressor Figure 4 illustrates a scenario where the compressor is not compatible with the decompressor and therefore it continues to send uncompressed headers to the decompressor with non-header-compression EtherType. Specifics of a header compression algorithm may differ widely. They include the way header-compression is initiated and synchronized. For example, compression request messages can be initiated by the compressor instead of decompressor. Regardless of the algorithm, the header-compression indication method proposed here signals the decompressor that the payload is header-compressed with the algorithm that it agreed to use. 3.3. Multicast and Broadcast Traffic The proposed header-compressed PDU signaling scheme will not support multicast or broadcast traffic. 4. Summary This document defines a mechanism to signal the receiver that the payload is header-compressed using ULE as the link layer. The mechansim is compatible with any peer-to-peer header compression algorithms. It uses a newly proposed EtherType to indicate the payload is header-compressed. The EtherType has the value of TBD which is not tied to a specific header compression algorithm. The proposed method to indicate header-compressed payload is not for multicast and broadcast as there is no gaurantee that the receivers are compatible decompressors. Byun, Border and Ragland Experimental [Page 6]
Header Compression over ULE October 2006 5. Acknowledgements TBD 6. Security Considerations The proposed header compression signaling method does not introduce any additional security concerns. 7. IANA Considerations A new EtherType number will be proposed to the IANA EtherType registry. This number will be used to indicate ULE PDU is header-compressed as described in this document. 8. References: 8.1. Normative References [ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organization (ISO), 2000. [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", 1990. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, 1997. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., et al, "Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 2001. [RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, 2005. [DVB-S2] Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications, ETSI EN 302 307 V1.1.1, 2005. 8.2. Informative References [GSE] Fairhurst, G., "A Network-Layer Interface To The Second Generation Standard For DVB Over Satellite", Work in Progress, September 2006. Byun, Border and Ragland Experimental [Page 7]
Header Compression over ULE October 2006 [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification" Version 2.0, November 1982. [ITU-H222] H.222.0, "Information technology - Generic coding of moving pictures and associated audio information: Systems", International Telecommunication Union, (ITU-T), 1995. Authors' Addresses Do J. Byun Hughes Network Systems 11717 Exploration Lane Germantown, MD, 20876 USA EMail: dbyun@hns.com John Border Hughes Network Systems 11717 Exploration Lane Germantown, MD, 20876 USA EMail: border@hns.com Roderick Ragland Hughes Network Systems 11717 Exploration Lane Germantown, MD, 20876 USA EMail: rragland@hns.com Comments are solicited and should be addressed to the authors. Byun, Border and Ragland Experimental [Page 8]
Header Compression over ULE October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.