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