idnits 2.17.1 draft-ietf-ipdvb-ule-00.txt: -(97): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(131): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(146): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(502): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1223): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 21 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 493 instances of too long lines in the document, the longest one being 4 characters 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: ---------------------------------------------------------------------------- == Line 404 has weird spacing: '...cell in an AT...' == Line 466 has weird spacing: '...or PDUs is il...' == Line 1250 has weird spacing: '...cations over ...' == 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 '', 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 (March 2004) is 7346 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 298, but not defined == Missing Reference: 'ISO-MPEG2' is mentioned on line 441, but not defined == Missing Reference: 'ITU3563' is mentioned on line 614, but not defined == Unused Reference: 'RFC2026' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'ATSC-DAT' is defined on line 1234, but no explicit reference was found in the text == Unused Reference: 'ATSC-DATG' is defined on line 1237, but no explicit reference was found in the text == Unused Reference: 'ATSC-G' is defined on line 1241, but no explicit reference was found in the text == Unused Reference: 'ATSC-PSIP-TC' is defined on line 1245, but no explicit reference was found in the text == Unused Reference: 'ATSC-S' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'CLC99' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'ETSI-DAT' is defined on line 1256, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBC' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBS' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBT' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'ITU-I363' is defined on line 1281, but no explicit reference was found in the text == Unused Reference: 'SI-DAT' is defined on line 1295, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG' Summary: 4 errors (**), 0 flaws (~~), 24 warnings (==), 3 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-00.txt Bernhard Collini-Nocker 4 University of Salzburg, A 6 Category: Internet Draft (ipdvb WG) March 2004 8 Ultra Lightweight Encapsulation (ULE) for transmission of 9 IP datagrams over MPEG-2/DVB networks 11 Status of this Draft 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The MPEG-2 TS has been widely accepted not only for providing 33 digital TV services, but also as a subnetwork technology for 34 building IP networks. This document describes an Ultra Lightweight 35 Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 36 Datagrams and other network protocol packets directly over ISO MPEG- 37 2 Transport Streams (TS) as TS Private Data. 39 [RFC EDITOR NOTE: 40 This section must be deleted prior to publication] 42 DOCUMENT HISTORY 44 Draft �00 45 This draft is intended as a study item for proposed future work by 46 the IETF in this area. Comments relating to this document will be 47 gratefully received by the author(s) and the ip-dvb mailing list at: 48 ip-dvb@erg.abdn.ac.uk 50 -------------------------------------------------------------------- 51 DRAFT 01 (Protocol update) 53 * Padding sequence modified to 0xFFFF, this change aligns with other 54 usage by MPEG-2 streams. Treatment remains the same as specified for 55 ULE. 57 * SDNU Format updated to include R-bit (reserved). 59 * Procedure for TS Packet carrying the final part of a SNDU with 60 either less than two bytes of unused payload updated. 62 * A Receiver MUST silently discard the remainder of a TS Packet 63 payload when two or less bytes remain unprocessed following the end 64 of a SNDU, irrespective of the PUSI value in the received TS Packet. 65 It MUST NOT record an error when the value of the remaining byte(s) 66 is identical to 0xFF or 0xFFFF. The Receiver MUST then wait for a 67 TS Packet with a PUSI value set to 1. 69 * Payload Pointer description updated. 71 * CRC Calculation added. 73 * Decapsulator processing revised. 75 * Type field split into two. 77 * References updated. 79 * Security considerations added (first draft). 81 * Appendix added with examples. 83 -------------------------------------------------------------------- 84 DRAFT - 02 (Improvement of clarity) 86 * Corrected CRC-32 to follow standard practice in DSM-CC. 88 * Removed LLC frame type, now redundant by Bridge-Type (==1) 90 * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain, 91 Bernhard 93 * Changes to description of minimum payload length. � Gorry 95 * MPEG-2 Error Indicator SHOULD be used � Hilmar & Gorry 97 * MPEG-2 CC MAY be used (since CRC-32 is strong anyway) � Hilmar & 98 Gorry 100 * Corrected CRC-32 to now follow standard practice in DSM-CC - 101 Gorry, Hilmar, Alain. 103 * Changed description of Encapsulator action for Packing, Gorry & 104 Hilmar. 106 * Changed description of Receiver to clarify packing, Gorry & Alain. 108 * Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG � 109 Hilmar/Bernhard. 111 * Recommend removal of section on Flushing bit stream - Gorry 113 * Updated SNDU figures to reflect D-bit and correct a mistake in the 114 bridged type field - Alain 116 * Reorganised section 5 to form sections 5 and 6, separating 117 encapsulation and receiver processing � Gorry, Hilmar, Alain. 119 * Added concept of Idle State and Reassembly State to the Receiver. 120 Renumbered sections 5,6 and following, - Gorry. 122 * Nits from Alain, Hilmar and Gorry. 123 Moved security issue on the design of the protocol to appropriate 124 sections, since this is not a concern for deployment: Length field 125 usage and padding initialisation. 127 * Changed wording: All multi-byte values in ULE (including Length, 128 Type, and Destination fields) are transmitted in network byte order 129 (most significant byte first) � old NiT from Alain, now fixed. 131 * Frame byte size in diagrams now updated to �standard- format, and 132 D bit action corrected, as requested by Alain. 134 * Frame format diagrams, redrawn to 32-bit format below: 135 0 1 2 3 136 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 138 * Additional diagram requested by Alain for D=0 bridging (added, and 139 subsequent figures renumbered). 141 * Diagrams of encapsulation process, redrawn for clarity (no change 142 to meaning) � Gorry. 144 * Reworded last para of CRC description. 146 * Clarification to the statements in the CRC coverage � to make it 147 clear that it is the entire SNDU (header AND payload) that is 148 checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at). 150 * References added for RCS (spotted by Alain) and AAL5 (provided by 151 Anthony Ang). 153 * Removed informative reference to MPEG part 1 � Alain. 154 Spelling correction -> Allain to Alain. 156 * Added description of Receiver processing of the address field.- 157 Gorry 159 * Added caution on LLC Length in bridged Packets thanks � 160 Gorry/wolfgang 162 * Removed Authors notes from text after their discussion on the list 163 � Gorry, 165 * Corrected text to now say maximum value of PP = 182 in ULE � 166 Gorry, 168 * Tidied diagrams at end (again) � Gorry, 170 Revision with following changes: 172 * Re issue as working group draft (filename change) 173 * Refinement of the text on CRC generation to be unambiguous. 174 * Revised CC processing at Encapsulator (B C-N/GF/A.Allison) 175 * Revised CC processing at Receiver (from List: A.Allison; et al ) 176 * Corrections to length/PP field in Examples (M Sooriyabandara, 177 Alain) 178 * Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit) 179 * Section 4.5 only SHARED routed links require D=0 180 * Packing Threshold defined 181 * Next-Layer-Header defined 182 * Addition of Appendix B (to aide verification of SNDFU format) 183 Issues pending working group consensus: 185 1) Query about the code point value for an Ethernet Bridging 186 SNDU � should the ULE type-field be 0x0001 ; 0x0007; or should 187 the IEEE Ethertype for bridging be used instead? 188 Author Note: This may depend on other assignments, to be 189 determined. 191 2) Should we allow configuration of an optional non-default CC 192 processing??? 194 3) Should ULE define optional extension headers (various proposals) 195 Author Note: Design trade-offs need to be considered. 197 4) Should ULE support FEC? 198 Author Note 1: No concrete proposal yet, although this seems within 199 the scope of the use of type fields. 200 Author Note 2: Text is required for the requirements ID so this may 201 first be updated to reflect the need for this option. 203 5) Should ULE support Encryption? 204 Author Note: In principle, this is just a code-point issue, since we 205 only defining an encapsulation here. This seems within the scope of 206 the use of type fields. 207 Author Note 2: Text is required for the requirements ID so this may 208 first be updated to reflect the need for this option (some inputs 209 from L. Claverotte/H. Cruickshank/et al). 211 6) Do we need to define OPTIONAL extension header fields to allow 212 Receivers backwards compatibility with unknown options? 214 [END of RFC EDITOR NOTE] 215 Table of Contents 217 1. Introduction 218 2. Conventions used in this document 219 3. Description of method 220 4. SNDU Format 221 4.1 Destination Address Present Field 222 4.2 Length Field 223 4.3 End Indicator 224 4.4 Type Field 225 4.4.1 Type 1: IANA Assigned Type Fields 226 4.4.2 Type 2: Ethertype Compatible Type Fields 227 4.5 SNDU Destination Address Field 228 4.6 SNDU Trailer CRC 229 4.7 Description of SNDU Formats 230 4.7.1 End Indicator 231 4.7.2 IPv4 SNDU Encapsulation 232 4.7.3 IPv6 SNDU Encapsulation 233 4.7.4 Test SNDU 234 5. Processing at the Encapsulator 235 5.1 SNDU Encapsulation 236 5.2 Procedure for Padding and Packing 237 6. Receiver Processing 238 6.1 Idle State 239 6.1.1 Reassembly Payload Pointer Checking 240 6.2 Processing of a Received SNDU 241 6.2.1 Reassembly Payload Pointer Checking 242 6.3 Other Error Conditions 243 7. Summary 244 8. Acknowledgments 245 9. Security Considerations 246 10. References 247 10.1 Normative References 248 10.2 Informative References 249 11. Authors' Addresses 250 12. IANA Considerations 252 ANNEXE A: Informative Appendix � SNDU Packing Examples 253 ANNEXE B: Informative Appendix � SNDU Encapsulation 254 1. Introduction 256 This document describes an encapsulation for transport of IP 257 datagrams, or other network layer packets, over ISO MPEG-2 Transport 258 Streams [ISO-MPEG]. It is suited to services based on MPEG-2, for 259 example the Digital Video Broadcast (DVB) architecture, the Advanced 260 Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other 261 similar MPEG-2 based transmission systems. Such systems typically 262 provide unidirectional (simplex) physical and link layer standards. 263 Support has been defined for a wide range of physical media (e.g. 264 Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS; 265 ATSC-S], Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). Bi- 266 directional (duplex) links may also be established using these 267 standards (e.g., DVB defines a range of return channel technologies, 268 including the use of two-way satellite links [ETSI-RCS] and dial-up 269 modem links [RFC3077]). 271 Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other 272 network layer packets) for transmission over an MPEG-2 Transport 273 Multiplex are passed to an Encapsulator. This formats each PDU into 274 a Subnetwork Data Unit (SNDU) by adding an encapsulation header and 275 an integrity check trailer. The SNDU is fragmented into a series of 276 TS Packets) that are sent over a single TS Logical Channel. 278 2. Conventions used in this document 280 ADAPTATION FIELD: An optional variable-length extension field of the 281 fixed-length TS Packet header, intended to convey clock references 282 and timing and synchronization information as well as stuffing over 283 an MPEG-2 Multiplex [ISO-MPEG]. 285 AFC: Adaptation Field Control, a pair of bits carried in the TS 286 Packet header that signal the presence of the Adaptation Field 287 and/or TS Packet payload. 289 ATSC: Advanced Television Systems Committee [ATSC]. A framework and 290 a set of associated standards for the transmission of video, audio, 291 and data using the ISO MPEG-2 standard. 293 DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC]. 294 A format for transmission of data and control information defined by 295 the ISO MPEG-2 standard that is carried in an MPEG-2 Private 296 Section. 298 DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of 299 associated standards published by the European Telecommunications 300 Standards Institute (ETSI) for the transmission of video, audio, and 301 data, using the ISO MPEG-2 Standard. 303 ENCAPSULATOR: A network device that receives PDUs and formats these 304 into Payload Units (known here as SNDUs) for output as a stream of 305 TS Packets. 307 END INDICATOR: A Type value that indicates to the Receiver that 308 there are no further SNDU are present within the current TS Packet. 310 MAC: Medium Access and Control. The link layer header of the 311 Ethernet IEEE 802 standard of protocols, consisting of a 6B 312 destination address, 6B source address, and 2B type field. 314 MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A 315 scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each 316 Section is sent in a series of TS Packets using a single TS Logical 317 Channel. 319 MPEG-2: A set of standards specified by the Motion Picture Experts 320 Group (MPEG), and standardized by the International Standards 321 Organisation (ISO) [ISO-MPEG]. 323 NEXT-HEADER: A Type value indicating an extension header. 325 NPA: Network Point of Attachment. In this document, refers to a 6 B 326 destination address within the MPEG-2 transmission network used to 327 identify individual Receivers or groups of Receivers. 329 PACKING THRESHOLD: A period of time an Encapsulator is willing to 330 defer transmission of a partially filled TS-Packet to accumulate 331 more SNDUs, rather than use Padding. After the Packet Threshold 332 period, the Encapsulator uses Padding to send the partially filled 333 TS-Packet. A Packing threshold of zero is equivalent to Padding. 335 PDU: Protocol Data Unit. Examples of PDU include Ethernet frames, 336 IPv4 or IPv6 datagrams, and other network packets 338 PES: Packetized Elementary Stream of MPEG-2 [ISO-MPEG]. 340 PID: Packet Identifier. A field carried in the header of TS Packets. 341 This is used to identify the TS Logical Channel to which a TS Packet 342 belongs [ISO-MPEG]. The TS Packets forming the parts of a Table 343 Section, PES, or other payload unit must all carry the same PID 344 value. The all 1s PID value indicates a Null TS Packet introduced 345 to maintain a constant bit rate of a TS Multiplex. 347 PP: Payload Pointer. An optional one byte pointer that directly 348 follows the TS Packet header. It contains the number of bytes 349 between the end of the TS Packet header and the start of a Payload 350 Unit. The presence of the Payload Pointer is indicated by the value 351 of the PUSI bit in the TS Packet header. The Payload Pointer is 352 present in DSM-CC, and Table Sections, it is not present in TS 353 Logical Channels that use the PES-format. 355 PU: Payload Unit. A sequence of bytes sent using a TS. Examples of 356 Payload Units include: an MPEG-2 Table Section or a ULE SNDU. 358 PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single 359 bit flag carried in the TS Packet header. A PUSI value of zero 360 indicates that the TS Packet does not carry the start of a new 361 Payload Unit. A PUSI value of one indicates that the TS Packet does 362 carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 363 also indicates the presence of a one byte Payload Pointer (PP). 365 PRIVATE SECTION: a syntactic structure used for mapping all service 366 information (e.g. an SI table) into TS Packets. A Table may be 367 divided into a number of Table Sections, however all Table Sections 368 must be carried over a single TS Logical Channel. 370 PSI: Program Specific Information. Tables used to convey information 371 about the service carried in a TS Multiplex. The set of PSI tables 372 is defined by [ISO-MPEG], see also SI Table. 374 SI TABLE: Service Information Table. In this document, this term 375 describes any table used to convey information about the service 376 carried in a TS Multiplex. SI tables are carried in MPEG-2 private 377 sections. 379 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 380 Payload Unit. 382 TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table. 384 TS: Transport Stream [ISO-MPEG], a method of transmission at the 385 MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI 386 reference model. See also TS Logical Channel and TS Multiplex. 388 TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel 389 identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of 390 the ISO/OSI reference model. All packets sent over a TS Logical 391 Channel carry the same PID value. According to MPEG-2, some TS 392 Logical Channels are reserved for specific signalling purposes. 393 Other standards (e.g., ATSC, DVB) also reserve specific TS Logical 394 Channels. 396 TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single 397 common physical link (i.e. a transmission at a specified symbol 398 rate, FEC setting, and transmission frequency). The same TS Logical 399 Channel may be repeated over more than one TS Multiplex, for example 400 to redistribute the same multicast content to two terrestrial TV 401 transmission cells. 403 TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex 404 [ISO-MPEG]. Operation resembles that of cell in an ATM network, and 405 may also be referred to as a TS_Cell. Each TS Packet carries a 4B 406 header, plus optional overhead including an Adaptation Field, 407 encryption details and time stamp information to synchronise a set 408 of related Transport Streams. 410 3. Description of the Method 412 PDUs (IP packets, Ethernet frames or packets from other network 413 protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). 414 The SNDU is transmitted over an MPEG-2 transmission network by 415 placing it either in the payload of a single TS Packet, or if 416 required, an SNDU may be fragmented into a series of TS Packets. 417 Where there is sufficient space, the method permits a single TS 418 Packet to carry more than one SNDU (or part there of), sometimes 419 known as Packing. All TS Packets comprising a SNDU MUST be assigned 420 the same PID, and therefore form a part of the same TS Logical 421 Channel. 423 The ULE encapsulation is limited to TS private streams only. The 424 header of each TS Packet carries a one bit Payload Unit Start 425 Indicator (PUSI) field. The PUSI identifies the start of a payload 426 unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of 427 the PUSI bit are defined differently for PES and PSI packets [ISO- 428 MPEG]; for private data, its use is not defined in the MPEG-2 429 Standard. In ULE, the operation follows that of PSI packets. Hence, 430 the following PUSI values are defined: 432 0: The TS Packet does NOT contain the start of a SNDU, but 433 contains the continuation, or end of a SNDU; 435 1: The TS Packet contains the start of a SNDU, and a one byte 436 Payload Pointer follows the last byte of the TS Packet header. 438 If a Payload Unit (SNDU) finishes before the end of a TS Packet 439 payload, but it is not convenient to start another Payload Unit, a 440 stuffing procedure fills the remainder of the TS Packet payload with 441 bytes with a value 0xFF [ISO-MPEG2], known as Padding. 443 A Receiver processing MPEG-2 Table Sections is aware that when it 444 receives a table_id value of 0xFF, this indicates Padding/Stuffing 445 occurred and silently discards the remainder of the TS Packet 446 payload. The payload of the next TS Packet for the same TS Logical 447 Channel will begin with a Payload Pointer of value 0x00, indicating 448 that the next Payload Unit immediately follows the TS Packet header. 449 The ULE protocol resembles this, but differs in the exact procedure 450 (see the following sections). 452 The TS Packet Header also carries a two bit Adaptation Field Control 453 (AFC) value. The purpose of the adaptation field is primarily to 454 carry timing and synchronisation information and may be used to also 455 include stuffing bytes before a TS Packet payload. Standard 456 Receivers discard TS Packets with an adaptation_field_control field 457 value of '00'. Adaptation Field stuffing is NOT used in this 458 encapsulation method, and TS Packets from a ULE Encapsulator MUST be 459 sent with an AFC value of '01'. Receivers MUST discard TS Packets 460 that carry other AFC values. 462 4. SNDU Format 464 PDUs (IP packets and bridged Ethernet frames)are encapsulated using 465 ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The 466 encapsulation format to be used for PDUs is illustrated below: 468 < ----------------------------- SNDU ----------------------------- > 469 +-+-------------------------------------------------------+--------+ 470 |D| Length | Type | PDU | CRC-32 | 471 +-+-------------------------------------------------------+--------+ 473 Figure 1: SNDU Encapsulation 475 All multi-byte values in ULE (including Length, Type, and 476 Destination fields) are transmitted in network byte order (most 477 significant byte first). Appendix A provides informative examples of 478 usage. 480 4.1 The Destination Address Present Field 482 The most significant bit of the Length Field carries the value of 483 the Destination Address Present Field, the D-bit. A value of 0 484 indicates the presence of the Destination Address Field (see section 485 4.5). A value of 1 indicates that a Destination Address Field is not 486 present (i.e. it is omitted). 488 By default, the D-bit value MUST be set to a value of 0, except for 489 the transmission of an End Indicator (see 4.3), in which this bit 490 MUST be set to the value of 1. 492 4.2 Length Field 494 A 15-bit value that indicates the length, in bytes, of the SNDU 495 (encapsulated Ethernet frame, IP datagram or other packet) counted 496 from the byte following the type field up to and including the CRC. 497 Note the special case described in 4.3. 499 4.3 End Indicator 501 When the first two bytes of a SNDU have the value 0xFFFF, this 502 denotes an End Indicator (i.e., all 1�s length combined with a D-bit 503 value of 1). It indicates to the Receiver that there are no further 504 SNDUs present within the current TS Packet (see section 6), and that 505 no Destination Address Field is present. The value 0xFF has specific 506 semantics in MPEG-2 framing, where it is used to indicate the 507 presence of Padding. This use resembles [ISO-DSMCC]. 509 4.4 Type Field 511 The 16-bit Type field indicates the type of payload carried in a 512 SNDU, or the presence of a Next-Header. The set of values that may 513 be assigned to this field is divided into two parts, similar to the 514 allocations for Ethernet. 516 Ethertypes were originally specified by Xerox under the DIX 517 framework for Ethernet. After specification of IEEE 802.3 [LLC], the 518 set of Ethertypes less than or equal to 1500 (0x05FC), assumed the 519 role of a length indicator. Ethernet receivers use this feature to 520 discriminate LLC format frames. Hence any IEEE Ethertype <= 1500 521 indicates an LLC frame, and the actual value indicates the length of 522 the LLC frame. 524 There is a potential ambiguous case when a Receiver receives a PDU 525 with two length fields: The Receiver would need to validate the 526 actual length and the Length field and ensure that inconsistent 527 values are not propagated by the network. Specification of two 528 independent length fields is therefore undesirable. In the ULE 529 header, this is avoided in the SNDU header by including only one 530 length value, but bridging of LLC frames re-introduces this 531 consideration (section 4.7.5). 533 The Ethernet LLC mode of identification is not required in ULE, 534 since the SNDU format always carries an explicit Length Field, and 535 therefore the procedure in ULE is modified, as below: 537 The first set of ULE Type Field values comprise the set of values <= 538 1500. These Type Field values are IANA assigned (see 4.4.1), and 539 indicate the Next-Header. 541 The second set of ULE Type Field values comprise the set of values > 542 1500. In ULE, this indicates that the value is identical to the 543 corresponding type codes specified by the IEEE/DIX type assignments 544 for Ethernet and recorded in the IANA EtherType registry. 546 4.4.1 Type 1: Next-Layer-Header 548 The first part of the Type space corresponds to the values 0x0000 to 549 1500 Decimal. These values may be used to identify link-specific 550 protocols and/or to indicate the presence of extension headers that 551 carry additional optional protocol fields (e.g. a bridging 552 encapsulation). Use of these values is co-ordinated by an IANA 553 registry. 555 The following types are defined: 557 [XXX IANA ACTION REQUIRED XXX] 559 0x0000: Test SNDU, discarded by the Receiver. 561 0x0001: Bridged Ethernet Frame (i.e. MAC source address follows) 563 [XXX END OF IANA ACTION REQUIRED XXX] 565 The remaining values within the first part of the Type space are 566 reserved for allocation by the IANA. 568 [Author NOTE: Type allocation and appropriate IANA Procedure to be 569 determined.] 571 4.4.2 Type 2: Ethertype compatible Type Fields 573 The second part of the Type space corresponds to the values 1500 574 Decimal and 0xFFFF. This set of type assignments follow DIX/IEEE 575 assignments (but exclude use of this field as a frame length 576 indicator) [LLC]. The following types are defined in this document 577 for part 2: 579 0x0800 : IPv4 Payload (according to IANA EtherTypes) 580 0x86DD : IPv6 Payload (according to IANA EtherTypes) 582 All assignments in this space MUST use the values defined for IANA 583 EtherTypes. 585 4.5 SNDU Destination Address Field 587 The SNDU Destination Address Field is optional (see section 4.1). 588 This field MUST be carried (i.e. D=0) for IP unicast packets 589 destined to routers that are sent using shared links (i.e., where 590 the same link connects multiple Receivers). A sender MAY omit this 591 field (D=1) for an IP unicast packet and/or multicast packets 592 delivered to Receivers that are able to utilise a discriminator 593 field (e.g. the IPv4/IPv6 destination address), which in combination 594 with the PID value, could be interpreted as a Link-Level address. 596 When the SNDU header indicates the presence of a SNDU Destination 597 Address field (i.e. D=0), a Network Point of Attachment, NPA, field 598 directly follows the SNDU Type Field. NPA destination addresses are 599 6 B numbers, normally expressed in hexadecimal, used to identify the 600 Receiver(s) in a MPEG-2 transmission network that should process a 601 received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as a 602 destination address in a SNDU. The least significant bit of the 603 first byte of the address is set to 1 for multicast frames, and the 604 remaining bytes specify the link layer multicast address. The 605 specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, 606 indicating this SNDU is to be delivered to all Receivers. 608 4.6 SNDU Trailer CRC 610 Each SNDU MUST carry a 32-bit CRC field in the last four bytes of 611 the SNDU. This position eases CRC computation by hardware. The CRC- 612 32 polynomial is to be used. Examples where this polynomial is also 613 employed include Ethernet, DSM-CC section syntax [ISO-DSMCC} and 614 AAL5 [ITU3563]. This is a 32 bit value calculated according to the 615 generator polynomial represented 0x04C11DB7 in hexadecimal: 617 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. 619 The Encapsulator initialises the CRC-32 accumulator register to the 620 value 0xFFFF FFFF. It then accumulates a transmit value for the 621 CRC32 that includes all bytes from the start of the SNDU header to 622 the end of the SNDU (excluding the 32-bit trailer), and places this 623 in the CRC Field. In ULE, the bytes are processed in order of 624 increasing position within the SNDU, the order of processing bits is 625 NOT reversed. This use resembles, but is different to that in SCTP 626 [RFC3309]. 628 The Receiver performs an integrity check by independently 629 calculating the same CRC value and comparing this with the 630 transmitted value in the SNDU trailer. SNDUs that do not have a 631 valid CRC, are discarded, causing the Receiver to enter the Idle 632 State. 634 This description may be suited for hardware implementation, but this 635 document does not imply any specific implementation. Software-based 636 table-lookup or hardware-assisted software-based implementations are 637 also possible. Annexe B provides an example of an Encapsulated PDU 638 that includes the computed CRC-32 value. 640 The primary purpose of this CRC is to protect the SNDU (header, and 641 payload) from undetected reassembly errors and errors introduced by 642 unexpected software / hardware operation while the SNDU is in 643 transit across the MPEG-2 subnetwork and during processing at the 644 encapsulation gateway and/or the Receiver. It may also detect the 645 presence of uncorrected errors from the physical link (however, 646 these may also be detected by other means, e.g. section 6.3). 648 4.7 Description of SNDU Formats 650 The format of a SNDU is determined by the combination of the 651 Destination Address Present bit (D) and the SNDU Type Field. The 652 simplest encapsulation places a PDU directly into a SNDU payload. 653 Some Type 1 encapsulations may require additional header fields. 654 These are inserted in the SNDU directly preceding the PDU. 656 The following SNDU Formats are defined here: 658 End Indicator: The Receiver should enter the Idle State. 659 IPv4 SNDU: The payload is a complete IPv4 datagram 660 IPv6 SNDU: The payload is a complete IPv6 datagram. 661 Test SNDU: The payload will be discarded by the Receiver. 662 Bridged SNDU: The payload carries a bridged MAC or LLC frame. 664 All other formats are currently reserved. 666 4.7.1 End Indicator 668 The format of the End Indicator is shown in figure 2. This format 669 MUST carry a D-bit value of 1. 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 |1| 0x7FFF | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | | 676 = Arbitrary number of bytes >= 0 with value 0xFF = 677 | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Figure 2: SNDU Format for an End Indicator. 682 4.7.2 IPv4 SNDU 684 IPv4 datagrams are transported using one of the two standard SNDU 685 structures, in which the PDU is placed directly in the SNDU payload. 686 The two encapsulations are shown in figures 3 and 4. (Note that in 687 this, and the following figures, the IP datagram payload is of 688 variable size, and is directly followed by the CRC-32). 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |0| Length (15b) | Type = 0x0800 | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Receiver Destination Address (6B) | 696 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 699 | | 700 = IPv4 datagram = 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | (CRC-32) | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0). 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |1| Length (15b) | Type = 0x0800 | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | | 714 = IPv4 datagram = 715 | | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | (CRC-32) | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1). 722 4.7.3 IPv6 SNDU Encapsulation 724 IPv6 datagrams are transported using one of the two standard SNDU 725 structures, in which the PDU is placed directly in the SNDU payload. 726 The two encapsulations are shown in figures 5 and 6. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |0| Length (15b) | Type = 0x086DD | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Receiver Destination Address (6B) | 734 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | | | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 737 | | 738 = IPv6 datagram = 739 | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | (CRC-32) | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0). 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |1| Length (15b) | Type = 0x086DD | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | | 752 = IPv6 datagram = 753 | | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | (CRC-32) | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1). 760 4.7.4 Test SNDU 762 A Test SNDU is of Type 1 (figure 6). The structure of the Data 763 portion of this SNDU is not defined by this document. All Receivers 764 MAY record reception in a log file, but MUST then discard any Test 765 SNDUs. The D-bit MAY be set in a TEST SNDU. 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 |D| Length (15b) | Type = 0x0000 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | | 773 = Data (ignored by Receivers) = 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | (CRC-32) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Figure 7: SNDU Format for a Test SNDU 781 4.7.5 Bridge Frame SNDU Encapsulation 783 A bridged SNDU is of Type 1. The payload includes a MAC source and 784 Ether-Type field together with the contents of a bridged MAC frame. 785 The SNDU has the format shown in figures 8 and 9. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 |0| Length (15b) | Type = 0x0001 | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Receiver Destination Address (6B) | 793 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 796 | MAC Destination Address (6B) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | MAC Source Address (6B) | 799 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | | EtherType (2B) | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | | 803 = (Contents of bridged MAC frame) = 804 | | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | (CRC-32) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 8: SNDU Format for a Bridged Payload (D=0) 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 |1| Length (15b) | Type = 0x0001 | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | MAC Destination Address (6B) | 816 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | | | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 819 | MAC Source Address (6B) | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | EtherType (2B) | | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 823 | | 824 = (Contents of bridged MAC frame) = 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | (CRC-32) | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Figure 9: SNDU Format for a Bridged Payload (D=1) 832 The MAC addresses are those specified in the frame being bridged and 833 SHOULD be assigned according to the rules specified by the IEEE and 834 may denote unknown, unicast, broadcast, and multicast link 835 addresses. These MAC addresses denote the intended recipient in the 836 destination LAN, and therefore have a different function to the NPA 837 addresses carried in the SNDU header. The EtherType field of a frame 838 is defined according to Ethernet/LLC [LLC]. 840 A frame type <1500 for a bridged frame, introduces a LLC Length 841 Field. The Receiver MUST check this length and discard any frame 842 with a length greater than permitted by the SNDU payload size. 844 In normal operation, it is expected that any padding appended to the 845 Ethernet frame will be removed prior to forwarding. This requires 846 the sender to be aware of such Ethernet padding. 848 Ethernet frames received at the Encapsulator for onward transmission 849 over ULE carry a Local Area Network Frame Check sequence, LAN FCS, 850 field (e.g. CRC-32 for Ethernet). The Encapsulator MUST check the 851 LAN-FCS value of all frames received, prior to further processing. 852 Frames received with an invalid LAN FCS MUST be discarded. After 853 checking, the LAN FCS is then removed (i.e., it is NOT forwarded in 854 the bridged SNDU). As in other ULE frames, the Encapsulator appends 855 a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate 856 LAN-FCS field will be appended to the bridged frame prior to onward 857 transmission on the Ethernet interface. 859 This design is readily implemented using existing network interface 860 cards, and does not introduce an efficiency cost by transmitting two 861 integrity check fields for bridged frames. However, it also 862 introduces the possibility that a frame corrupted within the 863 processing performed at an Encapsulator and/or Receiver may not be 864 detected by the final recipient(s) (i.e. such corruption would not 865 normally result in an invalid LAN FCS). 867 5. Processing at the Encapsulator 869 The Encapsulator forms the PDUs queued for transmission into SNDUs 870 by adding a header and trailer to each PDU (section 4). It then 871 segments the SNDU into a series of TS Packet payloads (figure 9). 872 These are transmitted using a single TS Logical Channel over a TS 873 Multiplex. The TS Multiplex may be processed by a number of MPEG-2 874 (re)multiplexors before it is finally delivered to a Receiver. 876 +------+--------------------------------+------+ 877 | ULE | Protocol Data Unit | ULE | 878 |Header| |CRC-32| 879 +------+--------------------------------+------+ 880 / / \ \ 881 / / \ \ 882 / / \ \ 883 +--------+---------+ +--------+---------+ +--------+---------+ 884 |MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 | 885 | Header | Payload | | Header | Payload | | Header | Payload | 886 +--------+---------+ +--------+---------+ +--------+---------+ 888 Figure 10: Encapsulation of a SNDU into a series of TS Packets 890 5.1 SNDU Encapsulation 892 When an Encapsulator has not previously sent a TS Packet for a 893 specific TS Logical Channel, or after an idle period, it starts to 894 send a SNDU in the first available TS Packet. This first TS Packet 895 generated MUST carry a PUSI value of 1. It MUST also carry a Payload 896 Pointer value of zero indicating the SNDU starts in the first 897 available byte of the TS Packet payload. 899 The Encapsulation MUST ensure that all TS Packets set the MPEG-2 900 Continuity Counter carried in the TS Packet header, according to 901 [ISO-MPEG]. This value MUST be incremented by one (modulo 16) for 902 each successive fragment/complete SNDU sent using a TS Logical 903 Channel. 905 An Encapsulator may decide not to immediately send another SNDU, 906 even if space is available in a partially filled TS Packet. This 907 procedure is known as Padding (figure 11). It informs the Receiver 908 that there are no more SNDUs in this TS Packet payload. The End 909 Indicator is followed by zero or more unused bytes until the end of 910 the TS Packet payload. All unused bytes MUST be set to the value of 911 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The padding 912 procedure trades decreased efficiency against improved latency. 914 +-/------------+ 915 | SubNetwork | 916 | DU 3 | 917 +-/------------+ 918 \ \ 919 \ \ 920 \ \ 921 +--------+--------+--------+----------+ 922 |MPEG-2TS| End of | 0xFFFF | Unused | 923 | Header | SNDU 3 | | Bytes | 924 +--------+--------+--------+----------+ 925 PUSI=0 ULE 926 End 927 Indicator 929 Figure 11: A TS Packet carrying the end of SNDU 3, followed by an 930 End Indicator. 932 Alternatively, when more packets are waiting at an Encapsulator, and 933 a TS Packet has sufficient space remaining in the payload, the 934 Encapsulator can follow a previously encapsulated SNDU with another 935 SNDU using the next available byte of the TS Packet payload (see 936 5.2). This is called Packing (figure 12). 938 +-/----------------+ +----------------/-+ 939 | Subnetwork | | Subnetwork | 940 | DU 1 | | DU 2 | 941 +-/----------------+ +----------------/-+ 942 \ \ / /\ 943 \ \ / / \ 944 \ \ / / \. . . 945 +--------+--------+--------+----------+ 946 |MPEG-2TS| Payload| end of | start of | 947 | Header | Pointer| SNDU 1 | SNDU 2 | 948 +--------+--------+--------+----------+ 949 PUSI=1 | ^ 950 | | 951 +--------------+ 953 Figure 12: A TS Packet with the end of SNDU 1, followed by SNDU 2. 955 5.2 Procedure for Padding and Packing 957 Five possible actions may occur when an Encapsulator has completed 958 encapsulation of an SNDU: 960 (i) If the TS Packet has no remaining space, the Encapsulator 961 transmits this TS Packet. It starts transmission of the next SNDU in 962 a new TS Packet. (The standard rules require the header of this new 963 TS Packet to carry a PUSI value of 1, and a Payload Pointer value of 964 0x00.) 966 (ii) If the TS Packet carrying the final part of a SNDU has one byte 967 of unused payload, the Encapsulator MUST place the value 0xFF in 968 this final byte, and transmit the TS Packet. This rule provides a 969 simple mechanism to resolve the complex behaviour that may arise 970 when the TS Packet has no PUSI set: To send another SNDU in the 971 current TS Packet, would otherwise require the addition of a Payload 972 Pointer that would consume the last remaining byte of TS Packet 973 payload. The behaviour follows similar practice for other MPEG-2 974 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission 975 of the next SNDU in a new TS Packet. (The standard rules require the 976 header of this new TS Packet to carry a PUSI value of 1 and a 977 Payload Pointer value of 0x00.) 979 (iii) If the TS Packet carrying the final part of a SNDU has exactly 980 two bytes of unused payload, and the PUSI was NOT already set, the 981 Encapsulator MUST place the value 0xFFFF in this final two bytes, 982 providing an End Indicator (4.7.1), and transmit the TS Packet. This 983 rule prevents fragmentation of the SNDU Length Field over two TS 984 Packets. The Encapsulator MUST start transmission of the next SNDU 985 in a new TS Packet. (The standard rules require the header of this 986 new TS Packet to carry a PUSI value of 1 and a Payload Pointer value 987 of 0x00.) 989 (iv) If the TS Packet has more than two bytes of unused payload, the 990 Encapsulator MAY transmit this partially full TS Packet but MUST 991 first place the value 0xFF in all remaining unused bytes (i.e. 992 setting an End Indicator followed by padding). The Encapsulator MUST 993 start transmission of the next SNDU in a new TS Packet. (The 994 standard rules require the header of this new TS Packet to carry a 995 PUSI value of 1 and a Payload Pointer value of 0x00.) 997 (v) If at least two bytes are available for payload data in the TS 998 Packet payload (i.e. three bytes if the PUSI was NOT previously set, 999 and two bytes if it was previously set), the Encapsulator MAY 1000 encapsulate further queued PDUs, by starting the next SNDU in the 1001 next available byte of the current TS Packet payload. The PUSI MUST 1002 be set. When the Encapsulator packs further SNDUs into a TS Packet 1003 where the PUSI has NOT already been set, this requires the PUSI to 1004 be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted 1005 in the first byte directly following the TS Packet header. The value 1006 MUST be set to the position of the byte following the end of the 1007 first SNDU in the TS Packet payload. If no further PDUs are 1008 available, an Encapsulator MAY wait for additional PDUs to fill the 1009 incomplete TS Packet. The maximum period of time an Encapsulator can 1010 wait, known as the Packing Threshold, MUST be bounded and SHOULD be 1011 configurable by the user. If no additional PDUs are received after 1012 the Packing Threshold, the Encapsulator MUST insert an End Indicator 1013 instead (using rule iv). 1015 Use of the Packing method (v) by an Encapsulation Gateway is 1016 optional, and may be determined on a per-session, per-packet, or 1017 per-SNDU basis. 1019 When a SNDU is less than the size of a TS Packet payload, a TS 1020 Packet may be formed that carries a PUSI value of one and also an 1021 End Indicator. 1023 6. Receiver Processing 1025 A Receiver tunes to a specific TS Multiplex and sets a receive 1026 filter to accept all TS Packets with a specific PID. These TS 1027 Packets are associated with a specific TS Logical Channel and are 1028 reassembled to form a stream of SNDUs. A single Receiver may be 1029 able to receive multiple TS Logical Channels, possibly using a range 1030 of TS Multiplexes. In each case, reassembly is performed 1031 independently for each TS Logical Channel. To perform this 1032 reassembly, the Receiver may use a buffer to hold the partially 1033 assembled SNDU, referred to here as the Current SNDU buffer. Other 1034 implementations may choose to use other data structures, but must 1035 provide equivalent operations. 1037 Receipt of a TS Packet with a PUSI value of 1 indicates that the TS 1038 Packet contains the start of a new SNDU. It also indicates the 1039 presence of the Payload Pointer (indicating the number of bytes to 1040 the start of the first SNDU in the TS-Packet currently being 1041 reassembled). It is illegal to receive a Payload Pointer value 1042 greater than 182, and this MUST cause the SNDU reassembly to be 1043 aborted and the Receiver to enter the Idle State. This event SHOULD 1044 be recorded as a payload pointer error. 1046 A Receiver MUST support the use of both the Packing and Padding 1047 method for any received SNDU, and MUST support reception of SNDUs 1048 with or without a Destination Address Field (i.e. D=0 and D=1). 1050 6.1 Idle State 1052 After initialisation or on receipt of an End Indicator, the Receiver 1053 enters the Idle State. In this state, the Receiver discards all TS 1054 Packets until it discovers the start of a new SNDU, when it then 1055 enters the Reassembly State. Figure 13 outlines these state 1056 transitions: 1058 +-------+ 1059 | START | 1060 +---+---+ 1061 | 1062 \/ 1063 +----------+ 1064 \| Idle |/ 1065 +-------/| State |\-------+ 1066 Insufficient | +----+-----+ | 1067 unused space | | PUSI set | MPEG-2 TS Error 1068 or | \/ | or 1069 End Indicator| +----------+ | SNDU Error 1070 | |Reassembly| | 1071 +--------| State |--------+ 1072 +----------+ 1074 Figure 13: Receiver state transitions 1076 6.1.1 Idle State Payload Pointer Checking 1078 A Receiver in the Idle State MUST check the PUSI value in the header 1079 of all received TS Packets. A PUSI value of 1 indicates the presence 1080 of a Payload Pointer. For the first TS Packet received, the Payload 1081 Pointer will also have a value of 0. Following a loss of 1082 synchronisation, values between 1 and 182 are permitted, in which 1083 case the Receiver MUST discard the number of bytes indicated by the 1084 Payload Pointer from the start of the TS Packet payload, before 1085 leaving the Idle State. It then enters the Reassembly State, and 1086 starts reassembly of a new SNDU at this point. 1088 6.2 Processing of a Received SNDU 1090 When in the Reassembly State, the Receiver reads a 2 byte SNDU 1091 Length Field from the TS Packet payload. If the value is less than 1092 or equal to 4, or equal to 0xFFFF, the Receiver discards the Current 1093 SNDU and the remaining TS Packet payload and returns to the Idle 1094 State. Receipt of an invalid Length Field is an error event and 1095 SHOULD be recorded as an SNDU length error. 1097 If the Length of the Current SNDU is greater than 4, the Receiver 1098 accepts bytes from the TS Packet payload to the Current SNDU buffer 1099 until either Length bytes in total are received, or the end of the 1100 TS Packet is reached. When Current SNDU length equals the value of 1101 the Length Field, the Receiver MUST calculate and verify the CRC 1102 value. SNDUs that contain an invalid CRC value MUST be discarded, 1103 causing the Receiver to re-enter the Idle State. 1105 When the Destination Address is present, the Receiver accepts SNDUs 1106 that match one of a set of addresses specified by the Receiver (this 1107 includes the NPA address of the Receiver, the NPA broadcast address 1108 and any required multicast NPA addresses). The Receiver MUST 1109 silently discard an SNDU with an unmatched address. 1111 After receiving a valid SNDU, the Receiver MUST check the Type Field 1112 (and process any Type 1 extensions specified). The SNDU payload is 1113 then passed to the next protocol layer specified. An SNDU with an 1114 unknown Type value MUST be discarded. This error event SHOULD be 1115 recorded as a SNDU type error. 1117 The Receiver then starts reassembly of the next SNDU. This MAY 1118 directly follow the previously reassembled SNDU within the TS Packet 1119 payload. 1121 (i) If the Current SNDU finishes at the end of a TS Packet payload, 1122 the Receiver MUST enter the Idle State. 1124 (ii) If only one byte remains unprocessed in the TS Packet payload 1125 after completion of the Current SNDU, the Receiver MUST discard this 1126 final byte of TS Packet payload. It then enters the Idle State. It 1127 MUST NOT record an error when the value of the remaining byte is 1128 identical to 0xFF. 1130 (iii) If two or more bytes of TS Packet payload data remain after 1131 completion of the Current SNDU, the Receiver accepts the next 2 1132 bytes and examines if this is an End Indicator. When an End 1133 Indicator is received, a Receiver MUST silently discard the 1134 remainder of the TS Packet payload and transition to the Idle State. 1135 Otherwise this is the start of the next Packed SNDU, and the 1136 Receiver continues by processing this SNDU. 1138 6.2.1 Reassembly Payload Pointer Checking 1140 A Receiver that has partially received a SNDU (in the Current SNDU 1141 buffer) MUST check the PUSI value in the header of all received TS 1142 Packets. If it receives a TS Packet with a PUSI value of 1, it MUST 1143 then verify the Payload Pointer. If the Payload Pointer does NOT 1144 equal the number of bytes remaining to complete the Current SNDU, 1145 i.e., the difference between the SNDU Length field and the number of 1146 reassembled bytes, the Receiver has detected a delimiting error. 1148 Following a delimiting error, the Receiver MUST discard the 1149 partially assembled SNDU (in the Current SNDU buffer), and SHOULD 1150 record a reassembly error. It MUST then re-enter the Idle State. 1152 6.3 Other Error Conditions 1154 The Receiver SHOULD check the MPEG-2 Transport Error indicator 1155 carried in the TS Packet header. This flag indicates a transmission 1156 error for a TS Logical Channel. If the flag is set to a value of 1157 one, a transmission error event SHOULD be recorded. Any partially 1158 received SNDU MUST be discarded. The Receiver then enters the Idle 1159 State. 1161 The Receiver MUST check the MPEG-2 Continuity Counter carried in the 1162 TS Packet header [ISO-MPEG]. If two (or more) successive TS Packets 1163 within the same TS Logical Channel carry the same Continuity Counter 1164 value, the duplicate TS Packets MUST be silently discarded. If the 1165 received value is NOT identical to that in the previous TS Packet, 1166 and it does NOT increment by one for successive TS Packets (modulo 1167 16), the Receiver has detected a continuity error. Any partially 1168 received SNDU MUST be discarded. A continuity counter error event 1169 SHOULD be recorded. The Receiver then enters the Idle State. 1171 Note that the MPEG2-2 Transmission network is permitted to carry 1172 duplicate TS Packets [ISO-MPEG], which are normally detected by the 1173 MPEG-2 Continuity Counter. A Receiver that does not perform the 1174 above Continuity Counter check, would accept duplicate copies of TS 1175 Packets to the reassembly procedure. In most cases, the SNDU CRC-32 1176 integrity check will result in discard of these SNDUs, leading to 1177 unexpected PDU loss, however in some cases, duplicate PDUs could 1178 pass undetected to the next layer protocol. 1180 7. Summary 1182 This document defines an Ultra Lightweight Encapsulation (ULE) to 1183 perform efficient and flexible support for IPv4 and IPv6 network 1184 services over networks built upon the MPEG-2 Transport Stream (TS). 1185 The encapsulation is also suited to transport of other protocol 1186 packets and bridged Ethernet frames. 1188 8. Acknowledgments 1190 This draft is based on a previous draft authored by: Horst D. 1191 Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry 1192 Fairhurst. The authors wish to thank the members of the ip-dvb 1193 mailing list for their input provided. In particular, the many 1194 comments received from Patrick Cipiere, Wolgang Fritsche, and Alain 1195 Ritoux. Alain also provided the original examples of usage. 1197 9. Security Considerations 1199 There is a known security issue with un-initialised stuffing bytes. 1200 In ULE, these bytes are set to 0xFF. 1202 There are known integrity issues with the removal of the LAN FCS in 1203 a bridged networking environment. The removal for bridged frames 1204 exposes the traffic to potentially undetected corruption while being 1205 processed by the Encapsulator and/or Receiver. 1207 There is a potential security issue when a Receiver receives a PDU 1208 with two length fields: The Receiver would need to validate the 1209 actual length and the Length Field and ensure that inconsistent 1210 values are not propagated by the network. In the ULE header, this is 1211 avoided by including only one SNDU Length Field. However, this 1212 issue still arises in bridged LLC frames, and frames with a LLC 1213 Length greater than the SNDU payload size MUST be discarded. 1215 10. References 1217 10.1 Normative References 1219 [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic 1220 coding of moving pictures and associated audio information: 1221 Systems", International Standards Organisation (ISO). 1223 [RFC2026] Bradner, S., "The Internet Standards Process � Revision 1224 3", BCP 9, RFC 2026, BCP 9, 1996. 1226 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 1227 Requirement Levels", BCP 14, RFC 2119, 1997. 1229 10.2 Informative References 1231 [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television 1232 Systems Committee (ATSC), Doc. A/53, 1995. 1234 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 1235 Systems Committee (ATSC), Doc. A/090, 2000. 1237 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 1238 for the ATSC Data Broadcast Standard", Advanced Television Systems 1239 Committee (ATSC), Doc. A/91, 2001. 1241 [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television 1242 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1243 1995. 1245 [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for 1246 Terrestrial Broadcast and Cable", Advanced Television Systems 1247 Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A, 2000. 1249 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV 1250 (DTV) Applications over Satellite", Advanced Television Systems 1251 Committee (ATSC), Doc. A/80, 1999. 1253 [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet 1254 over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. 1256 [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", 1257 European Telecommunications Standards Institute (ETSI). 1259 [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB 1260 interaction channel for Cable TV distribution systems (CATV)", 1261 European Telecommunications Standards Institute (ETSI). 1263 [ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation 1264 and Coding for DBS satellite systems at 11/12 GHz", European 1265 Telecommunications Standards Institute (ETSI). 1267 [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing 1268 structure, channel coding and modulation for digital terrestrial 1269 television (DVB-T)", European Telecommunications Standards Institute 1270 (ETSI). 1272 [ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB); 1273 Interaction Channel for Satellite Distribution Systems", European 1274 Telecommunications Standards Institute (ETSI). 1276 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic 1277 coding of moving pictures and associated audio information -- Part 1278 6: Extensions for DSM-CC is a full software implementation", 1279 International Standards Organisation (ISO). 1281 [ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification 1282 Type AAL5, International Standards Organisation (ISO), 1996. 1284 [LLC] "IEEE Logical Link Control" (ANSI/IEEE Std 802.2/ ISO 8802.2), 1285 1985. 1287 [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link 1288 Layer Tunneling Mechanism for Unidirectional Links", RFC3077, 1289 Proposed Standard, 2001. 1291 [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control 1292 Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed 1293 Standard, 2001. 1295 [SI-DAT] SI-DAT Group, "Second Draft DVB Specification for Data 1296 Broadcasting", Geneva, 1997. 1298 11. Authors' Addresses 1300 Godred Fairhurst 1301 Department of Engineering 1302 University of Aberdeen 1303 Aberdeen, AB24 3UE 1304 UK 1305 Email: gorry@erg.abdn.ac.uk 1306 Web: http://www.erg.abdn.ac.uk/users/Gorry 1308 Bernhard Collini-Nocker 1309 Department of Scientific Computing 1310 University of Salzburg 1311 Jakob Haringer Str. 2 1312 5020 Salzburg 1313 Austria 1314 Email: [bnocker]@cosy.sbg.ac.at 1315 Web: http://www.cosy.sbg.ac.at/sc/ 1317 Full Copyright Statement 1319 "Copyright (C) The Internet Society (date). All Rights Reserved. 1320 This document and translations of it may be copied and furnished to 1321 others, and derivative works that comment on or otherwise explain it 1322 or assist in its implementation may be prepared, copied, published 1323 and distributed, in whole or in part, without restriction of any 1324 kind, provided that the above copyright notice and this paragraph 1325 are included on all such copies and derivative works. However, this 1326 document itself may not be modified in any way, such as by removing 1327 the copyright notice or references to the Internet Society or other 1328 Internet organizations, except as needed for the purpose of 1329 developing Internet standards in which case the procedures for 1330 copyrights defined in the Internet Standards process must be 1331 followed, or as required to translate it into languages other than 1332 English. 1334 The limited permissions granted above are perpetual and will not be 1335 revoked by the Internet Society or its successors or assigns. 1337 12. IANA Considerations 1339 This document will require IANA involvement. 1341 The ULE type field defined in this document requires a registry. 1342 This registry allocates values 0-1499 (decimal). It MUST NOT 1343 allocate values greater than 1500 (decimal), since such values 1344 overlap the assignments made in the IANA Ethertypes registry. 1346 The following values need to be assigned by the IANA: 1348 ULE Type Field 1350 [Author Note: Optional extension headers also may require IANA 1351 action] 1352 ANNEXE A: Informative Appendix 1354 This appendix provides some examples of use. The appendix is 1355 informative. It does not provide a description of the protocol. The 1356 examples provide the complete TS Packet sequence for some sample 1357 encapsulated IP packets. 1359 The specification of the TS Packet header operation and field values 1360 is provided in [ISO-MPEG]. The specification of ULE is provided in 1361 the body of this document. 1363 The key below is provided for the following examples. 1365 HDR 4B TS Packet Header 1366 PUSI Payload Unit Start Indicator 1367 PP Payload Pointer 1368 *** TS Packet Payload Pointer (PP) 1370 Example A.1: Two 186B PDUs. 1372 SNDU A is 200 bytes (including destination MAC address) 1373 SNDU B is 200 bytes (including destination MAC address) 1375 The sequence comprises 3 TS Packets: 1377 SNDU 1378 PP=0 Length 1379 +-----+------+------+------+- -+------+ 1380 | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | 1381 +-----+----*-+-*----+------+- -+------+ 1382 PUSI=1 * * 1383 ***** 1384 SNDU 1385 PP=17 CRC for A Length 1386 +-----+------+------+- -+--- --+------+------+- -+------+ 1387 | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 | 1388 +-----+----*-+------+- -+------+-*----+------+- -+------+ 1389 PUSI=1 * * 1390 ************************* 1392 End Stuffing 1393 CRC for A Indicator Bytes 1394 +-----+------+- -+------+----+----+- -+----+ 1395 | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF| 1396 +-----+------+- -+------+----+----+- -+----+ 1397 PUSI=0 1398 Example A.2: Usage of last byte in a TS-Packet 1400 SNDU A is 183 bytes 1401 SNDU B is 182 bytes 1402 SNDU C is 181 bytes 1403 SNDU D is 185 bytes 1405 The sequence comprises 4 TS Packets: 1407 SNDU 1408 PP=0 Length CRC for A 1409 +-----+------+------+------+- -+------+ 1410 | HDR | 0x00 | 0x00 | 0x63 | ... | A182 | 1411 +-----+----*-+-*----+------+- -+------+ 1412 PUSI=1 * * 1413 ***** 1414 SNDU Unused 1415 PP=0 Length CRC for B byte 1416 +-----+------+------+------+- -+------+------+ 1417 | HDR | 0x00 | 0x00 | 0x62 | ... | B181 | 0xFF | 1418 +-----+---*--+-*----+------+- -+------+------+ 1419 PUSI=1 * * 1420 ****** 1421 SNDU SNDU 1422 PP=0 Length CRC for C Length 1423 +-----+------+------+------+- -+------+------+------+ 1424 | HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 | 1425 +-----+---*--+-*----+------+- -+------+------+------+ 1426 PUSI=1 * * 1427 ****** Unused 1428 byte 1429 +-----+------+- -+------+------+ 1430 | HDR | D002 | ... | D184 | 0xFF | 1431 +-----+------+- -+------+------+ 1432 PUSI=0 1433 Example A.3: Large SNDUs 1435 SNDU A is 732 bytes 1436 SNDU B is 284 bytes 1438 The sequence comprises 6 TS Packets: 1440 SNDU 1441 PP=0 Length 1442 +-----+------+------+------+- -+------+ 1443 | HDR | 0x00 | 0x02 | 0xD8 | ... | A182 | 1444 +-----+---*--+-*----+------+- -+------+ 1445 PUSI=1 * * 1446 ****** 1448 +-----+------+- -+------+ 1449 | HDR | A183 | ... | A366 | 1450 +-----+------+- -+------+ 1451 PUSI=0 1453 +-----+------+- -+------+ 1454 | HDR | A367 | ... | A550 | 1455 +-----+------+- -+------+ 1456 PUSI=0 1458 SNDU 1459 PP=181 CRC for A Length 1460 +-----+------+------+- -+------+------+------+ 1461 | HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 | 1462 +-----+---*--+------+- -+------+*-----+------+ 1463 PUSI=1 * * 1464 ************************* 1466 +-----+------+- -+------+ 1467 | HDR | B002 | ... | B185 | 1468 +-----+------+- -+------+ 1469 PUSI=0 1471 End Stuffing 1472 Indicator Bytes 1473 +-----+------+- -+------+------+------+- -+------+ 1474 | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF | 1475 +-----+------+- -+------+------+------+- -+------+ 1476 PUSI=0 1477 Example A.4: Packing of SNDUs 1479 SNDU A is 200 bytes 1480 SNDU B is 60 bytes 1481 SNDU C is 60 bytes 1483 The sequence comprises two TS Packets: 1485 SNDU 1486 PP=0 Length 1487 +-----+------+------+------+- -+------+ 1488 | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | 1489 +-----+----*-+-*----+------+- -+------+ 1490 PUSI=1 * * + + 1491 ***** ++++++++ 1492 + 1493 +++++++++++++++++ 1494 + SNDU 1495 PP=17 CRC for A + Length 1496 +-----+------+------+- -+------+-+----+------+- 1497 | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ... 1498 +-----+----*-+------+- -+------+*-----+------+- 1499 PUSI=1 * * + + 1500 ************************ +++++++++ 1501 + 1502 +++++++++++++++++++++++++++++++++++++++ 1503 + 1504 + SNDU End Stuffing 1505 + Length Indicator bytes 1506 + -+------+------+------+ -+------+------+------+- -+------+ 1507 + ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF | 1508 + -+------+-+----+------+ -+------+-+----+------+- -+------+ 1509 + + + + + 1510 + + ++++++++ + 1511 + + + + 1512 ++++++++++++++++ ++++++++++++++++++++++ 1514 *** TS Packet Payload Pointer (PP) 1515 +++ ULE Length Indicator 1516 Example A.5: Three 44B PDUs. 1518 SNDU A is 52 bytes (no destination MAC address) 1519 SNDU B is 52 bytes (no destination MAC address) 1520 SNDU C is 52 bytes (no destination MAC address) 1522 The sequence comprises 1 TS Packet: 1524 SNDU 1525 PP=0 Length 1526 +-----+------+------+------+- -+-----+------+-----+- -+-----+- 1527 | HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | .. 1528 +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- 1529 PUSI=1 * * 1530 ***** 1532 End Stuffing 1533 Indicator bytes 1534 -----+------+- -+-----+---------+- -+------+ 1535 ... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF | 1536 -*---+------+- -+-----+---------+- -+------+ 1537 ANNEXE B: Informative Appendix � SNDU Encapsulation 1539 An example of ULE encapsulation carrying an ICMPv6 packet generated 1540 by ping6. 1542 ULE SNDU Length : 63 decimal 1543 D-bit value : 0 (NPA Present) 1544 ULE Protocol Type : 0x86dd (IPv6) 1545 Destination ULE NPA Address: 01:02:03:04:05:06 1546 ULE CRC32 : 0x784679a5 1548 Source IPv6: 2001:660:3008:1789::5 1549 Destination IPv6: 2001:660:3008:1789::6 1551 SNDU contents (including CRC-32): 1553 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d 1554 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 1555 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 1556 0030: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 78 1557 0040: 46 79 a5