--- 1/draft-ietf-ipdvb-ule-04.txt 2006-02-04 23:37:29.000000000 +0100 +++ 2/draft-ietf-ipdvb-ule-05.txt 2006-02-04 23:37:30.000000000 +0100 @@ -1,22 +1,22 @@ Internet Engineering Task Force Gorry Fairhurst -Internet Draft University of Aberdeen, U.K. -Document: draft-ietf-ipdvb-ule-04.txt Bernhard Collini-Nocker - University of Salzburg, A +Internet Draft University of Aberdeen +Document: draft-ietf-ipdvb-ule-05.txt Bernhard Collini-Nocker + University of Salzburg ipdvb WG -Category: Draft, Intended Standards Track January 2005 +Category: Draft, Intended Standards Track February 2005 Ultra Lightweight Encapsulation (ULE) for transmission of - IP datagrams over MPEG-2/DVB networks + IP datagrams over an MPEG-2 Transport Stream 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 RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -26,40 +26,40 @@ 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 - The MPEG-2 TS has been widely accepted not only for providing - digital TV services, but also as a subnetwork technology for - building IP networks. This document describes an Ultra Lightweight - Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 - Datagrams and other network protocol packets directly over ISO MPEG- - 2 Transport Streams (TS) as TS Private Data. ULE supports an - extension format that allows it to carry both optional (with an - explicit extension length) and mandatory (with an implicit extension - length) header information to assist in network/Receiver processing - of a SNDU. + The MPEG-2 Transport Stream (TS) has been widely accepted not only + for providing digital TV services, but also as a subnetwork + technology for building IP networks. + + This document describes an Ultra Lightweight Encapsulation (ULE) + mechanism for the transport of IPv4 and IPv6 Datagrams and other + network protocol packets directly over the ISO MPEG-2 Transport + Stream as TS Private Data. ULE 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 July 2005 [page 1] Table of Contents 1. Introduction 2. Conventions used in this document 3. Description of method 4. SNDU Format - 4.1 Destination Address Present (D) Field + 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 @@ -86,258 +86,292 @@ 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 - ANNEXE A: Informative Appendix - SNDU Packing Examples - ANNEXE B: Informative Appendix - SNDU Encapsulation + ANNEX A: Informative Appendix - SNDU Packing Examples + ANNEX B: Informative Appendix - SNDU Encapsulation Expires July 2005 [page 2] 1. Introduction This document describes an encapsulation for transport of IP datagrams, or other network layer packets, over ISO MPEG-2 Transport - Streams [ISO-MPEG; ID-ipdvb-arch]. It is suited to services based + Streams [[ISO-MPEG2; ID-ipdvb-arch]. It is suited to services based on MPEG-2, for example the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other similar MPEG-2 based transmission systems. Such systems provide unidirectional (simplex) physical and link layer standards. Support has been defined for a wide range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS; ATSC-S], Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). Bi-directional (duplex) links may also be established using these standards (e.g., DVB defines a range of return channel technologies, including the use of two-way satellite links [ETSI-RCS] and dial-up modem links [RFC3077]). Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other network layer packets) for transmission over an MPEG-2 Transport Multiplex are passed to an Encapsulator. This formats each PDU into - a SubNetwork Data Unit (SNDU) [RFC3819] by adding an encapsulation - header and an integrity check trailer. The SNDU is fragmented into a - series of TS Packets) that are sent over a single TS Logical - Channel. + a SubNetwork Data Unit (SNDU) by adding an encapsulation header and + an integrity check trailer. The SNDU is fragmented into a series of + TS Packets that are sent over a single TS Logical Channel. + + The MPEG-2 specification [ISO-MPEG2] requires conformant TS + Multiplexes to provide Program Specific Information (PSI) for + each stream in the TS Multiplex. Other MPEG-2 based transmission + standards may also define Service Information (SI). This + information may allow Receivers and Re-multiplexors + [draft-ipdvb-arch] to locate a specific ULE Stream (i.e., the PID + value of the TS Logical Channel that carries a ULE Stream). The + conditions under which this information is required, and the + format in which it is to be provided is beyond the scope of + this document. Addressing and mapping issues for ULE over MPEG-2 + are also described in [draft-ipdvb-ar]. Expires July 2005 [page 3] 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]. + + Other terms used in this document are defined below: + Adaptation Field: An optional variable-length extension field of the fixed-length TS Packet header, intended to convey clock references and timing and synchronization information as well as stuffing over - an MPEG-2 Multiplex [ISO-MPEG]. + an MPEG-2 Multiplex [ISO-MPEG2]. AFC: Adaptation Field Control [ISO_MPEG]. A pair of bits carried in the TS Packet header that signal the presence of the Adaptation Field and/or TS Packet payload. ATSC: Advanced Television Systems Committee [ATSC]. A framework and a set of associated standards for the transmission of video, audio, and data using the ISO MPEG-2 standard. + b: bit. For example, one byte consists of 8b. + + B: Byte. Groups of bytes are represented in Internet byte order. + DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A - format for transmission of data and control information defined by - the ISO MPEG-2 standard that is carried in an MPEG-2 Private - Section. + format for transmission of data and control information in an MPEG-2 + Private Section, defined by the ISO MPEG-2 standard. 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, using the ISO MPEG-2 Standard. Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets. End Indicator: A value that indicates to the Receiver that there are no further SNDUs present within the current TS Packet. - MAC: Medium Access and Control. The link layer header of the - Ethernet IEEE 802 standard of protocols, consisting of a 6B - destination address, 6B source address, and 2B type field (see also - NPA). + LLC: Logical Link Control [ISO-8802-2]. A link layer protocol + defined by the IEEE 802 standard, which follows the Ethernet MAC + Header. + MAC: Medium Access Control [IEEE-802.3]. A link layer protocol + defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). + + MAC Header: The link layer header of the IEEE 802.3 standard [IEEE- + 802.3] or Ethernet v2 [DIX]. It consists of a 6B destination + address, 6B source address, and 2B type field (see also NPA, LLC). + +Expires July 2005 [page 4] MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel. MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards - Organisation (ISO) [ISO-MPEG]. + 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 B - destination address (resembling an IEEE MAC address) within the + NPA: Network Point of Attachment. In this document, refers to a 6 + byte destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers. -Expires July 2005 [page 4] Packing Threshold: A period of time an Encapsulator is willing to defer transmission of a partially filled TS-Packet to accumulate more SNDUs, rather than use Padding. After the Packet Threshold period, the Encapsulator uses Padding to send the partially filled TS-Packet. PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. - PES: Packetized Elementary Steam [ISO-MPEG]. A format of MPEG-2 TS + PES: Packetized Elementary Steam [ISO-MPEG2]. A format of MPEG-2 TS packet payload usually used for video or audio information. - PID: Packet Identifier [ISO_MPEG]. A 13 bit field carried in the + PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the header of TS Packets. This is used to identify the TS Logical - Channel to which a TS Packet belongs [ISO-MPEG]. The TS Packets + Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets forming the parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all 1s PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes. - PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that + PP: Payload Pointer [ISO-MPEG2]. An optional one byte pointer that directly follows the TS Packet header. It contains the number of bytes between the end of the TS Packet header and the start of a Payload Unit. The presence of the Payload Pointer is indicated by the value of the PUSI bit in the TS Packet header. The Payload Pointer is present in DSM-CC, and Table Sections, it is not present in TS Logical Channels that use the PES-format. Private Section: A syntactic structure constructed in accordance - with Table 2-30 of [ISO-MPEG]. The structure may be used to identify - private information (i.e. not defined by [ISO-MPEG]) relating to one - or more elementary streams, or a specific MPEG-2 program, or the - entire Transport Stream. Other Standards bodies, e.g. ETSI, ATSC, - have defined sets of table structures using the private_section - structure. A Private Section is transmitted as a sequence of TS - Packets using a TS Logical Channel. A TS Logical Channel may carry - sections from more than one set of tables. + with Table 2-30 of [ISO-MPEG2]. The structure may be used to + identify private information (i.e. not defined by [ISO-MPEG2]) + relating to one or more elementary streams, or a specific MPEG-2 + program, or the entire Transport Stream. Other Standards bodies, + e.g. ETSI, ATSC, have defined sets of table structures using the + private_section structure. A Private Section is transmitted as a - PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey +Expires July 2005 [page 5] + sequence of TS Packets using a TS Logical Channel. A TS Logical + Channel may carry sections from more than one set of tables. + + PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey information about services carried in a TS Multiplex. It is carried in one of four specifically identified table section constructs - [ISO-MPEG], see also SI Table. + [ISO-MPEG2], see also SI Table. - PSI: Program Specific Information [ISO-MPEG]. Tables used to convey + PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey information about the service carried in a TS Multiplex. The set of - PSI tables is defined by MPEG-2 [ISO-MPEG]. See also SI Table. + PSI tables is defined by MPEG-2 [ISO-MPEG2]. See also SI Table. PU: Payload Unit. A sequence of bytes sent using a TS. Examples of Payload Units include: an MPEG-2 Table Section or a ULE SNDU. -Expires July 2005 [page 5] - PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. A single bit flag + PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. A single bit flag carried in the TS Packet header. A PUSI value of zero indicates that the TS Packet does not carry the start of a new Payload Unit. A PUSI value of one indicates that the TS Packet does carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the presence of a one byte Payload Pointer (PP). - Receiver: An equipment that processes the signal from a TS Multiplex + Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer). - SI Table: Service Information Table [ISO-MPEG]. In this document, - this term describes a table that is used to convey information about - the services carried in a TS Multiplex, that has been defined by - another standards body. A Table may consist of one or more Table - Sections, however all sections of a particular SI Table must be - carried over a single TS Logical Channel [ISO-MPEG]. + 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 + TS Multiplex. A Table may consist of one or more Table Sections, + however all sections of a particular SI Table must be carried over a + single TS Logical Channel [ISO-MPEG2]. - SNDU: Subnetwork Data Unit [RFC3819]. An encapsulated PDU sent as an - MPEG-2 Payload Unit. + SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 + Payload Unit. Table Section: A Payload Unit carrying all or a part of an SI or PSI - Table [ISO-MPEG]. + Table [ISO-MPEG2]. - TS: Transport Stream [ISO-MPEG], a method of transmission at the - MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI + 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. See also TS Logical Channel and TS Multiplex. - TS Header: The 4 byte header of a TS Packet [ISO-MPEG]. +Expires July 2005 [page 6] + TS Header: The 4 byte header of a TS Packet [ISO-MPEG2]. Each 188B + TS Packet incorporates a 4B header with the following fields (those + referenced within this document are marked with *): + + Field Length Name/Purpose + (in bits) + + 8b Synchronisation pattern equal 0x47 + *1b Transport Error Indicator + *1b Payload Unit Start Indicator (PUSI) + 1b Transport Priority + *13b Packet IDentifier (PID) + 2b Transport scrambling control + *2b Adaptation Field Control (AFC) + *4b Continuity Counter (CC) TS Logical Channel: Transport Stream Logical Channel. In this - document, this term identifies a channel at the MPEG-2 level [ISO- - MPEG]. It exists at level 2 of the ISO/OSI reference model. All - packets sent over a TS Logical Channel carry the same PID value - (this value is unique within a specific TS Multiplex). According to - MPEG-2, some TS Logical Channels are reserved for specific - signalling purposes. Other standards (e.g., ATSC, DVB) also reserve - specific TS Logical Channels. + document, this term identifies a channel at the MPEG-2 level + [ISO-MPEG2]. This exists at level 2 of the ISO/OSI reference model. + All packets sent over a TS Logical Channel carry the same PID + value (this value is unique within a specific TS Multiplex). The + term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the + content carried by a specific TS Logical Channel (see, ULE Stream). + Some PID values are reserved (by MPEG-2) for specific signalling. + Other standards (e.g., ATSC, DVB) also reserve specific PID values. TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. This may be a common physical link (i.e. a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g. Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [ID- ipdvb-arch], for example to redistribute the same multicast content to two terrestrial TV transmission cells. -Expires July 2005 [page 6] TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex - [ISO-MPEG]. Each TS Packet carries a 4B header, plus optional + [ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional overhead including an Adaptation Field, encryption details and time stamp information to synchronise a set of related TS Logical - Channels. The 188B TS Packet incorporates a 4B header with the - following fields (those referenced within this document are marked - with *): - - Field Length Name/Purpose - (in bits) + Channels. - 8b Synchronisation pattern equal 0x47 - *1b Transport Error Indicator - *1b Payload Unit Start Indicator (PUSI) - 1b Transport Priority - *13b Packet IDentifier (PID) - 2b Transport scrambling control - *2b Adaptation Field Control (AFC) - *4b Continuity Counter (CC) + ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE + encapsulated PDUs. ULE Streams may be identified by definition of + a stream_type in SI/PSI [ISO_MPEG2]. Expires July 2005 [page 7] 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). The SNDU is transmitted over an MPEG-2 transmission network by placing it either in the payload of a single TS Packet, or if required, an SNDU may be fragmented into a series of TS Packets. Where there is sufficient space, the method permits a single TS Packet to carry more than one SNDU (or part there of), sometimes - known as Packing. All TS Packets comprising a SNDU MUST be assigned + known as Packing. All TS Packets comprising an SNDU MUST be assigned the same PID, and therefore form a part of the same TS Logical Channel. The ULE encapsulation is limited to TS private streams only. The header of each TS Packet carries a one bit Payload Unit Start - Indicator (PUSI) field. The PUSI identifies the start of a payload - unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of - the PUSI bit are defined for PES and PSI packets [ISO-MPEG]; for - private data, its use is not defined in the MPEG-2 Standard. In ULE, - although being private data, the operation follows that of PSI - packets. Hence, the following PUSI values are defined: + Indicator (PUSI) field. A PUSI field with a value of 1 indicates the + presence of at least one Payload Unit (SNDU) within the TS Packet + payload. The semantics of the PUSI bit are defined for PES and PSI + packets [ISO-MPEG2]; for private data, its use is not defined in the + MPEG-2 Standard. In ULE, although being private data, the operation + follows that of PSI packets. Hence, the following PUSI values are + defined: - 0: The TS Packet does NOT contain the start of a SNDU, but - contains the continuation, or end of a SNDU; + 0: The TS Packet does NOT contain the start of an SNDU, but + contains the continuation, or end of an SNDU; - 1: The TS Packet contains the start of a SNDU, and a one byte + 1: The TS Packet contains the start of an SNDU, and a one byte Payload Pointer follows the last byte of the TS Packet header. If a Payload Unit (SNDU) finishes before the end of a TS Packet payload, but it is not intended to start another Payload Unit, a stuffing procedure fills the remainder of the TS Packet payload with bytes with a value 0xFF [ISO-MPEG2], known as Padding. A Receiver processing MPEG-2 Table Sections that receives a value of 0xFF in place of the table_id field, interprets this as Padding/Stuffing and silently discards the remainder of the TS @@ -353,79 +387,78 @@ to include stuffing bytes before a TS Packet payload. Adaptation Field stuffing is NOT used in this encapsulation method, and TS Packets from a ULE Encapsulator MUST be sent with an AFC value of '01'. For TS Logical Channels supporting ULE, Receivers MUST discard TS Packets that carry other AFC values. Expires July 2005 [page 8] 4. SNDU Format - PDUs (IP packets and bridged Ethernet frames) are encapsulated using - ULE to form a SNDU. (Each SNDU is an MPEG-2 Payload Unit.) The - encapsulation format to be used for PDUs is illustrated below: + PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an + MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs + is illustrated below: < ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | Type | PDU | CRC-32 | +-+-------------------------------------------------------+--------+ Figure 1: SNDU Encapsulation All multi-byte values in ULE (including Length, Type, and Destination fields) 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. Appendix A provides informative examples of usage. - 4.1 Destination Address Present (D) Field + 4.1 Destination Address Absent (D) Field The most significant bit of the Length Field carries the value of - the Destination Address Present Field, the D-bit. A value of 0 + 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 (i.e. it is omitted). + present. By default, the D-bit value SHOULD be set to a value of 0 (see 4.5), except for the transmission of an End Indicator (see 4.3), for which this bit MUST be set to the value of 1. 4.2 Length Field A 15-bit value that indicates the length, in bytes, of the SNDU - (encapsulated Ethernet frame, IP datagram or other packet) counted - from the byte following the Type field, up to and including the CRC. - Note the special case described in 4.3. + 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 a SNDU have the value 0xFFFF, this + When the first two bytes of an SNDU have the value 0xFFFF, this denotes an End Indicator (i.e., all 1s length combined with a D-bit value of 1). This indicates to the Receiver that there are no further SNDUs present within the current TS Packet (see section 6), and that no Destination Address Field is present. The value 0xFF has specific semantics in MPEG-2 framing, where it is used to indicate the presence of Padding. This use resembles [ISO-DSMCC]. Expires July 2005 [page 9] 4.4 Type Field - The 16-bit Type field indicates the type of payload carried in a + 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. - EtherTypes were originally specified by Xerox under the DIX - framework for Ethernet. After specification of IEEE 802.3 [LLC], the - set of EtherTypes less than 1536 (0x0600), assumed the role of a - length indicator. Ethernet receivers use this feature to - discriminate LLC format frames. Hence any IEEE EtherType < 1536 + EtherTypes were originally specified by Xerox under the Ethernet v2 + Specification [DIX]. After specification of IEEE 802.3 [IEEE 802.3; + ISO-8802-2], the set of EtherTypes less than 1536 (0x0600), assumed + the role of a length indicator. Ethernet receivers use this feature + to discriminate LLC format frames. Hence any IEEE EtherType < 1536 indicates an LLC frame, and the actual value indicates the length of the LLC frame. There is a potential ambiguous case when a Receiver receives a PDU with two length fields: The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network. Specification of two independent length fields is therefore undesirable. In the ULE header, this is avoided in the SNDU header by including only one length value, but bridging of LLC frames re-introduces this @@ -445,74 +478,81 @@ 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 (e.g. a bridging encapsulation). Use of these values is co-ordinated by an IANA - registry. - -Expires July 2005 [page 10] - The following types are defined in this document: - - [XXX IANA ACTION REQUIRED XXX] - - 0x0000: Test SNDU, discarded by the Receiver. - 0x0001: Bridged Ethernet Frame (i.e. MAC source address follows) - 0x0100: Padding, ignored by the Receiver. + registry. The following types are defined in this document: - [XXX END OF IANA ACTION REQUIRED XXX] + 0x0000: Test SNDU (see 5.1) + 0x0001: Bridged Frame (see 5.2) + 0x0100: Extension-Padding (see 5.3) +Expires July 2005 [page 10] The remaining values within the first part of the Type space are reserved for Next-Header values allocated 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) [LLC]. 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): + 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 - 0x86DD : IPv6 Payload + 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), which in combination with the PID value, could - be interpreted as a Link-Level address. + destination address, or a bridged MAC destination address), which in + combination with the PID value, could be interpreted as a Link-Level + address. - When the SNDU header indicates the presence of a SNDU Destination + 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 a - 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. + 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 Expires July 2005 [page 11] + 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 [ITU3563]. This is a 32 bit value calculated according to the generator polynomial represented 0x104C11DB7 in hexadecimal: @@ -540,59 +580,59 @@ 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). +Expires July 2005 [page 12] 4.7 Description of SNDU Formats - The format of a SNDU is determined by the combination of the - Destination Address Present bit (D) and the SNDU Type Field. The - simplest encapsulation places a PDU directly into a SNDU payload. + 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 destination address and directly preceding the PDU. The following SNDU Formats are defined here: End Indicator: The Receiver should enter the Idle State (4.7.1). IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2) - -Expires July 2005 [page 12] IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3). Test SNDU: The payload will be discarded by the Receiver (5.1). - Bridged SNDU: The payload carries a bridged MAC or LLC frame (5.2). + Bridged SNDU: The payload carries a bridged MAC frame (5.2). Other 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | - = Arbitrary number (>= 0) bytes with value 0xFF = - | | + = A sequence of zero or more bytes with a value 0xFF filling = + | the remainder of the TS Packet Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 2: SNDU Format for an End Indicator. + Figure 2: Format for a ULE End Indicator. +Expires July 2005 [page 13] 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 two encapsulations are shown in figures 3 and 4. (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 @@ -606,74 +646,74 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | = IPv4 datagram = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0). -Expires July 2005 [page 13] 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 4: 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. The two encapsulations are shown in figures 5 and 6. +Expires July 2005 [page 14] 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 = 0x086DD | + |0| Length (15b) | Type = 0x86DD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | = IPv6 datagram = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: 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 = 0x086DD | + |1| Length (15b) | Type = 0x86DD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = IPv6 datagram = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1) -Expires July 2005 [page 14] +Expires July 2005 [page 15] 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. 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 @@ -697,36 +737,40 @@ 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). + A H-LEN 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. The set of currently permitted values for both types of Extension Headers are defined by an IANA Registry (section 15). Registry values for Optional Extensions are specified in the form H=1 (i.e. a decimal + +Expires July 2005 [page 16] number in the range 256-511), but may be used with an H-Length value in the range 1-5 (see example in 5.3). -Expires July 2005 [page 15] Two examples of Extension Headers are the Test_SNDU and the use of Extension-Padding. The Test-SNDU Mandatory Extension Header results in the entire PDU being discarded. The Extension-Padding Optional Extension Header results in the following (if any) option header being ignored (i.e. a total of H-LEN 16-bit words). The general format for an SNDU with Extension Headers is: < -------------------------- SNDU ------------------------- > +---+--------------------------------------------------+--------+ @@ -756,159 +800,177 @@ Using this method, several Extension Headers MAY be chained in series. Figure 12 shows an SNDU including two Extension Headers. The values of T1 and T2 are both less than 1536 Decimal, each indicates the presence of an Extension Header, rather than a directly following PDU. T3 has a value > 1535 indicating the EtherType of the PDU being carried. 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. -Expires July 2005 [page 16] +Expires July 2005 [page 17] 5.1 Test SNDU - A Test SNDU (figure 10) is of Type 1. The structure of the Data + A Test SNDU (figure 10) is of a Mandatory Extension Header of Type + 1. This header must be the final (or only) extension header + specified in the header chain of a SNDU. The structure of the Data portion of this SNDU is not defined by this document. All Receivers MAY record reception in a log file, but MUST then discard any Test SNDUs. The D-bit MAY be set in a TEST SNDU. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Length (15b) | Type = 0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = Data (not forwarded by a Receiver) = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: SNDU Format for a Test SNDU 5.2 Bridge Frame SNDU Encapsulation - A bridged SNDU is of Type 1. The payload includes MAC address and - Ether-Type fields together with the contents of a bridged MAC frame. - The SNDU has the format shown in figures 11 and 12. + A bridged SNDU is a Mandatory Extension Header of Type 1. It must be + the final (or only) extension header specified in the header chain + of a SNDU. The payload includes MAC address and EtherType [DIX] or + LLC Length [ISO-8802-2] fields together with the contents of a + bridged MAC frame. The SNDU has the format shown in figures 11 and + 12. + + When an NPA address is specified (D=0), Receivers MUST discard all + SNDUs that carry an NPA destination address that does NOT match + their own NPA address (or a broadcast/multicast address), the + payload of the remaining SNDUs are processed by the bridging rules + that follow. An SNDU without an NPA address (D=1) results in a + Receiver performing bridging processing on the payload of all + received SNDUs. + + A Gateway MAY also use this encapsulation format to directly + communicate network protocol packets that require the LLC + encapsulation [ISO-8802-2]. To do this, it constructs an SNDU with a + Bridge Extension Header containing the intended destination MAC + address, the MAC source address of the Gateway, and the LLC-Length. + The PDU comprises an LLC header followed by the required payload. + The Gateway MAY choose to suppress the NPA address (see 4.5). +Expires July 2005 [page 18] 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 = 0x0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Destination NPA Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Destination Address (6B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Source Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | EtherType (2B) | + | | EtherType/LLC-Length (2B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = (Contents of bridged MAC frame) = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: SNDU Format for a Bridged Payload (D=0) -Expires July 2005 [page 17] 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 = 0x0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Destination Address (6B) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Source Address (6B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | EtherType (2B) | | + | EtherType/LLC-Length (2B) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | = (Contents of bridged MAC frame) = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: SNDU Format for a Bridged Payload (D=1) - Note: The final two bytes of the bridging header also carry a Type - field (see section 5). In this special case, the extension mandatory - header format permits this to carry a LLC Length field, specified by - IEEE 802 [LLC] rather than an IANA assigned value. + The EtherType/LLC-Length field of a frame is defined according to + IEEE 802.3 [IEEE-802.3; ISO-8802-2] (see section 5). - When an NPA address is specified (D=0), Receivers MUST discard all - SNDUs that carry an NPA destination address that does NOT match - their own NPA address (or a broadcast/multicast address), the - payload of the remaining SNDUs are processed by the bridging rules - that follow. An SNDU without an NPA address (D=1) results in a - Receiver performing bridging processing on the payload of all - received SNDUs. + In this special case, the extension mandatory header format permits + this field may be interpreted as either an EtherType [DIX] or an LLC + +Expires July 2005 [page 19] + Length field, specified by IEEE 802 [IEEE-802.3] rather a value + assigned in the ULE Next Header Registry maintained by the IANA. The MAC addresses in the frame being bridged SHOULD be assigned according to the rules specified by the IEEE and may denote unknown, unicast, broadcast, and multicast link addresses. These MAC addresses denote the intended recipient in the destination LAN, and therefore have a different function to the NPA addresses carried in - the SNDU header. The EtherType field of a frame is defined according - to Ethernet/LLC [LLC]. + the SNDU header. A frame Type < 1536 for a bridged frame, introduces a LLC Length field. The Receiver MUST check this length and discard any frame with a length greater than permitted by the SNDU payload size. In normal operation, it is expected that any padding appended to the Ethernet frame SHOULD be removed prior to forwarding. This requires - the sender to be aware of such Ethernet padding (e.g. LLC). + the sender to be aware of such Ethernet padding (e.g. [DIX; IEEE- + 802.3]). -Expires July 2005 [page 18] Ethernet frames received at the Encapsulator for onward transmission over ULE carry a Local Area Network Frame Check sequence, LAN FCS, - field (e.g. CRC-32 for Ethernet). The Encapsulator MUST check the - LAN-FCS value of all frames received, prior to further processing. - Frames received with an invalid LAN FCS MUST be discarded. After - checking, the LAN FCS is then removed (i.e., it is NOT forwarded in - the bridged SNDU). As in other ULE frames, the Encapsulator appends - a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate - LAN-FCS field will be appended to the bridged frame prior to onward - transmission on the Ethernet interface. + field (e.g. CRC-32 for Ethernet [DIX; IEEE-802.3]). The Encapsulator + MUST check the LAN-FCS value of all frames received, prior to + further processing. Frames received with an invalid LAN FCS MUST be + discarded. After checking, the LAN FCS is then removed (i.e., it is + NOT forwarded in the bridged SNDU). As in other ULE frames, the + Encapsulator appends a CRC-32 to the transmitted SNDU. At the + Receiver, an appropriate LAN-FCS field will be appended to the + bridged frame prior to onward transmission on the Ethernet + interface. This design is readily implemented using existing network interface cards, and does not introduce an efficiency cost by transmitting two integrity check fields for bridged frames. However, it also introduces the possibility that a frame corrupted within the processing performed at an Encapsulator and/or Receiver may not be detected by the final recipient(s) (i.e. such corruption would not normally result in an invalid LAN FCS). 5.3 Extension-Padding Optional Extension Header The Extension-Padding Optional Extension Header is specified by an IANA assigned H-Type value of 0x100. As in other Optional Extensions, the total length of the extension is indicated by the H- LEN field (specified in 16-bit words). The extension field is formed - of a group of 1-5 16-bit fields. + of a group of 1 to 5 16-bit fields. For this specific option, only the last 16-bit word has an assigned value, the sender SHOULD set the remaining values to 0x0000. The last 16-bit field forms the Next-Header Type field. A Receiver MUST interpret the Type field, but MUST ignore any other fields of this Extension Header. -Expires July 2005 [page 19] +Expires July 2005 [page 20] 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 [ID- ipdvb-arch]. @@ -918,47 +980,48 @@ |Header| |CRC-32| +------+--------------------------------+------+ / / \ \ / / \ \ / / \ \ +--------+---------+ +--------+---------+ +--------+---------+ |MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 | | Header | Payload | | Header | Payload | | Header | Payload | +--------+---------+ +--------+---------+ +--------+---------+ - Figure 13: Encapsulation of a SNDU into a series of TS Packets + Figure 13: Encapsulation of an SNDU into a series of TS Packets 6.1 SNDU Encapsulation When an Encapsulator has not previously sent a TS Packet for a specific TS Logical Channel, or after an Idle period, it starts to - send a SNDU in the first available TS Packet. This first TS Packet + send an SNDU in the first available TS Packet. This first TS Packet generated MUST carry a PUSI value of 1. It MUST also carry a Payload Pointer value of zero indicating the SNDU starts in the first available byte of the TS Packet payload. The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header, according to - [ISO-MPEG]. This value MUST be incremented by one (modulo 16) for + [ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for each successive fragment/complete SNDU sent using a TS Logical Channel. 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). It informs the Receiver - that there are no more SNDUs in this TS Packet 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, following current practice in MPEG-2 [ISO-DSMCC]. The Padding - procedure trades decreased efficiency against improved latency. + procedure is known as Padding (figure 11). The End Indicator informs + the Receiver that there are no more SNDUs in this TS Packet 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, following current practice in MPEG-2 [ISO-DSMCC]. The + Padding procedure trades decreased efficiency against improved + latency. -Expires July 2005 [page 20] +Expires July 2005 [page 21] +-/------------+ | SubNetwork | | DU 3 | +-/------------+ \ \ \ \ \ \ +--------+--------+--------+----------+ |MPEG-2TS| End of | 0xFFFF | Unused | | Header | SNDU 3 | | Bytes | @@ -993,83 +1056,83 @@ Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2. 6.2 Procedure for Padding and Packing Five possible actions may occur when an Encapsulator has completed encapsulation of an SNDU: (i) If the TS Packet has no remaining space, the Encapsulator transmits this TS Packet. It starts transmission of the next SNDU in - a new TS Packet. (The standard rules [ISO-MPEG] require the header + a new TS Packet. (The standard rules [ISO-MPEG2] require the header of this new TS Packet to carry a PUSI value of 1, and a Payload Pointer value of 0x00.) -Expires July 2005 [page 21] - (ii) If the TS Packet carrying the final part of a SNDU has one byte - of unused payload, the Encapsulator MUST place the value 0xFF in - this final byte, and transmit the TS Packet. This rule provides a +Expires July 2005 [page 22] + (ii) If the TS Packet carrying the final part of an SNDU has one + byte of unused payload, the Encapsulator MUST place the value 0xFF + in this final byte, and transmit the TS Packet. This rule provides a simple mechanism to resolve the complex behaviour that may arise when the TS Packet has no PUSI set. To send another SNDU in the current TS Packet, would otherwise require the addition of a Payload Pointer that would consume the last remaining byte of TS Packet payload. The behaviour follows similar practice for other MPEG-2 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) - (iii) If the TS Packet carrying the final part of a SNDU has exactly - two bytes of unused payload, and the PUSI was NOT already set, the - Encapsulator MUST place the value 0xFFFF in this final two bytes, - providing an End Indicator (section 4.3), and transmit the TS + (iii) If the TS Packet carrying the final part of an SNDU has + exactly two bytes of unused payload, and the PUSI was NOT already + set, the Encapsulator MUST place the value 0xFFFF in this final two + bytes, providing an End Indicator (section 4.3), and transmit the TS Packet. This rule prevents fragmentation of the SNDU Length Field over two TS Packets. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) (iv) If the TS Packet has more than two bytes of unused payload, the Encapsulator MAY transmit this partially full TS Packet but MUST first place the value 0xFF in all remaining unused bytes (i.e. setting an End Indicator followed by Padding). The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The - standard rules [ISO-MPEG] require the header of this new TS Packet + standard rules [ISO-MPEG2] require the header of this new TS Packet to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) - (v) If at least two bytes are available for payload data in the TS + (v) If at least two bytes are available for SNDU data in the TS Packet payload (i.e. three bytes if the PUSI was NOT previously set, and two bytes if it was previously set), the Encapsulator MAY encapsulate further queued PDUs, by starting the next SNDU in the next available byte of the current TS Packet payload. The PUSI MUST be set. When the Encapsulator packs further SNDUs into a TS Packet where the PUSI has NOT already been set, this requires the PUSI to be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted in the first byte directly following the TS Packet header. The value MUST be set to the position of the byte following the end of the first SNDU in the TS Packet payload. If no further PDUs are available, an Encapsulator MAY wait for additional PDUs to fill the incomplete TS Packet. The maximum period of time an Encapsulator can wait, known as the Packing Threshold, MUST be bounded and SHOULD be configurable in the Encapsulator. If sufficient additional PDUs are NOT received to complete the TS Packet within the Packing Threshold, the Encapsulator MUST insert an End Indicator (using rule iv). Use of the Packing method (v) by an Encapsulator is optional, and may be determined on a per-session, per-packet, or per-SNDU basis. -Expires July 2005 [page 22] - When a SNDU is less than the size of a TS Packet payload, a TS +Expires July 2005 [page 23] + When an SNDU is less than the size of a TS Packet payload, a TS Packet may be formed that carries a PUSI value of one and also an End Indicator (using rule iv). -Expires July 2005 [page 23] +Expires July 2005 [page 24] 7. Receiver Processing A Receiver tunes to a specific TS Multiplex and sets a receive filter to accept all TS Packets with a specific PID. These TS Packets are associated with a specific TS Logical Channel and are reassembled to form a stream of SNDUs. A single Receiver may be able to receive multiple TS Logical Channels, possibly using a range of TS Multiplexes. In each case, reassembly MUST be performed independently for each TS Logical Channel. To perform this @@ -1110,165 +1173,171 @@ Insufficient | +----+-----+ | unused space | | PUSI set | MPEG-2 TS Error or | \/ | or End Indicator| +----------+ | SNDU Error | |Reassembly| | +--------| State |--------+ +----------+ Figure 16: Receiver state transitions -Expires July 2005 [page 24] +Expires July 2005 [page 25] 7.1.1 Idle State Payload Pointer Checking A Receiver in the Idle State MUST check the PUSI value in the header of all received TS Packets. A PUSI value of 1 indicates the presence of a Payload Pointer. Following a loss of synchronisation, values between 0 and 181 are permitted, in which case the Receiver MUST - discard the number of bytes indicated by the Payload Pointer from - the start of the TS Packet payload, before leaving the Idle State. - It then enters the Reassembly State, and starts reassembly of a new + discard the number of bytes indicated by the Payload Pointer + (counted from the first byte of the TS Packet payload field, and + excluding the PP field itself), 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 TS Packet payload. If the value is less than or equal to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and the remaining TS Packet payload 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 TS Packet payload to the Current SNDU buffer until either Length bytes in total are received, or the end of the TS Packet 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-* + 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 since bit errors, so the + results in patterns of errors, rather than single bit errors, so the Receiver needs to be robust to arbitrary patterns of corruption to the TS Packet and payload, including potential corruption of the PUSI, PP, and SNDU Length fields. Therefore, a Receiver SHOULD discard the remaining TS Packet 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 a SNDU type error. + recorded as an SNDU type error. +Expires July 2005 [page 26] The Receiver then starts reassembly of the next SNDU. This MAY directly follow the previously reassembled SNDU within the TS Packet payload. -Expires July 2005 [page 25] (i) If the Current SNDU finishes at the end of a TS Packet payload, the Receiver MUST enter the Idle State. (ii) If only one byte remains unprocessed in the TS Packet payload after completion of the Current SNDU, the Receiver MUST discard this final byte of TS Packet 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 TS Packet 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 TS Packet 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. + Otherwise this is the start of the next Packed SNDU and the Receiver + continues by processing this SNDU (provided that the TS Packet has a + PUSI value of 1, see 7.2.1, otherwise the Receiver has detected a + delimiting error and MUST discard all remaining bytes in the TS + Packet payload and transitions to the Idle State). 7.2.1 Reassembly Payload Pointer Checking - A Receiver that has partially received a SNDU (in the Current SNDU + A Receiver that has partially received an SNDU (in the Current SNDU buffer) MUST check the PUSI value in the header of all subsequent TS Packets with the same PID (i.e. same TS Logical Channel). If it receives a TS Packet with a PUSI value of 1, it MUST then verify the Payload Pointer. 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 has detected a delimiting error. Following a delimiting error, the Receiver MUST discard the partially assembled SNDU (in the Current SNDU buffer), and SHOULD record a reassembly error. It MUST then re-enter the Idle State. 7.3 Other Error Conditions The Receiver SHOULD check the MPEG-2 Transport Error Indicator - carried in the TS Packet header [ISO-MPEG]. This flag indicates a + carried in the TS Packet header [ISO-MPEG2]. This flag indicates a transmission error for a TS Logical Channel. If the flag is set to a value of one, 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 MPEG-2 Continuity Counter carried in the - TS Packet header [ISO-MPEG]. If two (or more) successive TS Packets + TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets within the same TS Logical Channel carry the same Continuity Counter + +Expires July 2005 [page 27] value, the duplicate TS Packets MUST be silently discarded. If the received value is NOT identical to that in the previous TS Packet, and it does NOT increment by one for successive TS Packets (modulo 16), 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 July 2005 [page 26] Note that an MPEG2-2 Transmission network is permitted to carry - duplicate TS Packets [ISO-MPEG], which are normally detected by the + duplicate TS Packets [ISO-MPEG2], which are normally detected by the MPEG-2 Continuity Counter. A Receiver that does not perform the above Continuity Counter check, would accept duplicate copies of TS Packets to the reassembly procedure. In most cases, the SNDU CRC-32 integrity check will result in discard of these SNDUs, leading to unexpected PDU loss, however in some cases, duplicate PDUs (fitting into one TS Packet) could pass undetected to the next layer protocol. -Expires July 2005 [page 27] +Expires July 2005 [page 28] 8. Summary This document defines an Ultra Lightweight Encapsulation (ULE) to perform efficient and flexible support for IPv4 and IPv6 network services over networks built upon the MPEG-2 Transport Stream (TS). The encapsulation is also suited to transport of other protocol packets and bridged Ethernet frames. ULE also provides an Extension Header format and defines an associated IANA registry for efficient and flexible support of both mandatory and optional SNDU headers. This allows for future - extension of the protocol, while providing backwards capability with - existing implementations. In particular, Optional Extension Headers - may safely be ignored by Receiver drivers that do not implement - them, or choose not to process them. + extension of the protocol, while providing backwards compatibility + with existing implementations. In particular, Optional Extension + Headers may safely be ignored by Receiver drivers that do not + implement them, or choose not to process them. 9. Acknowledgments This draft is based on a previous draft authored by: Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Fairhurst. The authors wish to thank the members of the ip-dvb mailing list for their input provided. In particular, the many - comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar - Linder, Alain Ritoux, and William Stanislaus. Alain also provided - the original examples of usage. + comments received from Art Allison, Carstsen Borman, Patrick + Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and + William Stanislaus. Alain also provided the original examples of + usage. -Expires July 2005 [page 28] +Expires July 2005 [page 29] 10. Security Considerations The security considerations for ULE resemble those that arise when the existing Multi-Protocol Encapsulation (MPE) is used. ULE does not add specific new threats that will impact the security of the general Internet. There is a known security issue with un-initialised stuffing bytes. In ULE, these bytes are set to 0xFF (normal practice in MPEG-2). @@ -1278,158 +1347,158 @@ exposes the traffic to potentially undetected corruption while being processed by the Encapsulator and/or Receiver. There is a potential security issue when a Receiver receives a PDU with two length fields: The Receiver would need to validate the actual length and the Length Field and ensure that inconsistent values are not propagated by the network. In direct encapsulation of IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length Field. However, this issue still arises in bridged LLC frames, and frames with a LLC Length greater than the SNDU payload size MUST be - discarded, and a SNDU payload length error SHOULD be recorded. + discarded, and an SNDU payload length error SHOULD be recorded. A ULE Mandatory Extension Header may in future be used to define a method to perform link encryption of the SNDU payload. This is as an additional security mechanism to IP, transport or application layer security - not a replacement [ID-ipdvb-arch]. The approach is generic and decouples the encapsulation from future security extensions. The operation provides functions that resemble those currently used with the MPE encapsulation. Additional security control fields may be provided as a part of this link encryption Extension Header, e.g. to associate an SNDU with one of a set of Security Association (SA) parameters. As a part of the encryption process, it may also be desirable to authenticate some/all of the SNDU 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. -Expires July 2005 [page 29] +Expires July 2005 [page 30] 11. References 11.1 Normative References - [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic - coding of moving pictures and associated audio information: - Systems", International Standards Organisation (ISO). - - [RFC2026] Bradner, S., "The Internet Standards Process - Revision - 3", BCP 9, RFC 2026, BCP 9, 1996. + [ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic + coding of moving pictures and associated audio information -- Part + 1: Systems", International Standards Organisation (ISO), 2000. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. + [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. + 11.2 Informative References [ID-ipdvb-arch] "Requirements for transmission of IP datagrams over MPEG-2 networks", Internet Draft, Work in Progress. [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53 Rev.C, 2004 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 2000. [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/91, 2001. [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1995. - [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for + [ATSC-PSIP-TC] A/65B Program and System Information Protocol for Terrestrial Broadcast and Cable", Advanced Television Systems - Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A, 2000. + Committee The(ATSC), Doc. A/65B, 18 March 2003. [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV (DTV) Applications over Satellite", Advanced Television Systems Committee (ATSC), Doc. A/80, 1999. - [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet - over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. +Expires July 2005 [page 31] + [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet + Local Area Network Specification" Version 2.0, November 1982. -Expires July 2005 [page 30] [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI). [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)", European Telecommunications Standards Institute (ETSI). [ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI). [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T)", European Telecommunications Standards Institute (ETSI). [ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", European Telecommunications Standards Institute (ETSI). + [IEEE-802.3] IEEE 802.3 "Local and metropolitan area networks: + Specific requirements Part 3: Carrier sense multiple access with + collision detection (CSMA/CD) access method and physical layer + specifications", IEEE Computer Society, (also ISO/IEC 8802-3). + [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic coding of moving pictures and associated audio information -- Part 6: Extensions for DSM-CC", International Standards Organisation (ISO). - [ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification - Type AAL5, International Standards Organisation (ISO), 1996. - - [LLC] "IEEE Logical Link Control" (ANSI/IEEE Std 802.2/ ISO 8802.2), - 1985. + [ISO-8802-2] ISO/IEC 8802.2 "Logical Link Control", International + Standards Organisation (ISO), 1998. [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link Layer Tunneling Mechanism for Unidirectional Links", RFC3077, Proposed Standard, 2001. [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed Standard, 2001. - [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., - Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, - "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July - 2004. - -Expires July 2005 [page 31] +Expires July 2005 [page 32] 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 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/ -Expires July 2005 [page 32] +Expires July 2005 [page 33] 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. @@ -1459,93 +1528,96 @@ 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 (2004). 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 July 2005 [page 33] +Expires July 2005 [page 34] 15. IANA Considerations This document will require IANA involvement. The ULE Next-Header type field defined in this document requires creation of a registry: ULE Next-Header registry - This registry allocates values 0-512 (decimal). + This registry allocates values 0-511 (decimal). 15.1 IANA Guidelines The following contains the IANA guidelines for management of the ULE - Next-Header registry. This registry allocates values 0-512 decimal + Next-Header registry. This registry allocates values 0-511 decimal (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater than 0x01FF (decimal). It subdivides the Next-Header registry in the following way: 1) 0-255 (decimal) IANA assigned values indicating Mandatory Extension Headers (or link-dependent type fields) for ULE, requiring expert review leading to prior issue of an IETF RFC. - This specification must define the value, and the name associated - with the Extension Header. It must also define the need for the - extension and the intended use. The size of the Extension Header - must also be specified. + This specification MUST define the value, and the name associated + with the Extension Header, together with the procedure for + processing the Extension Header. It MUST also define the need for + the extension and the intended use. The total size of the + Extension Header MUST be specified. Assignments made in this document: Type Name Reference 0: Test-SNDU Section 4.7.4. 1: Bridged-SNDU Section 4.7.5. 2) 256-511 (decimal) IANA assigned values indicating Optional Extension Headers for ULE, requiring expert review leading to - prior issue of an IETF RFC. This specification must define the - value, and the name associated with the Extension Header. The - entry must specify range of allowable H-LEN values that are - permitted (in the range 1-5). It must also define the need for the - extension and the intended use. + prior issue of an IETF RFC. This specification MUST define the + value, and the name associated with the Extension Header, together + with the procedure for processing the Extension Header. The entry + MUST specify range of allowable H-LEN values that are permitted + (in the range 1-5). It MUST also define the need for the extension + and the intended use. Assignments made in this document: Type Name H-LEN Reference 256: Extension-Padding 1-5 Section 5. -Expires July 2005 [page 34] - ANNEXE A: Informative Appendix - SNDU Packing Examples +Expires July 2005 [page 35] + +ANNEX A: Informative Appendix - SNDU Packing Examples This appendix provides some examples of use. The appendix is informative. It does not provide a description of the protocol. The examples provide the complete TS Packet sequence for some sample encapsulated IP packets. The specification of the TS Packet header operation and field values - is provided in [ISO-MPEG]. The specification of ULE is provided in + is provided in [ISO-MPEG2]. The specification of ULE is provided in the body of this document. The key below is provided for the following examples. HDR 4B TS Packet Header PUSI Payload Unit Start Indicator PP Payload Pointer *** TS Packet Payload Pointer (PP) Example A.1: Two 186B PDUs. - SNDU A is 200 bytes (including destination MAC address) - SNDU B is 200 bytes (including destination MAC address) + SNDU A is 200 bytes (including the ULE destination NPA address) + SNDU B is 200 bytes (including the ULE destination NPA address) The sequence comprises 3 TS Packets: SNDU PP=0 Length +-----+------+------+------+- -+------+ | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | +-----+----*-+-*----+------+- -+------+ PUSI=1 * * ***** @@ -1557,21 +1629,21 @@ PUSI=1 * * ************************* End Stuffing CRC for A Indicator Bytes +-----+------+- -+------+----+----+- -+----+ | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF| +-----+------+- -+------+----+----+- -+----+ PUSI=0 -Expires July 2005 [page 35] +Expires July 2005 [page 36] Example A.2: Usage of last byte in a TS-Packet SNDU A is 183 bytes SNDU B is 182 bytes SNDU C is 181 bytes SNDU D is 185 bytes The sequence comprises 4 TS Packets: SNDU @@ -1594,21 +1666,21 @@ | HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 | +-----+---*--+-*----+------+- -+------+------+------+ PUSI=1 * * ****** Unused byte +-----+------+- -+------+------+ | HDR | D002 | ... | D184 | 0xFF | +-----+------+- -+------+------+ PUSI=0 -Expires July 2005 [page 36] +Expires July 2005 [page 37] Example A.3: Large SNDUs SNDU A is 732 bytes SNDU B is 284 bytes The sequence comprises 6 TS Packets: SNDU PP=0 Length +-----+------+------+------+- -+------+ @@ -1640,21 +1712,21 @@ +-----+------+- -+------+ PUSI=0 End Stuffing Indicator Bytes +-----+------+- -+------+------+------+- -+------+ | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF | +-----+------+- -+------+------+------+- -+------+ PUSI=0 -Expires July 2005 [page 37] +Expires July 2005 [page 38] Example A.4: Packing of SNDUs SNDU A is 200 bytes SNDU B is 60 bytes SNDU C is 60 bytes The sequence comprises two TS Packets: SNDU PP=0 Length @@ -1681,67 +1753,67 @@ + ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF | + -+------+-+----+------+ -+------+-+----+------+- -+------+ + + + + + + + ++++++++ + + + + + ++++++++++++++++ ++++++++++++++++++++++ *** TS Packet Payload Pointer (PP) +++ ULE Length Indicator -Expires July 2005 [page 38] +Expires July 2005 [page 39] Example A.5: Three 44B PDUs. - SNDU A is 52 bytes (no destination MAC address) - SNDU B is 52 bytes (no destination MAC address) - SNDU C is 52 bytes (no destination MAC address) + SNDU A is 52 bytes (no ULE destination NPA address) + SNDU B is 52 bytes (no ULE destination NPA address) + SNDU C is 52 bytes (no ULE destination NPA address) The sequence comprises 1 TS Packet: SNDU PP=0 Length +-----+------+------+------+- -+-----+------+-----+- -+-----+- | HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | .. +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- PUSI=1 * * ***** End Stuffing Indicator bytes -----+------+- -+-----+---------+- -+------+ ... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF | -*---+------+- -+-----+---------+- -+------+ -Expires July 2005 [page 39] - ANNEXE B: Informative Appendix - SNDU Encapsulation +Expires July 2005 [page 40] + ANNEX B: Informative Appendix - SNDU Encapsulation An example of ULE encapsulation carrying an ICMPv6 packet generated by ping6. ULE SNDU Length : 63 decimal - D-bit value : 0 (NPA Present) + D-bit value : 0 (NPA destination address present) ULE Protocol Type : 0x86dd (IPv6) Destination ULE NPA Address: 00:01:02:03:04:05 ULE CRC32 : 0x4709a744 Source IPv6: 2001:660:3008:1789::5 Destination IPv6: 2001:660:3008:1789::6 SNDU contents (including CRC-32): 0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d 0016: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0032: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 0048: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 47 0064: 09 a7 44 -Expires July 2005 [page 40] +Expires July 2005 [page 41] [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 IETF in this area. Comments relating to this document will be gratefully received by the author(s) and the ip-dvb mailing list at: @@ -1749,47 +1821,47 @@ -------------------------------------------------------------------- DRAFT 01 (Protocol update) * Padding sequence modified to 0xFFFF, this change aligns with other usage by MPEG-2 streams. Treatment remains the same as specified for ULE. * SDNU Format updated to include R-bit (reserved). - * Procedure for TS Packet carrying the final part of a SNDU with - either less than two bytes of unused payload updated. + * Updated procedure for TS Packet carrying the final part of an SNDU + with either less than two bytes of unused payload updated. * A Receiver MUST silently discard the remainder of a TS Packet payload when two or less bytes remain unprocessed following the end - of a SNDU, irrespective of the PUSI value in the received TS Packet. - It MUST NOT record an error when the value of the remaining byte(s) - is identical to 0xFF or 0xFFFF. The Receiver MUST then wait for a - TS Packet with a PUSI value set to 1. + of an SNDU, irrespective of the PUSI value in the received TS + Packet. It MUST NOT record an error when the value of the remaining + byte(s) is identical to 0xFF or 0xFFFF. The Receiver MUST then wait + for a TS Packet with a PUSI value set to 1. * Payload Pointer description updated. * CRC Calculation added. * Decapsulator processing revised. * Type field split into two. * References updated. * Security considerations added (first draft). * Appendix added with examples. -------------------------------------------------------------------- -Expires July 2005 [page 41] +Expires July 2005 [page 42] DRAFT - 02 (Improvement of clarity) * Corrected CRC-32 to follow standard practice in DSM-CC. * Removed LLC frame type, now redundant by Bridge-Type (==1) * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain, Bernhard * Changes to description of minimum payload length. Gorry @@ -1826,21 +1898,21 @@ sections, since this is not a concern for deployment: Length field usage and padding initialisation. * Changed wording: All multi-byte values in ULE (including Length, Type, and Destination fields) are transmitted in network byte order (most significant byte first). old NiT from Alain, now fixed. * Frame byte size in diagrams now updated to -standard- format, and D bit action corrected, as requested by Alain. -Expires July 2005 [page 42] +Expires July 2005 [page 43] * Frame format diagrams, redrawn to 32-bit format below: 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 * Additional diagram requested by Alain for D=0 bridging (added, and subsequent figures renumbered). * Diagrams of encapsulation process, redrawn for clarity (no change to meaning). Gorry. @@ -1876,21 +1948,21 @@ * Revised CC processing at Encapsulator (B C-N/GF/A.Allison) * Revised CC processing at Receiver (from List: A.Allison; et al ) * Corrections to length/PP field in Examples (M Sooriyabandara, Alain) * Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit) * Section 4.5 only SHARED routed links require D=0 * Packing Threshold defined * Next-Layer-Header defined (Now called Next-Header) * Addition of Appendix B (to aide verification of SNDFU format) -Expires July 2005 [page 43] +Expires July 2005 [page 44] Working Group ID rev 01 Issues addressed: * Typographical * Types > 1500 should be passed to the next higher protocol (Hilmar) * The second part of the Type space corresponds to the values 1500 COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF. * IANA has already defined IP and IPv6 types - corrected text! Added more security considerations (-01d). * Should we allow an Adaptation Field within ULE (request for DVB- @@ -1916,21 +1988,21 @@ Correction of figure numbering. Correction to capitalisation in Transport Stream definition of fields Inserted space character after 1536 in line 2 of 4.4.2 Replaced } with ] after ISO_DSMCC Replace reference to section 6.3 with section 7.3 at end of section 4.6. Reference in 4.7.4 was changed to refer to figure 7 (not 6). Note added after figure 9. -Expires July 2005 [page 44] +Expires July 2005 [page 45] Working Group ID rev 03 Changes with this revision of the document: (i) The worked hexadecimal example in the annexe was reworked to include a valid MAC address for an IPv6 unicast packet. - (BCN) (ii) The IANA procedures revised, based on inputs from IANA to improve consistency of the term Next-Header and to add the @@ -1949,27 +2021,91 @@ (vi) Check for <- -> sequences of characters. (GF) (vii) Update refs to add RFC3667 / 3668. (GF) (viii) Changed text defining M in DSMCC definition to the word Media (ix) 7.1.1 Range of PP values corrected to 0-181. (x) Definition of END INDICATOR corrected in section 2 - this is not a TYPE value, but a LENGTH value. (xi) Next-Header used throughout the document to replace next-layer-header, and various other forms of wording. (xii) In section 7.2, added a ref the section on PP checking -Expires July 2005 [page 45] Working Group ID rev 04 This rev followed WGLC comments, which are defined in the ipdvb mailing list. Important changes included: (i) This text was moved to an appendix (ii) ToC was updated and section headers made consistent (iii) Revised definition text - (iv) Improved clarity with respect to terms defined in ISO 18181-1 + (iv) Improved clarity with respect to terms defined in ISO 13818-1 (v) Bridging and Extension-Padding formats move to section 5 (vi) Clarification of the NPA in packet headers - (vii) Clarification of placement of NPA address with extension headers. + (vii) Clarification of placement of NPA address with extension + headers. - [END of RFC EDITOR NOTE] + Issues address in rev-05: + + These revisions were made following a second WGLC and invited cross- + area IETF review of the Spec. + + NiTS corrected: Expires July 2005 [page 46] + Abstract shortened. + Added separate references to Ethernet v2; LLC; and 802.3 + Added RFC2119 Boilerplate for definitions of capitilised words. + Corrected English and 63 typos + Specified explicitly that Test & Bridge Extension Headers must be + the last in the extension chain (no other headers may follow) + 7.1.1. para 1 - changed PP processing description to specify where + to count the number of bytes that were pointed to + Corrected the range 0-512 in the IANA Guidelines (should be 0-511). + Fixed NPA to consistently refer to the ULE destination address. + + Specific Issues: + + 1) The reviewer suggested the title was confusing. A proposed new + Title is: + Ultra Lightweight Encapsulation (ULE) for transmission of + IP datagrams over an MPEG-2 Transport Stream + + 2) The reviewer suggested that the name of the D field was changed, + to make the meaning more obvious. The new name is Destination + Address Absent field, rather than the Destination Address + Present field. The semantics of the D-bit do not change. + + 3) The reviewer asked for a description of how to send an LLC frame + - in Section 4. This was added to the section on bridging. + + 4) The reviewer mentioned that we had NOT defined the values needed + for mapping addresses... I'm not sure this was an over-sight, but + This was an oversight, the new text was added to the end of the + description in section 4.5. Also added references to [RFC1112] + [RFC2464]. + + 5) Added text on the need for data descriptors. + + 6) Removed reference to RFC3819 which was either ambiguous in the + definition of SNDU. + + 7) In final clause of 7.2 (Receiver processing) the last sentence + was extended by a bracketed clause to deal with the case when there + was excess data and no PUSI set). + + (iii) If two or more bytes of TS Packet 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 TS Packet 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 TS Packet has a + PUSI value of 1, see 7.2.1, otherwise the Receiver has detected a + delimiting error and MUST discard all remaining bytes in the TS + Packet payload and transitions to the Idle State). + +Expires July 2005 [page 47] + 8) Revised IANA procedures to REQUIRE a definition of the PROCEDURE + when defining an extension header. + + [END of RFC EDITOR NOTE] + +Expires July 2005 [page 48]