summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5163.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5163.txt')
-rw-r--r--doc/rfc/rfc5163.txt1011
1 files changed, 1011 insertions, 0 deletions
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]
+