Internet Engineering Task Force                         Gorry Fairhurst 
Internet Draft                                   University of Aberdeen 
Expires July 2007                                     B. Collini-Nocker 
                                                 University of Salzburg 
                                                                        
                                                                        
Category: WG Draft intended for PS                           March 2007 
 
    
       Extension Formats for Unidirectional Link Encapsulation (ULE)  
              and the Generic Stream Encapsulation (GSE) 
                     draft-ietf-ipdvb-ule-ext-01.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 Link Encapsulation (ULE) [RFC4236].  
    
   The Extension Header formats defined in this document define new 
   extensions that are common extensions to both ULE and the Generic 
   Stream Encapsulation (GSE) [GSE] defined by the second generation 
   framing structure DVB-S2 standard [S2].  
     
    
    
    
    
    
    
    
    


  
Fairhurst              Expires September 2007                 [page 1] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 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. Summary 
    
   5. IANA Considerations 
    
   6. Acknowledgments 
    
   7. Security Considerations 
    
   8. References 
       8.1 Normative References 
       8.2 Informative References 
    
   9. Authors' Addresses 
    
   10. IPR Notices 
       10.1 Intellectual Property Statement 
       10.2 Disclaimer of Validity 
    
    
   11. Copyright Statement 
       11.1 Intellectual Property Statement 
       11.2 Disclaimer of Validity 
        
   Appendix A:  
    
    
    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
Fairhurst                 Expires July 2007                   [page 2] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
1. Introduction 
    
   This document describes two new Header Extensions that may be used 
   with both Unidirectional Link Encapsulation, ULE, [RFC4236] 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 specifically for DVB-S2 [ETSI-S2]. The requirements for 
   the Generic Stream are defined in [S2-REQ], [S2-REQ-RCS], and [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). 
 
   One extension header defines a method that allows one or more TS-
   Packets [ISO-MPEG] 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. 
    
   The 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   Mar 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 Broadcast. A framework and set of  
   associated standards published by the European Telecommunications  
   Standards Institute (ETSI) for the transmission of video, audio, and  
   data.  
        
   Encapsulator: A network device 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 [S2]. 
    
   GSE: Generic Stream Encapsulation [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-MPEG], and ITU-T (in H.220).  
        
   Next-Header: A Type value indicating an Extension Header [RFC4236].  
        
   NPA: Network Point of Attachment [RFC4236]. 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.  
 
   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-MPEG]. 
    
   SI Table: Service Information Table [ISO-MPEG]. 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 carrier. 
     
  
Fairhurst                 Expires July 2007                   [page 4] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
   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-MPEG], a method of transmission at the 
   MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 
   reference model.  
    
   ULE: Unidirectional Link Encapsulation (ULE) [RFC4236]. A scheme 
   that encapsulates PDUs, into SNDUs that are sent in a series of TS 
   Packets using a single TS Logical Channel. The encapsulation format 
   defined by this document shares the same extension format, and basic 
   processing rules and uses a common IANA Registry. 
    
    
    
    
    
    
    
    
    
    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    
    
    
    
    
    
    
    
    
 
 
 
 


  
Fairhurst                 Expires July 2007                   [page 5] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 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 specification is defined 
   in [GSE] and follows these formats, but as in other  SNDU formats, 
   GSE does not include a per-SNDU CRC and utilises a different SNDU 
   length calculation [GSE]. 
    
    
3.1 MPEG-2 TS-Concat Extension  
    
   >>> IANA Action required, please replace < #NH-TS-CAT> with assigned 
   value from the Next-Header Registry>>> 
    
   The MPEG-2 TS-Concat Extension Header is specified by an IANA 
   assigned H-Type value of <#NH-TS-CAT>. This is a Mandatory Next-
   Header Extension.   
    
   The extension is used to transport 1 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 specified by the remainder of the 
   Payload following the MPEG-2 TS Extension. 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 payload length is correct prior to 
   processing it. Any mismatch (remainder from the division) MUST 
   result in discard of all encapsulated PDUs and SHOULD be recorded as 
   TS-concat size mismatch error. 
    
   A value D=0 indicates the presence of a NPA address. In that case 
   the correct payload length for ULE is (Length-10) / 188, whereas in 
   case of GSE the correct payload length is (Length-6) / 188. 
    
   >>> IANA Action required, please replace < #NH-TS-CAT> with assigned 
   value from the Next-Header Registry>>> 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
Fairhurst                 Expires July 2007                   [page 6] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 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 = 0x <#NH-TS-CAT>       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            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) 
    
    
   >>> IANA Action required, please replace <#NH-TS-CAT> with assigned 
   value from the Next-Header Registry>>> 
    
     
       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 =0x <#NH-TS-CAT>        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            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 (D=0) 
    
    
   Note that fragmented GSE SNDUs are protected by a CRC-32 carried in 
   the final fragment, and that non-fragmented GSE SNDUs are protected 
   by a CRC-32 in the final bytes of the GS DataField. 
    
   A value of D=1, is also permitted and indicates the absence of a NPA 
   address, as defined in ULE. A similar format is supported in GSE. 
  
Fairhurst                 Expires July 2007                   [page 7] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
     
    
   >>> IANA Action required, please replace <#NH-TS-CAT> with assigned 
   value from the Next-Header Registry>>> 
    
    
       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 = 0x<#NH-TS-CAT>        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   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 extension may be used to transport one or more MPEG-2 TS Packets 
   of arbitrary content, interpreted according to [ISO-MPEG]. One 
   expected use is for the transmission of MPEG-2 SI/PSI signalling. 
    
   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 it 
   is noted that the operation may be simplified by ensuring that all 
   SNDUs that carry this Extension Header are placed before other data 
   within the GSE DataField [GSE]. 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
Fairhurst                 Expires July 2007                   [page 8] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
    
    
    
    
    
    
3.2 PDU-Concat Extension 
    
   >>> IANA Action required, please replace <#NH-PDU-CAT> with assigned 
   value from the Next-Header Registry>>> 
    
   The PDU-Concat Extension is specified by an IANA assigned H-Type 
   value of <#NH-PDU-CAT> 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 also 
   caries a 16-bit ULE Type field. Although any Type value specified in 
   the ULE Next-Header Registry may be assigned to the encapsulated 
   PDU, all PDUs included in the SNDU payload 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 MUST be set to zero. The length of 
   each PDU MUST be less than 32 758 bytes, but will generally be much 
   smaller.  
 
   When the SNDU header indicates the presence of an SNDU Destination 
   Address field (i.e. D=0), 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   Mar 2007  
 
 
    
    
   >>> IANA Action required, please replace <#NH-PDU-CAT> with assigned 
   value from the Next-Header Registry in the next two figures>>> 
    
 
       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 = 0x<#NH-PDU-CAT>       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            Receiver Destination NPA Address  (6B)             | 
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                               |        CONCAT-PDU-Type        |         
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|      PDU-Length-1  (15b)    |                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
      =                        PDU-1                                  = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|      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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |1|           Length  (15b)     |  Type = 0x<#NH-PDU-CAT>       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            Receiver Destination NPA Address  (6B)             | 
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                               |        CONCAT-PDU-Type        |         
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|      PDU-Length-1  (15b)    |                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
      =                        PDU-1                                  = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|      PDU-Length-2  (15b)    |                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
      =                        PDU-2                                  = 
      |                                                               | 
       
                                 More PDUs as required  
    
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  
Fairhurst                 Expires July 2007                  [page 10] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
                                      
       Figure 5: GSE/SNDU Format for a PDU-Concat Payload (D=0) 
    
   A value of D=1 indicates there is no NPA/MAC address in use. This 
   field MUST be carried (i.e. D=0) for IP unicast packets destined to 
   routers that are sent using shared links (i.e., where the same link 
   connects multiple Receivers). A sender MAY omit this field (D=1) for 
   a set of packets delivered to a Receiver or group of receivers that 
   are able to utilise a discriminator field (e.g. the IPv4/IPv6 
   destination address, or a bridged MAC destination address), which in 
   combination with the PID value, could be interpreted as a Link-Level 
   address. A similar format is supported in GSE. 
 
    
       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 = 0x<#NH-PDU-CAT>       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         CONCAT-PDU-Type       |0|      PDU-Length-1  (15b)    |            
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      =                        PDU-1                                  = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|      PDU-Length-2  (15b)    |                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
      =                        PDU-2                                  = 
      |                                                               | 
       
                                 More PDUs as required  
    
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
       Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) 
    
    
 
   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 the sum of the Lengths of 
   all processed PDUs is less than the Length specified in the SNDU 
   base header. A Receiver MUST discard the whole SNDU if the sizes do 
   not match and this event SHOULD be recorded as a PDU-concat size 
   mismatch error. 
 
    
    
    
    
    
  
Fairhurst                 Expires July 2007                  [page 11] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
   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. 
    
   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). 
    
    
   >>> IANA please insert a value for the H-Type from the Optional part 
   of the Next-Header Registry, and replace <NH-TStamp> in the sentence 
   below, and the figure following <<< 
    
   The Timestamp Extension Header is specified by the IANA-assigned H-
   Type of <NH-TStamp>. This extension is an Optional Extension Header 
   ([RFC4326], Section 5).  
    
    0               7               15              23              31 
    +---------------+---------------+---------------+---------------+ 
    |     0x03      | <NH-TStamp>   |       time stamp HI           | 
    +---------------+---------------+---------------+---------------+ 
    |         time stamp LO         |            Type               | 
    +---------------+---------------+---------------+---------------+ 
 
         Figure 7 The format of the 32-bit Timestamp Extension Header 
    
   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). 
    
   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 timestamp option was inserted, 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 that do not 
   implement, or do not wish to process, the Timestamp Extension MAY 
  
Fairhurst                 Expires July 2007                  [page 12] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
   skip this extension and continue to process the remainder of the 
   SNDU, forwarding the encapsulated PDU. 
 
 
4. Summary 
    
   This document defines a set of Next_Header Extensions for the 
   Unidirectional Link Encapsulation (ULE).  
    
    
    
5. 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.  
    
   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 <#NH-TS-CAT>. 
    
   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 <#NH-PDU-CAT>. 
    
   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 <#NH-TStamp>. 
   This documents defines format for a HLEN value of 0x3. 
 
    
6. Acknowledgments 
    
   The author gratefully acknowledges the inputs, comments and 
   assistance offered by the members of the DVB-GBS ad hoc group on S2 
   encapsulation, in particular contributions on transmission aspects 
   from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. 
    
    
7. 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 a PFU 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. 
 
  
Fairhurst                 Expires July 2007                  [page 13] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
    
    
    
 
    
8. References 
    
    
8.1 Normative References  
    
   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 
   Requirement Levels", BCP 14, RFC 2119, 1997. 
 
   [RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 
   Link Encapsulation (ULE) for transmission of IP datagrams over an 
   MPEG-2 Transport Stream", RFC 4236, December 2006. 
    
    
8.2 Informative References 
    
   [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", 
   European Telecommunications Standards Institute (ETSI). 
 
   [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). 
    
   [GSE] "Generic Stream Encapsulation", Work in Progress, DVB 
   Technical Module (GBS Group), 2006. 
    
   [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB-
   S2", Internet Draft <draft-cantillo-ipdvb-s2encaps-01.rxr>, Work in 
   Progress. 
    
   [ISO-MPEG] 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. 
     
   [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). 
 
   [S2-REQ] GBS0339, "Functional and performance requirements for 
   IP/S2", DVB-TM (GBS WG). 
    
  
Fairhurst                 Expires July 2007                  [page 14] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
   [S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB Technical 
   Module (RCS WG). 
 
 
 
9. 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/ 
    
10. IPR Notices 
    
10.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. 
    
    
    
  
Fairhurst                 Expires July 2007                  [page 15] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 2007  
 
 
    
    
    
10.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. 
    
    
11. 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. 
    
 
 
 
APPENDIX: DVB-S.2 
    
   PDUs, (Ethernet Frames, IP datagrams or other network layer packets) 
   are encapsulated to form a Subnetwork Data Unit (SNDU) [RFC4236] 
   associated with a specific Stream at the link layer. The SNDU is 
   transmitted over an DVB-S2 link by placing it either in a single 
   BBFrame, or if required, an SNDU may be fragmented into a series of 
   BBFrames [ID-S2-REQ]. A mode also permits an SNDU to be fragmented 
   with the remaining fragments sent in a later BBFrame(s), while 
   preserving the original order of each SNDU sent to a specific 
   MAC/NPA address over a Stream. Where there is sufficient space, the 
   method permits a BBFrame to carry more than one SNDU (or part there 
   of), sometimes known as Packing. All parts comprising an SNDU are 
   assigned to the same Stream.  
 
   In ULE and MPE [ETSI-DAT], each SNDU carries a 32-bit CRC field in 
   the last four bytes of the SNDU. The purpose of this CRC is to 
   protect the SNDU (header, and payload) from undetected reassembly 
   errors and errors introduced by unexpected software / hardware 
   operation. This also serves to verify the delineation (framing) of 
   PDUs and may detect the presence of uncorrected errors from the 
   physical link 
    
   When an SNDU is sent over a DVB-S2 subnetwork using GSE, the 
   Integrity protection is provided by a CRC at the baseband frame 
   level, using a CRC in the final bytes of the DataField.  
  
Fairhurst                 Expires July 2007                  [page 16] 
INTERNET DRAFT   Extension Formats for the ULE Encapsulation   Mar 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 
    
   [END of RFC EDITOR NOTE]  
 















  
Fairhurst                 Expires July 2007                  [page 17]