Internet Engineering Task Force Gorry Fairhurst Internet Draft University of Aberdeen Document: draft-fairhurst-ipdvb-s2-gule-00.txt Category: Draft September 2005 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 an Generic Lightweight Encapsulation (ULE) 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. Expires March 2006 [page 1] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 Table of Contents 1. Introduction 2. Conventions used in this document 3. Description of method 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 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. Acknowledgments 10. Security Considerations 11. References 11.1 Normative References 11.2 Informative References 12. Authors' Addresses 13. IPR Notices 13.1 Intellectual Property Statement 13.2 Disclaimer of Validity 14. Copyright Statement 14.1 Intellectual Property Statement 14.2 Disclaimer of Validity 15. IANA Considerations 15.1 IANA Guidelines Expires March 2006 [page 2] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 [S2] in the Generic Mode [ID-S2]. 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. The SNDU may be fragmented into a series of one or more BaseBand (BB) frames that are sent over the DVB S2 link. The method also allows TS Packets to be sent within GULE SNDUs. This may be used to provide control information and/or Program Specific Information (PSI) for a Multiplex. Expires March 2006 [page 3] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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]. More abbreviations should be defined here. b: bit. For example, one byte consists of 8b. B: Byte. Groups of bytes are represented in Internet byte order. BBframe payload [S2]: The data field part of a Baseband frame that may be used for the communication of data. The BBFrames size varies from 3072 to 58192 bits according to the FEC being used. BBH, Baseband Header [S2]: A fixed format 10 byte header that starts each BBframe. Counter: A 8-bit value located at a fixed position in the encapsulation header of all BB frames utilising the GULE encapsulation. The value 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). 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: A value that indicates to the Receiver that there are no further SNDUs present within the current BBframe. Encapsulation Header: The fixed format header that occupies the first bytes of a BBframe payload. MAC: Medium Access Control [IEEE-802.3]. A link layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). Next-Header: A Type value indicating an Extension Header. NPA: Network Point of Attachment. In this document, refers to a 6 byte destination address (resembling an IEEE MAC address) within the Expires March 2006 [page 4] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 DVB-S2 transmission network that is used to identify individual Receivers or groups of Receivers. Packing Threshold: 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. PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. PP, Payload Pointer: In GULE, the PP is a 16-bit pointer located at a fixed position in the encapsulation header of all BB frames 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. SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried in a SNDU: Subnetwork Data Unit. 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. TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI reference model. Expires March 2006 [page 5] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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) 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 BB frame, 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 TS Packet 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 resembles this, but differs in the procedure that binds it to the MPEG-2 TS physical layer. 3.1 BB Encapsulation Header 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 sent by an encapsulation Gateway. The format of the header is shown below: < ------------------ BBframe ----------------------- > +-----+---------------------------------+--------------------+ | BBH |Ver| Resv | Counter | PP | CRC-8 | BB frame payload | +-----+---------------------------------+--------------------+ < ----Encaspsulation Header---- > Figure 1: BBframe Encapsulation Header The BBframe encapsulation header is of a fixed format, identified by the 4-bit version field. This is followed by a 4-bit reserved field, a 8-bit BBframe counter, a 16-bit Payload Pointe and an 8-bit CRC-8. The CRC-8 provides an integrity check for the BB frame 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 will be defined in this document. Expires March 2006 [page 6] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 4. SNDU Format This section is Informative, the formats decribed in this section are defined by ULE [ULERFC]. 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) This format is identical that defined for ULE [ULE-RFC]. 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. 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 BB Frame (see section 6), and that no Destination Address Field is present. Expires March 2006 [page 7] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 March 2006 [page 8] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 MPEG-2 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 Each SNDU MUST 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]. 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, causing the Receiver to enter the Idle State. Expires March 2006 [page 9] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 primary 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 MPEG-2 subnetwork and during processing at the encapsulation gateway and/or the Receiver. It 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). 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 the TS Packet Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format for a ULE End Indicator. Expires March 2006 [page 10] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 March 2006 [page 11] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 March 2006 [page 12] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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. The H-LEN Assignment is described below: 0 Indicates a Mandatory Extension Header 1 Indicates an Optional Extension Header of length 2B 2 Indicates an Optional Extension Header of length 4B 3 Indicates an Optional Extension Header of length 6B 4 Indicates an Optional Extension Header of length 8B 5 Indicates an Optional Extension Header of length 10B >=6 the combined H-LEN and H-TYPE values indicate the EtherType of a PDU that directly follows this Type field. The H-LEN value indicates the total number of bytes in an Optional Extension Header (including the 2B Type field). 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 [ULE-RFC. The general format for an SNDU with Extension Headers is: Expires March 2006 [page 13] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 < -------------------------- 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 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 [ULE-RFC]. 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 [ULE-RFC]. 5.2 Bridge Frame SNDU Encapsulation A bridged SNDU is a Mandatory Extension Header of Type 1 specified by ULE [ULE-RFC]. 5.3 Extension-Padding Optional Extension Header The Extension-Padding Optional Extension Header is s specified by ULE [ULE-RFC]. 5.4 MPEG-2 TS Extension Expires March 2006 [page 14] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 The MPEG-2 TS Extension Header is specified by an IANA assigned H- Type value of . 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, after the last complete encapsulated MPEG-2 TS Packet. 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-MPEG2]. 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 . 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 SNDU. This CRC is used to verify the integrity and reassembly of the complete PDU. The Length field in an SNDU-Resume Extension fragment specifies the size of the remaining SNDU payload. (This includes the 4 byte CRC value for the complete SNDU payload, see below). Expires March 2006 [page 15] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 If the number of bytes to be sent in an SNDU-Resume Extension fragment exceeds the unfilled space in the BB frame payload, then the Encapsulator SHOULD by default continue transmission in the next BB frame 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. An SNDU that carries an SNDU-Resume Extension fragment with the final Fragment of a suspended SNDU carries the 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 appended to the SNDU payload (and is included in the calculated Length of the SNDU that carries this final Fragment). Each SNDU (including an SNDU-Resume Extension) also carry a CRC value that is used to validate framing of the SNDU. This value is omitted if the SNDU is itself suspended. 5.5.1 SNDU-Resume Extension fragment processing The Receiver SHOULD provisionally accept all SNDUs with a Length is greater than the number of bytes remaining in the BBframe, these are called Fragments. A Receiver could decide to silently discard such SNDUs to conserve reassembly buffer capacity, 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 is invoked, fro example, when an encapsulation Gateway is restarted). To reassemble Fragments, a Receiver needs to buffer of 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 the Receiver is configured to receive. Note: 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 BB frame for the same Stream had a PP value of zero. The processing of fragments uses the following rules: 1) 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. The Fragments are then added to the set of Fragments to be later reassembled. Expires March 2006 [page 16] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 2) 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. 3) The Receiver receives a subsequent SNDU-Resume Extension fragment that matches the NPA/MAC address of a Fragment pending 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 are then discarded. 4) 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 are then discarded and the Receiver continues with processing with of the next received SNDU. 5) 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 are then discarded and the Receiver continues with processing with of the received SNDU. 6) The Receiver receives a SNDU with an invalid Length of a Fragment and/or an invalid SNDU CRC. This case is an error, the SNDU is discarded, and the Receiver enters the idle state (see section 7). 7) Within the period specified by the specified Fragment-timeout, 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 are then discarded. 8) 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 are discarded. 5.5.1 SNDU-Resume Extension reassembly 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 proceeds with reassembly. The total accumulated size of all SNDU fragments (excluding the appended SNDU CRC) MUST exactly match this Length. SNDUs with an inconsistent length MUST be discarded (a framing error may be recorded). Expires March 2006 [page 17] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 The Receiver MUST verify the SNDU CRC value carried in the final 4 bytes of the final fragment of the SNDU. This value is used only to verify the integrity of the reassembled SNDU. A successfully reassembled SNDU payload is processed according to the Type field specified in the base header of the first suspended Fragment. Expires March 2006 [page 18] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 TS Packet payloads (figure 9). These are transmitted using a single TS Logical Channel over a TS Multiplex. The TS Multiplex may be processed by a number of MPEG-2 (re)multiplexors before it is finally delivered to a Receiver [ULE-RFC]. +------+------------------------------+------+ |ULE | Protocol Data Unit |ULE | |Header| |CRC-32| +------+------------------------------+------+ / /\ \ / / \ \ / / \ \ +-------+-----------------------+ +-------+-------------------+ |Encaps | | |Encaps | | |Header | | |Header | | +-------+-----------------------+ +-------+-------------------+ Figure 11: Encapsulation of an SNDU into a series of BB Frames 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 BB Frame. This BB Frame MUST carry a Payload Pointer value of zero indicating the SNDU starts in the first available byte of the BB Frame payload. The Encapsulation MUST ensure that all BB Frames incremented by one (modulo 256) the Continuity 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 TS Packet. This procedure is known as Padding (figure 11). The End Indicator informs the Receiver that there are no more SNDUs in this BB Frame payload. The End Indicator is followed by zero or more unused bytes until the end of the TS Packet payload. All unused bytes MUST be set to the value of 0xFF. The Padding procedure trades decreased efficiency against improved latency. Expires March 2006 [page 19] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 +-/------------+ | SubNetwork | | DU 3 | +-/------------+ \ \ \ \ \ \ +--------+--------+--------+----------+ | Encaps | End of | 0xFFFF | Unused | | Header | SNDU 3 | | Bytes | +--------+--------+--------+----------+ ULE End Indicator Figure 12: A BB Frame carrying the end of SNDU 3, followed by an End Indicator. Alternatively, when more packets are waiting at an Encapsulator, and the BB Frame 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 BB Frame payload (see 6.2). This is called Packing (figure 13). +-/----------------+ +----------------/-+ | Subnetwork | | Subnetwork | | DU 1 | | DU 2 | +-/----------------+ +----------------/-+ \ \ / /\ \ \ / / \ \ \ / / \. . . +--------+--------+--------+----------+ | Encaps | Payload| end of | start of | | Header | Pointer| SNDU 1 | SNDU 2 | +--------+--------+--------+----------+ | ^ | | +--------------+ Figure 13: A BB Frame 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 BB Frame. In this case, it may continue transmission by Expires March 2006 [page 20] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 March 2006 [page 21] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 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 SNDU, 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 BB Frame with a PP value not equal to 0xFFFF indicates that the BB Frame 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). 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, when it then enters the Reassembly State. Figure 14 outlines these state transitions: +-------+ | START | +---+---+ | \/ +----------+ \| Idle |/ +-------/| State |\-------+ Insufficient | +----+-----+ | unused space | | PUSI set | Physical Error or | \/ | or End Indicator| +----------+ | SNDU Error | |Reassembly| | +--------| State |--------+ +----------+ Figure 14: Receiver state transitions 7.1.1 Idle State Payload Pointer Checking Expires March 2006 [page 22] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 A Receiver in the Idle State MUST check the PP value in the BBframe header of all received BB frames. 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 BB frame 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 reassenly, 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. The under-lying physical-layer processing (e.g. forward error correction coding) often results in patterns of errors, rather than single bit errors, so the Receiver needs to be robust to arbitrary patterns of corruption to the BBframe payload, including potential corruption of the PP, and SNDU Length fields. Therefore, a Receiver SHOULD discard the remaining BBframe payload (if any) following a CRC mismatch and return to the Idle State. 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. Expires March 2006 [page 23] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 (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 all subsequent BBframes for the same Stream. 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, the Receiver may have detected a delimiting error, or a suspended frame. The receiver follows the procedure described in section 5. 7.3 Other Error Conditions The Receiver SHOULD 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. Any partially received SNDU MUST be discarded. The Receiver then enters the Idle State. The Receiver MUST check the BBframe Counter carried in the Encapsulation header. If the received value does NOT increment by one for successive BBframes within a stream (modulo 255), the Receiver has detected a continuity error. Any partially received SNDU MUST be discarded. A continuity counter error event SHOULD be recorded. The Receiver then enters the Idle State. Expires March 2006 [page 24] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 8. Summary This document defines an Generic 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 RFC-ULE and shares the associated IANA registry for support of both mandatory and optional SNDU headers. 9. 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-S.2. 10. 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 March 2006 [page 25] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 11. References 11.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. [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)". 11.2 Informative References XXX RFC Editor please replace this reference and all citations with the appropriate RFC number. The I-D referenced is currently ahead in the RFC-ED queue. XXX [RFCXXXX] "Requirements for transmission of IP datagrams over MPEG-2 networks", Internet Draft, Work in Progress. [ID-S2] "Requirements for transmission of IP datagrams over DVB- S.2", Internet Draft, Work in Progress. 12. 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 Expires March 2006 [page 26] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 13. IPR Notices 13.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. 13.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. 14. Copyright Statement Copyright (C) The Internet Society (2005). 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 March 2006 [page 27] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept 2005 15. 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. [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 -------------------------------------------------------------------- [END of RFC EDITOR NOTE] Expires March 2006 [page 28]