Internet Engineering Task Force G. Fairhurst Internet-Draft University of Aberdeen Intended status: Proposed Standard B. Collini-Nocker Expires: April 2007 University of Salzburg November 05, 2007 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) draft-ietf-ipdvb-ule-ext-06.txt Status of this Draft 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 This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC4326. The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) defined to support the second generation framing structure defined by Digital Video Broadcasting (DVB) family of specifications. Fairhurst Expires February 2008 [Page 1] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 Table of Contents 1. Introduction 2. Conventions used in this document 3. Description of method 3.1 MPEG-2 TS-Concat Extension 3.2 PDU-Concat Extension 3.3 TimeStamp Extension 4. IANA Considerations 5. Acknowledgements 6. Security Considerations 7. References 7.1 Normative References 7.2 Informative References Authors' Addresses Appendix: The Second Generation DVB Transmission Specifications Fairhurst Expires April 2008 [Page 2] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 1. Introduction This document describes three Header Extensions that may be used with both Unidirectional Lightweight Encapsulation, ULE, [RFC4326] and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links that employ the MPEG-2 Transport Stream, and supports a wide variety of physical-layer bearers [RFC4259]. GSE has been designed for the Generic Mode (also known as the Generic Stream (GS)), offered by second-generation DVB physical layers, and in the first instance for DVB-S2 [ETSI-S2]. The requirements for the Generic Stream are described in [ID-S2-REQ]. The important characteristics of this encapsulation are described in an Appendix to this document. GSE maintains a design philosophy that presents a common network interface to that of ULE and uses a similar construction for SubNetwork Data Unit (SNDUs). The first Extension Header defines a method that allows one or more TS-Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may be used to provide control plane information including the transmission of MPEG-2 Program Specific Information (PSI) for the Multiplex. In GSE, there is no native support for transport stream packets and this method is therefore suitable for providing an MPEG- 2 control plane. A second Extension Header allows one or more PDUs to be sent within the same ULE SNDU. This method is designed for cases where a large number of small PDUs are directed to the same Network Point of Attachment (NPA) address. The method may improve transmission efficiency (by removing duplicated MAC layer overhead). It can also reduce processing overhead for receivers that are not addressed by the NPA, since these receivers may then skip several PDUs in one operation. The method is defined as a generic Extension Header and may be used for IPv4 or IPv6 packets. If, and when, a compression format is defined for ULE or Ethernet, the method may also be used in combination with this method. A third Extension Header provides an optional timestamp value for an SNDU. Examples of the use of this timestamp option include monitoring and benchmarking of ULE and GSE links. Receivers that do not wish to decode (or do not support) the timestamp extension may discard the extension and process the remaining PDU or Extension Headers. An appendix includes a summary of key design issues and considerations relating to the GSE Specification defined by the DVB Technical Module [GSE]. Fairhurst Expires April 2008 [Page 3] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 2. Conventions used in this document 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 [RFC2119]. b: bit. For example, one byte consists of 8b. B: Byte. Groups of bytes are represented in Internet byte order. BBFrame payload: The data field part of a Baseband frame [ETSI-S2] that may be used for the communication of data. Typical BBFrames range in size from 3072 to 58192 bits according to the choice of modulation format and FEC in use. DVB: Digital Video Broadcasting. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data. E: A one-bit flag field defined in GSE [GSE]. Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output in DVB-S or the Generic Mode of DVB-S2 [RFC4259]. GS: Generic Stream. A stream of BBFrames identified by a common Input Stream Identifier, and which does not use the MPEG-2 TS format [ETSI-S2]. It represents layer 2 of the ISO/OSI reference model. GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating PDUs to form a Generic Stream, which is sent using a sequence of BBFrames. This encapsulation format shares the same extension format, and basic processing rules of ULE and uses a common IANA Registry. LT: A two-bit flag field defined in GSE [GSE]. MAC: Medium Access Control [IEEE-802.3]. A link layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2). MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). Next-Header: A Type value indicating an Extension Header [RFC4326]. NPA: Network Point of Attachment [RFC4326]. In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network that is used to identify individual Receivers or groups of Receivers. Fairhurst Expires April 2008 [Page 4] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of each TS Packet. This identifies the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the parts of a Table Section, or other Payload Unit must all carry the same PID value. The all ones PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes. PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. PSI: Program Specific Information [ISO-MPEG2]. S: A one-bit flag field defined in [GSE]. SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried on a DVB Multiplex. SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an encapsulated PDU sent using ULE or GSE. Stream: A logical flow from an Encapsulator to a set of Receivers. TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI reference model. ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A method that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel. The encapsulation defines an extension format and an associated IANA Registry. Fairhurst Expires April 2008 [Page 5] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 3. Description of the Method In ULE, a Type field value that is less than 1536 Decimal indicates an Extension Header. This section describes a set of three extension formats for the ULE encapsulation. [GSE] uses a Type field that adopts the same semantics as specified by RFC 4326. The encapsulation format differs in that GSE does not include a CRC for each SNDU, has different header flags, and utilises a different SNDU length calculation [GSE]. There is a natural ordering of extension headers, which is determined by the fields upon which the extension header operates. A suitable ordering for many applications is presented in the list below (from first to last header within an SNDU). This does not imply that all types of Extensions should be present in a single SNDU. The presented ordering may serve as a guideline for optimisation of Receiver processing. +----------------------------------+-------------------------------+ |Fields related to Extension Header| Example Extension Headers | +----------------------------------+-------------------------------+ | Link framing and transmission | Timestamp Extension | +----------------------------------+-------------------------------+ | Entire remaining SNDU Payload | Encryption Extension | +----------------------------------+-------------------------------+ | Group of encapsulated PDUs | PDU-Concat or TS-Concat | +----------------------------------+-------------------------------+ | Specific encapsulated PDU | IEEE-defined type | | | Test or MAC bridging Extension| +----------------------------------+-------------------------------+ Table 1: Recommended ordering of Extension Headers 3.1 MPEG-2 TS-Concat Extension The MPEG-2 TS-Concat Extension Header is specified by an IANA assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory Next-Header Extension. The extension is used to transport one or more MPEG-2 TS Packets within a ULE SNDU. The number of TS Packets carried in a specific SNDU is determined from the size of the remainder of the payload following the MPEG-2 TS Extension Header. The number of TS Packets contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N is the number of bytes associated with Extension Headers that precede the MPEG-2 TS-Concat Extension (zero if there are none). A Receiver MUST check the validity of the Length value prior to processing the payload. A valid Length corresponds to an integral number of TS Packets. An invalid Length (a remainder from the division by 188) MUST result in the discard of all encapsulated TS Packets and SHOULD be recorded as TS-Concat size mismatch error. Fairhurst Expires April 2008 [Page 6] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Length (15b) | Type = 0x0002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TS-Packet 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 2 (if Length > 2*188) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) Figure 1 illustrates the format of this Extension Header for ULE with a value D=0, which indicates the presence of a NPA address [RFC4326]. In this case, the valid payload Length for a ULE SNDU with no other extensions is (Length-10) / 188. The method used to define the Length in GSE differs to that of ULE. The equivalent case for GSE would result in a payload Length value of (Length-6) / 188 (Figure 2). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|E|0 0| Length (12b) | Type = 0x0002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TS-Packet 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 2 (if Length > 2*188) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00) Fairhurst Expires April 2008 [Page 7] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 Fragmented GSE SNDUs are protected by a CRC-32 carried in the final fragment. After reassembly, this CRC-32 is removed and the resulting SNDU carries a Total Length field. The fields labelled S and E are defined by [GSE] and contain control flags used by the GSE link layer. The Label Type field (LT) specifies the presence and format of the GSE label. The LT field is only specified for the first fragment (or a non-fragmented) GSE SNDU (i.e. when S=1). In ULE, a value of D=1, is also permitted and indicates the absence of a NPA address (Figure 3). A similar format is supported in GSE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Length (15b) | Type = 0x0002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 2 (if Length > 2*188) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) This extension may be used to transport one or more MPEG-2 TS Packets of arbitrary content, interpreted according to [ISO-MPEG2]. One expected use is for the transmission of MPEG-2 SI/PSI signaling [RFC4259]. NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this encapsulation. To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time that it can wait before sending all queued TS Packets. This is known as the TS Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs higher jitter and could increase the probability of corruption. If additional TS Packets are NOT received within the TS Packing Threshold, the Encapsulator MUST immediately send any queued TS Packets. The use of this format to transfer MPEG-2 clock references (e.g. a Network Clock Reference, NCR) over ULE/GSE framing raises timing considerations at the encapsulation gateway, including the need to update/modify the timing information prior to transmission by the physical layer. These issues are not considered here, but this operation may be simplified in GSE by ensuring that all SNDUs that Fairhurst Expires April 2008 [Page 8] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 carry this Extension Header are placed before other data within the BBFrame DataField [GSE]. This document does not specify how TS Packets are to be handled at the Receiver, however it notes that a poorly configured Encapsulator could lead to a Multiplex carrying multiple (possibly conflicting) sets of TS Logical Channels and SI information encapsulated at different levels or with different NPA addresses. The need for consistency in the use of PIDs and the related SI information is described in [RFC4947]. 3.2 PDU-Concat Extension The PDU-Concat Extension Header is specified by an IANA assigned H- Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header Extension. It enables a sequence of (usually short) PDUs to be sent within a single SNDU payload. The base header contains the Length of the entire SNDU. This carries the value of the combined length of all PDUs to be encapsulated, including each set of encapsulation headers. The base header MAY be followed by one or more additional Extension Headers that precede the PDU-Concat Extension Header. These Extension Headers (e.g. a TimeStamp Extension) apply to the composite concatenated PDU. The Extension Header also contains a 16-bit ULE Type field describing the encapsulated PDU, PDU-Concat-Type. Although any Type value specified in the ULE Next-Header Registry (including Extension Header Types) may be assigned to the encapsulated PDU (except the recursive use of a PDU-Concat type), all concatenated PDUs MUST have a common ULE Type (i.e. all concatenated PDUs passed by the network layer must be associated with the same Type value). This simplifies the receiver design, and reduces the transmission overhead for common use cases. Each PDU is prefixed by its length in bytes (shown as PDU-Length in the following diagrams). Encapsulated PDUs are of arbitrary length (in bytes) and are not necessarily aligned to 16-bit or 32-bit boundaries within the SNDU (as shown in the figure). The most significant bit of the first byte is reserved, R, and this specification requires that this MUST be set to zero. Receivers MUST ignore the value of the R bit. The length of each PDU MUST be less than 32758 bytes, but will generally be much smaller. When the SNDU header indicates the presence of an SNDU Destination Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA, field directly follows the fourth byte of the SNDU header. NPA destination addresses are 6 Byte numbers, normally expressed in hexadecimal, used to identify the Receiver(s) in a transmission network that should process a received SNDU. When present, the Receiver MUST associate the same specified MAC/NPA address with all Fairhurst Expires April 2008 [Page 9] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 PDUs within the SNDU Payload. This MAC/NPA address MUST also be forwarded with each PDU, if required by the forwarding interface. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Length (15b) | Type = 0x0003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PDU-Concat-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU-Length-1 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-1 = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU-Length-2 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-2 = | | More PDUs as required +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|E|0 0| Length (12b) | Type = 0x0003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PDU-Concat-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU-Length-1 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-1 = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU-Length-2 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-2 = | | More PDUs as required +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_ Fairhurst Expires April 2008 [Page 10] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 When the SNDU header indicates the absence of an SNDU Destination Address field (i.e. D=1 in ULE) all encapsulated PDUs MUST be processed as if they had been received without an NPA address. The value of D in the ULE header indicates whether a NPA/MAC address is in use [RFC4326]. A similar format is supported in GSE (using the LT field). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Length (15b) | Type = 0x0003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU-Concat-Type |R| PDU-Length-1 (15b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = PDU-1 = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU-Length-2 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-2 = | | More PDUs as required +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time it will wait before sending a Concatenated PDU. This is known as the PDU Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs higher jitter and could increase the probability of corruption. If additional PDUs are NOT received within the PDU Packing Threshold, the Encapsulator MUST immediately send all queued PDUs. The Receiver processes this Extension Header by verifying that it supports the specified PDU-Concat Type (unsupported Types MUST be discarded, but the receiver SHOULD record a PDU-Type error [RFC4326]). It then extracts each encapsulated PDU in turn. The Receiver MUST verify the Length of each PDU. It MUST also ensure that the sum of the Lengths of all processed PDUs equals the Length specified in the SNDU base header. A Receiver SHOULD discard the whole SNDU if the total and PDU sizes are not consistent and this event SHOULD be recorded as a PDU-Concat size mismatch error. A receiver MUST NOT forward a partial PDU with an indicated PDU-Length greater than the number of unprocessed bytes remaining in the SNDU payload field. Fairhurst Expires April 2008 [Page 11] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 3.3 Timestamp Extension The Timestamp Extension Header is an Optional Next-Header Extension that permits an Encapsulator to add a timestamp field to an SNDU. The Timestamp Extension Header is specified by the IANA-assigned H- Type value of 257 decimal. This extension is an Optional Extension Header ([RFC4326], Section 5). This extension is designed to support monitoring and measurement of the performance of a link to indicate the quality of an operational ULE link. This may be useful for GSE links (e.g. where significant complexity exists in the scheduling provided by the lower layers). Possible uses of this extension include: * Validation of in-sequence ordering per Logical Channel, * Measurement of one-way delay (when synchronised with the sender) * Measurement of PDU Jitter introduced by the link, * Measurement of PDU loss (with additional information from sender). Figure 7 shows the format of this extension with a HLEN value of 3 indicating a timestamp of length 4B with a Type field (there is no implied byte-alignment). 0 7 15 23 31 +---------------+---------------+---------------+---------------+ | 0x03 | 0x01 | time stamp HI | +---------------+---------------+---------------+---------------+ | time stamp LO | Type | +---------------+---------------+---------------+---------------+ Figure 7 The format of the 32-bit Timestamp Extension Header The extension carries a 32-bit value (time stamp HI plus time stamp LO). The specified resolution is 1 microsecond. The value therefore indicates the number of 1 microsecond ticks past the hour in Universal Time when the PDU was encapsulated. This value may be earlier than the time of transmission, due for example to Packing, queuing and other Encapsulator processing. The value is right- justified to the 32-bit field. Systems unable to insert timestamps at the specified resolution may use an arbitrary (and varying) value to pad the unused least-significant bits. The last two bytes carry a 16-bit Type field that indicates the type of payload carried in the SNDU, or the presence of a further Next- Header ([RFC4326], Section 4.4). Receivers MAY process the timestamp when the PDU encapsulation is removed. Receivers that do not implement, or do not wish to process, the Timestamp Extension MAY skip this extension header. Receivers MUST continue to process the remainder of the SNDU, forwarding the encapsulated PDU. Fairhurst Expires April 2008 [Page 12] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 4. IANA Considerations This document requires IANA involvement for the assignment of three new Next-Header Type values from the IANA ULE Next-Header Registry. These options are defined for specific use cases envisaged by GSE, but are compatible with ULE. The following assignments have been made in this document, and registered by IANA: Type Name Reference 2: TS-Concat Section 3.1 3: PDU-Concat Section 3.2 Type Name H-LEN Reference 257: Timestamp 3 Section 3.3 The TS-Concat Extension is a Mandatory next-type Extension Header, specified in section 3.1 of this document. The value of this next- header is defined by an IANA assigned H-Type value of 0x0002. The PDU-Concat Extension is a Mandatory next-type Extension Header specified in section 3.2 of this document. The value of this next- header is defined by an IANA assigned H-Type value of 0x0003. The Timestamp Extension is an Optional next-type Extension Header specified in section 3.3 of this document. The value of this next- header is defined by an IANA assigned H-Type value of 257 decimal. This documents defines format for a HLEN value of 0x3. 5. Acknowledgements The author gratefully acknowledges the inputs, comments and assistance offered by the members of the DVB-GBS ad hoc group on DVB-S2 encapsulation, in particular contributions on DVB-S2 transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. Juan Cantillo provided a significant contribution to the informative annexe. The authors thank Christian Praehauser for his insight and contribution on header extension processing issues. Fairhurst Expires April 2008 [Page 13] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 6. Security Considerations This document does not raise new security concerns. Security considerations for ULE are described in [RFC4326] and further information on security aspects of using ULE are described in the security considerations of [RFC4259] and [ID-Sec-Req]. 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997. [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", RFC 4326, December 2005. [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "European Telecommunication Standards Institute (ETSI). 7.2 Informative References [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications", European Telecommunication Standards Institute (ETSI). [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- S2", Internet-Draft , Work in Progress. [ID-Sec-Req] "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Internet-Draft < draft- ietf-ipdvb-sec-req-04.txt>, Work in Progress. [IEEE-802.3] "Local and metropolitan area networks - Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC 8802-3), 2002. [ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Standards Organisation (ISO). Fairhurst Expires April 2008 [Page 14] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2006. [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007. Fairhurst Expires April 2008 [Page 15] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 Authors' Addresses Godred Fairhurst School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE UK Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Bernhard Collini-Nocker Department of Computer Sciences, University of Salzburg, Jakob Haringer Str. 2, 5020 Salzburg, Austria EMail: bnocker@cosy.sbg.ac.at URI: http://www.cosy.sbg.ac.at Fairhurst Expires April 2008 [Page 16] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 Statement 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. Copyright Statement Copyright (C) The IETF Trust (2007). 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. Fairhurst Expires April 2008 [Page 17] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 APPENDIX: The Second Generation DVB Transmission Specifications This section provides informative background to the network-layer requirements of the second generation DVB Transmission Specifications. The second generation waveforms specified by the Digital Video Broadcasting project offer two main enhancements. First, more efficient physical layer methods that employ higher order modulation with stronger FEC and permit adaptive coding and modulation response to changes in traffic and propagation conditions. Second, at the link layer, they offer greater flexibility in framing. Support is provided for a range of stream formats including the classical Transport Stream (TS) [RFC4259]. In addition, a new method called Generic Streams (GS) (or the Generic Mode) is supported. A GS can be packetized or continuous and is intended to provide native transport of other network-layer services. One such method is that provided by the Generic Stream Encapsulation (GSE) [GSE]. For example, the DVB-S2 [ETSI-S2] transmission link sequentially multiplexes a series of baseband frames (BBFrames). Each BBFrame comprises a fixed-size 10B header and a payload. The payload carries a DataField and uses padding to fill any unused space. A stream comprises a sequence of BBFrames associated with an Input Stream Identifier (ISI) that is carried in the header of each BBFrame. The simplest scheme uses a single stream (with just one ISI value), but multiple streams are permitted. The BBFrames forming a stream may be of variable size (selected from a set of allowed sizes), and must use the same stream format (e.g. TS or GSE). Each stream represents an independent link with independent address resolution [RFC4947]. GSE provides functions that are equivalent to those of the Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It supports the transmission of IP packets and other network-layer protocols. The network-layer interface resembles that of ULE, where it adopts common mechanisms for a Length field, a 16-bit Type field, and support for Extension Headers. As in ULE, GSE permits multiple address formats, indicated by the LT field (functionally equivalent to the D field in ULE). The default addressing mode uses a 6-byte NPA and a suppressed NPA address (functionally equivalent to D=1 in ULE). GSE also provides more flexible fragmentation at the interface to the physical layer (using the S and E flags). This adapts the SNDUs to a variable-sized link-layer frame, and reflects the more complex requirements in terms of fragmentation and assembly that arise when using point-to-multipoint adaptive physical layers. The integrity of a reassembled SNDUs is provided by a CRC-32 in the last fragment for the corresponding PDU. Fairhurst Expires April 2008 [Page 18] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 [RFC EDITOR NOTE: This section must be deleted prior to publication] DOCUMENT HISTORY Individual Draft 00 This draft complements a study item in the DVB-GBS in this area to define a Generic Stream Encapsulation (GSE). Comments relating to this document will be gratefully received by the author(s) and may also be sent to ip-dvb mailing list. Individual Draft 01 Co-Author Added. This draft updates the language and format. This draft fixes problems with the concatenation mode, and defines a new header format that restricts the use of the Type field so that all concatenated PDUs MUST have the same Type. Future versions of this draft may define additional Extension Headers, proposals and ideas are welcome via the IETF ipdvb mailing list. Possible extensions include those for encapsulation FEC, Link parameter negotiation (e.g. for header compression), and support for ATM/ULE. Working Group Draft 00 Fixed editorial mistakes from Christian Praehauser and ID style for WG adoption. Working Group Draft 01 Corrected contact info for Bernhard. Added TimeStamp Options Corrected NITS in draft Working Group Draft 01 Amended diagrams and text to follow tentative IANA assignments for the codepoints. Working Group Draft 01 Amended text to follow IANA assignments for the codepoints. Added issues raised at ipdvb meeting by C Praehauser. Revised appendix with text from GSE Spec, J Cantillo, et al. Revised wording to clarify corner cases. Removed references to documents not in public domain. Updated conventions and abbreviations for consistency. Updated text referencing ULE. Working Group Draft 02 Added rules for Types of PDUs in PDU-Concat. Added appendix on DVB 2 nd generation. Added new text on timers to control concat (from list). Fairhurst Expires April 2008 [Page 19] Internet-Draft Extension Formats for the ULE Encapsulation Nov 2007 Working Group Draft 03 Added a table to the start of the method defining recommended. Fixed NiTs. Working Group Draft 04 Editorial changes to prepare the document for WGLC. Updated IANA section to comply with RFC4326 IANA Guidelines. Reduced Security considerations section by reference to other documents that give a fuller discussion. There were no intentional changes to the protocol specification. Working Group Draft 06 Addressed review comments. Working Group Draft 06 Updated reference to GSE (now an ETSI Spec) - This spec has a normative reference to the current document. Minor editorial corrections to English [END of RFC EDITOR NOTE] Fairhurst Expires April 2008 [Page 20]