doc: Add RFC documents

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]
+