Internet Engineering Task Force Bernhard Collini-Nocker Internet Draft Hilmar Linder Document: draft-collini-ipdvb-xule-00.txt University of Salzburg Gorry Fairhurst University of Aberdeen Category: Internet Draft May 2004 Ultra Lightweight Encapsulation (ULE) Extension Header Status of this Draft This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes an extension format for the Ultra-Lightweight Encapsulation (ULE) protocol. The proposed method allows ULE to carry both optional (with an explicit extension length) and mandatory (with an implicit extension length) header information to assist in network/Receiver processing of a SNDU. These functions modify the behaviour of ULE, and introduce header processing operations that will simplify the addition of new headers. This Internet Draft is presented as a separate document to allow ipdvb working group discussion of the design trade-offs involved. If accepted, the techniques will be incorporated within a future revision of ULE. Expires November 2004 [page 1] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 [RFC EDITOR NOTE - This section must be deleted prior to publication] DOCUMENT HISTORY This draft is intended as a study item for the IETF ipdvb WG. Comments relating to this document will be gratefully received by the author(s) and the ipdvb mailing list at: ipdvb@erg.abdn.ac.uk Draft -00 -0a based on discussions with B C-N, GF, HL and ipdvb WG list. -0b corrections to text. Change in allocation proposal. -0c amendments to encryption header - addition of encryption block -0d GF addition based on discussions with AR and WS -0e GF length field correct - and text returned to B-CN -0f/g proofreading and preparation of ID -0h, 0i, 0j, 0k edit to ID -00. [END of RFC EDITOR NOTE] Expires November 2004 [page 2] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 Table of Contents 1. Introduction 2. Extension Headers 2.1 Mandatory Extension Headers 2.1 Optional Extension Headers 3. Summary 4. Acknowledgments 5. Security Considerations 6. References 6.1 Normative References 6.2 Informative References 7. Authors' Addresses 8. IANA Considerations 8.1 IANA Guidelines Annexe A. Examples of use Expires November 2004 [page 3] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 1. Introduction This document describes an extension format for the ULE [ULE] encapsulation for transport of IP datagrams or other network layer packets over ISO MPEG-2 Transport Streams [ISO-MPEG]. The terminology used is defined in [ULE]. 2. Extension Headers PDUs in ULE [ULE] are encapsulated to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The encapsulation format to be used for PDUs (IP packets and bridged Ethernet frames) is illustrated below (in these examples, for simplicity we assume D=1, if D=0, a NPA destination address is inserted directly after the Type field of the base header if D=1, or the NPA address if D=0: <-------------------------- SNDU --------------------------> +---+---------------------------------------------------+--------+ |D=0| Length | Type | PDU | CRC-32 | +---+---------------------------------------------------+--------+ <- ULE base header -> Figure 1: SNDU Encapsulation, with no Extension Header In ULE, the Type field is assigned an IANA assigned value. All values above 1535 (decimal) follow the IEEE/DIX type assignments for Ethernet. Values less than 1536 (decimal) indicate a next-layer-header and are assigned from a separate IANA registry for ULE. The general format for these next-layer-header fields value is: <-------------------------- SNDU --------------------------> +---+--------------------------------------------------+--------+ |D=0| Length | H1 | T1 | ...| Hn | Tn | Type | PDU | CRC-32 | +---+--------------------------------------------------+--------+ <- ULE base header -> Figure 2: SNDU Encapsulation, with n Extension Headers Where: D is the ULE D_bit. T1 is the base header Type field. In this case, it specifies a next- layer-header value. H1 is a set of fields defined for header type T1. There may be 0 or more bytes of header information in a specific ULE extension. T2 is the Type field of the next header, or an EtherType > 1535 B indicating the type of the PDU being carried. Expires November 2004 [page 4] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 <-------------------------- SNDU ----------------------------> +---+---------------------------------------------------+--------+ |D=0| Length | H1 | T1 | T2 | H2 | Type | PDU | CRC-32 | +---+---------------------------------------------------+--------+ <- ULE base header -> Figure 3: SNDU Encapsulation, with two Extension Headers The above figure shows a SNDU that includes two extension headers. The Type values of T1 and T2 are both less than 1536 (decimal) indicating the presence of a next-layer-header rather than a directly following PDU. Using this method several headers may be chained in series. The 16-bit ULE next-layer-header field is used in place of the Type value. It is organised as a 5-bit zero prefix, a 3-bit H-LEN field and an 8-bit H-Type field, as follows: +----+-----+--------+ |0000|H-LEN| H-TYPE | +----+-----+--------+ Figure 4: Structure of ULE Type field. H-LEN Assignment 0 Indicates a Mandatory Extension Header 1 Indicates an Optional Extension Header of length 2B 2 Indicates an Optional Extension Header of length 4B 3 Indicates an Optional Extension Header of length 6B 4 Indicates an Optional Extension Header of length 8B 5 RESERVED for future use. >=6 the combined H-LEN and H-TYPE values indicate the Ethertype of a PDU that directly follows this Type field. A H-LEN of zero indicates a Mandatory Extension Header. Each specific Mandatory Extension header has a pre-defined length, that is not communicated in the H-LEN field. No additional limit is placed on the maximum length of a Mandatory Extension Header. 2.1 Mandatory Extension Headers The term Mandatory refers to the processing action required to forward a PDU and not to a requirement to implement an specific option. That is, Receivers are NOT required to implement all types of Mandatory Extension Headers, but MUST process these headers according to the following rules: A Receiver that receives a ULE SNDU with a next-layer-header value indicating a Mandatory Extension Header (i.e. a value less than 255 decimal) has two processing options: Expires November 2004 [page 5] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 (i) It MAY process the header, and continue processing the remainder of the SNDU. (ii) If it does not recognise the next-layer-header value, or is configured to reject the next-layer-header it MUST discard the remainder of the SNDU and commence processing with the next SNDU. Since the Receiver will suspend processing of a SNDU in case 2, there is no need for an explicit header length field to indicate the length of a mandatory extension. The following mandatory next-layer-header types are defined in the ULE specification: 0x0000: Test SNDU, discarded by the Receiver 0x0001: Bridged Ethernet Frame 0x0002: Mandatory Odd Encryption Header (see section A.1) 0x0003: Mandatory Even Encryption Header (see section A.1) The format of additional Mandatory Extension Headers will be specified in documents separate to the ULE base header, and these must specify the format and length of the specific extension header. 2.2 Optional Extension Headers A next-layer-header value greater than or equal to 512 decimal (0x0100, hexadecimal) and less than 1536 decimal (0x600, hexadecimal), indicates an Optional Extension Header. When a Receiver encounters a next-layer-header indicating an Optional Extension Headers, it MAY be configured to either: (i) Process the Optional Extension Header. This requires the Receiver to parse the bytes contained in this extension header. After parsing the extension header, the Receiver MAY decide to modify the processing of the remaining bytes within the SNDU. (ii) Ignore the Optional Extension Header. The Receiver MUST skip the number of bytes corresponding to the Extension header length (H-LEN), before reading the Type value that follows the extension header. The chosen processing depends upon the set of implemented Optional Extension Headers and the Receiver configuration. The length of each Optional Extension Header (in 2-byte words, including the extension payload type that follows each header) is implicit in the high-order byte of the extension type. This header length, is known as the H- LEN value. All Receivers MUST validate the H-LEN value, if this value would cause the total header length to exceed the SNDU Length, the Receiver MUST discard the SNDU. The Receiver SHOULD record an illegal extension length error. Expires November 2004 [page 6] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 The following optional next-layer-header types are defined in the ULE specification: 0x0100: Null Option, this header MUST be skipped by the Receiver. The format of other extension header fields will be specified in an IETF document. 3. Summary This document defines an extension header format for the Ultra Lightweight Encapsulation (ULE) to perform efficient and flexible support for including mandatory and optional SNDU headers. This document takes several design decisions that need to be considered by the ipdvb working group: First, it assumes the need for both optional and Mandatory Extension Headers. The authors suggest this is an important protocol component, since once this function is added, it allows future extension of the protocol, while providing backwards capability with existing protocol releases. In particular, Optional Extension Headers MAY be safely ignored by drivers that do not implement them, or choose not to process them. Second, it assumes that headers may be specified using the Type registry, although in IPv6 a separate registry is used for this purpose. The rationale for this decision is that it is not expected that packets will carry a large number of consecutive extension headers. The use of a single type space simplifies processing and saves assignment and the need to maintain multiple IANA registries. The cost is that a 2 byte value is used, with a small increase in both overhead and processing cost. Third, it assumes that the presence of extension headers can be indicated using the Type field of the base header, rather than by allocating bits within the header to indicate whether extensions are present. This is justified, on the basis of simplified processing and that it maintains a simple lightweight header for the common case when no extensions are present. Fourth, based on discussions within the ipdvb WG, the high-order byte of the Type 1 header is used to indicate the Length (H-LEN) of the extension header. This saves establishing a separate field for this purpose. This reduces the available code-points for Types, but still leaves adequate space for all envisaged extensions. Expires November 2004 [page 7] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 4. Acknowledgments The authors wish to thank the members of the ipdvb mailing list for the input provided. Particular thanks to Hilmar Linder, who helped structure the arguments and basic syntax, to Alain Ritoux and William Stanislaus for their suggestions and many improvements to the design. 5. Security Considerations The security issues for this document are the same as those for ULE itself. Security issues are not addressed in this document. 6. References 6.1 Normative References [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic coding of moving pictures and associated audio information: Systems", International Standards Organisation (ISO). [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ULE] Fairhurst, G., Collini-Nocker, "Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks", , IETF Work in Progress. 6.2 Informative References 7.Authors' Addresses Bernhard Collini-Nocker Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria Email: bnocker@cosy.sbg.ac.at Web: http://www.cosy.sbg.ac.at/sc/ Hilmar Linder Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria Expires November 2004 [page 8] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 Email: hlinder@cosy.sbg.ac.at Web: http://www.cosy.sbg.ac.at/sc/ Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK Email: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 8. IANA Considerations As in ULE, this document will require IANA involvement: The payload type field defined in this document must be aligned with an existing IANA registry or the following values need to be assigned by the IANA: ULE Type Field 8.1 IANA Guidelines The following contains the IANA guidelines for management of the ULE Next-Protocol-Header registry. This registry allocates values decimal 0-1535 (0x0000-0x05FF, hexadecimal). It MUST NOT allocate values greater than 1535 Expires November 2004 [page 9] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 (decimal), since such values overlap the assignments made in the IANA Ethertypes registry. It subdivides the Next-Layer-Header registry in the following way: 1) 0-255 (decimal) IANA assigned values indicating Mandatory extension headers (or link-dependent type fields) for ULE, requiring prior issue of an IETF standards-track RFC. 2) 256-511 (decimal) IANA assigned values indicating Optional extension headers for ULE with no additional extension data, requiring prior issue of an IETF standards-track RFC. 3) 512-767 (decimal) IANA assigned values indicating Optional extension headers for ULE with 2 bytes of extension data, requiring prior issue of an IETF standards-track RFC. 4) 768-1023 (decimal) IANA assigned values indicating Optional extension headers for ULE with 4 bytes of extension data, requiring prior issue of an IETF standards-track RFC. 5) 1024-1535 (decimal) IANA assigned values indicating Optional Extension Headers for ULE with 6 bytes of extension data, requiring prior issue of an IETF standards-track RFC. Note in this format of assignment, the first byte also serves as a count of the number of optional 2-byte words. XXX Author Note: Should the category 5 indicate 6 bytes? -- Or should we RESERVE this for future use??? XXX Author Note: Do we need an uncoordinated category? - In which case should we, e.g., assign the highest value of each length for private use? XXX Expires November 2004 [page 10] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 Annexe A: Illustrative Examples [RFC Ed note] This annexe to be removed. The following examples are hypothetical, and it is not the purpose of this appendix to define these new extensions. Such extensions may be defined by other documents or within a future revision of this ID. The examples are included here only to illustrate how such extensions may be defined, and are provided for discussion by the IETF ipdvb working group. A.1 Encryption Extension Header A and B The Encryption Extension header format is an example of a Mandatory Extension Header. This extension format defines two styles of extension headers (functionally equivalent to the encryption control behaviour of DSM-CC/MPE). PDUs that are not encrypted, do NOT include this header. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 | Length (2B) | Type = 0x00YY | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | = = | (Link encryption control block) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | EtherType (2B) | | +--+--+--+--+--+--+--+--+ | = = | (PDU or Extension Header) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + ULE CRC-32 (4B) + | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure A1: SNDU Format for the Encryption Header. This encryption header has a type value with one of two IANA- assigned 16-bit next-layer-header values. [IANA ACTION] IANA action is required to assign two successive code points from ULE Next-Layer-Header in the range 0x0000 -0x00FF. 00YY General Encryption Extension A Expires November 2004 [page 11] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 This indicates encryption using an even encryption key. 00YY General Encryption Extension B. This indicates encryption using an odd encryption key [END of IANA ACTION] The usage of the encryption header resembles that specified for MPE encryption. The specification of encryption algorithms and key management protocols is beyond the scope of this Document. Note that the encryption header is mandatory, that is a Receiver MUST process this header, before it processes the next header, or enclosed PDU. Similar processing is also performed for SNDUs with D=0. (Note in this case, the NPA value is not encrypted). A.1.1 IPv4-specific Encryption Extension Header The IPv4 Encryption Extension Header is an example of a Mandatory Extension Header, it is a specific variant of the header described in A.1. This header is only appropriate to PDUs that are IPv4, the general Encryption Extension header MUST be used for all other types of PDU, and MAY be used for IPv4: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 | Length (2B) | Type = 0x00WW | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | = = | (Link encryption control block) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | = = | (PDU - IPv4) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + ULE CRC-32 (4B) + | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure A2: SNDU Format for the Encryption Header. PDUs that are not encrypted, do NOT include this header. An encryption header has a type value with one of two IANA-assigned 16- bit next-layer-header values. Expires November 2004 [page 12] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 [IANA ACTION] IANA action is required to assign two successive code points from ULE Next-Layer-Header in the range 0x0000 -0x00FF. 00WW IPv4-specific Encryption Extension A This indicates encryption using an even encryption key. 00WW IPv4-specific Encryption Extension Header B. This indicates encryption using an odd encryption key [END of IANA ACTION] The usage of the encryption header resembles that specified for MPE encryption. The specification of encryption algorithms and key management protocols is beyond the scope of this Document. Note that the encryption header is mandatory, that is a Receiver MUST process this header, before it processes the enclosed PDU. Similar processing is also performed for SNDUs with D=0. XXX Similar header could/should/must also be defined for IPv6 and possibly for bridging - although all other protocols such as arp MUST use the generic headers XXX Expires November 2004 [page 13] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB September 2003 A.2 ULE Bridged Ethernet Frame The following ULE Bridged Ethernet Frame is an example of a Mandatory Extension Header: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 | Length (2B) | Type = 0x0001 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | MAC Destination Address (6B) | + +--+--+--+--+--+--+--+--+ | | | +--+--+--+--+--+--+--+--+ + | MAC Source Address (6B) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | EtherType (2B) | | +--+--+--+--+--+--+--+--+ | = = | (Contents of bridged MAC frame) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + ULE CRC-32 (4B) + | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure A3: SNDU Format for a Bridged Payload [IANA ACTION] IANA action is required to assign two successive code points from ULE Next-Layer-Header in the range 0x0000 -0x00FF. 0001 Bridged Ethernet Frame [END of IANA ACTION] Note that the final two bytes of the bridging header also have a Type field. This is true of all ULE extension headers, but in this special case the mandatory header format permits this to carry a LLC Length field, specified by IEEE 802. Normally this will be an IANA assigned value. Similar processing is also performed for SNDUs with D=0. [END of RFC Ed note to remove annexe ] Expires November 2004 [page 14]