idnits 2.17.1 draft-ietf-ipdvb-ule-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1463. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 15. IANA Considerations' ) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Category: Draft, Intended Standards Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7009 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ETSI-DVB' is mentioned on line 161, but not defined == Missing Reference: 'ITU3563' is mentioned on line 535, but not defined == Unused Reference: 'RFC3667' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: 'ATSC-DAT' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: 'ATSC-DATG' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'ATSC-G' is defined on line 1365, but no explicit reference was found in the text == Unused Reference: 'ATSC-PSIP-TC' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: 'ATSC-S' is defined on line 1373, but no explicit reference was found in the text == Unused Reference: 'ETSI-DAT' is defined on line 1380, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBC' is defined on line 1383, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBS' is defined on line 1387, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBT' is defined on line 1391, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG2' ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gorry Fairhurst 2 Internet Draft University of Aberdeen 3 Document: draft-ietf-ipdvb-ule-05.txt Bernhard Collini-Nocker 4 University of Salzburg 6 ipdvb WG 8 Category: Draft, Intended Standards Track February 2005 10 Ultra Lightweight Encapsulation (ULE) for transmission of 11 IP datagrams over an MPEG-2 Transport Stream 13 Status of this Draft 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The MPEG-2 Transport Stream (TS) has been widely accepted not only 36 for providing digital TV services, but also as a subnetwork 37 technology for building IP networks. 39 This document describes an Ultra Lightweight Encapsulation (ULE) 40 mechanism for the transport of IPv4 and IPv6 Datagrams and other 41 network protocol packets directly over the ISO MPEG-2 Transport 42 Stream as TS Private Data. ULE specifies a base encapsulation format 43 and supports an extension format that allows it to carry additional 44 header information to assist in network/Receiver processing. 46 Table of Contents 48 1. Introduction 49 2. Conventions used in this document 50 3. Description of method 51 4. SNDU Format 52 4.1 Destination Address Absent (D) Field 53 4.2 Length Field 54 4.3 End Indicator 55 4.4 Type Field 56 4.4.1 Type 1: Next-Header Type Fields 57 4.4.2 Type 2: EtherType Compatible Type Fields 58 4.5 SNDU Destination Address Field 59 4.6 SNDU Trailer CRC 60 4.7 Description of SNDU Formats 61 4.7.1 End Indicator 62 4.7.2 IPv4 SNDU Encapsulation 63 4.7.3 IPv6 SNDU Encapsulation 64 5. Extension Headers 65 5.1 Test SNDU 66 5.2 Bridged Frame SNDU Encapsulation 67 5.3 Extension-Padding Optional Extension Header 68 6.Processing at the Encapsulator 69 6.1 SNDU Encapsulation 70 6.2 Procedure for Padding and Packing 71 7. Receiver Processing 72 7.1 Idle State 73 7.1.1 Idle State Payload Pointer Checking 74 7.2 Processing of a Received SNDU 75 7.2.1 Reassembly Payload Pointer Checking 76 7.3 Other Error Conditions 77 8. Summary 78 9. Acknowledgments 79 10. Security Considerations 80 11. References 81 11.1 Normative References 82 11.2 Informative References 83 12. Authors' Addresses 84 13. IPR Notices 85 13.1 Intellectual Property Statement 86 13.2 Disclaimer of Validity 87 14. Copyright Statement 88 14.1 Intellectual Property Statement 89 14.2 Disclaimer of Validity 90 15. IANA Considerations 91 15.1 IANA Guidelines 93 ANNEX A: Informative Appendix - SNDU Packing Examples 94 ANNEX B: Informative Appendix - SNDU Encapsulation 95 1. Introduction 97 This document describes an encapsulation for transport of IP 98 datagrams, or other network layer packets, over ISO MPEG-2 Transport 99 Streams [[ISO-MPEG2; ID-ipdvb-arch]. It is suited to services based 100 on MPEG-2, for example the Digital Video Broadcast (DVB) 101 architecture, the Advanced Television Systems Committee (ATSC) 102 system [ATSC; ATSC-G], and other similar MPEG-2 based transmission 103 systems. Such systems provide unidirectional (simplex) physical and 104 link layer standards. Support has been defined for a wide range of 105 physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], 106 Satellite TV [ETSI-DVBS; ATSC-S], Cable Transmission [ETSI-DVBC; 107 ATSC-PSIP-TC]). Bi-directional (duplex) links may also be 108 established using these standards (e.g., DVB defines a range of 109 return channel technologies, including the use of two-way satellite 110 links [ETSI-RCS] and dial-up modem links [RFC3077]). 112 Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other 113 network layer packets) for transmission over an MPEG-2 Transport 114 Multiplex are passed to an Encapsulator. This formats each PDU into 115 a SubNetwork Data Unit (SNDU) by adding an encapsulation header and 116 an integrity check trailer. The SNDU is fragmented into a series of 117 TS Packets that are sent over a single TS Logical Channel. 119 The MPEG-2 specification [ISO-MPEG2] requires conformant TS 120 Multiplexes to provide Program Specific Information (PSI) for 121 each stream in the TS Multiplex. Other MPEG-2 based transmission 122 standards may also define Service Information (SI). This 123 information may allow Receivers and Re-multiplexors 124 [draft-ipdvb-arch] to locate a specific ULE Stream (i.e., the PID 125 value of the TS Logical Channel that carries a ULE Stream). The 126 conditions under which this information is required, and the 127 format in which it is to be provided is beyond the scope of 128 this document. Addressing and mapping issues for ULE over MPEG-2 129 are also described in [draft-ipdvb-ar]. 131 2. Conventions used in this document 133 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 134 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 Other terms used in this document are defined below: 140 Adaptation Field: An optional variable-length extension field of the 141 fixed-length TS Packet header, intended to convey clock references 142 and timing and synchronization information as well as stuffing over 143 an MPEG-2 Multiplex [ISO-MPEG2]. 145 AFC: Adaptation Field Control [ISO_MPEG]. A pair of bits carried in 146 the TS Packet header that signal the presence of the Adaptation 147 Field and/or TS Packet payload. 149 ATSC: Advanced Television Systems Committee [ATSC]. A framework and 150 a set of associated standards for the transmission of video, audio, 151 and data using the ISO MPEG-2 standard. 153 b: bit. For example, one byte consists of 8b. 155 B: Byte. Groups of bytes are represented in Internet byte order. 157 DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A 158 format for transmission of data and control information in an MPEG-2 159 Private Section, defined by the ISO MPEG-2 standard. 161 DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of 162 associated standards published by the European Telecommunications 163 Standards Institute (ETSI) for the transmission of video, audio, and 164 data, using the ISO MPEG-2 Standard. 166 Encapsulator: A network device that receives PDUs and formats these 167 into Payload Units (known here as SNDUs) for output as a stream of 168 TS Packets. 170 End Indicator: A value that indicates to the Receiver that there are 171 no further SNDUs present within the current TS Packet. 173 LLC: Logical Link Control [ISO-8802-2]. A link layer protocol 174 defined by the IEEE 802 standard, which follows the Ethernet MAC 175 Header. 177 MAC: Medium Access Control [IEEE-802.3]. A link layer protocol 178 defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). 180 MAC Header: The link layer header of the IEEE 802.3 standard [IEEE- 181 802.3] or Ethernet v2 [DIX]. It consists of a 6B destination 182 address, 6B source address, and 2B type field (see also NPA, LLC). 184 MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. A 185 scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each 186 Section is sent in a series of TS Packets using a single TS Logical 187 Channel. 189 MPEG-2: A set of standards specified by the Motion Picture Experts 190 Group (MPEG), and standardized by the International Standards 191 Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). 193 Next-Header: A Type value indicating an Extension Header. 195 NPA: Network Point of Attachment. In this document, refers to a 6 196 byte destination address (resembling an IEEE MAC address) within the 197 MPEG-2 transmission network that is used to identify individual 198 Receivers or groups of Receivers. 200 Packing Threshold: A period of time an Encapsulator is willing to 201 defer transmission of a partially filled TS-Packet to accumulate 202 more SNDUs, rather than use Padding. After the Packet Threshold 203 period, the Encapsulator uses Padding to send the partially filled 204 TS-Packet. 206 PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, 207 IPv4 or IPv6 datagrams, and other network packets. 209 PES: Packetized Elementary Steam [ISO-MPEG2]. A format of MPEG-2 TS 210 packet payload usually used for video or audio information. 212 PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the 213 header of TS Packets. This is used to identify the TS Logical 214 Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets 215 forming the parts of a Table Section, PES, or other Payload Unit 216 must all carry the same PID value. The all 1s PID value indicates a 217 Null TS Packet introduced to maintain a constant bit rate of a TS 218 Multiplex. There is no required relationship between the PID values 219 used for TS Logical Channels transmitted using different TS 220 Multiplexes. 222 PP: Payload Pointer [ISO-MPEG2]. An optional one byte pointer that 223 directly follows the TS Packet header. It contains the number of 224 bytes between the end of the TS Packet header and the start of a 225 Payload Unit. The presence of the Payload Pointer is indicated by 226 the value of the PUSI bit in the TS Packet header. The Payload 227 Pointer is present in DSM-CC, and Table Sections, it is not present 228 in TS Logical Channels that use the PES-format. 230 Private Section: A syntactic structure constructed in accordance 231 with Table 2-30 of [ISO-MPEG2]. The structure may be used to 232 identify private information (i.e. not defined by [ISO-MPEG2]) 233 relating to one or more elementary streams, or a specific MPEG-2 234 program, or the entire Transport Stream. Other Standards bodies, 235 e.g. ETSI, ATSC, have defined sets of table structures using the 236 private_section structure. A Private Section is transmitted as a 237 sequence of TS Packets using a TS Logical Channel. A TS Logical 238 Channel may carry sections from more than one set of tables. 240 PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey 241 information about services carried in a TS Multiplex. It is carried 242 in one of four specifically identified table section constructs 243 [ISO-MPEG2], see also SI Table. 245 PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey 246 information about the service carried in a TS Multiplex. The set of 247 PSI tables is defined by MPEG-2 [ISO-MPEG2]. See also SI Table. 249 PU: Payload Unit. A sequence of bytes sent using a TS. Examples of 250 Payload Units include: an MPEG-2 Table Section or a ULE SNDU. 252 PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. A single bit flag 253 carried in the TS Packet header. A PUSI value of zero indicates that 254 the TS Packet does not carry the start of a new Payload Unit. A PUSI 255 value of one indicates that the TS Packet does carry the start of a 256 new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the 257 presence of a one byte Payload Pointer (PP). 259 Receiver: Equipment that processes the signal from a TS Multiplex 260 and performs filtering and forwarding of encapsulated PDUs to the 261 network-layer service (or bridging module when operating at the link 262 layer). 264 SI Table: Service Information Table [ISO-MPEG2]. In this document, 265 this term describes a table that is been defined by another 266 standards body to convey information about the services carried in a 267 TS Multiplex. A Table may consist of one or more Table Sections, 268 however all sections of a particular SI Table must be carried over a 269 single TS Logical Channel [ISO-MPEG2]. 271 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 272 Payload Unit. 274 Table Section: A Payload Unit carrying all or a part of an SI or PSI 275 Table [ISO-MPEG2]. 277 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 278 MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 279 reference model. See also TS Logical Channel and TS Multiplex. 281 TS Header: The 4 byte header of a TS Packet [ISO-MPEG2]. Each 188B 282 TS Packet incorporates a 4B header with the following fields (those 283 referenced within this document are marked with *): 285 Field Length Name/Purpose 286 (in bits) 288 8b Synchronisation pattern equal 0x47 289 *1b Transport Error Indicator 290 *1b Payload Unit Start Indicator (PUSI) 291 1b Transport Priority 292 *13b Packet IDentifier (PID) 293 2b Transport scrambling control 294 *2b Adaptation Field Control (AFC) 295 *4b Continuity Counter (CC) 297 TS Logical Channel: Transport Stream Logical Channel. In this 298 document, this term identifies a channel at the MPEG-2 level 299 [ISO-MPEG2]. This exists at level 2 of the ISO/OSI reference model. 300 All packets sent over a TS Logical Channel carry the same PID 301 value (this value is unique within a specific TS Multiplex). The 302 term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the 303 content carried by a specific TS Logical Channel (see, ULE Stream). 304 Some PID values are reserved (by MPEG-2) for specific signalling. 305 Other standards (e.g., ATSC, DVB) also reserve specific PID values. 307 TS Multiplex: In this document, this term defines a set of MPEG-2 TS 308 Logical Channels sent over a single lower layer connection. This may 309 be a common physical link (i.e. a transmission at a specified symbol 310 rate, FEC setting, and transmission frequency) or an encapsulation 311 provided by another protocol layer (e.g. Ethernet, or RTP over IP). 312 The same TS Logical Channel may be repeated over more than one TS 313 Multiplex (possibly associated with a different PID value) [ID- 314 ipdvb-arch], for example to redistribute the same multicast content 315 to two terrestrial TV transmission cells. 317 TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex 318 [ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional 319 overhead including an Adaptation Field, encryption details and time 320 stamp information to synchronise a set of related TS Logical 321 Channels. 323 ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE 324 encapsulated PDUs. ULE Streams may be identified by definition of 325 a stream_type in SI/PSI [ISO_MPEG2]. 327 3. Description of the Method 329 PDUs (IP packets, Ethernet frames or packets from other network 330 protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). 331 The SNDU is transmitted over an MPEG-2 transmission network by 332 placing it either in the payload of a single TS Packet, or if 333 required, an SNDU may be fragmented into a series of TS Packets. 334 Where there is sufficient space, the method permits a single TS 335 Packet to carry more than one SNDU (or part there of), sometimes 336 known as Packing. All TS Packets comprising an SNDU MUST be assigned 337 the same PID, and therefore form a part of the same TS Logical 338 Channel. 340 The ULE encapsulation is limited to TS private streams only. The 341 header of each TS Packet carries a one bit Payload Unit Start 342 Indicator (PUSI) field. A PUSI field with a value of 1 indicates the 343 presence of at least one Payload Unit (SNDU) within the TS Packet 344 payload. The semantics of the PUSI bit are defined for PES and PSI 345 packets [ISO-MPEG2]; for private data, its use is not defined in the 346 MPEG-2 Standard. In ULE, although being private data, the operation 347 follows that of PSI packets. Hence, the following PUSI values are 348 defined: 350 0: The TS Packet does NOT contain the start of an SNDU, but 351 contains the continuation, or end of an SNDU; 353 1: The TS Packet contains the start of an SNDU, and a one byte 354 Payload Pointer follows the last byte of the TS Packet header. 356 If a Payload Unit (SNDU) finishes before the end of a TS Packet 357 payload, but it is not intended to start another Payload Unit, a 358 stuffing procedure fills the remainder of the TS Packet payload with 359 bytes with a value 0xFF [ISO-MPEG2], known as Padding. 361 A Receiver processing MPEG-2 Table Sections that receives a value of 362 0xFF in place of the table_id field, interprets this as 363 Padding/Stuffing and silently discards the remainder of the TS 364 Packet payload. The payload of the next TS Packet for the same TS 365 Logical Channel will begin with a Payload Pointer of value 0x00, 366 indicating that the next Payload Unit immediately follows the TS 367 Packet header. The ULE protocol resembles this, but differs in the 368 exact procedure (see the following sections). 370 The TS Packet Header also carries a two bit Adaptation Field Control 371 (AFC) value. This adaptation field may extend the TS Packet Header 372 to carry timing and synchronisation information and may also be used 373 to include stuffing bytes before a TS Packet payload. Adaptation 374 Field stuffing is NOT used in this encapsulation method, and TS 375 Packets from a ULE Encapsulator MUST be sent with an AFC value of 376 '01'. For TS Logical Channels supporting ULE, Receivers MUST discard 377 TS Packets that carry other AFC values. 379 4. SNDU Format 381 PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an 382 MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs 383 is illustrated below: 385 < ----------------------------- SNDU ----------------------------- > 386 +-+-------------------------------------------------------+--------+ 387 |D| Length | Type | PDU | CRC-32 | 388 +-+-------------------------------------------------------+--------+ 390 Figure 1: SNDU Encapsulation 392 All multi-byte values in ULE (including Length, Type, and 393 Destination fields) are transmitted in network byte order (most 394 significant byte first). The most significant bit of each byte is 395 placed in the left-most position of the 8-bit field. Appendix A 396 provides informative examples of usage. 398 4.1 Destination Address Absent (D) Field 400 The most significant bit of the Length Field carries the value of 401 the Destination Address Absent Field, the D-bit. A value of 0 402 indicates the presence of the Destination Address Field (see section 403 4.5). A value of 1 indicates that a Destination Address Field is not 404 present. 406 By default, the D-bit value SHOULD be set to a value of 0 (see 4.5), 407 except for the transmission of an End Indicator (see 4.3), for which 408 this bit MUST be set to the value of 1. 410 4.2 Length Field 412 A 15-bit value that indicates the length, in bytes, of the SNDU 413 counted from the byte following the Type field, up to and including 414 the CRC. Note the special case described in 4.3. 416 4.3 End Indicator 418 When the first two bytes of an SNDU have the value 0xFFFF, this 419 denotes an End Indicator (i.e., all 1s length combined with a D-bit 420 value of 1). This indicates to the Receiver that there are no 421 further SNDUs present within the current TS Packet (see section 6), 422 and that no Destination Address Field is present. The value 0xFF has 423 specific semantics in MPEG-2 framing, where it is used to indicate 424 the presence of Padding. This use resembles [ISO-DSMCC]. 426 4.4 Type Field 428 The 16-bit Type field indicates the type of payload carried in an 429 SNDU, or the presence of a Next-Header. The set of values that may 430 be assigned to this field is divided into two parts, similar to the 431 allocations for Ethernet. 433 EtherTypes were originally specified by Xerox under the Ethernet v2 434 Specification [DIX]. After specification of IEEE 802.3 [IEEE 802.3; 435 ISO-8802-2], the set of EtherTypes less than 1536 (0x0600), assumed 436 the role of a length indicator. Ethernet receivers use this feature 437 to discriminate LLC format frames. Hence any IEEE EtherType < 1536 438 indicates an LLC frame, and the actual value indicates the length of 439 the LLC frame. 441 There is a potential ambiguous case when a Receiver receives a PDU 442 with two length fields: The Receiver would need to validate the 443 actual length and the Length field and ensure that inconsistent 444 values are not propagated by the network. Specification of two 445 independent length fields is therefore undesirable. In the ULE 446 header, this is avoided in the SNDU header by including only one 447 length value, but bridging of LLC frames re-introduces this 448 consideration (section 5.2). 450 The Ethernet LLC mode of identification is not required in ULE, 451 since the SNDU format always carries an explicit Length Field, and 452 therefore the procedure in ULE is modified, as below: 454 The first set of ULE Type field values comprise the set of values 455 less than 1536 in decimal. These Type field values are IANA 456 assigned (see 4.4.1), and indicate the Next-Header. 458 The second set of ULE Type field values comprise the set of values 459 greater than or equal to 1536 in decimal. In ULE, this value is 460 identical to the corresponding type codes specified by the IEEE/DIX 461 type assignments for Ethernet and recorded in the IANA EtherType 462 registry. 464 4.4.1 Type 1: Next-Header Type Fields 466 The first part of the Type space corresponds to the values 0 to 1535 467 Decimal. These values may be used to identify link-specific 468 protocols and/or to indicate the presence of Extension Headers that 469 carry additional optional protocol fields (e.g. a bridging 470 encapsulation). Use of these values is co-ordinated by an IANA 471 registry. The following types are defined in this document: 473 0x0000: Test SNDU (see 5.1) 474 0x0001: Bridged Frame (see 5.2) 475 0x0100: Extension-Padding (see 5.3) 476 The remaining values within the first part of the Type space are 477 reserved for Next-Header values allocated by the IANA. 479 4.4.2 Type 2: EtherType Compatible Type Fields 481 The second part of the Type space corresponds to the values between 482 0x600 (1536 decimal) and 0xFFFF. This set of type assignments 483 follow DIX/IEEE assignments (but exclude use of this field as a 484 frame length indicator). All assignments in this space MUST use the 485 values defined for IANA EtherType, the following two Type values are 486 used as examples (taken from the IANA EtherTypes registry): 488 0x0800: IPv4 Payload (see 4.7.2) 489 0x86DD: IPv6 Payload (see 4.7.3) 491 4.5 SNDU Destination Address Field 493 The SNDU Destination Address Field is optional (see 4.1). This field 494 MUST be carried (i.e. D=0) for IP unicast packets destined to 495 routers that are sent using shared links (i.e., where the same link 496 connects multiple Receivers). A sender MAY omit this field (D=1) for 497 an IP unicast packet and/or multicast packets delivered to Receivers 498 that are able to utilise a discriminator field (e.g. the IPv4/IPv6 499 destination address, or a bridged MAC destination address), which in 500 combination with the PID value, could be interpreted as a Link-Level 501 address. 503 When the SNDU header indicates the presence of an SNDU Destination 504 Address field (i.e. D=0), a Network Point of Attachment, NPA, field 505 directly follows the fourth byte of the SNDU header. NPA destination 506 addresses are 6 Byte numbers, normally expressed in hexadecimal, 507 used to identify the Receiver(s) in a MPEG-2 transmission network 508 that should process a received SNDU. The value 0x00:00:00:00:00:00, 509 MUST NOT be used as a destination address in an SNDU. The least 510 significant bit of the first byte of the address is set to 1 for 511 multicast frames, and the remaining bytes specify the link layer 512 multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the 513 link broadcast address, indicating this SNDU is to be delivered to 514 all Receivers. 516 IPv4 packets carrying an IPv4 subnetwork broadcast address need to 517 be delivered to all systems with the same network prefix. When a 518 SNDU Destination Address is present (D=0) the value MUST be set to 519 the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF). 521 When the PDU is an IP multicast packet and an SNDU Destination 522 Address is present (D=0), the IP group destination address of the 523 multicast packet MUST be mapped to the multicast SNDU Destination 524 Address (following the method used to generate a destination MAC 525 address in Ethernet). The method for mapping IPv4 multicast 526 addresses is specified in [RFC1112]. The method for mapping IPv6 527 multicast addresses is specified in [RFC2464]. 529 4.6 SNDU Trailer CRC 531 Each SNDU MUST carry a 32-bit CRC field in the last four bytes of 532 the SNDU. This position eases CRC computation by hardware. The CRC- 533 32 polynomial is to be used. Examples where this polynomial is also 534 employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and 535 AAL5 [ITU3563]. This is a 32 bit value calculated according to the 536 generator polynomial represented 0x104C11DB7 in hexadecimal: 538 x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0. 540 The Encapsulator initialises the CRC-32 accumulator register to the 541 value 0xFFFF FFFF. It then accumulates a transmit value for the 542 CRC32 that includes all bytes from the start of the SNDU header to 543 the end of the SNDU (excluding the 32-bit trailer holding the CRC- 544 32), and places this in the CRC Field. In ULE, the bytes are 545 processed in order of increasing position within the SNDU, the order 546 of processing bits is NOT reversed. This use resembles, but is 547 different to that in SCTP [RFC3309]. 549 The Receiver performs an integrity check by independently 550 calculating the same CRC value and comparing this with the 551 transmitted value in the SNDU trailer. SNDUs that do not have a 552 valid CRC, are discarded, causing the Receiver to enter the Idle 553 State. 555 This description may be suited for hardware implementation, but this 556 document does not imply any specific implementation. Software-based 557 table-lookup or hardware-assisted software-based implementations are 558 also possible. Annexe B provides an example of an Encapsulated PDU 559 that includes the computed CRC-32 value. 561 The primary purpose of this CRC is to protect the SNDU (header, and 562 payload) from undetected reassembly errors and errors introduced by 563 unexpected software / hardware operation while the SNDU is in 564 transit across the MPEG-2 subnetwork and during processing at the 565 encapsulation gateway and/or the Receiver. It may also detect the 566 presence of uncorrected errors from the physical link (however, 567 these may also be detected by other means, e.g. section 7.3). 569 4.7 Description of SNDU Formats 571 The format of an SNDU is determined by the combination of the 572 Destination Address Absent bit (D) and the SNDU Type Field. The 573 simplest encapsulation places a PDU directly into an SNDU payload. 574 Some Type 1 encapsulations may require additional header fields. 575 These are inserted in the SNDU following the NPA destination address 576 and directly preceding the PDU. 578 The following SNDU Formats are defined here: 580 End Indicator: The Receiver should enter the Idle State (4.7.1). 581 IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2) 582 IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3). 583 Test SNDU: The payload will be discarded by the Receiver (5.1). 584 Bridged SNDU: The payload carries a bridged MAC frame (5.2). 586 Other formats may be defined through relevant assignments in the 587 IEEE and IANA registries. 589 4.7.1 End Indicator 591 The format of the End Indicator is shown in figure 2. This format 592 MUST carry a D-bit value of 1. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |1| 0x7FFF | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | | 600 = A sequence of zero or more bytes with a value 0xFF filling = 601 | the remainder of the TS Packet Payload | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 2: Format for a ULE End Indicator. 606 4.7.2 IPv4 SNDU 608 IPv4 datagrams are directly transported using one of the two 609 standard SNDU structures, in which the PDU is placed directly in the 610 SNDU payload. The two encapsulations are shown in figures 3 and 4. 611 (Note that in this, and the following figures, the IP datagram 612 payload is of variable size, and is directly followed by the CRC- 613 32). 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |0| Length (15b) | Type = 0x0800 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Receiver Destination NPA Address (6B) | 621 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 624 | | 625 = IPv4 datagram = 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | (CRC-32) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0). 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 |1| Length (15b) | Type = 0x0800 | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | | 639 = IPv4 datagram = 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | (CRC-32) | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1). 647 4.7.3 IPv6 SNDU Encapsulation 649 IPv6 datagrams are directly transported using one of the two 650 standard SNDU structures, in which the PDU is placed directly in the 651 SNDU payload. The two encapsulations are shown in figures 5 and 6. 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |0| Length (15b) | Type = 0x86DD | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Receiver Destination NPA Address (6B) | 659 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 662 | | 663 = IPv6 datagram = 664 | | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | (CRC-32) | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0). 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 |1| Length (15b) | Type = 0x86DD | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | | 677 = IPv6 datagram = 678 | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | (CRC-32) | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1) 684 5. Extension Headers 686 This section describes an extension format for the ULE 687 encapsulation. In ULE, a Type field value less than 1536 Decimal 688 indicates an Extension Header. These values are assigned from a 689 separate IANA registry defined for ULE. 691 The use of a single Type/Next-Header field simplifies processing and 692 eliminates the need to maintain multiple IANA registries. The cost 693 is that each Extension Header requires at least 2 bytes. This is 694 justified, on the basis of simplified processing and maintaining a 695 simple lightweight header for the common case when no extensions are 696 present. 698 A ULE Extension Header is identified by a 16-bit value in the Type 699 field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN 700 field and an 8-bit H-Type field, as follows: 702 0 1 703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 |0 0 0 0 0|H-LEN| H-Type | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 7: Structure of ULE Next-Header Field. 710 The H-LEN Assignment is described below: 712 0 Indicates a Mandatory Extension Header 713 1 Indicates an Optional Extension Header of length 2B 714 2 Indicates an Optional Extension Header of length 4B 715 3 Indicates an Optional Extension Header of length 6B 716 4 Indicates an Optional Extension Header of length 8B 717 5 Indicates an Optional Extension Header of length 10B 718 >=6 the combined H-LEN and H-TYPE values indicate the EtherType 719 of a PDU that directly follows this Type field. 721 The H-LEN value indicates the total number of bytes in an Optional 722 Extension Header (including the 2B Type field). 724 A H-LEN of zero indicates a Mandatory Extension Header. Each 725 Mandatory Extension Header has a pre-defined length that is not 726 communicated in the H-LEN field. No additional limit is placed on 727 the maximum length of a Mandatory Extension Header. A Mandatory 728 Extension Header MAY modify the format or encoding of the enclosed 729 PDU (e.g. to perform encryption and/or compression). 731 The H-Type is a one byte field that is either one of 256 Mandatory 732 Header Extensions or one of 256 Optional Header Extensions. The set 733 of currently permitted values for both types of Extension Headers 734 are defined by an IANA Registry (section 15). Registry values for 735 Optional Extensions are specified in the form H=1 (i.e. a decimal 736 number in the range 256-511), but may be used with an H-Length value 737 in the range 1-5 (see example in 5.3). 739 Two examples of Extension Headers are the Test_SNDU and the use of 740 Extension-Padding. The Test-SNDU Mandatory Extension Header results 741 in the entire PDU being discarded. The Extension-Padding Optional 742 Extension Header results in the following (if any) option header 743 being ignored (i.e. a total of H-LEN 16-bit words). 745 The general format for an SNDU with Extension Headers is: 747 < -------------------------- SNDU ------------------------- > 748 +---+--------------------------------------------------+--------+ 749 |D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 | 750 +---+--------------------------------------------------+--------+ 751 < ULE base header > < ext 1 > 753 Figure 8: SNDU Encapsulation with one Extension Header (for D=0). 755 Where: 756 D is the ULE D_bit (in this example D=0, however NPA addresses may 757 also be omitted when using Extension Headers). 758 T1 is the base header Type field. In this case, specifying a 759 Next-Header value. 760 H1 is a set of fields defined for header type T1. There may be 0 761 or more bytes of information for a specific ULE Extension Header. 762 T2 is the Type field of the next header, or an EtherType > 1535 B 763 indicating the type of the PDU being carried. 765 < -------------------------- SNDU ------------------------- > 766 +---+---------------------------------------------------+--------+ 767 |D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 | 768 +---+---------------------------------------------------+--------+ 769 < ULE base header >< ext 1 >< ext 2 > 771 Figure 9: SNDU Encapsulation with two Extension Headers (D=1). 773 Using this method, several Extension Headers MAY be chained in 774 series. Figure 12 shows an SNDU including two Extension Headers. The 775 values of T1 and T2 are both less than 1536 Decimal, each indicates 776 the presence of an Extension Header, rather than a directly 777 following PDU. T3 has a value > 1535 indicating the EtherType of the 778 PDU being carried. Although an SNDU may contain an arbitrary number 779 of consecutive Extension Headers, it is not expected that SNDUs will 780 generally carry a large number of extensions. 782 5.1 Test SNDU 784 A Test SNDU (figure 10) is of a Mandatory Extension Header of Type 785 1. This header must be the final (or only) extension header 786 specified in the header chain of a SNDU. The structure of the Data 787 portion of this SNDU is not defined by this document. All Receivers 788 MAY record reception in a log file, but MUST then discard any Test 789 SNDUs. The D-bit MAY be set in a TEST SNDU. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 |D| Length (15b) | Type = 0x0000 | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | | 797 = Data (not forwarded by a Receiver) = 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | (CRC-32) | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Figure 10: SNDU Format for a Test SNDU 805 5.2 Bridge Frame SNDU Encapsulation 807 A bridged SNDU is a Mandatory Extension Header of Type 1. It must be 808 the final (or only) extension header specified in the header chain 809 of a SNDU. The payload includes MAC address and EtherType [DIX] or 810 LLC Length [ISO-8802-2] fields together with the contents of a 811 bridged MAC frame. The SNDU has the format shown in figures 11 and 812 12. 814 When an NPA address is specified (D=0), Receivers MUST discard all 815 SNDUs that carry an NPA destination address that does NOT match 816 their own NPA address (or a broadcast/multicast address), the 817 payload of the remaining SNDUs are processed by the bridging rules 818 that follow. An SNDU without an NPA address (D=1) results in a 819 Receiver performing bridging processing on the payload of all 820 received SNDUs. 822 A Gateway MAY also use this encapsulation format to directly 823 communicate network protocol packets that require the LLC 824 encapsulation [ISO-8802-2]. To do this, it constructs an SNDU with a 825 Bridge Extension Header containing the intended destination MAC 826 address, the MAC source address of the Gateway, and the LLC-Length. 827 The PDU comprises an LLC header followed by the required payload. 828 The Gateway MAY choose to suppress the NPA address (see 4.5). 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 |0| Length (15b) | Type = 0x0001 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Receiver Destination NPA Address (6B) | 836 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | | | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 839 | MAC Destination Address (6B) | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | MAC Source Address (6B) | 842 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | | EtherType/LLC-Length (2B) | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | | 846 = (Contents of bridged MAC frame) = 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | (CRC-32) | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Figure 11: SNDU Format for a Bridged Payload (D=0) 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |1| Length (15b) | Type = 0x0001 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | MAC Destination Address (6B) | 860 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | | | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 863 | MAC Source Address (6B) | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | EtherType/LLC-Length (2B) | | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 867 | | 868 = (Contents of bridged MAC frame) = 869 | | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | (CRC-32) | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Figure 12: SNDU Format for a Bridged Payload (D=1) 876 The EtherType/LLC-Length field of a frame is defined according to 877 IEEE 802.3 [IEEE-802.3; ISO-8802-2] (see section 5). 879 In this special case, the extension mandatory header format permits 880 this field may be interpreted as either an EtherType [DIX] or an LLC 881 Length field, specified by IEEE 802 [IEEE-802.3] rather a value 882 assigned in the ULE Next Header Registry maintained by the IANA. 884 The MAC addresses in the frame being bridged SHOULD be assigned 885 according to the rules specified by the IEEE and may denote unknown, 886 unicast, broadcast, and multicast link addresses. These MAC 887 addresses denote the intended recipient in the destination LAN, and 888 therefore have a different function to the NPA addresses carried in 889 the SNDU header. 891 A frame Type < 1536 for a bridged frame, introduces a LLC Length 892 field. The Receiver MUST check this length and discard any frame 893 with a length greater than permitted by the SNDU payload size. 895 In normal operation, it is expected that any padding appended to the 896 Ethernet frame SHOULD be removed prior to forwarding. This requires 897 the sender to be aware of such Ethernet padding (e.g. [DIX; IEEE- 898 802.3]). 900 Ethernet frames received at the Encapsulator for onward transmission 901 over ULE carry a Local Area Network Frame Check sequence, LAN FCS, 902 field (e.g. CRC-32 for Ethernet [DIX; IEEE-802.3]). The Encapsulator 903 MUST check the LAN-FCS value of all frames received, prior to 904 further processing. Frames received with an invalid LAN FCS MUST be 905 discarded. After checking, the LAN FCS is then removed (i.e., it is 906 NOT forwarded in the bridged SNDU). As in other ULE frames, the 907 Encapsulator appends a CRC-32 to the transmitted SNDU. At the 908 Receiver, an appropriate LAN-FCS field will be appended to the 909 bridged frame prior to onward transmission on the Ethernet 910 interface. 912 This design is readily implemented using existing network interface 913 cards, and does not introduce an efficiency cost by transmitting two 914 integrity check fields for bridged frames. However, it also 915 introduces the possibility that a frame corrupted within the 916 processing performed at an Encapsulator and/or Receiver may not be 917 detected by the final recipient(s) (i.e. such corruption would not 918 normally result in an invalid LAN FCS). 920 5.3 Extension-Padding Optional Extension Header 922 The Extension-Padding Optional Extension Header is specified by an 923 IANA assigned H-Type value of 0x100. As in other Optional 924 Extensions, the total length of the extension is indicated by the H- 925 LEN field (specified in 16-bit words). The extension field is formed 926 of a group of 1 to 5 16-bit fields. 928 For this specific option, only the last 16-bit word has an assigned 929 value, the sender SHOULD set the remaining values to 0x0000. The 930 last 16-bit field forms the Next-Header Type field. A Receiver MUST 931 interpret the Type field, but MUST ignore any other fields of this 932 Extension Header. 934 6. Processing at the Encapsulator 936 The Encapsulator forms the PDUs queued for transmission into SNDUs 937 by adding a header and trailer to each PDU (section 4). It then 938 segments the SNDU into a series of TS Packet payloads (figure 9). 939 These are transmitted using a single TS Logical Channel over a TS 940 Multiplex. The TS Multiplex may be processed by a number of MPEG-2 941 (re)multiplexors before it is finally delivered to a Receiver [ID- 942 ipdvb-arch]. 944 +------+--------------------------------+------+ 945 | ULE | Protocol Data Unit | ULE | 946 |Header| |CRC-32| 947 +------+--------------------------------+------+ 948 / / \ \ 949 / / \ \ 950 / / \ \ 951 +--------+---------+ +--------+---------+ +--------+---------+ 952 |MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 | 953 | Header | Payload | | Header | Payload | | Header | Payload | 954 +--------+---------+ +--------+---------+ +--------+---------+ 956 Figure 13: Encapsulation of an SNDU into a series of TS Packets 958 6.1 SNDU Encapsulation 960 When an Encapsulator has not previously sent a TS Packet for a 961 specific TS Logical Channel, or after an Idle period, it starts to 962 send an SNDU in the first available TS Packet. This first TS Packet 963 generated MUST carry a PUSI value of 1. It MUST also carry a Payload 964 Pointer value of zero indicating the SNDU starts in the first 965 available byte of the TS Packet payload. 967 The Encapsulation MUST ensure that all TS Packets set the MPEG-2 968 Continuity Counter carried in the TS Packet header, according to 969 [ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for 970 each successive fragment/complete SNDU sent using a TS Logical 971 Channel. 973 An Encapsulator MAY decide not to immediately send another SNDU, 974 even if space is available in a partially filled TS Packet. This 975 procedure is known as Padding (figure 11). The End Indicator informs 976 the Receiver that there are no more SNDUs in this TS Packet payload. 977 The End Indicator is followed by zero or more unused bytes until the 978 end of the TS Packet payload. All unused bytes MUST be set to the 979 value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The 980 Padding procedure trades decreased efficiency against improved 981 latency. 983 +-/------------+ 984 | SubNetwork | 985 | DU 3 | 986 +-/------------+ 987 \ \ 988 \ \ 989 \ \ 990 +--------+--------+--------+----------+ 991 |MPEG-2TS| End of | 0xFFFF | Unused | 992 | Header | SNDU 3 | | Bytes | 993 +--------+--------+--------+----------+ 994 PUSI=0 ULE 995 End 996 Indicator 998 Figure 14: A TS Packet carrying the end of SNDU 3, followed by an 999 End Indicator. 1001 Alternatively, when more packets are waiting at an Encapsulator, and 1002 a TS Packet has sufficient space remaining in the payload, the 1003 Encapsulator can follow a previously encapsulated SNDU with another 1004 SNDU using the next available byte of the TS Packet payload (see 1005 6.2). This is called Packing (figure 15). 1007 +-/----------------+ +----------------/-+ 1008 | Subnetwork | | Subnetwork | 1009 | DU 1 | | DU 2 | 1010 +-/----------------+ +----------------/-+ 1011 \ \ / /\ 1012 \ \ / / \ 1013 \ \ / / \. . . 1014 +--------+--------+--------+----------+ 1015 |MPEG-2TS| Payload| end of | start of | 1016 | Header | Pointer| SNDU 1 | SNDU 2 | 1017 +--------+--------+--------+----------+ 1018 PUSI=1 | ^ 1019 | | 1020 +--------------+ 1022 Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2. 1024 6.2 Procedure for Padding and Packing 1026 Five possible actions may occur when an Encapsulator has completed 1027 encapsulation of an SNDU: 1029 (i) If the TS Packet has no remaining space, the Encapsulator 1030 transmits this TS Packet. It starts transmission of the next SNDU in 1031 a new TS Packet. (The standard rules [ISO-MPEG2] require the header 1032 of this new TS Packet to carry a PUSI value of 1, and a Payload 1033 Pointer value of 0x00.) 1034 (ii) If the TS Packet carrying the final part of an SNDU has one 1035 byte of unused payload, the Encapsulator MUST place the value 0xFF 1036 in this final byte, and transmit the TS Packet. This rule provides a 1037 simple mechanism to resolve the complex behaviour that may arise 1038 when the TS Packet has no PUSI set. To send another SNDU in the 1039 current TS Packet, would otherwise require the addition of a Payload 1040 Pointer that would consume the last remaining byte of TS Packet 1041 payload. The behaviour follows similar practice for other MPEG-2 1042 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission 1043 of the next SNDU in a new TS Packet. (The standard rules require the 1044 header of this new TS Packet to carry a PUSI value of 1 and a 1045 Payload Pointer value of 0x00.) 1047 (iii) If the TS Packet carrying the final part of an SNDU has 1048 exactly two bytes of unused payload, and the PUSI was NOT already 1049 set, the Encapsulator MUST place the value 0xFFFF in this final two 1050 bytes, providing an End Indicator (section 4.3), and transmit the TS 1051 Packet. This rule prevents fragmentation of the SNDU Length Field 1052 over two TS Packets. The Encapsulator MUST start transmission of the 1053 next SNDU in a new TS Packet. (The standard rules require the header 1054 of this new TS Packet to carry a PUSI value of 1 and a Payload 1055 Pointer value of 0x00.) 1057 (iv) If the TS Packet has more than two bytes of unused payload, the 1058 Encapsulator MAY transmit this partially full TS Packet but MUST 1059 first place the value 0xFF in all remaining unused bytes (i.e. 1060 setting an End Indicator followed by Padding). The Encapsulator MUST 1061 start transmission of the next SNDU in a new TS Packet. (The 1062 standard rules [ISO-MPEG2] require the header of this new TS Packet 1063 to carry a PUSI value of 1 and a Payload Pointer value of 0x00.) 1065 (v) If at least two bytes are available for SNDU data in the TS 1066 Packet payload (i.e. three bytes if the PUSI was NOT previously set, 1067 and two bytes if it was previously set), the Encapsulator MAY 1068 encapsulate further queued PDUs, by starting the next SNDU in the 1069 next available byte of the current TS Packet payload. The PUSI MUST 1070 be set. When the Encapsulator packs further SNDUs into a TS Packet 1071 where the PUSI has NOT already been set, this requires the PUSI to 1072 be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted 1073 in the first byte directly following the TS Packet header. The value 1074 MUST be set to the position of the byte following the end of the 1075 first SNDU in the TS Packet payload. If no further PDUs are 1076 available, an Encapsulator MAY wait for additional PDUs to fill the 1077 incomplete TS Packet. The maximum period of time an Encapsulator can 1078 wait, known as the Packing Threshold, MUST be bounded and SHOULD be 1079 configurable in the Encapsulator. If sufficient additional PDUs are 1080 NOT received to complete the TS Packet within the Packing Threshold, 1081 the Encapsulator MUST insert an End Indicator (using rule iv). 1083 Use of the Packing method (v) by an Encapsulator is optional, and 1084 may be determined on a per-session, per-packet, or per-SNDU basis. 1086 When an SNDU is less than the size of a TS Packet payload, a TS 1087 Packet may be formed that carries a PUSI value of one and also an 1088 End Indicator (using rule iv). 1090 7. Receiver Processing 1092 A Receiver tunes to a specific TS Multiplex and sets a receive 1093 filter to accept all TS Packets with a specific PID. These TS 1094 Packets are associated with a specific TS Logical Channel and are 1095 reassembled to form a stream of SNDUs. A single Receiver may be 1096 able to receive multiple TS Logical Channels, possibly using a range 1097 of TS Multiplexes. In each case, reassembly MUST be performed 1098 independently for each TS Logical Channel. To perform this 1099 reassembly, the Receiver may use a buffer to hold the partially 1100 assembled SNDU, referred to here as the Current SNDU buffer. Other 1101 implementations may choose to use other data structures, but MUST 1102 provide equivalent operations. 1104 Receipt of a TS Packet with a PUSI value of 1 indicates that the TS 1105 Packet contains the start of a new SNDU. It also indicates the 1106 presence of the Payload Pointer (indicating the number of bytes to 1107 the start of the first SNDU in the TS-Packet currently being 1108 reassembled). It is illegal to receive a Payload Pointer value 1109 greater than 181, and this MUST cause the SNDU reassembly to be 1110 aborted and the Receiver to enter the Idle State. This event SHOULD 1111 be recorded as a payload pointer error. 1113 A Receiver MUST support the use of both the Packing and Padding 1114 method for any received SNDU, and MUST support reception of SNDUs 1115 with or without a Destination Address Field (i.e. D=0 and D=1). 1117 7.1 Idle State 1119 After initialisation, errors, or on receipt of an End Indicator, the 1120 Receiver enters the Idle State. In this state, the Receiver discards 1121 all TS Packets until it discovers the start of a new SNDU, when it 1122 then enters the Reassembly State. Figure 16 outlines these state 1123 transitions: 1125 +-------+ 1126 | START | 1127 +---+---+ 1128 | 1129 \/ 1130 +----------+ 1131 \| Idle |/ 1132 +-------/| State |\-------+ 1133 Insufficient | +----+-----+ | 1134 unused space | | PUSI set | MPEG-2 TS Error 1135 or | \/ | or 1136 End Indicator| +----------+ | SNDU Error 1137 | |Reassembly| | 1138 +--------| State |--------+ 1139 +----------+ 1141 Figure 16: Receiver state transitions 1142 7.1.1 Idle State Payload Pointer Checking 1144 A Receiver in the Idle State MUST check the PUSI value in the header 1145 of all received TS Packets. A PUSI value of 1 indicates the presence 1146 of a Payload Pointer. Following a loss of synchronisation, values 1147 between 0 and 181 are permitted, in which case the Receiver MUST 1148 discard the number of bytes indicated by the Payload Pointer 1149 (counted from the first byte of the TS Packet payload field, and 1150 excluding the PP field itself), before leaving the Idle State. It 1151 then enters the Reassembly State, and starts reassembly of a new 1152 SNDU at this point. 1154 7.2 Processing of a Received SNDU 1156 When in the Reassembly State, the Receiver reads a 2 byte SNDU 1157 Length Field from the TS Packet payload. If the value is less than 1158 or equal to 4, or equal to 0xFFFF, the Receiver discards the Current 1159 SNDU and the remaining TS Packet payload and returns to the Idle 1160 State. Receipt of an invalid Length Field is an error event and 1161 SHOULD be recorded as an SNDU length error. 1163 If the Length of the Current SNDU is greater than 4, the Receiver 1164 accepts bytes from the TS Packet payload to the Current SNDU buffer 1165 until either Length bytes in total are received, or the end of the 1166 TS Packet is reached (see also 7.2.1). When Current SNDU length 1167 equals the value of the Length Field, the Receiver MUST calculate 1168 and verify the CRC value (see 4.6). SNDUs that contain an invalid 1169 CRC value MUST be discarded. Mismatch of the CRC is an error event 1170 and SHOULD be recorded as a CRC error. The under-lying physical- 1171 layer processing (e.g. forward error correction coding) often 1172 results in patterns of errors, rather than single bit errors, so the 1173 Receiver needs to be robust to arbitrary patterns of corruption to 1174 the TS Packet and payload, including potential corruption of the 1175 PUSI, PP, and SNDU Length fields. Therefore, a Receiver SHOULD 1176 discard the remaining TS Packet payload (if any) following a CRC 1177 mismatch and return to the Idle State. 1179 When the Destination Address is present (D=0), the Receiver accepts 1180 SNDUs that match one of a set of addresses specified by the Receiver 1181 (this includes the NPA address of the Receiver, the NPA broadcast 1182 address and any required multicast NPA addresses). The Receiver MUST 1183 silently discard an SNDU with an unmatched address. 1185 After receiving a valid SNDU, the Receiver MUST check the Type Field 1186 (and process any Type 1 Extension Headers). The SNDU payload is then 1187 passed to the next protocol layer specified. An SNDU with an unknown 1188 Type value < 1536 MUST be discarded. This error event SHOULD be 1189 recorded as an SNDU type error. 1191 The Receiver then starts reassembly of the next SNDU. This MAY 1192 directly follow the previously reassembled SNDU within the TS Packet 1193 payload. 1195 (i) If the Current SNDU finishes at the end of a TS Packet payload, 1196 the Receiver MUST enter the Idle State. 1198 (ii) If only one byte remains unprocessed in the TS Packet payload 1199 after completion of the Current SNDU, the Receiver MUST discard this 1200 final byte of TS Packet payload. It then enters the Idle State. It 1201 MUST NOT record an error when the value of the remaining byte is 1202 identical to 0xFF. 1204 (iii) If two or more bytes of TS Packet payload data remain after 1205 completion of the Current SNDU, the Receiver accepts the next 2 1206 bytes and examines if this is an End Indicator. When an End 1207 Indicator is received, a Receiver MUST silently discard the 1208 remainder of the TS Packet payload and transition to the Idle State. 1209 Otherwise this is the start of the next Packed SNDU and the Receiver 1210 continues by processing this SNDU (provided that the TS Packet has a 1211 PUSI value of 1, see 7.2.1, otherwise the Receiver has detected a 1212 delimiting error and MUST discard all remaining bytes in the TS 1213 Packet payload and transitions to the Idle State). 1215 7.2.1 Reassembly Payload Pointer Checking 1217 A Receiver that has partially received an SNDU (in the Current SNDU 1218 buffer) MUST check the PUSI value in the header of all subsequent TS 1219 Packets with the same PID (i.e. same TS Logical Channel). If it 1220 receives a TS Packet with a PUSI value of 1, it MUST then verify the 1221 Payload Pointer. If the Payload Pointer does NOT equal the number of 1222 bytes remaining to complete the Current SNDU, i.e., the difference 1223 between the SNDU Length field and the number of reassembled bytes, 1224 the Receiver has detected a delimiting error. 1226 Following a delimiting error, the Receiver MUST discard the 1227 partially assembled SNDU (in the Current SNDU buffer), and SHOULD 1228 record a reassembly error. It MUST then re-enter the Idle State. 1230 7.3 Other Error Conditions 1232 The Receiver SHOULD check the MPEG-2 Transport Error Indicator 1233 carried in the TS Packet header [ISO-MPEG2]. This flag indicates a 1234 transmission error for a TS Logical Channel. If the flag is set to a 1235 value of one, a transmission error event SHOULD be recorded. Any 1236 partially received SNDU MUST be discarded. The Receiver then enters 1237 the Idle State. 1239 The Receiver MUST check the MPEG-2 Continuity Counter carried in the 1240 TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets 1241 within the same TS Logical Channel carry the same Continuity Counter 1242 value, the duplicate TS Packets MUST be silently discarded. If the 1243 received value is NOT identical to that in the previous TS Packet, 1244 and it does NOT increment by one for successive TS Packets (modulo 1245 16), the Receiver has detected a continuity error. Any partially 1246 received SNDU MUST be discarded. A continuity counter error event 1247 SHOULD be recorded. The Receiver then enters the Idle State. 1249 Note that an MPEG2-2 Transmission network is permitted to carry 1250 duplicate TS Packets [ISO-MPEG2], which are normally detected by the 1251 MPEG-2 Continuity Counter. A Receiver that does not perform the 1252 above Continuity Counter check, would accept duplicate copies of TS 1253 Packets to the reassembly procedure. In most cases, the SNDU CRC-32 1254 integrity check will result in discard of these SNDUs, leading to 1255 unexpected PDU loss, however in some cases, duplicate PDUs (fitting 1256 into one TS Packet) could pass undetected to the next layer 1257 protocol. 1259 8. Summary 1261 This document defines an Ultra Lightweight Encapsulation (ULE) to 1262 perform efficient and flexible support for IPv4 and IPv6 network 1263 services over networks built upon the MPEG-2 Transport Stream (TS). 1264 The encapsulation is also suited to transport of other protocol 1265 packets and bridged Ethernet frames. 1267 ULE also provides an Extension Header format and defines an 1268 associated IANA registry for efficient and flexible support of both 1269 mandatory and optional SNDU headers. This allows for future 1270 extension of the protocol, while providing backwards compatibility 1271 with existing implementations. In particular, Optional Extension 1272 Headers may safely be ignored by Receiver drivers that do not 1273 implement them, or choose not to process them. 1275 9. Acknowledgments 1277 This draft is based on a previous draft authored by: Horst D. 1278 Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry 1279 Fairhurst. The authors wish to thank the members of the ip-dvb 1280 mailing list for their input provided. In particular, the many 1281 comments received from Art Allison, Carstsen Borman, Patrick 1282 Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and 1283 William Stanislaus. Alain also provided the original examples of 1284 usage. 1286 10. Security Considerations 1288 The security considerations for ULE resemble those that arise when 1289 the existing Multi-Protocol Encapsulation (MPE) is used. ULE does 1290 not add specific new threats that will impact the security of the 1291 general Internet. 1293 There is a known security issue with un-initialised stuffing bytes. 1294 In ULE, these bytes are set to 0xFF (normal practice in MPEG-2). 1296 There are known integrity issues with the removal of the LAN FCS in 1297 a bridged networking environment. The removal for bridged frames 1298 exposes the traffic to potentially undetected corruption while being 1299 processed by the Encapsulator and/or Receiver. 1301 There is a potential security issue when a Receiver receives a PDU 1302 with two length fields: The Receiver would need to validate the 1303 actual length and the Length Field and ensure that inconsistent 1304 values are not propagated by the network. In direct encapsulation of 1305 IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length 1306 Field. However, this issue still arises in bridged LLC frames, and 1307 frames with a LLC Length greater than the SNDU payload size MUST be 1308 discarded, and an SNDU payload length error SHOULD be recorded. 1310 A ULE Mandatory Extension Header may in future be used to define a 1311 method to perform link encryption of the SNDU payload. This is as an 1312 additional security mechanism to IP, transport or application layer 1313 security - not a replacement [ID-ipdvb-arch]. The approach is 1314 generic and decouples the encapsulation from future security 1315 extensions. The operation provides functions that resemble those 1316 currently used with the MPE encapsulation. 1318 Additional security control fields may be provided as a part of this 1319 link encryption Extension Header, e.g. to associate an SNDU with one 1320 of a set of Security Association (SA) parameters. As a part of the 1321 encryption process, it may also be desirable to authenticate 1322 some/all of the SNDU headers. The method of encryption and the way 1323 in which keys are exchanged is beyond the scope of this 1324 specification, as also are the definition of the SA format and that 1325 of the related encryption keys. 1327 11. References 1329 11.1 Normative References 1331 [ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic 1332 coding of moving pictures and associated audio information -- Part 1333 1: Systems", International Standards Organisation (ISO), 2000. 1335 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 1336 Requirement Levels", BCP 14, RFC 2119, 1997. 1338 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1339 3667, February 2004. 1341 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 1342 Technology", BCP 79, RFC 3668, February 2004. 1344 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1345 RFC 1112, August 1989. 1347 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1348 Networks", RFC 2464, December 1998. 1350 11.2 Informative References 1352 [ID-ipdvb-arch] "Requirements for transmission of IP datagrams over 1353 MPEG-2 networks", Internet Draft, Work in Progress. 1355 [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television 1356 Systems Committee (ATSC), Doc. A/53 Rev.C, 2004 1358 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 1359 Systems Committee (ATSC), Doc. A/090, 2000. 1361 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 1362 for the ATSC Data Broadcast Standard", Advanced Television Systems 1363 Committee (ATSC), Doc. A/91, 2001. 1365 [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television 1366 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1367 1995. 1369 [ATSC-PSIP-TC] A/65B Program and System Information Protocol for 1370 Terrestrial Broadcast and Cable", Advanced Television Systems 1371 Committee The(ATSC), Doc. A/65B, 18 March 2003. 1373 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV 1374 (DTV) Applications over Satellite", Advanced Television Systems 1375 Committee (ATSC), Doc. A/80, 1999. 1377 [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet 1378 Local Area Network Specification" Version 2.0, November 1982. 1380 [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", 1381 European Telecommunications Standards Institute (ETSI). 1383 [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB 1384 interaction channel for Cable TV distribution systems (CATV)", 1385 European Telecommunications Standards Institute (ETSI). 1387 [ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation 1388 and Coding for DBS satellite systems at 11/12 GHz", European 1389 Telecommunications Standards Institute (ETSI). 1391 [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing 1392 structure, channel coding and modulation for digital terrestrial 1393 television (DVB-T)", European Telecommunications Standards Institute 1394 (ETSI). 1396 [ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB); 1397 Interaction Channel for Satellite Distribution Systems", European 1398 Telecommunications Standards Institute (ETSI). 1400 [IEEE-802.3] IEEE 802.3 "Local and metropolitan area networks: 1401 Specific requirements Part 3: Carrier sense multiple access with 1402 collision detection (CSMA/CD) access method and physical layer 1403 specifications", IEEE Computer Society, (also ISO/IEC 8802-3). 1405 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic 1406 coding of moving pictures and associated audio information -- Part 1407 6: Extensions for DSM-CC", International Standards Organisation 1408 (ISO). 1410 [ISO-8802-2] ISO/IEC 8802.2 "Logical Link Control", International 1411 Standards Organisation (ISO), 1998. 1413 [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link 1414 Layer Tunneling Mechanism for Unidirectional Links", RFC3077, 1415 Proposed Standard, 2001. 1417 [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control 1418 Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed 1419 Standard, 2001. 1421 12. Authors' Addresses 1423 Godred Fairhurst 1424 Department of Engineering 1425 University of Aberdeen 1426 Aberdeen, AB24 3UE 1427 UK 1428 Email: gorry@erg.abdn.ac.uk 1429 Web: http://www.erg.abdn.ac.uk/users/Gorry 1431 Bernhard Collini-Nocker 1432 Department of Scientific Computing 1433 University of Salzburg 1434 Jakob Haringer Str. 2 1435 5020 Salzburg 1436 Austria 1437 Email: bnocker@cosy.sbg.ac.at 1438 Web: http://www.scicomp.sbg.ac.at/ 1439 13. IPR Notices 1441 13.1 Intellectual Property Statement 1443 The IETF takes no position regarding the validity or scope of any 1444 Intellectual Property Rights or other rights that might be claimed 1445 to pertain to the implementation or use of the technology described 1446 in this document or the extent to which any license under such 1447 rights might or might not be available; nor does it represent that 1448 it has made any independent effort to identify any such rights. 1449 Information on the procedures with respect to rights in RFC 1450 documents can be found in BCP 78 and BCP 79. 1452 Copies of IPR disclosures made to the IETF Secretariat and any 1453 assurances of licenses to be made available, or the result of an 1454 attempt made to obtain a general license or permission for the use 1455 of such proprietary rights by implementers or users of this 1456 specification can be obtained from the IETF on-line IPR repository 1457 at http://www.ietf.org/ipr. 1459 The IETF invites any interested party to bring to its attention any 1460 copyrights, patents or patent applications, or other proprietary 1461 rights that may cover technology that may be required to implement 1462 this standard. Please address the information to the IETF at ietf- 1463 ipr@ietf.org. 1465 13.2 Disclaimer of Validity 1467 This document and the information contained herein are provided on 1468 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1469 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1470 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1471 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1472 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1473 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1475 14. Copyright Statement 1477 Copyright (C) The Internet Society (2004). This document is 1478 subject to the rights, licenses and restrictions contained in 1479 BCP 78, and except as set forth therein, the authors retain all 1480 their rights. 1482 15. IANA Considerations 1484 This document will require IANA involvement. 1486 The ULE Next-Header type field defined in this document requires 1487 creation of a registry: 1489 ULE Next-Header registry 1491 This registry allocates values 0-511 (decimal). 1493 15.1 IANA Guidelines 1495 The following contains the IANA guidelines for management of the ULE 1496 Next-Header registry. This registry allocates values 0-511 decimal 1497 (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater 1498 than 0x01FF (decimal). 1500 It subdivides the Next-Header registry in the following way: 1502 1) 0-255 (decimal) IANA assigned values indicating Mandatory 1503 Extension Headers (or link-dependent type fields) for ULE, 1504 requiring expert review leading to prior issue of an IETF RFC. 1505 This specification MUST define the value, and the name associated 1506 with the Extension Header, together with the procedure for 1507 processing the Extension Header. It MUST also define the need for 1508 the extension and the intended use. The total size of the 1509 Extension Header MUST be specified. 1511 Assignments made in this document: 1513 Type Name Reference 1515 0: Test-SNDU Section 4.7.4. 1516 1: Bridged-SNDU Section 4.7.5. 1518 2) 256-511 (decimal) IANA assigned values indicating Optional 1519 Extension Headers for ULE, requiring expert review leading to 1520 prior issue of an IETF RFC. This specification MUST define the 1521 value, and the name associated with the Extension Header, together 1522 with the procedure for processing the Extension Header. The entry 1523 MUST specify range of allowable H-LEN values that are permitted 1524 (in the range 1-5). It MUST also define the need for the extension 1525 and the intended use. 1527 Assignments made in this document: 1529 Type Name H-LEN Reference 1531 256: Extension-Padding 1-5 Section 5. 1533 ANNEX A: Informative Appendix - SNDU Packing Examples 1535 This appendix provides some examples of use. The appendix is 1536 informative. It does not provide a description of the protocol. The 1537 examples provide the complete TS Packet sequence for some sample 1538 encapsulated IP packets. 1540 The specification of the TS Packet header operation and field values 1541 is provided in [ISO-MPEG2]. The specification of ULE is provided in 1542 the body of this document. 1544 The key below is provided for the following examples. 1546 HDR 4B TS Packet Header 1547 PUSI Payload Unit Start Indicator 1548 PP Payload Pointer 1549 *** TS Packet Payload Pointer (PP) 1551 Example A.1: Two 186B PDUs. 1553 SNDU A is 200 bytes (including the ULE destination NPA address) 1554 SNDU B is 200 bytes (including the ULE destination NPA address) 1556 The sequence comprises 3 TS Packets: 1558 SNDU 1559 PP=0 Length 1560 +-----+------+------+------+- -+------+ 1561 | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | 1562 +-----+----*-+-*----+------+- -+------+ 1563 PUSI=1 * * 1564 ***** 1565 SNDU 1566 PP=17 CRC for A Length 1567 +-----+------+------+- -+--- --+------+------+- -+------+ 1568 | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 | 1569 +-----+----*-+------+- -+------+-*----+------+- -+------+ 1570 PUSI=1 * * 1571 ************************* 1573 End Stuffing 1574 CRC for A Indicator Bytes 1575 +-----+------+- -+------+----+----+- -+----+ 1576 | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF| 1577 +-----+------+- -+------+----+----+- -+----+ 1578 PUSI=0 1579 Example A.2: Usage of last byte in a TS-Packet 1581 SNDU A is 183 bytes 1582 SNDU B is 182 bytes 1583 SNDU C is 181 bytes 1584 SNDU D is 185 bytes 1586 The sequence comprises 4 TS Packets: 1588 SNDU 1589 PP=0 Length CRC for A 1590 +-----+------+------+------+- -+------+ 1591 | HDR | 0x00 | 0x00 | 0x63 | ... | A182 | 1592 +-----+----*-+-*----+------+- -+------+ 1593 PUSI=1 * * 1594 ***** 1595 SNDU Unused 1596 PP=0 Length CRC for B byte 1597 +-----+------+------+------+- -+------+------+ 1598 | HDR | 0x00 | 0x00 | 0x62 | ... | B181 | 0xFF | 1599 +-----+---*--+-*----+------+- -+------+------+ 1600 PUSI=1 * * 1601 ****** 1602 SNDU SNDU 1603 PP=0 Length CRC for C Length 1604 +-----+------+------+------+- -+------+------+------+ 1605 | HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 | 1606 +-----+---*--+-*----+------+- -+------+------+------+ 1607 PUSI=1 * * 1608 ****** Unused 1609 byte 1610 +-----+------+- -+------+------+ 1611 | HDR | D002 | ... | D184 | 0xFF | 1612 +-----+------+- -+------+------+ 1613 PUSI=0 1614 Example A.3: Large SNDUs 1616 SNDU A is 732 bytes 1617 SNDU B is 284 bytes 1619 The sequence comprises 6 TS Packets: 1621 SNDU 1622 PP=0 Length 1623 +-----+------+------+------+- -+------+ 1624 | HDR | 0x00 | 0x02 | 0xD8 | ... | A182 | 1625 +-----+---*--+-*----+------+- -+------+ 1626 PUSI=1 * * 1627 ****** 1629 +-----+------+- -+------+ 1630 | HDR | A183 | ... | A366 | 1631 +-----+------+- -+------+ 1632 PUSI=0 1634 +-----+------+- -+------+ 1635 | HDR | A367 | ... | A550 | 1636 +-----+------+- -+------+ 1637 PUSI=0 1639 SNDU 1640 PP=181 CRC for A Length 1641 +-----+------+------+- -+------+------+------+ 1642 | HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 | 1643 +-----+---*--+------+- -+------+*-----+------+ 1644 PUSI=1 * * 1645 ************************* 1647 +-----+------+- -+------+ 1648 | HDR | B002 | ... | B185 | 1649 +-----+------+- -+------+ 1650 PUSI=0 1652 End Stuffing 1653 Indicator Bytes 1654 +-----+------+- -+------+------+------+- -+------+ 1655 | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF | 1656 +-----+------+- -+------+------+------+- -+------+ 1657 PUSI=0 1658 Example A.4: Packing of SNDUs 1660 SNDU A is 200 bytes 1661 SNDU B is 60 bytes 1662 SNDU C is 60 bytes 1664 The sequence comprises two TS Packets: 1666 SNDU 1667 PP=0 Length 1668 +-----+------+------+------+- -+------+ 1669 | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | 1670 +-----+----*-+-*----+------+- -+------+ 1671 PUSI=1 * * + + 1672 ***** ++++++++ 1673 + 1674 +++++++++++++++++ 1675 + SNDU 1676 PP=17 CRC for A + Length 1677 +-----+------+------+- -+------+-+----+------+- 1678 | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ... 1679 +-----+----*-+------+- -+------+*-----+------+- 1680 PUSI=1 * * + + 1681 ************************ +++++++++ 1682 + 1683 +++++++++++++++++++++++++++++++++++++++ 1684 + 1685 + SNDU End Stuffing 1686 + Length Indicator bytes 1687 + -+------+------+------+ -+------+------+------+- -+------+ 1688 + ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF | 1689 + -+------+-+----+------+ -+------+-+----+------+- -+------+ 1690 + + + + + 1691 + + ++++++++ + 1692 + + + + 1693 ++++++++++++++++ ++++++++++++++++++++++ 1695 *** TS Packet Payload Pointer (PP) 1696 +++ ULE Length Indicator 1697 Example A.5: Three 44B PDUs. 1699 SNDU A is 52 bytes (no ULE destination NPA address) 1700 SNDU B is 52 bytes (no ULE destination NPA address) 1701 SNDU C is 52 bytes (no ULE destination NPA address) 1703 The sequence comprises 1 TS Packet: 1705 SNDU 1706 PP=0 Length 1707 +-----+------+------+------+- -+-----+------+-----+- -+-----+- 1708 | HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | .. 1709 +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- 1710 PUSI=1 * * 1711 ***** 1713 End Stuffing 1714 Indicator bytes 1715 -----+------+- -+-----+---------+- -+------+ 1716 ... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF | 1717 -*---+------+- -+-----+---------+- -+------+ 1718 ANNEX B: Informative Appendix - SNDU Encapsulation 1720 An example of ULE encapsulation carrying an ICMPv6 packet generated 1721 by ping6. 1723 ULE SNDU Length : 63 decimal 1724 D-bit value : 0 (NPA destination address present) 1725 ULE Protocol Type : 0x86dd (IPv6) 1726 Destination ULE NPA Address: 00:01:02:03:04:05 1727 ULE CRC32 : 0x4709a744 1729 Source IPv6: 2001:660:3008:1789::5 1730 Destination IPv6: 2001:660:3008:1789::6 1732 SNDU contents (including CRC-32): 1734 0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d 1735 0016: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 1736 0032: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 1737 0048: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 47 1738 0064: 09 a7 44 1739 [RFC EDITOR NOTE: 1740 This section must be deleted prior to publication] 1742 DOCUMENT HISTORY 1744 Draft 00 1745 This draft is intended as a study item for proposed future work by 1746 the IETF in this area. Comments relating to this document will be 1747 gratefully received by the author(s) and the ip-dvb mailing list at: 1748 ip-dvb@erg.abdn.ac.uk 1750 -------------------------------------------------------------------- 1751 DRAFT 01 (Protocol update) 1753 * Padding sequence modified to 0xFFFF, this change aligns with other 1754 usage by MPEG-2 streams. Treatment remains the same as specified for 1755 ULE. 1757 * SDNU Format updated to include R-bit (reserved). 1759 * Updated procedure for TS Packet carrying the final part of an SNDU 1760 with either less than two bytes of unused payload updated. 1762 * A Receiver MUST silently discard the remainder of a TS Packet 1763 payload when two or less bytes remain unprocessed following the end 1764 of an SNDU, irrespective of the PUSI value in the received TS 1765 Packet. It MUST NOT record an error when the value of the remaining 1766 byte(s) is identical to 0xFF or 0xFFFF. The Receiver MUST then wait 1767 for a TS Packet with a PUSI value set to 1. 1769 * Payload Pointer description updated. 1771 * CRC Calculation added. 1773 * Decapsulator processing revised. 1775 * Type field split into two. 1777 * References updated. 1779 * Security considerations added (first draft). 1781 * Appendix added with examples. 1783 -------------------------------------------------------------------- 1784 DRAFT - 02 (Improvement of clarity) 1786 * Corrected CRC-32 to follow standard practice in DSM-CC. 1788 * Removed LLC frame type, now redundant by Bridge-Type (==1) 1790 * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain, 1791 Bernhard 1793 * Changes to description of minimum payload length. Gorry 1795 * MPEG-2 Error Indicator SHOULD be used.Hilmar & Gorry 1797 * MPEG-2 CC MAY be used (since CRC-32 is strong anyway). Hilmar & 1798 Gorry 1800 * Corrected CRC-32 to now follow standard practice in DSM-CC. Gorry, 1801 Hilmar, Alain. 1803 * Changed description of Encapsulator action for Packing. Gorry & 1804 Hilmar. 1806 * Changed description of Receiver to clarify packing. Gorry & Alain. 1808 * Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG. 1809 Hilmar/Bernhard. 1811 * Recommend removal of section on Flushing bit stream. Gorry 1813 * Updated SNDU figures to reflect D-bit and correct a mistake in the 1814 bridged type field. Alain 1816 * Reorganised section 5 to form sections 5 and 6, separating 1817 encapsulation and receiver processing. Gorry, Hilmar, Alain. 1819 * Added concept of Idle State and Reassembly State to the Receiver. 1820 Renumbered sections 5,6 and following. Gorry. 1822 * Nits from Alain, Hilmar and Gorry. 1823 Moved security issue on the design of the protocol to appropriate 1824 sections, since this is not a concern for deployment: Length field 1825 usage and padding initialisation. 1827 * Changed wording: All multi-byte values in ULE (including Length, 1828 Type, and Destination fields) are transmitted in network byte order 1829 (most significant byte first). old NiT from Alain, now fixed. 1831 * Frame byte size in diagrams now updated to -standard- format, and 1832 D bit action corrected, as requested by Alain. 1834 * Frame format diagrams, redrawn to 32-bit format below: 1835 0 1 2 3 1836 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 1838 * Additional diagram requested by Alain for D=0 bridging (added, and 1839 subsequent figures renumbered). 1841 * Diagrams of encapsulation process, redrawn for clarity (no change 1842 to meaning). Gorry. 1844 * Reworded last para of CRC description. 1846 * Clarification to the statements in the CRC coverage - to make it 1847 clear that it is the entire SNDU (header AND payload) that is 1848 checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at). 1850 * References added for RCS (spotted by Alain) and AAL5 (provided by 1851 Anthony Ang). 1853 * Removed informative reference to MPEG part 1.Alain. 1854 Spelling correction -> Allain to Alain. 1856 * Added description of Receiver processing of the address 1857 field.Gorry 1859 * Added caution on LLC Length in bridged Packets thanks. 1860 Gorry/wolfgang 1862 * Removed Authors notes from text after their discussion on the list 1863 Gorry 1865 * Corrected text to now say maximum value of PP = 182 in ULE. Gorry 1867 * Tidied diagrams at end (again) - Gorry, 1869 Revision with following changes: 1871 * Re issue as working group draft (filename change) 1872 * Refinement of the text on CRC generation to be unambiguous. 1873 * Revised CC processing at Encapsulator (B C-N/GF/A.Allison) 1874 * Revised CC processing at Receiver (from List: A.Allison; et al ) 1875 * Corrections to length/PP field in Examples (M Sooriyabandara, 1876 Alain) 1877 * Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit) 1878 * Section 4.5 only SHARED routed links require D=0 1879 * Packing Threshold defined 1880 * Next-Layer-Header defined (Now called Next-Header) 1881 * Addition of Appendix B (to aide verification of SNDFU format) 1882 Working Group ID rev 01 1884 Issues addressed: 1885 * Typographical 1886 * Types > 1500 should be passed to the next higher protocol (Hilmar) 1887 * The second part of the Type space corresponds to the values 1500 1888 COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF. 1889 * IANA has already defined IP and IPv6 types - corrected text! 1890 Added more security considerations (-01d). 1891 * Should we allow an Adaptation Field within ULE (request for DVB- 1892 RCS compatibility)? Requirement to be clarified! Implementation 1893 impact to be evaluated! 1894 Current Recommendation: The current spec does not preclude use of 1895 AF, it simply says that this is not the standard for ULE. The use 1896 case and requirement for this mode are not currently clear, based on 1897 this there is no current intention to add this to ULE - text for 1898 requirements would be welcome. 1899 * Verify the minimum value allocated to DIX Ethernet Header Types. 1900 Draft updated to align with IEEE Registry assignments. 1902 -------------------------------------------------------------------- 1904 Working Group ID rev 02 1906 Revised IPR disclosure 1907 Revised copyright notice 1909 Section 5 added to ULE to define optional Extension Headers (see 1910 xule) 1912 Correction of figure numbering. 1913 Correction to capitalisation in Transport Stream definition of fields 1914 Inserted space character after 1536 in line 2 of 4.4.2 1915 Replaced } with ] after ISO_DSMCC 1916 Replace reference to section 6.3 with section 7.3 at end of section 1917 4.6. 1918 Reference in 4.7.4 was changed to refer to figure 7 (not 6). 1919 Note added after figure 9. 1921 Working Group ID rev 03 1923 Changes with this revision of the document: 1925 (i) The worked hexadecimal example in the annexe was reworked to 1926 include a valid MAC address for an IPv6 unicast packet. - 1927 (BCN) 1929 (ii) The IANA procedures revised, based on inputs from IANA to 1930 improve consistency of the term Next-Header and to add the 1931 HLEN field to the IANA registry record for OPTIONAL headers. 1932 (GF) 1934 (iii) 7.2 Change to revert wording in the second para to MUST enter 1935 IDLE after CRC failure of SNDU check. 1937 (iv) In normal operation, it is expected that any padding appended 1938 to a bridged Ethernet frame SHOULD be removed prior to 1939 forwarding. This requires the sender to be aware of such 1940 Ethernet padding (e.g. LLC). (Made this a SHOULD). (GF) 1941 NiTS: 1942 (v) Format of page Breaks was updated. (GF) 1943 (vi) Check for <- -> sequences of characters. (GF) 1944 (vii) Update refs to add RFC3667 / 3668. (GF) 1945 (viii) Changed text defining M in DSMCC definition to the word Media 1946 (ix) 7.1.1 Range of PP values corrected to 0-181. 1947 (x) Definition of END INDICATOR corrected in section 2 - this is 1948 not a TYPE value, but a LENGTH value. 1949 (xi) Next-Header used throughout the document to replace 1950 next-layer-header, and various other forms of wording. 1951 (xii) In section 7.2, added a ref the section on PP checking 1953 Working Group ID rev 04 1955 This rev followed WGLC comments, which are defined in the ipdvb 1956 mailing list. Important changes included: 1958 (i) This text was moved to an appendix 1959 (ii) ToC was updated and section headers made consistent 1960 (iii) Revised definition text 1961 (iv) Improved clarity with respect to terms defined in ISO 13818-1 1962 (v) Bridging and Extension-Padding formats move to section 5 1963 (vi) Clarification of the NPA in packet headers 1964 (vii) Clarification of placement of NPA address with extension 1965 headers. 1967 Issues address in rev-05: 1969 These revisions were made following a second WGLC and invited cross- 1970 area IETF review of the Spec. 1972 NiTS corrected: 1974 Abstract shortened. 1975 Added separate references to Ethernet v2; LLC; and 802.3 1976 Added RFC2119 Boilerplate for definitions of capitilised words. 1977 Corrected English and 63 typos 1978 Specified explicitly that Test & Bridge Extension Headers must be 1979 the last in the extension chain (no other headers may follow) 1980 7.1.1. para 1 - changed PP processing description to specify where 1981 to count the number of bytes that were pointed to 1982 Corrected the range 0-512 in the IANA Guidelines (should be 0-511). 1983 Fixed NPA to consistently refer to the ULE destination address. 1985 Specific Issues: 1987 1) The reviewer suggested the title was confusing. A proposed new 1988 Title is: 1989 Ultra Lightweight Encapsulation (ULE) for transmission of 1990 IP datagrams over an MPEG-2 Transport Stream 1992 2) The reviewer suggested that the name of the D field was changed, 1993 to make the meaning more obvious. The new name is Destination 1994 Address Absent field, rather than the Destination Address 1995 Present field. The semantics of the D-bit do not change. 1997 3) The reviewer asked for a description of how to send an LLC frame 1998 - in Section 4. This was added to the section on bridging. 2000 4) The reviewer mentioned that we had NOT defined the values needed 2001 for mapping addresses... I'm not sure this was an over-sight, but 2002 This was an oversight, the new text was added to the end of the 2003 description in section 4.5. Also added references to [RFC1112] 2004 [RFC2464]. 2006 5) Added text on the need for data descriptors. 2008 6) Removed reference to RFC3819 which was either ambiguous in the 2009 definition of SNDU. 2011 7) In final clause of 7.2 (Receiver processing) the last sentence 2012 was extended by a bracketed clause to deal with the case when there 2013 was excess data and no PUSI set). 2015 (iii) If two or more bytes of TS Packet payload data remain after 2016 completion of the Current SNDU, the Receiver accepts the next 2 2017 bytes and examines if this is an End Indicator. When an End 2018 Indicator is received, a Receiver MUST silently discard the 2019 remainder of the TS Packet payload and transition to the Idle State. 2020 Otherwise this is the start of the next Packed SNDU and the Receiver 2021 continues by processing this SNDU (provided that the TS Packet has a 2022 PUSI value of 1, see 7.2.1, otherwise the Receiver has detected a 2023 delimiting error and MUST discard all remaining bytes in the TS 2024 Packet payload and transitions to the Idle State). 2026 8) Revised IANA procedures to REQUIRE a definition of the PROCEDURE 2027 when defining an extension header. 2029 [END of RFC EDITOR NOTE]