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