GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5163

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5163.txt · Last modified: 2008/04/23 00:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki