Internet DRAFT - draft-fairhurst-ipdvb-s2-gule

draft-fairhurst-ipdvb-s2-gule





Internet Engineering Task Force                         Gorry Fairhurst 
Internet Draft                                   University of Aberdeen 
Document: draft-fairhurst-ipdvb-s2-gule-04.txt                          
                                                                        
                                                                        
                                                                        
                                                                        
                                                                        
Category: Draft                                            January 2006 
 
 
                     An Encapsulation for Transmission of 
              IP Datagrams over a DVB-S2 Generic Stream (GULE) 
    
    
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 Generic stream Unidirectional Lightweight 
   Encapsulation (GULE) mechanism for the transport of IPv4 and IPv6 
   Datagrams and other network protocol packets directly over the DVB 
   S2 Generic Stream. This specifies a base encapsulation format and 
   supports an extension format that allows it to carry additional 
   header information to assist in network/Receiver processing. 
    
   Internet-Drafts can be and are used to describe technical issues and 
   protocols that are of interest to the Internet community but that 
   are not finally standardised within the IETF. This is such a 
   document. It is intended for open discussion, but there is no 
   current plan to publish this as an Internet RFC. 
    
    
    
    
    

  
Expires June 2006                                             [page 1] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   Table of Contents 
    
   1. Introduction 
     1.1 SNDU and PDU Processing 
     1.2 Fragmentation Considerations 
    
   2. Conventions used in this document 
    
   3. Description of method 
     3.1 GULE Encapsulation Overhead 
     3.2 Placement of the Encapsulation Header within the BBHeader 
     3.3 BB Encapsulation Header within the BBFrame Payload 
    
   4. SNDU Format 
     4.1 Destination Address Absent (D) Field 
     4.2 Length Field 
     4.3 End Indicator 
     4.4 Type Field 
       4.4.1 Type 1: Next-Header Type Fields  
       4.4.2 Type 2: EtherType Compatible Type Fields 
     4.5 SNDU Destination Address Field 
     4.6 SNDU Trailer CRC 
     4.7 Description of SNDU Formats  
       4.7.1 End Indicator 
       4.7.2 IPv4 SNDU Encapsulation 
       4.7.3 IPv6 SNDU Encapsulation 
    
   5. Extension Headers 
     5.1 Test SNDU 
     5.2 Bridged Frame SNDU Encapsulation 
     5.3 Extension-Padding Optional Extension Header 
     5.4 MPEG-2 TS Extension 
     5.5 SNDU-Resume Extension 
        5.5.1 SNDU-Resume Extension fragment processing 
        5.5.2 SNDU-Resume Extension reassembly 
     5.6 SNDU-Suspend. 
     5.7 SNDU-Concat Extension 
 
   6.Processing at the Encapsulator  
     6.1 SNDU Encapsulation 
     6.2 Procedure for Padding and Packing 
    
   7. Receiver Processing 
     7.1 Idle State 
       7.1.1 Idle State Payload Pointer Checking 
     7.2 Processing of a Received SNDU 
       7.2.1 Reassembly Payload Pointer Checking 
     7.3 Other Error Conditions 
    
   8. Summary 
    
   9. IANA Considerations 
    
  
Expires June 2006                                             [page 2] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   10. Acknowledgments 
    
   11. Security Considerations 
    
   12. References 
     12.1 Normative References 
     12.2 Informative References 
    
   13. Authors' Addresses 
    
   14. IPR Notices 
       14.1 Intellectual Property Statement 
       14.2 Disclaimer of Validity 
    
    
   15. Copyright Statement 
       15.1 Intellectual Property Statement 
       15.2 Disclaimer of Validity 
        
   Appendix A: Scenarios for Fragmentation 
    
   Appendix B 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
Expires June 2006                                             [page 3] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
1. Introduction 
    
   This document describes an encapsulation for transport of IP 
   datagrams, or other network layer packets, over a link using the 
   physical layer specified by DVB-S2 [ETSI-S2] in the Generic Mode 
   (also known as the Generic Stream (GS)). Protocol requirements are 
   defined in [S2-REQ], [S2-REQ-RCS], and [ID-S2-REQ]. Some recommended 
   evaluation criteria are defined in [S2-REQ] and [S2-EVAL].  
    
   The method also allows TS-Packets [ISO-MPEG] to be sent within GULE 
   SNDUs. This may be used to provide control information and/or 
   Program Specific Information (PSI) for a Multiplex.  
    
   Note: Internet-Drafts can be and are used to describe technical 
   issues and protocols that are of interest to the Internet community 
   but that are not finally standardised within the IETF. This is such 
   a document and is intended for open discussion. 
    
    
1.1  SNDU and PDU Processing 
    
   Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other 
   network layer packets) for transmission are passed to an 
   Encapsulator. This formats each PDU into a SubNetwork Data Unit 
   (SNDU) by adding an encapsulation header and an integrity check 
   trailer [RFC4259]. The SNDU may be fragmented into a series of 
   fragments sent in one or more BaseBand (BB) frames that are sent 
   over the DVB S2 link.  
    
   Although this document defines a different framing method to ULE 
   [RFC4236], it maintains the same design philosophy as ULE for 
   construction of the SNDUs. The important characteristics of this 
   encapsulation are described in this subsection. This will allow 
   subsequent additions to ULE to also be supported within GULE. The 
   key features are that each SNDU has: 
    
   (i) D-bit  
   This permits both addressed and unaddressed SNDUs. The D=1 mode may 
   be used as an enhancement to link efficiency (e.g. where IP-based 
   address filtering is in use). 
    
   (ii) SNDU Length 
   This may be utilised in the SNDU framing, to skip unwanted SNDUs and 
   to validate wanted SNDUs. 
    
   (iii) SNDU Type/Extension field 
   The Type field uses an extension processing in place of flag-parsing 
   for options, providing a method for efficient option support. This 
   field also permits the use of any IEEE format frame, including those 
   that control L2 infrastructure (QoS, VLAN, Network Management, ST, 
   etc), bridging, and IETF-defined methods such as IPv4, IPv6, MPLS, 
   arp, etc.  The final use of this field is as a discriminator for 
   IETF-defined encapsulation extensions. Currently envisaged 
  
Expires June 2006                                             [page 4] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   extensions are (a) Security extensions providing functions such as: 
   encryption, identity hiding, and authentication methods; (b) Header 
   compression methods for various formats of payloads. 
    
   An important consideration is that the Length and Type fields 
   replicate information that may also be extracted from the network-
   layer protocol information.  There are various reasons for this 
   design:  
    
        (i) It is envisaged that SNDU parsing could be implemented in 
        hardware/firmware or could use specialised logic to assist in 
        parsing the SNDUs. In this case, access to the information may 
        be required at a low-level to assure rapid filtering or 
        unwanted packets and correct queuing of wanted packets. 
        Omitting the information requires additional processing for all 
        PDUs, irrespective of whether specific PDUs are forwarded to 
        the specific Receiver, incurring significant additional 
        computational cost. 
          
        (ii) Not all network-layer PDUs contain Type/Length information 
        (e.g. DIX-format packets). When present, the fields are located 
        at an offset from the start of each PDU (e.g. IPv4/IPv6). In 
        some cases, this also requires computation (e.g. header 
        skipping in IEEE/LLC).  
         
        (ii) Omitting the Type and Length field places a reliance of 
        the SNDU framing on the PDU formats that are supported. This 
        dependency will hinder evolution of the encapsulation for new 
        applications.  
         
 
   If transmission efficiency is an important consideration, the 
   duplicate protocol fields should be compressed at the PDU-level not 
   the SNDU-level. This approach ensures protocol-independent framing 
   of SNDUs; enable protocol-dependent compression (allowing the 
   context of a particular protocol associations to provide 
   sophisticated compression where needed); requires decompression only 
   of those PDUs to be forwarded; and finally allows the decompression 
   function to be off-loaded from the SNDU framing function (e.g. a 
   design that does this as part of the Internet driver interface, 
   rather than the device driver). The recommended approach is 
   therefore to define well-founded and robust methods that may be used 
   with both ULE and GULE. 
    
1.2  Fragmentation Considerations 
    
   Three forms of fragmentation are provided in this encapsulation 
   method:  
    
        (i) The simplest (default) provides efficient fragmentation and 
        reassembly for consecutive fragmentation (adjacent BBFrames) 
        [S2-REQ]. This follows a procedure that resembles that used by 
        ULE [RFC4236], and common to other MPEG-2 TS formats [ISO-
  
Expires June 2006                                             [page 5] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
        MPEG]. This mode requires each Receiver to maintain one buffer 
        for reassembly of the Current SNDU [ULE-RFC]. A constraint is 
        that a BBFrame may contain only the fragment of a single new 
        SNDU, which must be aligned to the end of the BBFrame. 
         
        (ii) The SNDU-Resume Extension Header defined in this document 
        provides a method for non-consecutive fragmentation with 
        multiplexing [S2-REQ] (i.e. where intervening BBFrames may be 
        sent using an arbitrary ModCod value). When used in the latter 
        way, an arbitrary large number of fragments may be resumed in 
        the same BBFrame (i.e. multiple fragment support [S2-REQ]). A 
        constraint is that a BBFrame may contain only the fragment of a 
        single new SNDU, which must be aligned to the end of the 
        BBFrame. 
         
        This method requires an additional protocol overhead within 
        each resumed fragment. To utilise this method, Receivers need 
        to maintain several buffers, up to one buffer for each MAC/NPA 
        address that they expect to receive, plus one for the case of 
        no specified MAC/NPA address (D=1).  Receivers that allocate 
        fewer buffers, may not be able to buffer all fragmented SNDUs, 
        potentially resulting in some packet loss (depending on the 
        fragmentation policy of the Gateway).  This document defines a 
        method to recover buffers that are occupied by incomplete 
        fragments after a specified interval. 
 
        (iii) The SNDU-Suspend Extension Header defined in this 
        document provides a method for non-consecutive fragmentation 
        with multiplexing [S2-REQ] that also supports an arbitrary 
        fragmentation of the first fragment of a new SNDU. This method 
        must be used in combination with the SNDU-Resume method and has 
        the same buffer management requirements as for the SNDU-Resume 
        method. Using this method, a BBFrame may contain any number of 
        fragments that start a new SNDU. New fragmented SNDUs do not 
        need to be aligned to the end of the BBFrame. 
         
        To utilise this method, a Receiver needs to be able to accept 
        an arbitrary large number of new fragmented new SNDUs within a 
        BBFrame. This may add complexity to the Receiver design, but 
        permits more flexibility in fragmentation by the Gateway. 
 
   These methods provide backwards compatibility: All Receivers MUST 
   implement method (i). If a Receiver does not also implement methods 
   (ii) and (iii), this Receiver will silently discard all PDUs sent 
   using the SNDU-Resume or SNDU-Suspend method. A Receiver that 
   implements the SNDU-Resume method may use method (i) and/or (ii), 
   but will silently discard all PDUs sent using the SNDU-Suspend 
   method (iii). A Receiver that implements the SNDU-Resume or SNDU-
   Suspend method is able to receive and forward PDU encapsulated using 
   any/all of the three methods. 
    
    
    
  
Expires June 2006                                             [page 6] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   2. Conventions used in this document 
    
   The capitalized 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 
   [RFC2119]. 
    
   ACM: Adaptive Coding and Modulation (see ModCod). 
    
   b: bit. For example, one byte consists of 8b.  
        
   B: Byte. Groups of bytes are represented in Internet byte order.  
    
   BB: Baseband. 
     
   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. 
    
   BBH, Baseband Header [ETSI-S2]: A fixed format 10 byte header that 
   starts each BBFrame. 
    
   Counter: An encapsulation protocol field located at a fixed position 
   in all BBFrames utilising the GULE encapsulation. The value is 
   incremented modulo 255 in each BBFrame sent with a specific ISI. It 
   is used to monitor in-sequence reception of BBFrames within a 
   Stream, and may be utilised for monitoring functions as a part of 
   link-layer Operations and Management (OAM). In addition, the value 
   is used to verify that BBFrames are consecutive within a Stream when 
   the PP value is used to reassemble frames. 
    
   DF: Data Field [ETSI-S2]. The BBFrame payload. Note this 
   abbreviation is also used for a different function at the IP layer. 
    
   DFL: Data Field Length [ETSI-S2]. The size of the BBFrame payload 
   measured in bits. A set of DFL values have been specified by S.2, 
   corresponding to the set of specified ModCod formats. 
    
   DVB: Digital Video Broadcast [ETSI-DVB]. 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 the Generic 
   Mode of DVB-S2.  
        
   End Indicator [RFC4236]: A value that indicates to the Receiver that 
   there are no further SNDUs present within the current BBFrame.  
    
   Encapsulation Header: The logical group of fields that carry the 
   protocol control information for the encapsulation protocol. 
  
Expires June 2006                                             [page 7] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
   GULE: Generic Stream ULE. The protocol defined in this document. 
    
   GS: Generic Stream. 
    
   ISI: Input Stream Identifier, the second byte of the header of a 
   BBFrame. This value uniquely identifies a specific logical channel 
   within a DVB-S2 multiplex. 
    
   MAC: Medium Access Control [IEEE-802.3]. A link layer protocol  
   defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).  
    
   ModCod: Modulation/Coding. A combination of Modulation and FEC 
   Coding that together determine the size of a BBFrame. 
    
   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-S2 transmission network that is used to identify individual 
   Receivers or groups of Receivers.  
    
   OAM: Operations and Management. 
    
   Packing Threshold: In GULE, this is a period of time an Encapsulator 
   is willing to defer transmission of a partially filled BBFrame to 
   accumulate more SNDUs, rather than use Padding. After the Packet 
   Threshold period, the Encapsulator uses Padding to send the 
   partially filled BBFrame.   
        
   Padding: A sequence of bytes with the value 0xFF that are used after 
   an End Indicator to occupy the unused portion of a BBFrame payload. 
   The DFL field may also be used in place of Padding. 
 
   PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include 
   Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.  
    
   PP, Payload Pointer: In GULE, the PP is a 13-bit pointer located at 
   a fixed position in the encapsulation header of all BBFrames 
   utilising the GULE encapsulation. If the BBFrame contains the start 
   of a GULE SNDU, the PP value SHALL be set to the position of the 
   first byte of the first SNDU within the BBFrame. If the BBFrame 
   contains neither the start of a SNDU (or an End Indicator), the 
   value SHALL be assigned 0xFFFF. 
    
   PSI: Programme 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  
  
Expires June 2006                                             [page 8] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   standards body to convey information about the services carried in a  
     
   SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an 
   encapsulated PDU sent using GULE.  
    
   Stream: A logical flow from an Encapsulator to a set of Receivers. 
   The addresses at the MAC/NPA level and IP level need to be unique 
   within a specific stream (i.e. denoted by a common S.2 ISI value). 
     
   SYNCD: Synchronisation Distance [ETSI-S2]. This is specified for a 
   DVB-S2 packetized stream, where the distance in bits from the start 
   of the DataField to the first start of packet contained in this 
   DataField.  This use resembles the MPEG-2 Payload Pointer, as 
   defined in ULE. The use of SYNCD is not specified for continuous 
   Generic Streams. 
       
   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 Lightweight 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. 
    
    
    
    
    
    
    
    
    
    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
Expires June 2006                                             [page 9] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
3. Description of the Method 
    
   PDUs (IP packets, Ethernet frames or packets from other network 
   protocols) 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. A mode also permits an SNDU to be suspended and 
   resumed in a later BBFrame, 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 MUST be assigned to the same Stream.  
    
   If a SNDU finishes before the end of a BBFrame, but it is not 
   intended to start another SNDU, a stuffing procedure fills the 
   remainder of the BBFrame payload with bytes with a value 0xFF, known 
   as Padding.  
    
   A Receiver that receives a value of 0xFF in place of the start of a 
   SNDU, interprets this as Padding/Stuffing and silently discards the 
   remainder of the BBFrame payload. The payload of the next BBFrame 
   for the same stream will begin with a Payload Pointer of value 
   0x0000, indicating that the next SNDU immediately follows the 
   encapsulation header. The ULE protocol [RFC4236] resembles this, but 
   differs in the procedure that binds it to the MPEG-2 TS physical 
   layer. 
    
 
3.1 GULE Encapsulation Overhead 
    
   Each BBFrame includes a logical encapsulation header. This overhead 
   comprises a set of fixed format fields defined by GULE, shown in the 
   figure below.  
    
   < ------------------- BBFrame ------------------------------- > 
   +---------------------------- ----+---------------------------+ 
   |Ver| Resv | Counter | Resv | PP | CRC-8 |  BBFrame payload   | 
   +---------------------------------+---------------------------+ 
    < ----Encapsulation Overhead---- > 
    
       Figure 1: BBFrame Logical Encapsulation Overhead 
    
   The BBFrame encapsulation is identified by the 4-bit version field. 
   There are also a BBFrame counter (size to be determined), a 13-bit 
   Payload Pointer (aligned to an 8 byte boundary) and an 8-bit CRC-8. 
   All unused fields are reserved for future use. The BBFrame payload 
   is also known as the User Payload [ETSI-S2]. 
    
   A CRC-8 provides an integrity check for the encapsulation overhead. 
   It also guards against framing misalignment that may otherwise 
   result following corruption of the PP value. The polynomial for 
   computation of the CRC-8 will be defined in this document. 
  
Expires June 2006                                            [page 10] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
   Field   Size of Field                   Notes 
   -----   -----------------------------   ----- 
    -      -                               Identifies the GULE format. 
    ver    (4 bits + 4 reserved bits)      *1 
    Counter(8 bits)                        For use in OAM *2 
    PP     (13 bits)                       Measured in bytes. 
           (3 bits)                        Reserved for future use. 
    CRC    CRC-8                           Overhead integrity check. 
    
   Notes: 
   *1 Usage to be confirmed. 
   *2 Also used to verify that BBFrames are consecutive within a Stream 
   when the PP value is used to reassemble SNDUs. 
    
   Table 1: Encapsulation Overhead Protocol Fields 
    
   The specification described by this document does not define a 
   transmission format for the logical encapsulation header. The 
   approach recommended in this document is to include this 
   encapsulation overhead within the BBFrame Header itself (Section 
   3.2). An alternative is to prefix as a fixed-sized protocol header 
   within the BBFrame payload, placed following the BBFrame header 
   defined by DVB-S2 (Section 3.3). 
    
3.2 Placement of the Encapsulation Header within the BBHeader 
    
   This section describes the physical placement of the extension 
   overhead fields within the header of a BBFrame [ID-S2-REQ], known as 
   the BaseBand Header (BBH) [ETSI-S2].  These fields are placed into 
   positions that are currently unused within the DVB S.2 BBH when 
   sending in the Generic Mode. This placement eliminates the need for 
   a separate Encapsulation header.  
 
   Field   Corresponding BB Header Field   Notes 
   -----   -----------------------------   ----- 
           MATYPE (2B)                     Identifies the GULE format. 
           ISI (1B subfield)               Identifies the stream. 
   0000    User Payload Length, UPL (2B)*1 Identifies the GULE format.                
           Data Field Length, DFL (2B)*2   As used in S.2 TS. 
    ver    Sync Pattern SYNCD (1B)*1       
    Counter                                For use in OAM. 
    PP     Sync Distance SYNCD (2B)*1      Equivalent function.  
    CRC    CRC-8 *2                        Function already provided. 
    
   Notes:  
   *1 The usage of this BBH field is not specified in the DVB-S2 
   Specification for the Generic Mode [ID-S2-REQ]. 
   *2 This BBH field is specified in the S.2 Specification and use in 
   the Generic Mode [ID-S2-REQ] is identical to use for Transport 
   Streams [ISO-MPEG]. 
    
                        Table 2: BBFrame Header Structure 
  
Expires June 2006                                            [page 11] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
   Usage of these fields (as in Table 2) within the BB header is 
   subject to clarification of acceptable usage for the Generic Mode 
   within the DVB-S2 Standard [ETSI-S2].  
    
 
3.3 BB Encapsulation Header within the BBFrame Payload 
     
   This section describes an alternative method for communicating the 
   encapsulation protocol overhead, in the case where the fields in the 
   BBFrame header are not accessible to the GULE Gateway/Receiver. 
    
   The payload of each BBFrame starts with an encapsulation header  
   defined by GULE. The GULE encapsulation header is sent as the first 
   bytes of every BBFrame transmitetd by an encapsulation Gateway.  
        
   The BBFrame encapsulation header is of a fixed format. This 
   comprises an 8-bit BBFrame counter, a 16-bit Payload Pointer field 
   and an 8-bit CRC-8.   
    
   XXX Future revisions of this document may define additional fields 
   within this header to accelerate processing of the GULE Receiver. 
   XXX 
        
   The CRC-8 provides an integrity check for the entire GULE 
   encapsulation header, and guards against framing mis-alignment that 
   may otherwise result following corruption of the PP value. The 
   polynomial for computation of the CRC-8 is identical to that 
   specified for the BBHeader in [DVB-S2].  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
 
    
    
    
    
    
    
    
  
Expires June 2006                                            [page 12] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
4. SNDU Format 
    
   This section is Informative, the formats described in this section 
   are defined by ULE [RFC4236]. 
    
   PDUs are encapsulated using ULE to form an SNDU. The encapsulation 
   format to be used for PDUs is illustrated below: 
    
   < ----------------------------- SNDU ----------------------------- > 
   +-+-----------------------------------------------------+----------+ 
   |D| Length | Type | Dest Address* |           PDU       | CRC-32** | 
   +-+-----------------------------------------------------+----------+ 
    
       Figure 2: SNDU Encapsulation (* optional Destination Address) 
   (** CRC-32 is optional for some formats of SNDU) 
    
   This format is identical that defined for ULE [RFC4236]. All multi-
   byte values (including the Length/End Indicator (4.2,4.3), Type 
   (4.4), Destination Address (4.5), and Extension Headers (5)) are 
   transmitted in network byte order (most significant byte first). The 
   most significant bit of each byte is placed in the left-most 
   position of the 8-bit field.  
    
    
4.1 Destination Address Absent (D) Field 
    
   The most significant bit of the Length Field carries the value of 
   the Destination Address Absent Field, the D-bit. A value of 0 
   indicates the presence of the Destination Address Field (see section 
   4.5). A value of 1 indicates that a Destination Address Field is not 
   present.  
    
   An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other 
   SNDUs SHOULD be sent with a D-bit value of 0 (see 4.5). 
    
    
4.2 Length Field 
    
   A 15-bit value that indicates the length, in bytes, of the SNDU 
   counted from the byte following the Type field, up to and including 
   the CRC (when present). Note the special case described in 4.3. 
    
    
4.3 End Indicator 
    
   When the first two bytes of an SNDU have the value 0xFFFF, this 
   denotes an End Indicator (i.e., all ones length combined with a  
   D-bit value of 1). This indicates to the Receiver that there are no 
   further SNDUs present within the current BBFrame (see section 6), 
   and that no Destination Address Field is present.  
    
    
    
  
Expires June 2006                                            [page 13] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
4.4 Type Field 
    
   The 16-bit Type field indicates the type of payload carried in an 
   SNDU, or the presence of a Next-Header. The set of values that may 
   be assigned to this field is divided into two parts, similar to the 
   allocations for Ethernet.  
    
   The first set of ULE Type field values comprise the set of values 
   less than 1536 in decimal.  These Type field values are IANA 
   assigned (see 4.4.1), and indicate the Next-Header. 
    
   The second set of ULE Type field values comprise the set of values 
   greater than or equal to 1536 in decimal. In ULE, this value is 
   identical to the corresponding type codes specified by the IEEE/DIX 
   type assignments for Ethernet and recorded in the IANA EtherType 
   registry. 
    
    
4.4.1 Type 1: Next-Header Type Fields 
    
   The first part of the Type space corresponds to the values 0 to 1535 
   Decimal. These values may be used to identify link-specific 
   protocols and/or to indicate the presence of Extension Headers that 
   carry additional optional protocol fields. The format is defined by 
   ULE and the ULE registry maintained by the IANA. 
    
    
4.4.2 Type 2: EtherType Compatible Type Fields 
    
   The second part of the Type space corresponds to the values between 
   0x600 (1536 decimal) and 0xFFFF.  This set of type assignments 
   follow DIX/IEEE assignments (but exclude use of this field as a 
   frame length indicator).  All assignments in this space MUST use the 
   values defined for IANA EtherType, the following two Type values are 
   used as examples (taken from the IANA EtherTypes registry): 
    
           0x0800: IPv4 Payload (see 4.7.2) 
           0x86DD: IPv6 Payload (see 4.7.3) 
    
    
4.5 SNDU Destination Address Field 
    
   The SNDU Destination Address Field is optional (see 4.1). 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 
   an IP unicast packet and/or multicast packets delivered to 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. 
    

  
Expires June 2006                                            [page 14] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   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 DVB-S2 transmission network 
   that should process a received SNDU. The value 0x00:00:00:00:00:00, 
   MUST NOT be used as a destination address in an SNDU. The least 
   significant bit of the first byte of the address is set to 1 for 
   multicast frames, and the remaining bytes specify the link layer 
   multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the 
   link broadcast address, indicating this SNDU is to be delivered to 
   all Receivers. 
    
   IPv4 packets carrying an IPv4 subnetwork broadcast address need to 
   be delivered to all systems with the same network prefix.  When a 
   SNDU Destination Address is present (D=0) the value MUST be set to 
   the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).  
    
   When the PDU is an IP multicast packet and an SNDU Destination 
   Address is present (D=0), the IP group destination address of the 
   multicast packet MUST be mapped to the multicast SNDU Destination 
   Address (following the method used to generate a destination MAC 
   address in Ethernet). The method for mapping IPv4 multicast 
   addresses is specified in [RFC1112]. The method for mapping IPv6 
   multicast addresses is specified in [RFC2464]. 
    
    
4.6 SNDU Trailer CRC 
    
   A SNDU may carry a 32-bit CRC field in the last four bytes of the 
   SNDU. This position eases CRC computation by hardware.  The CRC-32 
   polynomial is to be used. Examples where this polynomial is also 
   employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and 
   AAL5 [ITU-3563]. This is a 32 bit value calculated according to the 
   generator polynomial represented 0x104C11DB7 in hexadecimal: 
      
   x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0. 
    
   The Encapsulator initialises the CRC-32 accumulator register to the 
   value 0xFFFF FFFF.  It then accumulates a transmit value for the 
   CRC32 that includes all bytes from the start of the SNDU header to 
   the end of the SNDU (excluding the 32-bit trailer holding the CRC-
   32), and places this in the CRC Field. In ULE, the bytes are 
   processed in order of increasing position within the SNDU, the order 
   of processing bits is NOT reversed.  This use resembles, but is 
   different to that in SCTP [RFC3309].   
    
   When present, the Receiver performs an integrity check by 
   independently calculating the same CRC value and comparing this with 
   the transmitted value in the SNDU trailer. SNDUs that do not have a 
   valid CRC, are discarded. 
    

  
Expires June 2006                                            [page 15] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   This description may be suited for hardware implementation, but this 
   document does not imply any specific implementation.  Software-based 
   table-lookup or hardware-assisted software-based implementations are 
   also possible. Annexe B provides an example of an Encapsulated PDU 
   that includes the computed CRC-32 value. 
    
   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 while the SNDU is in 
   transit across the DVB-S2 subnetwork and during processing at the 
   encapsulation gateway and/or the Receiver. It serves to verify the 
   delineation (framing) of PDUs and may also detect the presence of 
   uncorrected errors from the physical link (however, these may also 
   be detected by other means, e.g. section 7.3). When a MAC?NPA 
   address is present, it binds the SNDU to the specified address.  
    
   The presence of a CRC field is determined by the format of the SNDU 
   (specified in the Type field of the Header). Formats by default 
   SHOULD include a CRC, exceptions include amn End Indicator, the 
   SNDU-Suspend and SNDU-Resume fragments. 
    
4.7 Description of SNDU Formats 
    
   The format of an SNDU is determined by the combination of the 
   Destination Address Absent bit (D) and the SNDU Type Field. The 
   simplest encapsulation places a PDU directly into an SNDU payload.  
   Some Type 1 encapsulations may require additional header fields. 
   These are inserted in the SNDU following the NPA/MAC destination 
   address and directly preceding the PDU.  
    
   Formats may be defined through relevant assignments in the IEEE and 
   IANA registries. 
    
    
4.7.1 End Indicator 
    
   The format of the End Indicator is defined by ULE [ULERFC]. It is 
   shown in figure 2. This format MUST carry a D-bit value of 1. 
    
       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|                            0x7FFF                           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      =   A sequence of zero or more bytes with a value 0xFF filling  =  
      |           the remainder of BB frame payload                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
     Figure 3: Format for a ULE End Indicator. 
    
    

  
Expires June 2006                                            [page 16] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
4.7.2 IPv4 SNDU  
    
   IPv4 datagrams are directly transported using one of the two 
   standard SNDU structures, in which the PDU is placed directly in the 
   SNDU payload. The formats are defined by ULE [ULERFC]. The two 
   encapsulations are shown in figures 4 and 5. (Note that in this, and 
   the following figures, the IP datagram payload is of variable size, 
   and is directly followed by the CRC-32). 
    
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|        Length  (15b)        |         Type = 0x0800         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            Receiver Destination NPA Address  (6B)             | 
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                               |                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
      |                                                               | 
      =                           IPv4 datagram                       = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Figure 4: SNDU Format for an IPv4 Datagram using L2 filtering (D=0). 
    
    
          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 = 0x0800         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      =                           IPv4 datagram                       = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Figure 5: SNDU Format for an IPv4 Datagram using L3 filtering (D=1). 
    
    
4.7.3 IPv6 SNDU Encapsulation 
    
   IPv6 datagrams are directly transported using one of the two 
   standard SNDU structures, in which the PDU is placed directly in the 
   SNDU payload, as defined by ULE [ULERFC].  The two encapsulations 
   are shown in figures 6 and 7. 
    
        
    
    
  
Expires June 2006                                            [page 17] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|        Length  (15b)        |         Type = 0x86DD         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |            Receiver Destination NPA Address  (6B)             | 
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                               |                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + 
      |                                                               | 
      =                           IPv6 datagram                       = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Figure 6: SNDU Format for an IPv6 Datagram using L2 filtering (D=0). 
    
    
       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 = 0x86DD         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      =                           IPv6 datagram                       = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Figure 7: SNDU Format for an IPv6 Datagram using L3 filtering (D=1) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

  
Expires June 2006                                            [page 18] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
 5. Extension Headers  
    
   This section describes an extension format for the ULE 
   encapsulation. In ULE, a Type field value less than 1536 Decimal 
   indicates an Extension Header. These values are assigned from a 
   separate IANA registry defined for ULE [ELE-RFC].  
    
   The use of a single Type/Next-Header field simplifies processing and 
   eliminates the need to maintain multiple IANA registries. The cost 
   is that each Extension Header requires at least 2 bytes. This is 
   justified, on the basis of simplified processing and maintaining a 
   simple lightweight header for the common case when no extensions are 
   present. 
    
   A ULE Extension Header is identified by a 16-bit value in the Type 
   field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN 
   field and an 8-bit H-Type field, as follows: 
    
           0                   1 
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          |0 0 0 0 0|H-LEN|    H-Type     | 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Figure 8: Structure of ULE Next-Header Field [RFC4236]. 
    
    
   The H-LEN value indicates the total number of bytes in an Optional 
   Extension Header (including the 2B Type field) [RFC4236]. 
    
   An H-LEN value of zero indicates a Mandatory Extension Header. Each 
   Mandatory Extension Header has a pre-defined length that is not 
   communicated in the H-LEN field. No additional limit is placed on 
   the maximum length of a Mandatory Extension Header. A Mandatory 
   Extension Header MAY modify the format or encoding of the enclosed 
   PDU (e.g. to perform encryption and/or compression). 
    
   The H-Type is a one byte field that is either one of 256 Mandatory 
   Header Extensions or one of 256 Optional Header Extensions. This is 
   defined by ULE [RFC4236]. 
    
   The general format for an SNDU with Extension Headers is: 
    
   < --------------------------   SNDU   ------------------------- > 
   +---+--------------------------------------------------+--------+ 
   |D=0| Length | T1 | NPA Address | H1 | T2 |    PDU     | CRC-32 | 
   +---+--------------------------------------------------+--------+ 
   < ULE base header >             <  ext 1  > 
    
   Figure 9: SNDU Encapsulation with one Extension Header (for D=0). 
    
   Where: 
   D is the ULE D_bit (in this example D=0, however NPA addresses may    
  
Expires June 2006                                            [page 19] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
     also be omitted when using Extension Headers). 
   T1 is the base header Type field. In this case, specifying a  
      Next-Header value. 
   H1 is a set of fields defined for header type T1.  There may be 0  
      or more bytes of information for a specific ULE Extension Header. 
   T2 is the Type field of the next header, or an EtherType > 1535 B  
      indicating the type of the PDU being carried. 
    
    
   < --------------------------   SNDU   ------------------------- > 
   +---+---------------------------------------------------+--------+ 
   |D=1| Length | T1 | H1 | T2 | H2 | T3 |       PDU       | CRC-32 | 
   +---+---------------------------------------------------+--------+ 
   < ULE base header >< ext 1 >< ext 2 > 
    
   Figure 9: SNDU Encapsulation with two Extension Headers (D=1). 
    
   Using this method, several Extension Headers MAY be chained in 
   series [RFC4236]. Although an SNDU may contain an arbitrary number 
   of consecutive Extension Headers, it is not expected that SNDUs will 
   generally carry a large number of extensions. 
    
    
5.1 Test SNDU 
    
   A Test SNDU is a Mandatory Extension Header of Type 1, specified by 
   ULE [RFC4236].  
    
    
5.2 Bridge Frame SNDU Encapsulation 
    
   A bridged SNDU is a Mandatory Extension Header of Type 1 specified 
   by ULE [RFC4236].  
    
    
5.3 Extension-Padding Optional Extension Header 
    
   The Extension-Padding Optional Extension Header is s specified by 
   ULE [RFC4236].  
    
    
 
 










  
Expires June 2006                                            [page 20] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
5.4 MPEG-2 TS Extension  
    
   The MPEG-2 TS Extension Header is specified by an IANA assigned H-
   Type value of <tbd>. This is a Mandatory Extension.  The extension 
   is used to communicate 1 or more MPEG-2 TS Packets over the DVB-S2 
   link when utilising the Generic Mode. 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. A 
   Receiver MUST silently discard any data, if present, between the 
   last complete encapsulated MPEG-2 TS Packet and the size denoted in 
   the Length field of the SNDU fragment base header.  
    
   A value of D=1 indicates there is no NPA/MAC address in use. A value 
   D=0 is also permitted, as defined in ULE. 
     
   The extension may be used to communicate 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 
   and clock references. 
    
    
       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 = 0xtbd          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   TS-Packet 1                                 | 
      =                                                               = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   TS-Packet 2 (if Length > 2*188)             | 
      =                                                               = 
      |                              etc.                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Figure 10: SNDU Format for a TS-Packet Payload (D=1) 
    
    
5.5 SNDU-Resume Extension 
    
   The SNDU-Resume Extension is specified by an IANA assigned H-Type 
   value of <tbd>. This is a Mandatory Extension.  The extension is 
   used to send the remainder of a suspended SNDU.  It MAY be used at 
   any time by Gateway which has already sent the first part of a SNDU. 
    
   The payload of an SNDU-Resume Extension contains a Fragment of a 
   SNDU payload. The final fragment includes the SNDU CRC value 
   calculated over the entire (reassembled) SNDU. This CRC is used to 
   verify the integrity and reassembly of the complete PDU. It also 
   binds this to the MAC address for the case D=0. 
    
  
Expires June 2006                                            [page 21] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   The Length field in an SNDU-Resume Extension fragment specifies the 
   size of the SNDU-Resume payload. 
    
   A Receiver that receives an SNDU-Resume fragment that it will not 
   process/forward MUST silently discard all bytes from the fragment, 
   it MUST NOT check the CRC value of the fragment, and proceeds with 
   processing of the next in-sequence SNDU. 
    
   An SNDU that carries an SNDU-Resume Extension fragment that contains 
   the final Fragment of a suspended SNDU carries the 4 byte CRC of the 
   complete SNDU (that would have been sent at the end of the of the 
   original SNDU, had the SNDU not been suspended). This CRC is follows 
   the SNDU payload and is included in the calculated Length of the 
   SNDU that carries this final Fragment (figure 11).  
    
   It is allowed to have a SNDU-Resume fragment with a Length less than 
   the total remaining bytes (see Appendix for an example), however 
   these fragments do NOT contain a CRC field. 
    
 
       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 = 0xtbd          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      =             Continuation of a previous SNDU Payload           = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             CRC of Complete reassembled SNDU *                | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
   * If the SNDU-Resume fragment contains the final byte of a SNDU, the 
   CRC-32 of the original SNDU (prior to fragmentation) is appended to 
   the SNDU-Resume fragment to form the CRC field (and included in the 
   Length calculation). This is not the CRC of the fragment, but in 
   this case the CRC of the complete reassembled SNDU. If further SNDU-
   Resume fragments would be required to complete the SNDU, the CRC 
   field is omitted. 
    
   Figure 11: SNDU Format for a SNDU-Resume Payload (D=1). 
    
   If the number of bytes to be sent in an SNDU-Resume Extension 
   fragment exceeds the unfilled space in the BBFrame payload, then the 
   Encapsulator SHOULD by default continue transmission in the next 
   BBFrame for the same stream. However, it MAY instead choose (e.g. 
   utilising a local policy with ACM coding to optimise overall 
   efficiency) to suspend the partially sent frame.  
    
    
    
    
    
  
Expires June 2006                                            [page 22] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
5.5.1 SNDU-Resume Extension fragment processing 
    
   A receiver may receive a BBFrame containing zero or more SNDUs that 
   carry the SNDU-Resume Extension. 
    
   The Receiver SHOULD provisionally accept all SNDUs with a Length 
   that is greater than the number of bytes remaining in the BBFrame, 
   these are called Fragments. A Receiver MAY silently discard such 
   SNDUs to recover the space in previously allocated reassembly 
   buffers, or to limit processing, e.g. if it believes it is under a 
   DoS attack, the resources consumed exceed some threshold, or other 
   information indicates the frame has been corrupted by physical layer 
   errors. A receiver MUST also configure a Fragment-timeout. Fragments 
   that have been buffered for more than this predetermined period MUST 
   be discarded (this procedure MUST be invoked when an encapsulation 
   Gateway is restarted, and MAY be invoked via the control interface). 
    
   To reassemble the Fragments of a fragmented SNDU, a Receiver should 
   buffer up to one full-sized SNDU for each NPA/MAC filter for which 
   it expects to receive SNDUs. Reassembly is performed independently 
   for each Stream that the Receiver is configured to receive. A 
   Receiver may be configured to receive an arbitrary large number of 
   multicast NPA/MAC addresses over a single Stream. This is in 
   contrast to normal reassembly, where a Receiver needs to buffer at 
   most one SNDU per Stream. 
 
   The Receiver detects the presence of a Fragment, when the SNDU 
   Length is greater than the number of bytes remaining in a BBFrame, 
   and the next BBFrame for the same Stream had a PP value of zero.  
    
   The processing of fragments uses the following rules: 
    
        1) Under-sized SNDU 
        The Receiver receives a subsequent SNDU-Resume Extension 
        fragment with the same NPA/MAC address of a fragment that is 
        pending reassembly for the Stream, and which contains less than 
        the expected number of bytes required to complete the SNDU 
        payload (SNDU Length of original base header). The Fragments 
        SHOULD be added to the set of Fragments to be later 
        reassembled. 
         
        2) Correct-sized SNDU 
        The Receiver receives a subsequent SNDU-Resume Extension 
        fragment with a NPA/MAC address that matches a Fragment pending 
        reassembly for the Stream, and which contains the expected 
        number of bytes required to complete the SNDU payload. The 
        Fragments are then reassembled and the CRC-32 is validated. An 
        invalid CRC-32 MUST result in SNDU discard. The Receiver 
        continues processing the next SNDU in the BBFrame. 
         
        3) Over-Sized SNDU 
        The Receiver receives a subsequent SNDU-Resume Extension 
        Fragment that matches the NPA/MAC address of a Fragment pending 
  
Expires June 2006                                            [page 23] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
        reassembly for the Stream, and which contains more than the 
        expected number of bytes required to complete the SNDU payload. 
        This is a framing error. All Fragments for this combination of 
        Stream and NPA/MAC address MUST be discarded. The Receiver 
        continues processing the next SNDU in the BBFrame.  
         
        4) Unexpected Fragment 
        The Receiver receives a SNDU that is an SNDU-Resume Extension 
        Fragment, but for which it has no Fragments pending reassembly 
        with the same NPA/MAC address for the Stream. This is not a 
        framing error. All Fragments for this combination of Stream and 
        NPA/MAC address MUST be discarded and the Receiver will 
        continue processing of the next received SNDU. 
         
        5) Unexpected SNDU 
        The Receiver receives a SNDU that is not an SNDU-Resume 
        Extension fragment, but has the same NPA/MAC address of a 
        Fragment that is pending reassembly for the Stream. This is a 
        framing error. All Fragments for this combination of Stream and 
        NPA/MAC address MUST be discarded. The Receiver then continues 
        processing the next received SNDU. 
         
        6) Invalid Length 
        The Receiver receives a SNDU with an invalid Length of a 
        Fragment. The SNDU MUST be discarded, and the Receiver enters 
        the Idle state (see section 7). 
         
        7) Time-out 
        Within the period specified by the specified Fragment-timeout 
        (see section 7), the Receiver does not receive an SNDU with a 
        subsequent SNDU-Resume Extension for a NPA/MAC address for 
        which it has Fragments outstanding. This is a framing error. 
        All Fragments for this combination of Stream and NPA/MAC 
        address MUST be discarded. The Receiver continues processing 
        the next received SNDU. 
         
        8) Abort 
        The Receiver decides by other means that it will abort the 
        reassembly processing. This is a not framing error. All 
        Fragments for this combination of Stream and NPA/MAC address 
        will be discarded. The Receiver continues processing the next 
        received SNDU. 
         
    
    
 
 
 
 
 



  
Expires June 2006                                            [page 24] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
5.5.1 SNDU-Resume Extension reassembly 
    
   No specific algorithm for reassembly processing is mandated in this 
   specification. Implementers may choose to reassemble SNDU Fragments 
   as they are received, or only when all fragments are received. 
    
   When a Receiver has accumulated a set of Fragments with the Length 
   specified in the SNDU in the base header of the first suspended 
   Fragment, it must validate the reassembly. The total accumulated 
   size of all SNDU fragments (including the SNDU CRC in the final 
   fragment) MUST exactly match this Length. SNDUs with an inconsistent 
   length MUST be discarded (a framing error may be recorded).   
    
   The Receiver MUST verify the SNDU CRC value carried in the final 4 
   bytes of the final fragment of a SNDU that it has reassembled. This 
   value is used to verify the integrity of the reassembled SNDU. 
   A Receiver MUST ignore the SNDU CRC value of an SNDU-Resume fragment 
   that is incomplete or has not been reassembled. 
    
   A successfully reassembled SNDU payload is processed according to 
   the Type field specified in the base header of the first suspended 
   Fragment (i.e. the start of the SNDU). 
    
 
5.6 SNDU-Suspend Extension 
    
   The normal (continuous) method of transmission of a SNDU requires 
   that a SNDU can only be fragmented if it is positioned at the end of 
   a BBFrame. The sender can therefore only start one fragmented SNDU 
   in each BBFrame, while this bounds processing costs per BBFrame, it 
   can impose scheduler limitations. 
    
   Use of the method described in this section allows more scheduler 
   flexibility. A Gateway using this method MUST use the SNDU-Resume 
   method to transmit the remainder of the SNDU payload. 
    
   The SNDU-Suspend Extension is specified by an IANA assigned H-Type 
   value of <tbd>. This is a Mandatory Extension.  It enables a sender 
   to start a SNDU at an arbitrary position within a BBFrame, and to 
   then suspend processing to allow the SNDU to be completed in a 
   subsequent BBFrame (or aborted). It MAY be used at any time by 
   Gateway that wishes to start a new SNDU. 
    
   The extension header specifies the number of bytes sent in the 
   current fragment (always less than the SNDU Length). The normal use 
   of this extension is to allow a Gateway to start more than one 
   different fragmented SNDU in the same BBFrame, in this case the 
   Suspended-Length will be less than the number of bytes remaining 
   within a BBFrame. 
    
   A value of D=1 indicates there is no NPA/MAC address in use. A value 
   D=0 is also permitted, as defined in ULE, and in this case a MAC/NPA 
   address is attached to the SNDU base header. 
  
Expires June 2006                                            [page 25] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
    
    
       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 = 0xtbd-Suspend         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |R|   Suspended-Length  (15b)   |     Type                      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      =                        Start of a PDU                         = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
       Figure 12: SNDU Format for a SNDU-Suspend Payload (D=1) 
    
    
    
5.7 SNDU-Concat Extension 
    
   The SNDU-Concat Extension is specified by an IANA assigned H-Type 
   value of <tbd>. This is a Mandatory Extension.  It enables a 
   sequence of (usually short) PDUs to be sent within a single SNDU 
   payload. Each PDU is prefixed by its length in bytes. The Receiver 
   processes this type of SNDU by extracting each SNDU in turn. The 
   Receiver first verifies the Length and CRC of the SNDU. A Receiver 
   MUST silently discard any data, if present, after the last complete 
   encapsulated PDU. 
    
       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 = 0xtbd-concat          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         EtherType             |0|           Length  (15b)     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      =                        PDU-1                                  = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|           Length  (15b)     |                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               | 
      =                        PDU-2                                  = 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             (CRC-32)                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
       Figure 13: SNDU Format for a SNDU-Concat Payload (D=1) 
    
   A value of D=1 indicates there is no NPA/MAC address in use. A value 
   D=0 is also permitted, as defined in ULE, and in this case a MAC/NPA 
   address is attached to the SNDU base header. When D=1, the Receiver 
   MUST associate the specified MAC/NPA address with all PDUs within 
  
Expires June 2006                                            [page 26] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   the SNDU Payload. This MAC/NPA address MUST also be forwarded with 
   each PDU, if required by the forwarding interface. 
 
 
6. Processing at the Encapsulator  
    
   The Encapsulator forms the PDUs queued for transmission into SNDUs 
   by adding a header and trailer to each PDU (section 4). It then 
   segments the SNDU into a series of BBFrame payloads (figure 9). 
   These are transmitted using a single DVB-S2 Logical Channel (denoted 
   by a specific ISI). Each BBFrame carries a Counter value, that is 
   incremented modulo 255 after transmission of the BBFrame. 
    
                +------+------------------------------+------+ 
                |ULE   |      Protocol Data Unit      |ULE   | 
                |Header|                              |CRC-32| 
                +------+------------------------------+------+ 
               /                      /\                      \ 
              /                      /  \                      \  
             /                      /    \                      \        
   +-------+-----------------------+      +-------+-------------------+ 
   |Encaps |                       |      |Encaps |                   | 
   |Header |                       |      |Header |                   | 
   +-------+-----------------------+      +-------+-------------------+ 
    
   Figure 14: Encapsulation of an SNDU into a series of BBFrames  
    
    
6.1 SNDU Encapsulation 
    
   When an Encapsulator has not previously sent a SNDU for a specific 
   Stream, or after an Idle period, it starts to send an SNDU in the 
   first available BBFrame.  This BBFrame MUST carry a Payload Pointer 
   value of zero indicating the SNDU starts in the first available byte 
   of the BBFrame payload.  
    
   The Encapsulation MUST ensure that all BBFrames incremented by one 
   (e.g. modulo 256 for an 8-bit value) the Counter carried in the 
   Encapsulation header.  
    
   An Encapsulator MAY decide not to immediately send another SNDU, 
   even if space is available in a partially filled BBFrame payload. 
   This procedure is known as Padding (figure 11). The End Indicator 
   informs the Receiver that there are no more SNDUs in this BBFrame 
   payload. The End Indicator is followed by zero or more unused bytes 
   until the end of the BBFrame payload. All unused bytes MUST be set 
   to the value of 0xFF. The Padding procedure trades decreased 
   efficiency against improved latency. 
    
    
    



  
Expires June 2006                                            [page 27] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
        
                 +-/------------+ 
                 |  SubNetwork  | 
                 |     DU 3     | 
                 +-/------------+ 
                        \        \ 
                         \        \ 
                          \        \ 
                 +--------+--------+--------+----------+ 
                 | Encaps | End of | 0xFFFF |  Unused  | 
                 | Header | SNDU 3 |        |  Bytes   | 
                 +--------+--------+--------+----------+ 
                                     ULE 
                                     End 
                                     Indicator 
    
   Figure 15: A BBFrame carrying the end of SNDU 3, followed by an End 
   Indicator. 
    
   Alternatively, when more packets are waiting at an Encapsulator, and 
   the BBFrame has sufficient space remaining in the payload, the 
   Encapsulator can follow a previously encapsulated SNDU with another 
   SNDU using the next available byte of the BBFrame payload (see 6.2). 
   This is called Packing (figure 16). 
    
              +-/----------------+       +----------------/-+ 
              |   Subnetwork     |       |   Subnetwork     | 
              |      DU 1        |       |      DU 2        | 
              +-/----------------+       +----------------/-+ 
                         \        \     /          /\ 
                          \        \   /          /  \ 
                           \        \ /          /    \. . . 
          +--------+--------+--------+----------+ 
          | Encaps | Payload| end of | start of | 
          | Header | Pointer| SNDU 1 | SNDU 2   | 
          +--------+--------+--------+----------+ 
                       |              ^ 
                       |              | 
                       +--------------+ 
    
   Figure 16: A BBFrame with the end of SNDU 1, followed by SNDU 2. 
    
    
6.2 Procedure for Padding and Packing 
    
   Use of the Packing method by an Encapsulator is optional, and may be 
   determined on a per-session, per-packet, or per-SNDU basis. 
    
    
6.3 Suspend/Resume processing 
    
   An encapsulation gateway MAY also decide to suspend a SNDU at the 
   end of BBFrame. In this case, it may continue transmission by 
  
Expires June 2006                                            [page 28] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   sending SNDUs to other MAC addresses within the same Stream.  It 
   MUST however preserve FIFO delivery of packets with the same MAC 
   address by either sending a subsequent SNDU-Resume fragment (see 
   section 5) or by aborting the suspended SNDU (by starting a new SNDU 
   with the same MAC address).  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
Expires June 2006                                            [page 29] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
7. Receiver Processing 
    
   A Receiver tunes to a specific S2 Multiplex and sets a receive 
   filter to accept all Packets from a specific Stream. A single 
   Receiver may be able to receive multiple Streams.  In each case, 
   reassembly MUST be performed independently for each Stream. To 
   perform reassembly, the Receiver may use a buffer to hold the 
   partially assembled SNDUs (when the SNDU-Resume extension is used, 
   the buffers are managed separately for each active MAC/NPA address). 
   The buffer is referred to here as the Current SNDU buffer. Other 
   implementations may choose to use other data structures, but MUST 
   provide equivalent operations. 
    
   Receipt of a BBFrame with a PP value not equal to 0xFFFF indicates 
   that the BBFrame contains the start of a new SNDU.  The value of the 
   Payload Pointer indicates the number of bytes to the start of the 
   first SNDU in the BBFrame. It is illegal to receive a Payload 
   Pointer value greater than the size of the BBFrame payload, and this 
   MUST cause the SNDU reassembly to be aborted and the Receiver to 
   enter the Idle State.  This event SHOULD be recorded as a payload 
   pointer error. 
    
   A Receiver MUST support the use of both the Packing and Padding 
   method for any received SNDU, and MUST support reception of SNDUs 
   with or without a Destination Address Field (i.e. D=0 and D=1). 
    
   In GULE, the buffers that hold partially reassembled PDUs destined 
   for each NPA/MAC address MAY be released at any time, and SHOULD be 
   released after holding a buffer pending completion for a maximum of 
   256 BBFrames (with the same ISI). A simple way to implement this, is 
   to mark each partially reassembled frame with the BBFrame Counter 
   value of the BBFrame in which the SNDU started, and to abort (i.e. 
   discard the memory buffer) when the BBFrame Counter of a later 
   BBFrame increments to the stored value.  This mechanism imposes a 
   maximum fragment lifetime within the DVB-S.2 link, ensuring that 
   badly formed fragments are purged from the Receiver.  The value 255 
   was chosen as a balance between memory usage, and the need for 
   flexible fragmentation of 
   large PDUs. 
    
    
7.1 Idle State 
    
   After initialisation, errors, or on receipt of an End Indicator, the 
   Receiver enters the Idle State. In this state, the Receiver discards 
   all BBFrames until it discovers the start of a new SNDU (using the 
   PP value), when it then enters the Reassembly State.  
    
   The Idle State does NOT normally result in the discard of any 
   buffered SNDU Fragments. The space in buffers occupied by Fragments 
   that are no longer required is recovered by other means (section 7). 
    
   Figure 17 outlines these state transitions:  
  
Expires June 2006                                            [page 30] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
 
                                +-------+ 
                                | START | 
                                +---+---+ 
                                    | 
                                   \/ 
                               +----------+ 
                              \|   Idle   |/ 
                      +-------/|   State  |\-------+ 
         Insufficient |        +----+-----+        | 
         unused space |             | PP valid     | Physical Error 
         or           |            \/              | or 
         End Indicator|        +----------+        | SNDU Error 
                      |        |Reassembly|        | 
                      +--------|  State   |--------+ 
                               +----------+ 
    
   Figure 17: Receiver state transitions 
    
 
    
7.1.1 Idle State Payload Pointer Checking 
    
   A Receiver in the Idle State MUST check the PP value in the BBFrame 
   header of all received BBFrames. Following a loss of 
   synchronisation, the Receiver MUST discard the number of bytes 
   indicated by the Payload Pointer (counted from the first byte of the 
   BBFrame payload field), before leaving the Idle State. It then 
   enters the Reassembly State, and starts reassembly of a new SNDU at 
   this point. 
    
    
7.2 Processing of a Received SNDU 
    
   When in the Reassembly State, the Receiver reads a 2 byte SNDU 
   Length Field from the BBFrame payload. If the value is less than or 
   equal to 4, or equal to 0xFFFF, the Receiver discards the Current 
   SNDU and the remaining SNDU payload (and any Fragments pending 
   reassembly, see section 5) and returns to the Idle State. Receipt of 
   an invalid Length Field is an error event and SHOULD be recorded as 
   an SNDU length error. 
    
   If the Length of the Current SNDU is greater than 4, the Receiver 
   accepts bytes from the BBFrame payload to the Current SNDU buffer 
   until either Length bytes in total are received, or the end of the 
   BBFrame payload is reached (see also 7.2.1). When Current SNDU 
   length equals the value of the Length Field, the Receiver MUST 
   calculate and verify the CRC value (see 4.6). SNDUs that contain an 
   invalid CRC value MUST be discarded. Mismatch of the CRC is an error 
   event and SHOULD be recorded as a CRC error.  
 

  
Expires June 2006                                            [page 31] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   When the Destination Address is present (D=0), the Receiver accepts 
   SNDUs that match one of a set of addresses specified by the Receiver 
   (this includes the NPA address of the Receiver, the NPA broadcast 
   address and any required multicast NPA addresses). The Receiver MUST 
   silently discard an SNDU with an unmatched address. 
    
   After receiving a valid SNDU, the Receiver MUST check the Type Field 
   (and process any Type 1 Extension Headers). The SNDU payload is then 
   passed to the next protocol layer specified. An SNDU with an unknown 
   Type value < 1536 MUST be discarded. This error event SHOULD be 
   recorded as an SNDU type error. 
    
   The Receiver then starts reassembly of the next SNDU. This MAY 
   directly follow the previously reassembled SNDU within the BBFrame 
   payload.  
    
        (i) If the Current SNDU finishes at the end of a BBFrame, the 
        Receiver MUST enter the Idle State. 
         
        (ii) If only one byte remains unprocessed in the BBFrame 
        payload after completion of the Current SNDU, the Receiver MUST 
        discard this final byte of BBFrame payload. It then enters the 
        Idle State. It MUST NOT record an error when the value of the 
        remaining byte is identical to 0xFF. 
         
        (iii) If two or more bytes of BBFrame payload data remain after 
        completion of the Current SNDU, the Receiver accepts the next 2 
        bytes and examines if this is an End Indicator. When an End 
        Indicator is received, a Receiver MUST silently discard the 
        remainder of the BBFrame payload and transition to the Idle 
        State. Otherwise this is the start of the next Packed SNDU and 
        the Receiver continues by processing this SNDU (provided that 
        the BBFrame has a PP value of less than 0xFFFF, see 7.2.1, 
        otherwise the Receiver has detected a delimiting error and MUST 
        discard all remaining bytes in the BBFrame payload and 
        transitions to the Idle State). 
    
    
7.2.1 Reassembly Payload Pointer Checking 
    
   A Receiver that has partially received an SNDU (in the Current SNDU 
   buffer) MUST check the PP value in the header of the next 
   consecutive BBFrames for the same Stream (consecutive frames are 
   identified by verifying the Counter value associated with the 
   BBFrame).  If the Payload Pointer does NOT equal the number of bytes 
   remaining to complete the Current SNDU, i.e., the difference between 
   the SNDU Length field and the number of reassembled bytes, or the 
   Counter value is not one larger, modulo 255, than in the previous 
   BBFrame for the same Stream) the Receiver has detected a delimiting 
   error, or a suspended frame.  The receiver follows the procedure 
   described in section 5.  
    
    
  
Expires June 2006                                            [page 32] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
7.3 Other Error Conditions 
    
   The Receiver MUST check the BBFrame header and physical layer for 
   information that indicates a BBFrame has been corrupted. If 
   detected, a transmission error event SHOULD be recorded, and the 
   entire BBFrame MUST be discarded. 
    
   The Receiver MUST check the BBFrame Counter of the Encapsulation. If 
   the received value does NOT increment by one for successive BBFrames 
   within a stream (modulo 255), the Receiver has detected a continuity 
   error. A BBFrame counter error event SHOULD be recorded. A loss of 
   continuity implies a Receiver has missed one or more SNDUs (e.g. 
   because they was sent using a ModCod that the Receiver was unable to 
   decode). The missed SNDUs do not necessarily have a NPA/MAC that the 
   Receiver will forward.  The Receiver MUST enter the Idle State, and 
   use the PP value in the new BBFrame to recover framing alignment.  
    
   In Generic Mode, continuity errors may occur because an 
   Encapsulation Gateway uses a ModCod [ETSI-S2, S2-REQ] that does not 
   provide sufficient protection for the receive conditions experienced 
   by a Receiver or a ModCod that is not implemented by a specific the 
   Receiver.  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
Expires June 2006                                            [page 33] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
8. Summary 
    
   This document defines an Generic Unidirectional Lightweight 
   Encapsulation (GULE) to perform efficient and flexible support for 
   IPv4 and IPv6 network services over networks built upon the DVB S2 
   physical layer specification operating in the Generic Mode. The 
   encapsulation is also suited to transport of other protocol packets 
   and bridged Ethernet frames. 
    
   GULE utilises Extension Header format defined by the Uni-directional 
   Lihtweight Encapsulation (ULE) defined by RFC4236 and shares the 
   associated IANA registry for support of both mandatory and optional 
   SNDU headers. 
    
    
9. IANA Considerations  
    
   This document will require IANA involvement for the assignment of 
   two new ULE option headers. These options are defined for specific 
   use cases envisaged by GULE, but are compatible with ULE.  
    
    
10. Acknowledgments 
    
   This draft is based on the ULE protocol specification developed by 
   the IETF ipdvb WG.  The author gratefully acknowledges the inputs, 
   comments and assistance offered by the members of the DVB-GBS ad hoc 
   group on S2 encapsulation, and the inputs provided by the DVB-RCS WG 
   in identifying appropriate protocol requirements. The author also 
   wishes to thank Bernhard Collini-Nocker for his constructive email 
   and to others who have patiently tried to explain DVB-S2. The author 
   particularly wishes to thank Juan Cantillo & Jerome Lacan for their 
   constant attention to detail and their contributions to the 
   definition of the requirements for this protocol spec. The Suspend 
   and Concat modes, and various other improvements followed 
   discussions with Rita Ronaldo and Ulrik de Be.  
    
    
11. Security Considerations 
    
   The security considerations for GULE resemble those of ULE, and 
   security mechanisms developed as ULE extensions are expected to be 
   appropriate also to the use of GULE. 
    
    
    
    
    
    
    
    
    
  
Expires June 2006                                            [page 34] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
12. References 
    
    
12.1 Normative References  
    
   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 
   Requirement Levels", BCP 14, RFC 2119, 1997. 
    
   [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,  
   RFC 1112, August 1989. 
    
   [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet  
   Networks", RFC 2464, December 1998. 
    
   [RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 
   Lightweight Encapsulation (ULE) for transmission of IP 
   datagrams over an MPEG-2 Transport Stream", Formerly <draft-ipdvb-
   arch-xx.txt, RFC 4236, December 2006. 
    
   [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). 
    
    
12.2 Informative References 
    
   [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", 
   European Telecommunications 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. 
    
   [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-Eval] "Procedure for Comparative Evaluation of IP/DVB-S2 
   Encapsulation Protocol over Generic Streams", Technical Note, Work 
   in Progress, DVB TM-GBS. 
    
   [S2-REQ] GBS0339, "Functional and performance requirements for 
   IP/S2", DVB-TM GBS WG. 
    
   [S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB TM RCS WG. 
 
 
  
Expires June 2006                                            [page 35] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
13. 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 
    
14. IPR Notices 
    
14.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. 
    
14.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 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. 
    
    
15. Copyright Statement 
    
   Copyright (C) The Internet Society (2006).  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. 
  
Expires June 2006                                            [page 36] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
Appendix A: Scenarios for Fragmentation 
    
   This appendix provides a set of informative examples of the usage of 
   this encapsulation. 
    
    
A.1 CONSECUTIVE Fragmentation 
    
   This is the normal mode for fragmentation, where there is no 
   additional header overhead resulting from SNDU fragmentation.  SNDU 
   fragments sent to the same NPA/MAC address follow in the next 
   consecutive BBFrame sent to the same stream. These may be 
   interleaved with other BBFrames associated with different streams. 
    
   In the following figure, there are no additional overhead bytes 
   consumed by Fragmentation of F2.  
    
    
      +--------------+ +-------------+ 
      |  F1 |   F2a  | | F2b  |F3    | 
      |*   c|*       | |     c|*    c| 
      +--------------+ +-------------+ 
    
   BBFrame      1       2 
   PP           F2a     F3 
   * = SNDU base header 
   c = SNDU payload CRC-32 
    
   Figure A.1.1 Fragments will follow in the next consecutive BBFrame 
    
   In the figure below, a large SNDU is fragmented across 3 consecutive 
   frames, each sent using the same stream. 
    
      +--------------+ +-------------+ +--------------+ 
      |  F1 |   F2a  | |    F2b      | | F2c |  F3    | 
      |*   c|*       | |             | |    c|*      c| 
      +--------------+ +-------------+ +--------------+ 
    
   BBFrame      1       2               3 
   PP           F2a     0xFFFF          F3 
   * = SNDU base header 
   c = SNDU payload CRC-32 
    
   Figure A.1.2 Figure A.1.2 Fragments will follow in the next 
   consecutive BBFrame 
    
   There is no additional overhead bytes consumed by Fragmentation of 
   F2 in the case of fragmentation across an arbitrary number of 
   BBFrames. 
    
    
    
  
Expires June 2006                                            [page 37] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
A.2 GAP Fragmentation 
    
   In the case of a "gap" fragmentation, the Encapsulation sends a 
   BBFrame after starting a fragment, that is not completed in the next 
   adjacent BBFrame.  Instead, one or more BBFrames are sent which are 
   not directed at the same intended recipient (i.e. NPA/MAC address). 
   It may be, for instance be that the Receiver can not decode the 
   ModCod used for these intervening frames. In the figures in this 
   section, it is assumed that all the BBFrames are directed to the 
   same common stream. 
    
   In this encapsulation, this requires a fragment header in the 
   resumed segment (F2b shown in the figure below). 
    
      +--------------+ +-------------+ +--------------+ 
      |  F1 |   F2a  | |XXXXXXXXXXXXX| | F2b |        | 
      |*   c|*       | |             | |+   c|        | 
      +--------------+ +-------------+ +--------------+ 
    
   * = SNDU base header 
   + = SNDU-Resume Fragment 
   c = SNDU payload CRC-32 
    
   Figure A.2.1 BBFrames are not consecutive in the SNDU flow. 
    
    
   The additional overhead resulting from the fragmentation of F2 = 1 
   base header+CRC in F2b. 
    
     +--------------+ +-------------+ +-------------+ +--------------+ 
     |  F1 |   F2a  | |XXXXXXXXXXXX | |     F2b     | | F2c |        | 
     |*   c|*       | |      |      | |+            | |    c|        | 
     +--------------+ +-------------+ +-------------+ +--------------+ 
    
   * = SNDU base header 
   + = SNDU-Resume Fragment 
   c = SNDU payload CRC-32 
    
   Figure A.2.2 BBFrames are not consecutive in the SNDU flow. 
    
    
   The additional overhead resulting from the fragmentation of the SNDU 
   into three BBFrames is the same as that for the frame depicted in 
   Figure A.2.2.  Since the fragment F2c is consecutive with that of 
   F2c (i.e. it is the next in-sequence BBFrame that was sent with the 
   same stream identifier), there is no additional fragmentation 
   header. 
    
   In some cases the Encapsulation Gateway may choose a transmission 
   ordering that eliminates the need for a gap transmission (in this 
   case, scheduling the 2nd burst in figure A.2.2 before the start of 
   the first). Where this is possible, it eliminates the need for the 
   additional overhead associated with suspending and resuming a SNDU. 
  
Expires June 2006                                            [page 38] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
   It is also permitted to suspend and later resume a SNDU on more than 
   one occasion, should the Encapsulation Gateway wish to send a frame 
   using space available in several BBFrames.  
    
       +--------------+ +--------------+ +--------------+ 
       |  F1 |   F2a  | |F3   | F2b    | | F4  |   F2c  | 
       |*   c|*       | |*   c|+       | |*   c|+      c| 
       +--------------+ +--------------+ +--------------+ 
    
   * = SNDU base header 
   + = SNDU-Resume Fragment 
   c = SNDU payload CRC-32 
    
   Figure A.2.3 BBFrames that send F2 utilising the remaining space in 
   3 BBFrames. 
    
   In the above example, SNDUs F3 and F4 carry a unicast address that 
   is not the same as that used for F2. In this encapsulation, this 
   requires two fragment headers (and CRCs) in each of the resumed 
   segments (F2b,F2c shown in the figure below). The extra flexibility 
   may be justified, for example, in cases where the three BBFrames are 
   sent using ModCod values that provide higher protection than 
   required for transmission of F2, but where there is no higher 
   priority traffic pending transmission in these frames. In this case, 
   there will be a higher physical-layer cost, and the additional 
   overhead only adds to this transmission cost. 
    
    
A.3 Abort Fragmentation 
    
   These examples show the cases where the encapsulation process is 
   terminated, resulting in discard of the partially received fragment. 
   All the examples refer to a sequence of BBFrames associated with the 
   same stream. 
    
               +--------------+ +-------------+ 
               |  F1 |   F2a  | |    F3       |  
               |*   c|*       | |*           c|  
               +--------------+ +-------------+  
    
   BBFrame      1                 2 
   PP           F2a               0 (First byte of F3) 
    
   * = SNDU base header 
   + = SNDU-Resume Fragment 
   c = SNDU payload CRC-32 
    
   Figure A.3.1  Aborted Frame by start of a new complete SNDU (F3) to 
   same NPA/MAC address 
    
   In the above example, F2a is a partially complete fragment, followed 
   by a BBFrame that contains the start of a different SNDU that is has 
  
Expires June 2006                                            [page 39] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   the same Receiver NPA/MAC address. Receipt of the SNDU F3 results in 
   F2a being aborted. 
    
      +--------------+ +-------------+ +--------------+ 
      |  F1 |   F2a  | |XXXXXXXXXXXX | | F3  |  F4    | 
      |*   c|*       | |      |      | |*   c|*      c| 
      +--------------+ +-------------+ +--------------+ 
    
   Figure A.3.2  Aborted Frame by start of a new complete fragment to 
   same MAC address 
    
   In the above example, F2a is a partially complete fragment, followed 
   by a BBFrame that is not decoded by the Receiver and F3 is a 
   complete SNDU sent to a different Receiver NPA/MAC address. F4 is 
   sent to the same MAC address as F2a, and results in F2a being 
   aborted. 
 
    
A.4 Informative examples of usage of SNDU-Resume 
    
   These examples illustrate use of the SNDU-Resume extension. All the 
   examples refer to a sequence of BBFrames associated with the same 
   Stream. 
    
   In the following example, SNDU 2 is fragmented into three parts 
   (F2a,F2b,F2c). The first part of the SNDU, F2a contains the SNDU 
   base header, followed by a sequence of bytes until the end of the 
   1st BBFrame. Fragment F2b follows in a later BBFrame as a SNDU-
   Resume fragment F2b, allowing transmission of F3 also within the 
   second BBFrame. The final part of the SNDU is also sent in an SNDU-
   Resume fragment, F2c. 
    
            +--------------+ +--------------+ +--------------+ 
            |  F1 |   F2a  | |F2b  | F3     | | F4 |   F2c   | 
            |*   c|*       | |+   d|*      c| |*  c|+       c| 
            +--------------+ +--------------+ +--------------+ 
    
   BBFrame  1                2                3 
   PP       0                0                0 
    
   * = SNDU base header 
   + = SNDU-Resume header 
   c = CRC-32 used to validate integrity of SNDU. 
   d = CRC-32 used only to validate framing. 
    
   Figure A.4.1 Example use of SNDU-Resume 
    
   In the example above, a decision was made by the Gateway to send 
   fragment F2c as a SNDU-Resume fragment. If the Fragment F2b had been 
   sent at the end of the second BBFrame, the Length field of the SNDU-
   Resume fragment could have been set to the total number of remaining 
   bytes, allowing F2c to be sent as a continuation fragment, 
   eliminating the need for a SNDU-header for 
  
Expires June 2006                                            [page 40] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
   F2c (and hence improving efficiency). 
    
            +--------------+ +--------------+ +--------------+ 
            |  F1 |   F2a  | |F3  | F2b     | |   F2c   | F4 | 
            |*   c|*       | |*  c|+        | |        c|*  c| 
            +--------------+ +--------------+ +--------------+ 
    
   BBFrame  1                2                3 
   PP       0                0                (1st byte of F4) 
    
   * = SNDU base header 
   + = SNDU-Resume header 
   c = CRC-32 used to validate integrity of SNDU. 
    
   Figure A.4.2 Example use of SNDU-Resume (optimised placement) 






































  
Expires June 2006                                            [page 41] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
Appendix B: Alternative design options. 
    
   This section identifies a set of issued that will require further 
   consideration. 
    
B.1 Expanded D-Field 
    
                00      No MAC 
                01      Mac 3B * ** 
                10      Mac 6B 
                11      Currently Unused 
    
   * Note: Subject to a satisfactory use-case being defined. 
   **  Note: The short-form NPA/MAC address may also be represented in 
   long-form by prefixing this with a well-known/reserved IEEE OUI 
   field. The mapping of multicast IP addresses to the short-form OUI 
   is to be specified. This mode is also outlined in [S2-REQ]. 
    
    
B.2 Reduction of CRC Field 
    
   The size of the CRC field may be reduced in future revisions of this 
   document, subject to alternative methods being found that provide 
   equivalent protection. A CRC-16 could be used in combination with 
   appropriate and reliable feedback from the BBFrame processing layer. 
    
   A method could be defined that does not employ a CRC for complete 
   (unfragmented) SNDUs. 
    
   Selection of the appropriate method requires inputs from experts 
   with knowledge of the DVB-S.2 channel. 
    
    
B.3 Encapsulation Header Field 
    
   Two methods of adding encapsulation overhead are defined. Selection 
   of the appropriate method requires inputs from experts with 
   knowledge of the DVB-S.2 BBHeader format. 
 
    
    
    
    
    
    
    
    
    
    
    
    
 
    
  
Expires June 2006                                            [page 42] 
INTERNET DRAFT  Encapsulation for IP over DVB-S2/GS          Jan 2006  
 
 
    
   [RFC EDITOR NOTE:  
   This section must be deleted prior to publication] 
    
   DOCUMENT HISTORY 
    
   Draft 00 
   This draft is intended as a study item for proposed future work by 
   the DVB-GBS in this area.  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 
    
   Draft 01 
   This draft was updated to include recommended placement of the 
   encapsulation overhead within the BBFrame header, improved 
   readability, correction of the counter field use (this does not 
   trigger realignment, and is only for OAM), improved fragmentation 
   text. 
    
   Draft 02 
   The author wishes to acknowdledge the detailed review by Juan 
   Cantillo & Jerome Lacan, and their comments and contributions. Many 
   references to MPEG-2 TS were corrected, and other minor mistakes 
   were also corrected. 
    
   Draft 03 
   This draft was updated following discussion at the DVB S.2 GS Study 
   Group. 
   The additions include: 
   SNDU-Resume - addition of payload format and informative examples 
   SNDU-Suspend - new extension 
   SNDU-Concat - new extension 
   The Idle state does not result in discard of the Currenmt SNDU (as 
   in GULE). 
   Section 1 now includes implementation notes/constraints. 
   It also includes a number of editorial corrections. 
    
   Draft 04 
    
   This rev of the Spec does not use the CRC for validating frame 
   alignment (i.e.delineating SNDU boundaries), and also therefore the 
   SNDU Suspend option has no CRC-32. The SNDU-Resume option only 
   carries a CRC when this is the final fragment of a SNDU. This 
   modification came from comments from Axel J. and Rita R. 
    
   Text was also updated on the Counter – to clarify use in combination 
   with the PP value (U.de.B). 
    
   -------------------------------------------------------------------- 
    
   [END of RFC EDITOR NOTE]  
    
    
  
Expires June 2006                                            [page 43]