Internet Engineering Task Force Gorry Fairhurst Internet Draft University of Aberdeen Document: draft-ietf-ipdvb-ule-ext-00.txt B. Collini-Nocker University of Salzburg Category: WG Draft intended for PS January 2006 Extension Formats for Unidirectional Link Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) 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. Copyright Notice Copyright (c) The IETF Trust (2007). Abstract This document describes a set of Extension Headers for the Unidirectional Link Encapsulation (ULE) [RFC4236]. The Extension Header formats defined in this document define new extensions that are common extensions to both ULE and the Generic Stream Encapsulation (GSE) [GSE] defined by the second generation framing structure DVB-S2 standard [S2]. Fairhurst, et al. Expires June 2007 [page 1] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 Table of Contents 1. Introduction 2. Conventions used in this document 3. Description of method 3.1 MPEG-2 TS-Concat Extension 3.2 PDU-Concat Extension 4. Summary 5. IANA Considerations 6. Acknowledgments 7. Security Considerations 8. References 8.1 Normative References 8.2 Informative References 9. Authors' Addresses 10. IPR Notices 10.1 Intellectual Property Statement 10.2 Disclaimer of Validity 11. Copyright Statement 11.1 Intellectual Property Statement 11.2 Disclaimer of Validity Appendix A: Fairhurst, et al. Expires June 2007 [page 2] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 1. Introduction This document describes two new Header Extensions that may be used with both Unidirectional Link Encapsulation, ULE, [RFC4236] and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links that employ the MPEG-2 Transport Stream, and supports a wide variety of physical-layer bearers [RFC4259]. GSE has been designed for the Generic Mode (also known as the Generic Stream (GS)), offered by second-generation DVB physical layers, and specifically for DVB-S2 [ETSI-S2]. The requirements for the Generic Stream are defined in [S2-REQ], [S2-REQ-RCS], and [ID-S2-REQ]. The important characteristics of this encapsulation are described in an Appendix to this document. GSE maintains a design philosophy that presents a common network interface to that of ULE and uses a similar construction for Subnetwork Data Unit (SNDUs). One extension header defines a method that allows one or more TS- Packets [ISO-MPEG] to be sent within a ULE SNDU. This method may be used to provide control plane information including the transmission of MPEG-2 Program Specific Information (PSI) for the Multiplex. In GSE, there is no native support for transport stream packets and this method is therefore suitable for providing an MPEG-2 control plane. A second extension header allows one or more PDUs to be sent within the same ULE SNDU. This method is designed for cases where a large number of small PDUs are directed to the same Network Point of Attachment (NPA) address. The method may improve transmission efficiency (by removing duplicated MAC layer overhead). It can also reduce processing overhead for receivers that are not addressed by the NPA, since these receivers may then skip several PDUs in one operation. The method is defined as a generic extension header and may be used for IPv4 or IPv6 packets. If and when a compression format is defined for ULE or Ethernet, the method may also be used in combination with this method. Future versions of this document are expected to provide recommendations on the interface between the Generic Stream Encapsulation (GSE) and the Internet Protocol Stack. The appendix includes a summary of key design issues and considerations based on the GSE Specification defined by the DVB Technical Module[GSE]. Fairhurst, et al. Expires June 2007 [page 3] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 2. Conventions used in this document This document uses the conventions defined in [RFC2119]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. This indicates the requirement levels for compliant implementations. b: bit. For example, one byte consists of 8b. B: Byte. Groups of bytes are represented in Internet byte order. BBFrame payload [ETSI-S2]: The data field part of a Baseband frame that may be used for the communication of data. Typical BBFrames range in size from 3072 to 58192 bits according to the choice of modulation format and method of Forward Error Correction in use. DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data. Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output in DVB-S or the Generic Mode of DVB-S2. GS: Generic Stream [S2]. GSE: Generic Stream Encapsulation [GSE]. MAC: Medium Access Control [IEEE-802.3]. A link layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2). MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organisation (ISO/IEC 113818-1) [ISO-MPEG], and ITU-T (in H.220). Next-Header: A Type value indicating an Extension Header [RFC4236]. NPA: Network Point of Attachment [RFC4236]. In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network that is used to identify individual Receivers or groups of Receivers. PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. PSI: Program Specific Information [ISO-MPEG]. SI Table: Service Information Table [ISO-MPEG]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried on a DVB carrier. Fairhurst, et al. Expires June 2007 [page 4] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an encapsulated PDU sent using ULE or GSE. Stream: A logical flow from an Encapsulator to a set of Receivers. . TS: Transport Stream [ISO-MPEG], a method of transmission at the MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI reference model. ULE: Unidirectional Link Encapsulation (ULE) [RFC4236]. A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel. The encapsulation format defined by this document shares the same extension format, and basic processing rules and uses a common IANA Registry. Fairhurst, et al. Expires June 2007 [page 5] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 3. Description of the Method In ULE, a Type field value that is less than 1536 Decimal indicates an Extension Header. This section describes a set of two extension formats for the ULE encapsulation. The GSE specification is defined in [GSE] and follows these formats, but as in other SNDU formats, GSE does not include a per-SNDU CRC and utilises a different SNDU length calculation [GSE]. 3.1 MPEG-2 TS-Concat Extension >>> IANA Action required, please replace < #NH-TS-CAT> with assigned value from the Next-Header Registry>>> The MPEG-2 TS-Concat Extension Header is specified by an IANA assigned H-Type value of <#NH-TS-CAT>. This is a Mandatory Next- Header Extension. The extension is used to transport 1 or more MPEG-2 TS Packets within a ULE SNDU. The number of TS Packets carried in a specific SNDU is determined from the size specified by the remainder of the Payload following the MPEG-2 TS Extension. A Receiver MUST verify that payload length is correct prior to processing it, and SHOULD be recorded as TS-concat size mismatch error. Consider the example shown in the figure below. The value D=0 indicates the presence of a NPA address. In this example, there are no additional extension headers between the ULE base header and the TS-Concast extension, therefore the payload length value using ULE is (Length - 10) / 188, whereas the value for payload length using GSE is (Length - 6) / 188. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Length (15b) | Type = 0x #NH-TS-CAT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TS-Packet 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 2 (if Length > 2*188) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) Fairhurst, et al. Expires June 2007 [page 6] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 >>> IANA Action required, please replace < #NH-TS-CAT> with assigned value from the Next-Header Registry in Figures 1 and 2>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Length (15b) | Type =0x #NH-TS-CAT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TS-Packet 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 2 (if Length > 2*188) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: GSE/SNDU Format for a TS-Packet Payload (D=0) Note that fragmented GSE SNDUs are protected by a CRC-32 carried in the final fragment, and that non-fragmented GSE SNDUs are protected by a CRC-32 in the final bytes of the GS DataField. A value of D=1, is also permitted and indicates the absence of a NPA address, as defined in ULE. A similar format is supported in GSE. >>> IANA Action required, please replace < #NH-TS-CAT> with assigned value from the Next-Header Registry>>> Fairhurst, et al. Expires June 2007 [page 7] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Length (15b) | Type = 0x< #NH-TS-CAT> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 1 | = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS-Packet 2 (if Length > 2*188) | = = | etc. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) The extension may be used to transport one or more MPEG-2 TS Packets of arbitrary content, interpreted according to [ISO-MPEG]. One expected use is for the transmission of MPEG-2 SI/PSI signalling. The use of this format to transfer MPEG-2 clock references (e.g. a Network Clock Reference, NCR, SI Table) over ULE/GSE framing raises timing considerations at the encapsulation gateway, including the need to update/modify the timing information prior to transmission by the physical layer. These issues are not considered here, but it is noted that the operation may be simplified by ensuring that all SNDUs that carry this Extension Header are placed before other data within the GSE DataField [GSE]. Fairhurst, et al. Expires June 2007 [page 8] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 3.2 PDU-Concat Extension >>> IANA Action required, please replace <#NH-PDU-CAT> with assigned value from the Next-Header Registry>>> The PDU-Concat Extension is specified by an IANA assigned H-Type value of #NH-PDU-CAT This is a Mandatory Next-Header Extension. It enables a sequence of (usually short) PDUs to be sent within a single SNDU payload. The base header contains the Length of the entire SNDU. This carries the value of the combined length of all PDUs to be encapsulated, including each set of encapsulation headers. The base header also caries a 16-bit ULE Type field. Although any Type value specified in the ULE Next-Header Registry may be assigned to the encapsulated PDU, all PDUs included in the SNDU payload MUST have a common ULE Type (i.e. all concatenated PDUs passed by the network layer must be associated with the same Type value). This simplifies the receiver design, and reduces the transmission overhead for common use cases. Each PDU is prefixed by its length in bytes (shown as PDU-Length in the following diagrams). Encapsulated PDUs are of arbitrary length (in bytes) and are not necessarily aligned to 16-bit or 32-bit boundaries within the SNDU (as shown in the figure). The most significant bit of the first byte MUST be set to zero. The length of each PDU MUST be less than 32 758 bytes, but will generally be much smaller. When the SNDU header indicates the presence of an SNDU Destination Address field (i.e. D=0), a Network Point of Attachment, NPA, field directly follows the fourth byte of the SNDU header. NPA destination addresses are 6 Byte numbers, normally expressed in hexadecimal, used to identify the Receiver(s) in a transmission network that should process a received SNDU. When present the Receiver MUST associate the same specified MAC/NPA address with all PDUs within the SNDU Payload. This MAC/NPA address MUST also be forwarded with each PDU, if required by the forwarding interface. >>> IANA Action required, please replace <#NH-PDU-CAT> with assigned value from the Next-Header Registry in the next two figures>>> Fairhurst, et al. Expires June 2007 [page 9] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Length (15b) | Type = 0x<#NH-PDU-CAT> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CONCAT-PDU-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| PDU-Length-1 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-1 = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| PDU-Length-2 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-2 = | | More PDUs as required +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Length (15b) | Type = 0x<#NH-PDU-CAT> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CONCAT-PDU-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| PDU-Length-1 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-1 = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| PDU-Length-2 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-2 = | | More PDUs as required +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: GSE/SNDU Format for a PDU-Concat Payload (D=0) A value of D=1 indicates there is no NPA/MAC address in use. This field MUST be carried (i.e. D=0) for IP unicast packets destined to Fairhurst, et al. Expires June 2007 [page 10] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 routers that are sent using shared links (i.e., where the same link connects multiple Receivers). A sender MAY omit this field (D=1) for a set of packets delivered to a Receiver or group of receivers that are able to utilise a discriminator field (e.g. the IPv4/IPv6 destination address, or a bridged MAC destination address), which in combination with the PID value, could be interpreted as a Link-Level address. A similar format is supported in GSE. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Length (15b) | Type = 0x<#NH-PDU-CAT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CONCAT-PDU-Type |0| PDU-Length-1 (15b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = PDU-1 = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| PDU-Length-2 (15b) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = PDU-2 = | | More PDUs as required +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) The Receiver processes this Extension Header by verifying that it supports the specified CONCAT-PDU Type (unsupported Types MUST be discarded but the receiver SHOULD record a PDU-Type error). It then extracts each encapsulated PDU in turn. The Receiver MUST verify the Length of each PDU. It MUST also ensure the sum of the Lengths of all processed PDUs is less than the Length specified in the SNDU base header. A Receiver MUST discard the whole SNDU if the sizes do not match and this event SHOULD be recorded as a PDU-concat size mismatch error. Fairhurst, et al. Expires June 2007 [page 11] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 4. Summary This document defines a set of Next_Header Extensions for the Unidirectional Link Encapsulation (ULE). 5. IANA Considerations This document requires IANA involvement for the assignment of two new Next-Header Type values from the IANA ULE Next-Header Registry. These options are defined for specific use cases envisaged by GSE, but are compatible with ULE. The TS-Concat Extension is a Mandatory next-type extension header, specified in section 3.1 of this document. The value of this next- header is defined by an IANA assigned H-Type value of #NH-TS-CAT. The PDU-Concat Extension is a Mandatory next-type extension header specified in section 3.2 of this document. The value of this next- header is defined by an IANA assigned H-Type value of #NH-PDU-CAT. 6. Acknowledgments The author gratefully acknowledges the inputs, comments and assistance offered by the members of the DVB-GBS ad hoc group on S2 encapsulation, in particular contributions on transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. 7. Security Considerations No specific security issues are raised within this document. Additional security control fields may be provided as a part of a link encryption Extension Header, e.g. to associate a PFU with one of a set of Security Association (SA) parameters. As a part of the encryption process, it may also be desirable to authenticate some/all of the headers. The method of encryption and the way in which keys are exchanged is beyond the scope of this specification, as also are the definition of the SA format and that of the related encryption keys. Fairhurst, et al. Expires June 2007 [page 12] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997. [RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Link Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", RFC 4236, December 2006. 8.2 Informative References [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI). [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications", European Telecommunication Standards Institute (ETSI). [GSE] "Generic Stream Encapsulation", Work in Progress, DVB Technical Module (GBS Group), 2006. [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- S2", Internet Draft , Work in Progress. [ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Standards Organisation (ISO). [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2006. [S2] EN 302 307, "Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications", European Telecommunication Standards Institute (ETSI). [S2-REQ] GBS0339, "Functional and performance requirements for IP/S2", DVB-TM GBS WG. [S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB Technical Module (RCS WG). Fairhurst, et al. Expires June 2007 [page 13] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 9. Authors' Addresses Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK Email: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/Gorry Bernhard Collini-Nocker Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria EMail: bnocker@cosy.sbg.ac.at Web: http://www.scicomp.sbg.ac.at/ 10. IPR Notices Copyright (c) The IETF Trust (2007). 10.1 Intellectual Property Statement Full Copyright Statement This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10.2 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Fairhurst, et al. Expires June 2007 [page 14] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 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. 11. Copyright Statement Copyright (C) The IETF Trust (2007). [RFC EDITOR NOTE: This section must be deleted prior to publication] Fairhurst, et al. Expires June 2007 [page 15] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 DOCUMENT HISTORY Individual Draft 00 This draft complements a study item in the DVB-GBS in this area to define a Generic Stream Encapsulation (GSE). Comments relating to this document will be gratefully received by the author(s) and may also be sent to ip-dvb mailing list at: ip-dvb@erg.abdn.ac.uk Individual Draft 01 Co-Author Added. This draft updates the language and format. This draft fixes problems with the concatenation mode, and defines a new header format that restricts the use of the Type field so that all concatenated PDUs MUST have the same Type. Future versions of this draft may define additional Extension Headers, proposals and ideas are welcome via the IETF ipdvb mailing list. Possible extensions include those for encapsulation FEC, Link parameter negotiation (e.g. for header compression), and support for ATM/ULE. Working Group Draft 00 Fixed editorial mistakes from Christian Praehauser and ID style for WG adoption. [END of RFC EDITOR NOTE] Fairhurst, et al. Expires June 2007 [page 16] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 Fairhurst, et al. Expires June 2007 [page 17] INTERNET DRAFT Extension Formats for ULE and GSE Jan 2007 APPENDIX: DVB-S.2 PDUs, (Ethernet Frames, IP datagrams or other network layer packets) are encapsulated to form a Subnetwork Data Unit (SNDU) [RFC4236] associated with a specific Stream at the link layer. The SNDU is transmitted over an DVB-S2 link by placing it either in a single BBFrame, or if required, an SNDU may be fragmented into a series of BBFrames [ID-S2-REQ]. A mode also permits an SNDU to be fragmented with the remaining fragments sent in a later BBFrame(s), while preserving the original order of each SNDU sent to a specific MAC/NPA address over a Stream. Where there is sufficient space, the method permits a BBFrame to carry more than one SNDU (or part there of), sometimes known as Packing. All parts comprising an SNDU are assigned to the same Stream. In ULE and MPE [ETSI-DAT], each SNDU carries a 32-bit CRC field in the last four bytes of the SNDU. The purpose of this CRC is to protect the SNDU (header, and payload) from undetected reassembly errors and errors introduced by unexpected software / hardware operation. This also serves to verify the delineation (framing) of PDUs and may detect the presence of uncorrected errors from the physical link When an SNDU is sent over a DVB-S2 subnetwork using GSE, the Integrity protection is provided by a CRC at the baseband frame level, using a CRC in the final bytes of the DataField. Fairhurst, et al. Expires June 2007 [page 18]