From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5163.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc5163.txt (limited to 'doc/rfc/rfc5163.txt') diff --git a/doc/rfc/rfc5163.txt b/doc/rfc/rfc5163.txt new file mode 100644 index 0000000..5e67817 --- /dev/null +++ b/doc/rfc/rfc5163.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group G. Fairhurst +Request for Comments: 5163 University of Aberdeen +Category: Standards Track B. Collini-Nocker + University of Salzburg + April 2008 + + + Extension Formats for Unidirectional Lightweight Encapsulation (ULE) + and the Generic Stream Encapsulation (GSE) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes a set of Extension Headers for the + Unidirectional Lightweight Encapsulation (ULE), RFC 4326. + + The Extension Header formats specified in this document define + extensions appropriate to both ULE and the Generic Stream + Encapsulation (GSE) for the second-generation framing structure + defined by the Digital Video Broadcasting (DVB) family of + specifications. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................3 + 3. Description of the Method .......................................4 + 3.1. MPEG-2 TS-Concat Extension .................................5 + 3.2. PDU-Concat Extension .......................................8 + 3.3. TimeStamp Extension .......................................12 + 4. IANA Considerations ............................................13 + 5. Acknowledgments ................................................13 + 6. Security Considerations ........................................14 + 7. References .....................................................14 + 7.1. Normative References ......................................14 + 7.2. Informative References ....................................14 + Appendix A. The Second-Generation DVB Transmission + Specifications .................................................16 + + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 1] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + +1. Introduction + + This document describes three Extension Headers that may be used with + both the 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 [S2-REQ]. The important + characteristics of this encapsulation are described in the appendix + of this document. GSE maintains a design philosophy that presents a + network interface that is common to that presented by ULE and uses a + similar construction for SubNetwork Data Units (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 a receiver that is not configured to + receive the NPA address associated with an SNDU, allowing this + receiver to 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. + + The appendix includes a summary of key design issues and + considerations relating to the GSE Specification defined by the DVB + Technical Module [GSE]. + + + +Fairhurst & Collini-Nocker Standards Track [Page 2] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + +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 Forward Error Correction (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 [RFC4259] 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. + + 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. + + MPEG-2: A set of standards specified by the Motion Picture Experts + Group (MPEG), and standardized by the International Organization for + Standardization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). + + Next-Header: A Type value indicating an Extension Header [RFC4326]. + + + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 3] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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. + + 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. + +3. Description of the Method + + In ULE, a Type field value that is less than 1536 in 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 + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 4] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + encapsulation format differs in that GSE does not include a Cyclic + Redundancy Check (CRC) for each SNDU, has different header flags, and + utilizes 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 optimization 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 + Extension Header. + + 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) and D is the + value of the D-bit. + + 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 & Collini-Nocker Standards Track [Page 5] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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 an 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 & Collini-Nocker Standards Track [Page 6] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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 labeled S and E are + defined by [GSE] and contain control flags used by the GSE link + layer. The Label Type (LT) field 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 + an 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) + + The TS-Concat 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 + signalling [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 + + + +Fairhurst & Collini-Nocker Standards Track [Page 7] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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 + 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: + + * A Receiver needs to consistently associate all TS Packets in a + Stream with one TS Logical Channel (Stream). If an Encapsulator + transmits more than one Stream of TS Packets each encapsulated at a + different level or with a different NPA address, a Receiver needs + to ensure that each is independently demultiplexed as a separate + Stream (Section 3.2 [RFC4259]). + + * If an Encapsulator transmits service information encapsulated at + different levels or with different NPA addresses, the Receivers + need to ensure each Stream is related to the corresponding SI table + information (if any). A RECOMMENDED way to reduce signaling + interactions is to ensure each PID value uniquely identifies a + Stream within a TS Multiplex carrying ULE and also any TS Packets + encapsulated by a ULE/GSE Stream. + + The need for consistency in the use of PIDs and the related service + information is described in section 4.2 of [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 + + + + +Fairhurst & Collini-Nocker Standards Track [Page 8] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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 in the following + diagrams as PDU-x-Length for the xth PDU). 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 figures 4, 5, + and 6). 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 + 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-1-Length (15b) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + = PDU-1 = + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R| PDU-2-Length (15b) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + = PDU-2 = + | | + More PDUs as required + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (CRC-32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) + + + + +Fairhurst & Collini-Nocker Standards Track [Page 9] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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-1-Length (15b) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + = PDU-1 = + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R| PDU-2-Length (15b) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + = PDU-2 = + | | + More PDUs as required + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00) + + 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 an NPA/MAC address + is in use [RFC4326]. A similar format is supported in GSE (using the + LT field). + + + + + + + + + + + + + + + + + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 10] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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-1-Length (15b) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-1 = + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R| PDU-2-Length (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 + + + + + + + + + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 11] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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. + +3.3. TimeStamp Extension + + The TimeStamp Extension Header is an Optional Extension Header 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 synchronized 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 | TimeStamp HI | + +---------------+---------------+---------------+---------------+ + | TimeStamp LO | Type | + +---------------+---------------+---------------+---------------+ + + Figure 7: Format of the 32-bit TimeStamp Extension Header + + The extension carries a 32-bit value (TimeStamp HI plus TimeStamp + 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 MUST pad the unused least-significant + bits with a value of zero. + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 12] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + 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. + +4. IANA Considerations + + IANA has assigned 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 the format for an HLEN value of 0x3. + +5. Acknowledgments + + The authors gratefully acknowledge 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. + + + + +Fairhurst & Collini-Nocker Standards Track [Page 13] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + Juan Cantillo provided a significant contribution to the informative + appendix. The authors thank Christian Praehauser for his insight and + contribution on Extension Header processing issues. + +6. Security Considerations + + 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 [Sec-Req]. + + An attacker that is able to inject arbitrary TS Packets in a ULE or + GSE Stream may modify layer 2 signalling information transmitted by + the MPEG-2 TS-Concat extension. Since this attack requires access to + the link and/or layer 2 equipment, such an attack could also directly + attack signalling information sent as native TS Packets (not + encapsulated by ULE/GSE). Security issues relating to the + transmission and interpretation of layer 2 signalling information + (including Address Resolution) within a TS Multiplex are described in + [RFC4947]. The use of security mechanisms to protect the MPEG-2 + signalling information is discussed by [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, March 1997. + + [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional + Lightweight Encapsulation (ULE) for Transmission of IP + Datagrams over an MPEG-2 Transport Stream (TS)", RFC + 4326, December 2005. + + [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic + Stream Encapsulation (GSE) Protocol, "European + Telecommunication Standards, Institute (ETSI), 2007. + +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). + + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 14] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + + [S2-REQ] Cantillo, J. and J. Lacan, "A Design Rationale for + Providing IP Services over DVB-S2 Links", Work in + Progress, December 2006. + + [Sec-Req] Cruickshank, H., Iyengar, S., and P. Pillai, "Security + requirements for the Unidirectional Lightweight + Encapsulation (ULE) protocol", Work in Progress, + November 2007. + + [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 Organization for + Standardization (ISO), 2000. + + [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 2005. + + [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution + Mechanisms for IP Datagrams over MPEG-2 Networks", RFC + 4947, July 2007. + + + + + + + + + + + + + + + + + + + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 15] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + +Appendix A. 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 Stream (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 (i.e., 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 SNDU is validated using a CRC-32 in the last fragment + for the corresponding PDU. + + + + +Fairhurst & Collini-Nocker Standards Track [Page 16] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + +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/users/gorry + + + 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 & Collini-Nocker Standards Track [Page 17] + +RFC 5163 Extension Formats for the ULE Encapsulation April 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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 + + 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. + + + + + + + + + + + + +Fairhurst & Collini-Nocker Standards Track [Page 18] + -- cgit v1.2.3