[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fairhurst-ipdvb-ule-ext) 00 01 02 03 04 05 06 07 RFC 5163

Internet Engineering Task Force                         Gorry Fairhurst
Internet Draft                                   University of Aberdeen
Expires November 2007                                 B. Collini-Nocker
                                                 University of Salzburg


Category: WG Draft intended for PS                             May 2007


 Extension Formats for Unidirectional Lightweight Encapsulation (ULE)
              and the Generic Stream Encapsulation (GSE)
                        draft-ietf-ipdvb-ule-ext-02.txt

Status of this Draft

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Abstract

   This document describes a set of Extension Headers for the
   Unidirectional Lightweight Encapsulation (ULE), RFC4326.

   The Extension Header formats defined in this document define new
   extensions that are common extensions to both ULE and the Generic
   Stream Encapsulation (GSE) defined to support the second generation
   framing structure defined by Digital Video Broadcasting (DVB) family
   of specifications.











Fairhurst              Expires November 2007                  [page 1]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


Table of Contents

   1. Introduction

   2. Conventions used in this document

   3. Description of method
       3.1 MPEG-2 TS-Concat Extension
       3.2 PDU-Concat Extension
       3.3 TimeStamp Extension

   4. IANA Considerations

   5. Acknowledgements

   6. Security Considerations

   7. References
       7.1 Normative References
       7.2 Informative References

   8. Authors' Addresses

   9. IPR Notices
       9.1 Intellectual Property Statement
       9.2 Disclaimer of Validity


   10. Copyright Statement

   Appendix: The Second Generation DVB Transmission Specifications























Fairhurst                 Expires July 2007                   [page 2]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


1. Introduction

   This document describes three new Header Extensions that may be used
   with both Unidirectional Lightweight Encapsulation, ULE, [RFC4326]
   and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for
   links that employ the MPEG-2 Transport Stream, and supports a wide
   variety of physical-layer bearers [RFC4259].

   GSE has been designed for the Generic Mode (also known as the
   Generic Stream (GS)), offered by second-generation DVB physical
   layers, and in the first instance for DVB-S2 [ETSI-S2]. The
   requirements for the Generic Stream are described in [ID-S2-REQ].
   The important characteristics of this encapsulation are described in
   an Appendix to this document. GSE maintains a design philosophy that
   presents a common network interface to that of ULE and uses a
   similar construction for Subnetwork Data Unit (SNDUs).

   The first Extension Header defines a method that allows one or more
   TS-Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may
   be used to provide control plane information including the
   transmission of MPEG-2 Program Specific Information (PSI) for the
   Multiplex. In GSE, there is no native support for transport stream
   packets and this method is therefore suitable for providing an MPEG-
   2 control plane.

   A second Extension Header allows one or more PDUs to be sent within
   the same ULE SNDU. This method is designed for cases where a large
   number of small PDUs are directed to the same Network Point of
   Attachment (NPA) address. The method may improve transmission
   efficiency (by removing duplicated MAC layer overhead). It can also
   reduce processing overhead for receivers that are not addressed by
   the NPA, since these receivers may then skip several PDUs in one
   operation. The method is defined as a generic Extension Header and
   may be used for IPv4 or IPv6 packets. If and when a compression
   format is defined for ULE or Ethernet, the method may also be used
   in combination with this method.

   A third Extension Header provides an optional timestamp value for an
   SNDU. Examples of the use of this timestamp option include
   monitoring and benchmarking of ULE and GSE links. Receivers that do
   not wish to decode (or do not support) the timestamp extension may
   discard the extension and process the remaining PDU or Extension
   Headers.

   An appendix includes a summary of key design issues and
   considerations based on the GSE Specification defined by the DVB
   Technical Module [GSE].







Fairhurst                 Expires July 2007                   [page 3]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119 [RFC2119].

   b: bit. For example, one byte consists of 8b.

   B: Byte. Groups of bytes are represented in Internet byte order.

   BBFrame payload [ETSI-S2]: The data field part of a Baseband frame
   that may be used for the communication of data. Typical BBFrames
   range in size from 3072 to 58192 bits according to the choice of
   modulation format and FEC in use.

   DVB: Digital Video Broadcasting. A framework and set of
   associated standards published by the European Telecommunications
   Standards Institute (ETSI) for the transmission of video, audio, and
   data.

   E: A one-bit flag field defined in [GSE].

   Encapsulator: A network device that receives PDUs and formats these
   in to Payload Units (known here as SNDUs) for output in DVB-S or the
   Generic Mode of DVB-S2.

   GS: Generic Stream [ETSI-S2].  A stream of BBFrames identified by a
   common Input Stream Identifier, and which does not use the MPEG-2 TS
   format.

   GSE: Generic Stream Encapsulation [GSE]. A method that encapsulates
   PDUs that 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].

   MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
   defined by the IEEE 802.3 standard (or by Ethernet v2).

   MPEG-2: A set of standards specified by the Motion Picture Experts
   Group (MPEG), and standardized by the International Standards
   Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).

   Next-Header: A Type value indicating an Extension Header [RFC4326].

   NPA: Network Point of Attachment [RFC4326]. In this document, refers
   to a destination address (resembling an IEEE MAC address) within the
   DVB-S/S2 transmission network that is used to identify individual
   Receivers or groups of Receivers.


Fairhurst                 Expires July 2007                   [page 4]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


   PID: Packet Identifier  [ISO-MPEG2]. A 13 bit field carried in the
   header of each TS Packet. This identifies the TS Logical Channel to
   which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the
   parts of a Table Section, or other Payload Unit must all carry the
   same PID value.  The all ones PID value indicates a Null TS Packet
   introduced to maintain a constant bit rate of a TS Multiplex. There
   is no required relationship between the PID values used for TS
   Logical Channels transmitted using different TS Multiplexes.

   PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include
   Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.

   PSI: Program Specific Information [ISO-MPEG2].

   S: A one-bit flag field defined in [GSE].

   SI Table: Service Information Table [ISO-MPEG2]. In this document,
   this term describes a table that is been defined by another
   standards body to convey information about the services carried on a
   DVB Multiplex.

   SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an
   encapsulated PDU sent using ULE or GSE.

   Stream: A logical flow from an Encapsulator to a set of Receivers.

   TS: Transport Stream [ISO-MPEG2], a method of transmission at the
   MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
   reference model.

   ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A
   method that encapsulates PDUs, into SNDUs that are sent in a series
   of TS Packets using a single TS Logical Channel. The encapsulation
   defines an extension format and an associated IANA Registry.




















Fairhurst                 Expires July 2007                   [page 5]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


3. Description of the Method

   In ULE, a Type field value that is less than 1536 Decimal indicates
   an Extension Header.  This section describes a set of two extension
   formats for the ULE encapsulation. The GSE [GSE] follows the same
   format as used in the ULE Type field. The encapsulation format
   differs in that GSE does not include a per-SNDU CRC, has different
   header flags, and utilises a different SNDU length calculation
   [GSE].

3.1 MPEG-2 TS-Concat Extension

   The MPEG-2 TS-Concat Extension Header is specified by an IANA
   assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory
   Next-Header Extension.

   The extension is used to transport one or more MPEG-2 TS Packets
   within a ULE SNDU. The number of TS Packets carried in a specific
   SNDU is determined from the size of the remainder of the payload
   following the MPEG-2 TS Extension Header. The number of TS Packets
   contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N
   is the number of bytes associated with Extension Headers that
   precede the MPEG-2 TS-Concat Extension (zero if there are none).

   A Receiver MUST check that the validity of the value of the payload
   Length prior to processing. Any mismatch (remainder from the
   division) MUST result in discard of all encapsulated PDUs and SHOULD
   be recorded as TS-Concat size mismatch error.


       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)




Fairhurst                 Expires July 2007                   [page 6]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


   Figure 1 illustrates the format of this Extension Header for ULE
   with a value D=0, which indicates the presence of a NPA address
   [RFC4326]. In this case, the valid payload Length for a ULE SNDU
   with no other extensions is (Length-10) / 188.

   The method used to define the Length in GSE differs to that of ULE.
   The equivalent case for GSE would result in a payload Length value
   of (Length-6) / 188 (Figure 2).


       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|E|0 0|      Length  (12b)    |         Type = 0x0002         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Receiver Destination NPA Address  (6B)             |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                   TS-Packet 1                                 |
      =                                                               =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   TS-Packet 2 (if Length > 2*188)             |
      =                                                               =
      |                              etc.                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)

   Note that fragmented GSE SNDUs are protected by a CRC-32 carried in
   the final fragment. The fields labelled S and E are defined by [GSE}
   and contains control flags used by the GSE link layer. The Label
   Type field (LT) specifies the presence and format of the GSE label.

   In ULE, a value of D=1, is also permitted and indicates the absence
   of a NPA address (Figure 3). A similar format is supported in GSE.

















Fairhurst                 Expires July 2007                   [page 7]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|           Length  (15b)     |         Type = 0x0002         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   TS-Packet 1                                 |
      =                                                               =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   TS-Packet 2 (if Length > 2*188)             |
      =                                                               =
      |                              etc.                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)


   This extension may be used to transport one or more MPEG-2 TS
   Packets of arbitrary content, interpreted according to [ISO-MPEG2].
   One expected use is for the transmission of MPEG-2 SI/PSI
   signalling.

   NULL TS Packets are not normally 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, SI Table) over ULE/GSE framing raises
   timing considerations at the encapsulation gateway, including the
   need to update/modify the timing information prior to transmission
   by the physical layer. These issues are not considered here, but
   this operation may be simplified in GSE by ensuring that all SNDUs
   that carry this Extension Header are placed before other data within
   the BBFrame DataField [GSE].

   This document does not specify how TS Packets are to be handled at
   the Receiver, however it notes that a poorly configured Encapsulator
   could lead to a Multiplex carrying multiple (possibly conflicting)
   sets of TS Logical Channels and SI information encapsulated at
   different levels or with different NPA addresses. The need for
   consistency in the use of PIDs and the related SI information is
   described in [RFCxARx].


Fairhurst                 Expires July 2007                   [page 8]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007



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 preceding the
   PDU-Concat Extension Header. These Extension Headers (e.g. a
   TimeStamp Extension) apply to the composite concatenated PDU.

   The Extension Header also conatains a 16-bit ULE Type field
   describing the encapsulated PDU, CONCAT-PDU-Type. Although any Type
   value specified in the ULE Next-Header Registry (including Extension
   Header Types) may be assigned to the encapsulated PDU, all
   concatenated PDUs MUST have a common ULE Type (i.e. all concatenated
   PDUs passed by the network layer must be associated with the same
   Type value). This simplifies the receiver design, and reduces the
   transmission overhead for common use cases.

   Each PDU is prefixed by its length in bytes (shown as PDU-Length in
   the following diagrams). Encapsulated PDUs are of arbitrary length
   (in bytes) and are not necessarily aligned to 16-bit or 32-bit
   boundaries within the SNDU (as shown in the figure). The most
   significant bit of the first byte is reserved, R, and this
   specification requires that this MUST be set to zero. 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.












Fairhurst                 Expires July 2007                   [page 9]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007



       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|           Length  (15b)     |         Type = 0x0003         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Receiver Destination NPA Address  (6B)             |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |        CONCAT-PDU-Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|      PDU-Length-1  (15b)    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      =                        PDU-1                                  =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|      PDU-Length-2  (15b)    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      =                        PDU-2                                  =
      |                                                               |
                                 More PDUs as required

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0)



       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|E|0 0|      Length  (12b)    |         Type = 0x0003         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Receiver Destination NPA Address  (6B)             |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |        CONCAT-PDU-Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|      PDU-Length-1  (15b)    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      =                        PDU-1                                  =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|      PDU-Length-2  (15b)    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      =                        PDU-2                                  =
      |                                                               |
                                 More PDUs as required

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_

   The value of D in the ULE header idicates whether a NPA/MAC address
   is in use [RFC4326]. A similar format is supported in GSE.

Fairhurst                 Expires July 2007                  [page 10]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007




       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|           Length  (15b)     |         Type = 0x0003         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         CONCAT-PDU-Type       |R|      PDU-Length-1  (15b)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      =                        PDU-1                                  =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|      PDU-Length-2  (15b)    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      =                        PDU-2                                  =
      |                                                               |
                                 More PDUs as required

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)

   To reduce transmission overhead and processing, an Encapsulator
   SHOULD specify a maximum period of time it will wait before sending
   a Concatenated PDU. This is known as the PDU Packing Threshold. This
   value MUST be bounded and SHOULD be configurable in the
   Encapsulator. A larger value can improve efficiency, but incurs
   higher jitter and could increase the probability of corruption. If
   additional PDUs are NOT received within the PDU Packing Threshold,
   the Encapsulator MUST immediately send any queued PDUs.

   The Receiver processes this Extension Header by verifying that it
   supports the specified CONCAT-PDU Type (unsupported Types MUST be
   discarded but the receiver SHOULD record a PDU-Type error).  It then
   extracts each encapsulated PDU in turn. The Receiver MUST verify the
   Length of each PDU. It MUST also ensure that the sum of the Lengths
   of all processed PDUs equals the Length specified in the SNDU base
   header. A Receiver SHOULD discard the whole SNDU if the total and
   PDU sizes are not consistent and this event SHOULD be recorded as a
   PDU-Concat size mismatch error.


   3.3 Timestamp Extension

   The Timestamp Extension Header permits an Encapsulator to add a
   timestamp field to an SNDU. This is designed to support monitoring
   and measurement of ULE performance over a link to indicate the
   quality of an operational ULE link. This may be useful for GSE links
   (where significant complexity exists in the scheduling provided by
   the lower layers). This extension may be (optionally) checked at the
   Receiver.


Fairhurst                 Expires July 2007                  [page 11]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


   Possible uses of this extension include:

   * Validation of in-sequence ordering per Logical Channel,
   * Measurement of one-way delay (when synchronised with the sender)
   * Measurement of PDU Jitter introduced by the link,
   * PDU loss (with additional information from the sender).

   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).

   Figure 7 shows the format of this extension with a HLEN value of 3
   indicating a timestamp of length 4B with a Type field (there is no
   implied byte-alignment).

    0               7               15              23              31
    +---------------+---------------+---------------+---------------+
    |     0x03      |      0x01     |       time stamp HI           |
    +---------------+---------------+---------------+---------------+
    |         time stamp LO         |            Type               |
    +---------------+---------------+---------------+---------------+

         Figure 7 The format of the 32-bit Timestamp Extension Header


   The extension carries a 32-bit value (time stamp HI plus time stamp
   LO). The specified resolution is 1 microsecond. The value therefore
   indicates the number of 1 microsecond ticks past the hour in
   Universal Time when the PDU was encapsulated. This value may be
   earlier than the time of transmission due for example to Packing,
   queueing and other Encapsulator processing. The value is right-
   justified to the 32-bit field. Systems unable to insert timestamps
   at the specified resolution may use an arbitrary (and varying) value
   to pad the unused least-significant bits.

   The last two bytes carry a 16-bit Type field that indicates the type
   of payload carried in the SNDU, or the presence of a further Next-
   Header ([RFC4326], Section 4.4).

   This is an Optional Extension Header. Receivers SHOULD process the
   timestamp when the PDU is decapsulated. Receivers that do not
   implement, or do not wish to process, the Timestamp Extension MAY
   skip this extension and continue to process the remainder of the
   SNDU, forwarding the encapsulated PDU.


4.. IANA Considerations

   This document requires IANA involvement for the assignment of two
   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.


Fairhurst                 Expires July 2007                  [page 12]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


   The TS-Concat Extension is a Mandatory next-type Extension Header,
   specified in section 3.1 of this document. The value of this next-
   header is defined by an IANA assigned H-Type value of 0x0002.

   The PDU-Concat Extension is a Mandatory next-type Extension Header
   specified in section 3.2 of this document. The value of this next-
   header is defined by an IANA assigned H-Type value of 0x0003.

   The Timestamp Extension is an Optional next-type Extension Header
   specified in section 3.3 of this document. The value of this next-
   header is defined by an IANA assigned H-Type value of 257 decimal.
   This documents defines format for a HLEN value of 0x3.


5. Acknowledgments

   The author gratefully acknowledges the inputs, comments and
   assistance offered by the members of the DVB-GBS ad hoc group on
   DVB-S2 encapsulation, in particular contributions on DVB-S2
   transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
   Juan Cantillo provided a significant contribution to the informative
   annexe. The authors thank Christian Praehauser for his insight and
   contribution on header extension processing issues.


6. Security Considerations

   No specific security issues are raised within this document.

   Additional security control fields may be provided as a part of a
   link encryption Extension Header, e.g. to associate an SNDU with one
   of a set of Security Association (SA) parameters. As a part of the
   encryption process, it may also be desirable to authenticate
   some/all of the headers. The method of encryption and the way in
   which keys are exchanged is beyond the scope of this specification,
   as also are the definition of the SA format and that of the related
   encryption keys.


7. References


7.1 Normative References

   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, 1997.

   [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
   Lightweight Encapsulation (ULE) for transmission of IP datagrams
   over an MPEG-2 Transport Stream", RFC 4326, December 2005.

   [GSE] "Generic Stream Encapsulation", DVB Document A116, DVB
   Technical Module (GBS Group), May 2007.

Fairhurst                 Expires July 2007                  [page 13]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 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).

   [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB-
   S2", Internet Draft <draft-cantillo-ipdvb-s2encaps-01.rxr>, Work in
   Progress.

   [IEEE-802.3] "Local and metropolitan area networks - Specific
   requirements Part 3: Carrier sense multiple access with collision
   detection (CSMA/CD) access method and physical layer
   specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC
   8802-3), 2002.

   [ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology;
   Generic Coding of Moving Pictures and Associated Audio Information
   Systems", International Standards Organisation (ISO).

   [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
   Nocker, B., and H. Linder, "A Framework for Transmission of IP
   Datagrams over MPEG-2 Networks", RFC 4259, November 2006.

   [RFCxARx] Montpetit, M.-J., Fairhurst, G., "Address Resolution
   Mechanisms for IP Datagrams over MPEG-2 Networks", RFC Ed Queue,
   <draft-ietf-ipdvb-ar-xx.txt>, 2007.


8. Authors' Addresses

   Godred Fairhurst
   Department of Engineering
   University of Aberdeen
   Aberdeen, AB24 3UE
   UK
   Email: gorry@erg.abdn.ac.uk
   Web: 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
   Web: http://www.cosy.sbg.ac.at/


Fairhurst                 Expires July 2007                  [page 14]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007





10. IPR Notices

9.1 Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


9.2 Disclaimer of Validity

   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.


10. Copyright Statement


   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.




Fairhurst                 Expires July 2007                  [page 15]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007



APPENDIX: The Second Generation DVB Transmission Specifications

   This section provides informative background to the network layer
   requirements of the second generation DVB Transmission
   Specifications. The second generation waveforms specified by the
   Digital Video Broadcasting project offer two main enhancements.
   First, more efficient physical layer methods that employ higher
   order modulation with stronger FEC and permit adaptive coding and
   modulation response to changes in traffic and propagation
   conditions. Second, at the link layer, they offer greater
   flexibility in framing. Support is provided for a range of stream
   formats including the classical Transport Stream (TS) [RFC4259]. In
   addition, a new method called Generic Streams (GS) (or the Generic
   Mode) is supported. A GS can be packetized or continuous and is
   intended to provide native transport of other network-layer
   services. One such method is that provided by the Generic Stream
   Encapsulation (GSE) [GSE].

   A transmission link sequentially multiplexes a series of baseband
   frames (BBFrames). Each BBFrame comprises a fixed-size 10B header
   and a payload. The payload carries a DataField and uses padding to
   fill any unused space. A stream comprises a sequence of BBFrames
   associated with an Input Stream Identifier (ISI) that is carried in
   the header of each BBFrame.  The simplest scheme uses a single
   stream (with just one ISI value), but multiple streams are
   permitted. The BBFrames forming a stream may be of variable size
   (selected from a set of allowed sizes), and must use the same stream
   format (e.g. TS or GSE). Each stream represents an independently
   link with independent address resolution [RFCxARx].

   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,
   support for Extension Headers, and addressing using a 6-byte NPA and
   a suppressed NPA address (functionally equivalent to D=1 in ULE). In
   addition GSE also supports other addressing modes. It employs a CRC
   method in which a CRC is placed at the end of a BBFrame, covering
   multiples SNDUs. This is a result of more advanced physical layer
   coding and a larger link frame size differ than used by the MPEG-2
   TS. In some systems the CRC may be suppressed and replaced by cross-
   layer signalling from the physical layer.

   GSE also provides more flexible fragmentation at the interface to
   the physical layer. 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.




Fairhurst                 Expires July 2007                  [page 16]

INTERNET DRAFT   Extension Formats for the ULE Encapsulation   May 2007


   [RFC EDITOR NOTE:
   This section must be deleted prior to publication]

   DOCUMENT HISTORY

   Individual Draft 00
   This draft complements a study item in the DVB-GBS in this area to
   define a Generic Stream Encapsulation (GSE).  Comments relating to
   this document will be gratefully received by the author(s) and may
   also be sent to ip-dvb mailing list at: ip-dvb@erg.abdn.ac.uk

   Individual Draft 01
   Co-Author Added.
   This draft updates the language and format.
   This draft fixes problems with the concatenation mode, and defines a
   new header format that restricts the use of the Type field so that
   all concatenated PDUs MUST have the same Type.

   Future versions of this draft may define additional Extension
   Headers, proposals and ideas are welcome via the IETF ipdvb mailing
   list. Possible extensions include those for encapsulation FEC, Link
   parameter negotiation (e.g. for header compression), and support for
   ATM/ULE.

   Working Group Draft 00
   Fixed editorial mistakes from Christian Praehauser and ID style for
   WG adoption.

   Working Group Draft 01
   Corrected contact info for Bernhard.
   Added TimeStamp Options
   Corrected NITS in draft

   Working Group Draft 01
   Amended diagrams and text to follow tentative IANA assignments for
   the codepoints.

   Working Group Draft 01
   Ammended text to follow IANA assignments for the codepoints.
   Added issues raised at ipdvb meeting by C Praehauser.
   Revised annexe with text from GSE Spec, J Cantillo, et al.
   Revised wording to clarify corner cases.
   Removed references to documents not in public domain.
   Updated conventions and abbreviations for consistency.
   Updated text referencing ULE.

   [END of RFC EDITOR NOTE]







Fairhurst                 Expires July 2007                  [page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/