idnits 2.17.1 draft-ietf-ipdvb-ule-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1521. ** 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 42 longer pages, the longest (page 1) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (October 2004) is 7126 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 335, but not defined == Missing Reference: 'ISO-MPEG2' is mentioned on line 493, but not defined == Missing Reference: 'ITU3563' is mentioned on line 661, but not defined == Unused Reference: 'RFC2026' is defined on line 1404, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1407, but no explicit reference was found in the text == Unused Reference: 'ATSC-DAT' is defined on line 1418, but no explicit reference was found in the text == Unused Reference: 'ATSC-DATG' is defined on line 1421, but no explicit reference was found in the text == Unused Reference: 'ATSC-G' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'ATSC-PSIP-TC' is defined on line 1429, but no explicit reference was found in the text == Unused Reference: 'ATSC-S' is defined on line 1433, but no explicit reference was found in the text == Unused Reference: 'CLC99' is defined on line 1437, but no explicit reference was found in the text == Unused Reference: 'ETSI-DAT' is defined on line 1440, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBC' is defined on line 1443, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBS' is defined on line 1447, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBT' is defined on line 1451, but no explicit reference was found in the text == Unused Reference: 'ITU-I363' is defined on line 1465, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG' Summary: 6 errors (**), 0 flaws (~~), 21 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gorry Fairhurst 3 Internet Draft University of Aberdeen, U.K. 4 Document: draft-ietf-ipdvb-ule-02.txt Bernhard Collini-Nocker 5 University of Salzburg, A 7 ipdvb WG 9 Category: Draft, Intended Standards Track October 2004 11 Ultra Lightweight Encapsulation (ULE) for transmission of 12 IP datagrams over MPEG-2/DVB networks 14 Status of this Draft 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The MPEG-2 TS has been widely accepted not only for providing 37 digital TV services, but also as a subnetwork technology for 38 building IP networks. This document describes an Ultra Lightweight 39 Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 40 Datagrams and other network protocol packets directly over ISO MPEG- 41 2 Transport Streams (TS) as TS Private Data. ULE supports an 42 extension format that allows it to carry both optional (with an 43 explicit extension length) and mandatory (with an implicit extension 44 length) header information to assist in network/Receiver processing 45 of a SNDU. 47 [RFC EDITOR NOTE: 48 This section must be deleted prior to publication] 50 DOCUMENT HISTORY 52 Draft 00 53 This draft is intended as a study item for proposed future work by 54 the IETF in this area. Comments relating to this document will be 55 gratefully received by the author(s) and the ip-dvb mailing list at: 56 ip-dvb@erg.abdn.ac.uk 58 -------------------------------------------------------------------- 59 DRAFT 01 (Protocol update) 61 * Padding sequence modified to 0xFFFF, this change aligns with other 62 usage by MPEG-2 streams. Treatment remains the same as specified for 63 ULE. 65 * SDNU Format updated to include R-bit (reserved). 67 * Procedure for TS Packet carrying the final part of a SNDU with 68 either less than two bytes of unused payload updated. 70 * A Receiver MUST silently discard the remainder of a TS Packet 71 payload when two or less bytes remain unprocessed following the end 72 of a SNDU, irrespective of the PUSI value in the received TS Packet. 73 It MUST NOT record an error when the value of the remaining byte(s) 74 is identical to 0xFF or 0xFFFF. The Receiver MUST then wait for a 75 TS Packet with a PUSI value set to 1. 77 * Payload Pointer description updated. 79 * CRC Calculation added. 81 * Decapsulator processing revised. 83 * Type field split into two. 85 * References updated. 87 * Security considerations added (first draft). 89 * Appendix added with examples. 91 -------------------------------------------------------------------- 92 DRAFT - 02 (Improvement of clarity) 94 * Corrected CRC-32 to follow standard practice in DSM-CC. 96 * Removed LLC frame type, now redundant by Bridge-Type (==1) 98 * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain, 99 Bernhard 101 * Changes to description of minimum payload length. Gorry 103 * MPEG-2 Error Indicator SHOULD be used.Hilmar & Gorry 105 * MPEG-2 CC MAY be used (since CRC-32 is strong anyway). Hilmar & 106 Gorry 108 * Corrected CRC-32 to now follow standard practice in DSM-CC. Gorry, 109 Hilmar, Alain. 111 * Changed description of Encapsulator action for Packing. Gorry & 112 Hilmar. 114 * Changed description of Receiver to clarify packing. Gorry & Alain. 116 * Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG. 117 Hilmar/Bernhard. 119 * Recommend removal of section on Flushing bit stream. Gorry 121 * Updated SNDU figures to reflect D-bit and correct a mistake in the 122 bridged type field. Alain 124 * Reorganised section 5 to form sections 5 and 6, separating 125 encapsulation and receiver processing. Gorry, Hilmar, Alain. 127 * Added concept of Idle State and Reassembly State to the Receiver. 128 Renumbered sections 5,6 and following. Gorry. 130 * Nits from Alain, Hilmar and Gorry. 131 Moved security issue on the design of the protocol to appropriate 132 sections, since this is not a concern for deployment: Length field 133 usage and padding initialisation. 135 * Changed wording: All multi-byte values in ULE (including Length, 136 Type, and Destination fields) are transmitted in network byte order 137 (most significant byte first). old NiT from Alain, now fixed. 139 * Frame byte size in diagrams now updated to -standard- format, and 140 D bit action corrected, as requested by Alain. 142 * Frame format diagrams, redrawn to 32-bit format below: 143 0 1 2 3 144 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 146 * Additional diagram requested by Alain for D=0 bridging (added, and 147 subsequent figures renumbered). 149 * Diagrams of encapsulation process, redrawn for clarity (no change 150 to meaning). Gorry. 152 * Reworded last para of CRC description. 154 * Clarification to the statements in the CRC coverage - to make it 155 clear that it is the entire SNDU (header AND payload) that is 156 checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at). 158 * References added for RCS (spotted by Alain) and AAL5 (provided by 159 Anthony Ang). 161 * Removed informative reference to MPEG part 1.Alain. 162 Spelling correction -> Allain to Alain. 164 * Added description of Receiver processing of the address 165 field.Gorry 167 * Added caution on LLC Length in bridged Packets thanks. 168 Gorry/wolfgang 170 * Removed Authors notes from text after their discussion on the list 171 Gorry 173 * Corrected text to now say maximum value of PP = 182 in ULE. Gorry 175 * Tidied diagrams at end (again) - Gorry, 177 Revision with following changes: 179 * Re issue as working group draft (filename change) 180 * Refinement of the text on CRC generation to be unambiguous. 181 * Revised CC processing at Encapsulator (B C-N/GF/A.Allison) 182 * Revised CC processing at Receiver (from List: A.Allison; et al ) 183 * Corrections to length/PP field in Examples (M Sooriyabandara, 184 Alain) 185 * Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit) 186 * Section 4.5 only SHARED routed links require D=0 187 * Packing Threshold defined 188 * Next-Layer-Header defined 189 * Addition of Appendix B (to aide verification of SNDFU format) 191 Working Group ID rev 01 193 Issues addressed: 194 * Typographical 195 * Types > 1500 should be passed to the next higher protocol (Hilmar) 196 * The second part of the Type space corresponds to the values 1500 197 COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF. 198 * IANA has already defined IP and IPv6 types - corrected text! 199 Added more security considerations (-01d). 200 * Should we allow an Adaptation Field within ULE (request for DVB- 201 RCS compatibility)? Requirement to be clarified! Implementation 202 impact to be evaluated! 203 Current Recommendation: The current spec does not preclude use of 204 AF, it simply says that this is not the standard for ULE. The use 205 case and requirement for this mode are not currently clear, based on 206 this there is no current intention to add this to ULE - text for 207 requirements would be welcome. 208 * Verify the minimum value allocated to DIX Ethernet Header Types. 209 Draft updated to align with IEEE Registry assignments. 211 -------------------------------------------------------------------- 213 Working Group ID rev 02 215 Revised IPR disclosure 216 Revised copyright notice 218 Section 5 added to ULE to define optional extension headers (see 219 xule) 221 Correction of figure numbering. 222 Correction to capitalisation in Transport Stream definition of fields 223 Inserted space character after 1536 in line 2 of 4.4.2 224 Replaced } with ] after ISO_DSMCC 225 Replace reference to section 6.3 with section 7.3 at end of section 226 4.6. 227 Reference in 4.7.4 was changed to refer to figure 7 (not 6). 228 Note added after figure 9. 230 7.2 Changed, New text: <> The rationale is that the this a SNDU-integrity 233 check - rather than a framing issue. The mantra of being liberal in 234 what is accepted suggests we discard, but not that we also discard 235 succeeding SNDUs. 237 Known issues with this revision of the document: 239 (i) The worked hexadecimal example in the annexe needs to be 240 reworked. 241 (ii) The IANA procedures need to be checked with IANA. 242 (iii) Format page breaks in next rev! 244 [END of RFC EDITOR NOTE] 245 Table of Contents 247 1. Introduction 248 2. Conventions used in this document 249 3. Description of method 250 4. SNDU Format 251 4.1 Destination Address Present Field 252 4.2 Length Field 253 4.3 End Indicator 254 4.4 Type Field 255 4.4.1 Type 1: IANA Assigned Type Fields 256 4.4.2 Type 2: Ethertype Compatible Type Fields 257 4.5 SNDU Destination Address Field 258 4.6 SNDU Trailer CRC 259 4.7 Description of SNDU Formats 260 4.7.1 End Indicator 261 4.7.2 IPv4 SNDU Encapsulation 262 4.7.3 IPv6 SNDU Encapsulation 263 4.7.4 Test SNDU 264 5. Extension Headers 265 5.1 Mandatory Extension Header 266 5.2 Optional Extension Header 267 6.Processing at the Encapsulator 268 6.1 SNDU Encapsulation 269 6.2 Procedure for Padding and Packing 270 7. Receiver Processing 271 7.1 Idle State 272 7.1.1 Reassembly Payload Pointer Checking 273 7.2 Processing of a Received SNDU 274 7.2.1 Reassembly Payload Pointer Checking 275 7.3 Other Error Conditions 276 8. Summary 277 9. Acknowledgments 278 10. Security Considerations 279 11. References 280 11.1 Normative References 281 11.2 Informative References 282 12. Authors' Addresses 283 13. IPR Notices 284 14. Copyright Statement 285 14.1 Intellectual Property Statement 286 14.2 Disclaimer of Validity 287 15. IANA Considerations 289 ANNEXE A: Informative Appendix - SNDU Packing Examples 290 ANNEXE B: Informative Appendix - SNDU Encapsulation 291 1. Introduction 293 This document describes an encapsulation for transport of IP 294 datagrams, or other network layer packets, over ISO MPEG-2 Transport 295 Streams [ISO-MPEG; ID-ipdvb-arch]. It is suited to services based 296 on MPEG-2, for example the Digital Video Broadcast (DVB) 297 architecture, the Advanced Television Systems Committee (ATSC) 298 system [ATSC; ATSC-G], and other similar MPEG-2 based transmission 299 systems. Such systems provide unidirectional (simplex) physical and 300 link layer standards. Support has been defined for a wide range of 301 physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], 302 Satellite TV [ETSI-DVBS; ATSC-S], Cable Transmission [ETSI-DVBC; 303 ATSC-PSIP-TC]). Bi-directional (duplex) links may also be 304 established using these standards (e.g., DVB defines a range of 305 return channel technologies, including the use of two-way satellite 306 links [ETSI-RCS] and dial-up modem links [RFC3077]). 308 Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other 309 network layer packets) for transmission over an MPEG-2 Transport 310 Multiplex are passed to an Encapsulator. This formats each PDU into 311 a Subnetwork Data Unit (SNDU) by adding an encapsulation header and 312 an integrity check trailer. The SNDU is fragmented into a series of 313 TS Packets) that are sent over a single TS Logical Channel. 315 2. Conventions used in this document 317 ADAPTATION FIELD: An optional variable-length extension field of the 318 fixed-length TS Packet header, intended to convey clock references 319 and timing and synchronization information as well as stuffing over 320 an MPEG-2 Multiplex [ISO-MPEG]. 322 AFC: Adaptation Field Control, a pair of bits carried in the TS 323 Packet header that signal the presence of the Adaptation Field 324 and/or TS Packet payload. 326 ATSC: Advanced Television Systems Committee [ATSC]. A framework and 327 a set of associated standards for the transmission of video, audio, 328 and data using the ISO MPEG-2 standard. 330 DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC]. 331 A format for transmission of data and control information defined by 332 the ISO MPEG-2 standard that is carried in an MPEG-2 Private 333 Section. 335 DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of 336 associated standards published by the European Telecommunications 337 Standards Institute (ETSI) for the transmission of video, audio, and 338 data, using the ISO MPEG-2 Standard. 340 ENCAPSULATOR: A network device that receives PDUs and formats these 341 into Payload Units (known here as SNDUs) for output as a stream of 342 TS Packets. 344 END INDICATOR: A Type value that indicates to the Receiver that 345 there are no further SNDUs present within the current TS Packet. 347 MAC: Medium Access and Control. The link layer header of the 348 Ethernet IEEE 802 standard of protocols, consisting of a 6B 349 destination address, 6B source address, and 2B type field. 351 MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A 352 scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each 353 Section is sent in a series of TS Packets using a single TS Logical 354 Channel. 356 MPEG-2: A set of standards specified by the Motion Picture Experts 357 Group (MPEG), and standardized by the International Standards 358 Organisation (ISO) [ISO-MPEG]. 360 NEXT-HEADER: A Type value indicating an extension header. 362 NPA: Network Point of Attachment. In this document, refers to a 6 B 363 destination address (similar to an Ethernet MAC address) within the 364 MPEG-2 transmission network used to identify individual Receivers or 365 groups of Receivers. 367 PACKING THRESHOLD: A period of time an Encapsulator is willing to 368 defer transmission of a partially filled TS-Packet to accumulate 369 more SNDUs, rather than use Padding. After the Packet Threshold 370 period, the Encapsulator uses Padding to send the partially filled 371 TS-Packet. 373 PDU: Protocol Data Unit. Examples of PDU include Ethernet frames, 374 IPv4 or IPv6 datagrams, and other network packets 375 PES: Packetized Elementary Stream of MPEG-2 [ISO-MPEG]. 377 PID: Packet Identifier. A 13 bit field carried in the header of TS 378 Packets. This is used to identify the TS Logical Channel to which a 379 TS Packet belongs [ISO-MPEG]. The TS Packets forming the parts of a 380 Table Section, PES, or other payload unit must all carry the same 381 PID value. The all 1s PID value indicates a Null TS Packet 382 introduced to maintain a constant bit rate of a TS Multiplex. 384 PP: Payload Pointer. An optional one byte pointer that directly 385 follows the TS Packet header. It contains the number of bytes 386 between the end of the TS Packet header and the start of a Payload 387 Unit. The presence of the Payload Pointer is indicated by the value 388 of the PUSI bit in the TS Packet header. The Payload Pointer is 389 present in DSM-CC, and Table Sections, it is not present in TS 390 Logical Channels that use the PES-format. 392 PU: Payload Unit. A sequence of bytes sent using a TS. Examples of 393 Payload Units include: an MPEG-2 Table Section or a ULE SNDU. 395 PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single 396 bit flag carried in the TS Packet header. A PUSI value of zero 397 indicates that the TS Packet does not carry the start of a new 398 Payload Unit. A PUSI value of one indicates that the TS Packet does 399 carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 400 also indicates the presence of a one byte Payload Pointer (PP). 402 PRIVATE SECTION: a syntactic structure used for mapping all service 403 information (e.g. an SI table) into TS Packets. A Table may be 404 divided into a number of Table Sections, however all Table Sections 405 must be carried over a single TS Logical Channel. 407 PSI: Program Specific Information. Tables used to convey information 408 about the service carried in a TS Multiplex. The set of PSI tables 409 is defined by [ISO-MPEG], see also SI Table. 411 SI TABLE: Service Information Table. In this document, this term 412 describes any table used to convey information about the service 413 carried in a TS Multiplex. SI tables are carried in MPEG-2 private 414 sections. 416 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 417 Payload Unit. 419 TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table. 421 TS: Transport Stream [ISO-MPEG], a method of transmission at the 422 MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI 423 reference model. See also TS Logical Channel and TS Multiplex. 425 TS HEADER: The 4 byte header of a TS Packet as illustrated in the 426 introduction. 428 TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel 429 identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of 430 the ISO/OSI reference model. All packets sent over a TS Logical 431 Channel carry the same PID value. According to MPEG-2, some TS 432 Logical Channels are reserved for specific signalling purposes. 434 Other standards (e.g., ATSC, DVB) also reserve specific TS Logical 435 Channels. 437 TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single 438 common physical link (i.e. a transmission at a specified symbol 439 rate, FEC setting, and transmission frequency). The same TS Logical 440 Channel may be repeated over more than one TS Multiplex, for example 441 to redistribute the same multicast content to two terrestrial TV 442 transmission cells. 444 TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex 445 [ISO-MPEG]. Each TS Packet carries a 4B header, plus optional 446 overhead including an Adaptation Field, encryption details and time 447 stamp information to synchronise a set of related Transport Streams. 448 The 188B TS Packets incorporate a 4B header with the following 449 fields (those referenced within this document are marked with *): 451 Field Length Name/Purpose 452 (in bits) 454 8b Synchronisation pattern equal 0x47 455 *1b Transport Error Indicator 456 *1b Payload Unit Start Indicator (PUSI) 457 1b Transport Priority 458 *13b Packet IDentifier (PID) 459 2b Transport scrambling control 460 *2b Adaptation Field Control (AFC) 461 *4b Continuity Counter (CC) 462 3. Description of the Method 464 PDUs (IP packets, Ethernet frames or packets from other network 465 protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). 466 The SNDU is transmitted over an MPEG-2 transmission network by 467 placing it either in the payload of a single TS Packet, or if 468 required, an SNDU may be fragmented into a series of TS Packets. 469 Where there is sufficient space, the method permits a single TS 470 Packet to carry more than one SNDU (or part there of), sometimes 471 known as Packing. All TS Packets comprising a SNDU MUST be assigned 472 the same PID, and therefore form a part of the same TS Logical 473 Channel. 475 The ULE encapsulation is limited to TS private streams only. The 476 header of each TS Packet carries a one bit Payload Unit Start 477 Indicator (PUSI) field. The PUSI identifies the start of a payload 478 unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of 479 the PUSI bit are defined for PES and PSI packets [ISO-MPEG]; for 480 private data, its use is not defined in the MPEG-2 Standard. In ULE, 481 although being private data, the operation follows that of PSI 482 packets. Hence, the following PUSI values are defined: 484 0: The TS Packet does NOT contain the start of a SNDU, but 485 contains the continuation, or end of a SNDU; 487 1: The TS Packet contains the start of a SNDU, and a one byte 488 Payload Pointer follows the last byte of the TS Packet header. 490 If a Payload Unit (SNDU) finishes before the end of a TS Packet 491 payload, but it is not intended to start another Payload Unit, a 492 stuffing procedure fills the remainder of the TS Packet payload with 493 bytes with a value 0xFF [ISO-MPEG2], known as Padding. 495 A Receiver processing MPEG-2 Table Sections is aware that when it 496 receives a table_id value of 0xFF, this indicates Padding/Stuffing 497 occurred and silently discards the remainder of the TS Packet 498 payload. The payload of the next TS Packet for the same TS Logical 499 Channel will begin with a Payload Pointer of value 0x00, indicating 500 that the next Payload Unit immediately follows the TS Packet header. 501 The ULE protocol resembles this, but differs in the exact procedure 502 (see the following sections). 504 The TS Packet Header also carries a two bit Adaptation Field Control 505 (AFC) value. The purpose of the adaptation field is primarily to 506 extend the TS header for timing and synchronisation information and 507 may be used to also include stuffing bytes before a TS Packet 508 payload. Standard Receivers discard TS Packets with an 509 adaptation_field_control field value of '00'. Adaptation Field 510 stuffing is NOT used in this encapsulation method, and TS Packets 511 from a ULE Encapsulator MUST be sent with an AFC value of '01'. 512 Receivers MUST discard TS Packets that carry other AFC values. 514 4. SNDU Format 516 PDUs (IP packets and bridged Ethernet frames) are encapsulated using 517 ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The 518 encapsulation format to be used for PDUs is illustrated below: 520 < ----------------------------- SNDU ----------------------------- > 521 +-+-------------------------------------------------------+--------+ 522 |D| Length | Type | PDU | CRC-32 | 523 +-+-------------------------------------------------------+--------+ 525 Figure 1: SNDU Encapsulation 527 All multi-byte values in ULE (including Length, Type, and 528 Destination fields) are transmitted in network byte order (most 529 significant byte first). Appendix A provides informative examples of 530 usage. 532 4.1 The Destination Address Present Field 534 The most significant bit of the Length Field carries the value of 535 the Destination Address Present Field, the D-bit. A value of 0 536 indicates the presence of the Destination Address Field (see section 537 4.5). A value of 1 indicates that a Destination Address Field is not 538 present (i.e. it is omitted). 540 By default, the D-bit value MUST be set to a value of 0, except for 541 the transmission of an End Indicator (see 4.3), in which this bit 542 MUST be set to the value of 1. 544 4.2 Length Field 546 A 15-bit value that indicates the length, in bytes, of the SNDU 547 (encapsulated Ethernet frame, IP datagram or other packet) counted 548 from the byte following the type field up to and including the CRC. 549 Note the special case described in 4.3. 551 4.3 End Indicator 553 When the first two bytes of a SNDU have the value 0xFFFF, this 554 denotes an End Indicator (i.e., all 1s length combined with a D-bit 555 value of 1). It indicates to the Receiver that there are no further 556 SNDUs present within the current TS Packet (see section 6), and that 557 no Destination Address Field is present. The value 0xFF has specific 558 semantics in MPEG-2 framing, where it is used to indicate the 559 presence of Padding. This use resembles [ISO-DSMCC]. 561 4.4 Type Field 563 The 16-bit Type field indicates the type of payload carried in a 564 SNDU, or the presence of a Next-Header. The set of values that may 565 be assigned to this field is divided into two parts, similar to the 566 allocations for Ethernet. 568 Ethertypes were originally specified by Xerox under the DIX 569 framework for Ethernet. After specification of IEEE 802.3 [LLC], the 570 set of Ethertypes less than 1536 (0x0600), assumed the role of a 571 length indicator. Ethernet receivers use this feature to 572 discriminate LLC format frames. Hence any IEEE Ethertype < 1536 573 indicates an LLC frame, and the actual value indicates the length of 574 the LLC frame. 576 There is a potential ambiguous case when a Receiver receives a PDU 577 with two length fields: The Receiver would need to validate the 578 actual length and the Length field and ensure that inconsistent 579 values are not propagated by the network. Specification of two 580 independent length fields is therefore undesirable. In the ULE 581 header, this is avoided in the SNDU header by including only one 582 length value, but bridging of LLC frames re-introduces this 583 consideration (section 4.7.5). 585 The Ethernet LLC mode of identification is not required in ULE, 586 since the SNDU format always carries an explicit Length Field, and 587 therefore the procedure in ULE is modified, as below: 589 The first set of ULE Type Field values comprise the set of values < 590 1536. These Type Field values are IANA assigned (see 4.4.1), and 591 indicate the Next-Header. 593 The second set of ULE Type Field values comprise the set of values 594 >= 1536. In ULE, this indicates that the value is identical to the 595 corresponding type codes specified by the IEEE/DIX type assignments 596 for Ethernet and recorded in the IANA EtherType registry. 598 4.4.1 Type 1: Next-Layer-Header 600 The first part of the Type space corresponds to the values 0 to 601 1535 Decimal. These values may be used to identify link-specific 602 protocols and/or to indicate the presence of extension headers that 603 carry additional optional protocol fields (e.g. a bridging 604 encapsulation). Use of these values is co-ordinated by an IANA 605 registry. 607 The following types are defined: 609 [XXX IANA ACTION REQUIRED XXX] 611 0x0000: Test SNDU, discarded by the Receiver. 612 0x0001: Bridged Ethernet Frame (i.e. MAC source address follows) 613 0x0100: Padding, ignored by the Receiver. 615 [XXX END OF IANA ACTION REQUIRED XXX] 617 The remaining values within the first part of the Type space are 618 reserved for allocation by the IANA. 620 4.4.2 Type 2: Ethertype compatible Type Fields 622 The second part of the Type space corresponds to the values 1536 623 Decimal (0x600) and 0xFFFF. This set of type assignments follow 624 DIX/IEEE assignments (but exclude use of this field as a frame 625 length indicator) [LLC]. All assignments in this space MUST use the 626 values defined for IANA EtherType, the following two Type values are 627 used as examples (taken from the IANA Ethertypes registry): 629 0x0800 : IPv4 Payload 630 0x86DD : IPv6 Payload 632 4.5 SNDU Destination Address Field 634 The SNDU Destination Address Field is optional (see section 4.1). 635 This field MUST be carried (i.e. D=0) for IP unicast packets 636 destined to routers that are sent using shared links (i.e., where 637 the same link connects multiple Receivers). A sender MAY omit this 638 field (D=1) for an IP unicast packet and/or multicast packets 639 delivered to Receivers that are able to utilise a discriminator 640 field (e.g. the IPv4/IPv6 destination address), which in combination 641 with the PID value, could be interpreted as a Link-Level address. 643 When the SNDU header indicates the presence of a SNDU Destination 644 Address field (i.e. D=0), a Network Point of Attachment, NPA, field 645 directly follows the SNDU Type Field. NPA destination addresses are 646 6 Byte numbers, normally expressed in hexadecimal, used to identify 647 the Receiver(s) in a MPEG-2 transmission network that should process 648 a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as 649 a destination address in a SNDU. The least significant bit of the 650 first byte of the address is set to 1 for multicast frames, and the 651 remaining bytes specify the link layer multicast address. The 652 specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, 653 indicating this SNDU is to be delivered to all Receivers. 655 4.6 SNDU Trailer CRC 657 Each SNDU MUST carry a 32-bit CRC field in the last four bytes of 658 the SNDU. This position eases CRC computation by hardware. The CRC- 659 32 polynomial is to be used. Examples where this polynomial is also 660 employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and 661 AAL5 [ITU3563]. This is a 32 bit value calculated according to the 662 generator polynomial represented 0x04C11DB7 in hexadecimal: 664 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. 666 The Encapsulator initialises the CRC-32 accumulator register to the 667 value 0xFFFF FFFF. It then accumulates a transmit value for the 668 CRC32 that includes all bytes from the start of the SNDU header to 669 the end of the SNDU (excluding the 32-bit trailer holding the CRC- 670 32), and places this in the CRC Field. In ULE, the bytes are 671 processed in order of increasing position within the SNDU, the order 672 of processing bits is NOT reversed. This use resembles, but is 673 different to that in SCTP [RFC3309]. 675 The Receiver performs an integrity check by independently 676 calculating the same CRC value and comparing this with the 677 transmitted value in the SNDU trailer. SNDUs that do not have a 678 valid CRC, are discarded, causing the Receiver to enter the Idle 679 State. 681 This description may be suited for hardware implementation, but this 682 document does not imply any specific implementation. Software-based 683 table-lookup or hardware-assisted software-based implementations are 684 also possible. Annexe B provides an example of an Encapsulated PDU 685 that includes the computed CRC-32 value. 687 The primary purpose of this CRC is to protect the SNDU (header, and 688 payload) from undetected reassembly errors and errors introduced by 689 unexpected software / hardware operation while the SNDU is in 690 transit across the MPEG-2 subnetwork and during processing at the 691 encapsulation gateway and/or the Receiver. It may also detect the 692 presence of uncorrected errors from the physical link (however, 693 these may also be detected by other means, e.g. section 7.3). 695 4.7 Description of SNDU Formats 697 The format of a SNDU is determined by the combination of the 698 Destination Address Present bit (D) and the SNDU Type Field. The 699 simplest encapsulation places a PDU directly into a SNDU payload. 700 Some Type 1 encapsulations may require additional header fields. 701 These are inserted in the SNDU directly preceding the PDU. 703 The following SNDU Formats are defined here: 705 End Indicator: The Receiver should enter the Idle State. 706 IPv4 SNDU: The payload is a complete IPv4 datagram 707 IPv6 SNDU: The payload is a complete IPv6 datagram. 708 Test SNDU: The payload will be discarded by the Receiver. 709 Bridged SNDU: The payload carries a bridged MAC or LLC frame. 711 All other formats are currently reserved. 713 4.7.1 End Indicator 715 The format of the End Indicator is shown in figure 2. This format 716 MUST carry a D-bit value of 1. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 |1| 0x7FFF | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | | 723 = Arbitrary number (>= 0) bytes with value 0xFF = 724 | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Figure 2: SNDU Format for an End Indicator. 729 4.7.2 IPv4 SNDU 731 IPv4 datagrams are transported using one of the two standard SNDU 732 structures, in which the PDU is placed directly in the SNDU payload. 733 The two encapsulations are shown in figures 3 and 4. (Note that in 734 this, and the following figures, the IP datagram payload is of 735 variable size, and is directly followed by the CRC-32). 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 |0| Length (15b) | Type = 0x0800 | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Receiver Destination Address (6B) | 743 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 746 | | 747 = IPv4 datagram = 748 | | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | (CRC-32) | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0). 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 |1| Length (15b) | Type = 0x0800 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | | 761 = IPv4 datagram = 762 | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | (CRC-32) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1). 769 4.7.3 IPv6 SNDU Encapsulation 771 IPv6 datagrams are transported using one of the two standard SNDU 772 structures, in which the PDU is placed directly in the SNDU payload. 773 The two encapsulations are shown in figures 5 and 6. 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 |0| Length (15b) | Type = 0x086DD | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Receiver Destination Address (6B) | 781 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 784 | | 785 = IPv6 datagram = 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | (CRC-32) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0). 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 |1| Length (15b) | Type = 0x086DD | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | | 799 = IPv6 datagram = 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | (CRC-32) | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1). 807 4.7.4 Test SNDU 809 A Test SNDU is of Type 1 (figure 7). The structure of the Data 810 portion of this SNDU is not defined by this document. All Receivers 811 MAY record reception in a log file, but MUST then discard any Test 812 SNDUs. The D-bit MAY be set in a TEST SNDU. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |D| Length (15b) | Type = 0x0000 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 = Data (not forwarded by a Receiver) = 821 | | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | (CRC-32) | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Figure 7: SNDU Format for a Test SNDU 828 4.7.5 Bridge Frame SNDU Encapsulation 830 A bridged SNDU is of Type 1. The payload includes a MAC source and 831 Ether-Type field together with the contents of a bridged MAC frame. 832 The SNDU has the format shown in figures 8 and 9. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 |0| Length (15b) | Type = 0x0001 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Receiver Destination Address (6B) | 840 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | | | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 843 | MAC Destination Address (6B) | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | MAC Source Address (6B) | 846 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | EtherType (2B) | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | | 850 = (Contents of bridged MAC frame) = 851 | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | (CRC-32) | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Figure 8: SNDU Format for a Bridged Payload (D=0) 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 |1| Length (15b) | Type = 0x0001 | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | MAC Destination Address (6B) | 863 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | | | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 866 | MAC Source Address (6B) | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | EtherType (2B) | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 870 | | 871 = (Contents of bridged MAC frame) = 872 | | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | (CRC-32) | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 Figure 9: SNDU Format for a Bridged Payload (D=1) 879 Note: The final two bytes of the bridging header also carry a Type 880 field (see section 5). In this special case, the extension mandatory 881 header format permits this to carry a LLC Length field, specified by 882 IEEE 802 [LLC] rather than an IANA assigned value. 884 When an NPA address is specified (D=0), Receivers MUST discard all 885 SNDUs that carry an NPA address that does NOT match their own NPA 886 address (or a broadcast/mcast address), the payload of the remaining 887 SNDUs are processed by the bridging rules that follow. An SNDU 888 without an NPA address (D=1) results in a Receiver performing 889 bridging processing on the payload of all received SNDUs. 891 The MAC addresses in the frame being bridged SHOULD be assigned 892 according to the rules specified by the IEEE and may denote unknown, 893 unicast, broadcast, and multicast link addresses. These MAC 894 addresses denote the intended recipient in the destination LAN, and 895 therefore have a different function to the NPA addresses carried in 896 the SNDU header. The EtherType field of a frame is defined according 897 to Ethernet/LLC [LLC]. 899 A frame type < 1536 for a bridged frame, introduces a LLC Length 900 Field. The Receiver MUST check this length and discard any frame 901 with a length greater than permitted by the SNDU payload size. 903 In normal operation, it is expected that any padding appended to the 904 Ethernet frame will be removed prior to forwarding. This requires 905 the sender to be aware of such Ethernet padding. 907 Ethernet frames received at the Encapsulator for onward transmission 908 over ULE carry a Local Area Network Frame Check sequence, LAN FCS, 909 field (e.g. CRC-32 for Ethernet). The Encapsulator MUST check the 910 LAN-FCS value of all frames received, prior to further processing. 911 Frames received with an invalid LAN FCS MUST be discarded. After 912 checking, the LAN FCS is then removed (i.e., it is NOT forwarded in 913 the bridged SNDU). As in other ULE frames, the Encapsulator appends 914 a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate 915 LAN-FCS field will be appended to the bridged frame prior to onward 916 transmission on the Ethernet interface. 918 This design is readily implemented using existing network interface 919 cards, and does not introduce an efficiency cost by transmitting two 920 integrity check fields for bridged frames. However, it also 921 introduces the possibility that a frame corrupted within the 922 processing performed at an Encapsulator and/or Receiver may not be 923 detected by the final recipient(s) (i.e. such corruption would not 924 normally result in an invalid LAN FCS). 926 5. Extension Headers 928 This section describes an extension format for the ULE 929 encapsulation. In ULE, a Type field value less than 1536 Decimal 930 indicates a next-layer-header and is assigned from a separate IANA 931 registry defined for ULE. 933 The use of a single Type/next-layer-header registry simplifies 934 processing and eliminates the need to maintain multiple IANA 935 registries. The cost is that each extension header requires at least 936 2 bytes. This is justified, on the basis of simplified processing 937 and maintaining a simple lightweight header for the common case when 938 no extensions are present. 940 The 16-bit ULE next-layer-header field is used in place of the Type 941 value. It is organised as a 5-bit zero prefix, a 3-bit H-LEN field 942 and an 8-bit H-Type field, as follows: 944 +----+-----+--------+ 945 |0000|H-LEN| H-TYPE | 946 +----+-----+--------+ 948 Figure 10: Structure of ULE Next-Layer-Header Extension Type. 950 The H-LEN Assignment 952 0 Indicates a Mandatory Extension Header 953 1 Indicates an Optional Extension Header of length 2B 954 2 Indicates an Optional Extension Header of length 4B 955 3 Indicates an Optional Extension Header of length 6B 956 4 Indicates an Optional Extension Header of length 8B 957 5 Indicates an Optional Extension Header of length 10BX 958 >=6 the combined H-LEN and H-TYPE values indicate the Ethertype 959 of a PDU that directly follows this Type field. 961 A H-LEN of zero indicates a Mandatory Extension Header. Each 962 specific Mandatory Extension header has a pre-defined length, that 963 is not communicated in the H-LEN field. No additional limit is 964 placed on the maximum length of a Mandatory Extension Header. A 965 Mandatory Extension header MAY modify the format or encoding of the 966 enclosed PDU (e.g. to perform encryption and/or compression). 968 The H-Type is sent in a one byte field which may be either be 969 one of 256 Mandatory Header Extensions or one of 256 Optional 970 Header Extensions. The set of currently permitted H-Type values 971 for both types of header extension are defined by an IANA Registry. 973 The simplest examples of Extension Headers are Test and Padding. 974 The Test Mandatory Extension Header results in the entire PDU 975 being discarded. The Padding Optional Extension Header results 976 in the following (if any) option header being ignored. 978 The general format for an SNDU with extension headers is: 980 <-------------------------- SNDU ---------------------------> 981 +---+--------------------------------------------------+--------+ 982 |D=1| Length | T1 | H1 | T2 | PDU | CRC-32 | 983 +---+--------------------------------------------------+--------+ 984 <-ULE base header->< ext 1 > 986 Figure 11: SNDU Encapsulation with one Extension Header 988 Where: 989 D is the ULE D_bit (in this example D=1, however NPA addresses may 990 also be used in combination with extension headers). 991 T1 is the base header Type field. In this case, specifying a 992 next-layer-header value. 993 H1 is a set of fields defined for header type T1. There may be 0 994 or more bytes of information for a specific ULE extension header. 995 T2 is the Type field of the next header, i.e. a value > 1535 B 996 indicating the Ethertype of the PDU being carried. 998 <-------------------------- SNDU ---------------------------> 999 +---+---------------------------------------------------+--------+ 1000 |D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 | 1001 +---+---------------------------------------------------+--------+ 1002 < ext 1 > < ext 2 > 1004 Figure 12: SNDU Encapsulation with two Extension Headers 1006 Using this method several extension headers may be chained in 1007 series. Figure 12 shows an SNDU including two extension headers. 1008 The values of T1 and T2 are both less than 1536 Decimal, each 1009 indicating the presence of a next-layer-header rather than a 1010 directly following PDU. T3 has a value > 1535 indicating the 1011 Ethertype of the PDU being carried. Although an SNDU may contain 1012 an arbitrary number of consecutive extension headers, it is not 1013 expected that SNDUs will generally carry a large number. 1015 6. Processing at the Encapsulator 1017 The Encapsulator forms the PDUs queued for transmission into SNDUs 1018 by adding a header and trailer to each PDU (section 4). It then 1019 segments the SNDU into a series of TS Packet payloads (figure 9). 1020 These are transmitted using a single TS Logical Channel over a TS 1021 Multiplex. The TS Multiplex may be processed by a number of MPEG-2 1022 (re)multiplexors before it is finally delivered to a Receiver. 1024 +------+--------------------------------+------+ 1025 | ULE | Protocol Data Unit | ULE | 1026 |Header| |CRC-32| 1027 +------+--------------------------------+------+ 1028 / / \ \ 1029 / / \ \ 1030 / / \ \ 1031 +--------+---------+ +--------+---------+ +--------+---------+ 1032 |MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 | 1033 | Header | Payload | | Header | Payload | | Header | Payload | 1034 +--------+---------+ +--------+---------+ +--------+---------+ 1036 Figure 13: Encapsulation of a SNDU into a series of TS Packets 1038 6.1 SNDU Encapsulation 1040 When an Encapsulator has not previously sent a TS Packet for a 1041 specific TS Logical Channel, or after an idle period, it starts to 1042 send a SNDU in the first available TS Packet. This first TS Packet 1043 generated MUST carry a PUSI value of 1. It MUST also carry a Payload 1044 Pointer value of zero indicating the SNDU starts in the first 1045 available byte of the TS Packet payload. 1047 The Encapsulation MUST ensure that all TS Packets set the MPEG-2 1048 Continuity Counter carried in the TS Packet header, according to 1049 [ISO-MPEG]. This value MUST be incremented by one (modulo 16) for 1050 each successive fragment/complete SNDU sent using a TS Logical 1051 Channel. 1053 An Encapsulator MAY decide not to immediately send another SNDU, 1054 even if space is available in a partially filled TS Packet. This 1055 procedure is known as Padding (figure 11). It informs the Receiver 1056 that there are no more SNDUs in this TS Packet payload. The End 1057 Indicator is followed by zero or more unused bytes until the end of 1058 the TS Packet payload. All unused bytes MUST be set to the value of 1059 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The padding 1060 procedure trades decreased efficiency against improved latency. 1062 +-/------------+ 1063 | SubNetwork | 1064 | DU 3 | 1065 +-/------------+ 1066 \ \ 1067 \ \ 1068 \ \ 1069 +--------+--------+--------+----------+ 1070 |MPEG-2TS| End of | 0xFFFF | Unused | 1071 | Header | SNDU 3 | | Bytes | 1072 +--------+--------+--------+----------+ 1073 PUSI=0 ULE 1074 End 1075 Indicator 1077 Figure 14: A TS Packet carrying the end of SNDU 3, followed by an 1078 End Indicator. 1080 Alternatively, when more packets are waiting at an Encapsulator, and 1081 a TS Packet has sufficient space remaining in the payload, the 1082 Encapsulator can follow a previously encapsulated SNDU with another 1083 SNDU using the next available byte of the TS Packet payload (see 1084 6.2). This is called Packing (figure 15). 1086 +-/----------------+ +----------------/-+ 1087 | Subnetwork | | Subnetwork | 1088 | DU 1 | | DU 2 | 1089 +-/----------------+ +----------------/-+ 1090 \ \ / /\ 1091 \ \ / / \ 1092 \ \ / / \. . . 1093 +--------+--------+--------+----------+ 1094 |MPEG-2TS| Payload| end of | start of | 1095 | Header | Pointer| SNDU 1 | SNDU 2 | 1096 +--------+--------+--------+----------+ 1097 PUSI=1 | ^ 1098 | | 1099 +--------------+ 1101 Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2. 1103 6.2 Procedure for Padding and Packing 1105 Five possible actions may occur when an Encapsulator has completed 1106 encapsulation of an SNDU: 1108 (i) If the TS Packet has no remaining space, the Encapsulator 1109 transmits this TS Packet. It starts transmission of the next SNDU in 1110 a new TS Packet. (The standard rules require the header of this new 1111 TS Packet to carry a PUSI value of 1, and a Payload Pointer value of 1112 0x00.) 1114 (ii) If the TS Packet carrying the final part of a SNDU has one byte 1115 of unused payload, the Encapsulator MUST place the value 0xFF in 1116 this final byte, and transmit the TS Packet. This rule provides a 1117 simple mechanism to resolve the complex behaviour that may arise 1118 when the TS Packet has no PUSI set. To send another SNDU in the 1119 current TS Packet, would otherwise require the addition of a Payload 1120 Pointer that would consume the last remaining byte of TS Packet 1121 payload. The behaviour follows similar practice for other MPEG-2 1122 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission 1123 of the next SNDU in a new TS Packet. (The standard rules require the 1124 header of this new TS Packet to carry a PUSI value of 1 and a 1125 Payload Pointer value of 0x00.) 1127 (iii) If the TS Packet carrying the final part of a SNDU has exactly 1128 two bytes of unused payload, and the PUSI was NOT already set, the 1129 Encapsulator MUST place the value 0xFFFF in this final two bytes, 1130 providing an End Indicator (section 4.3), and transmit the TS 1131 Packet. This rule prevents fragmentation of the SNDU Length Field 1132 over two TS Packets. The Encapsulator MUST start transmission of the 1133 next SNDU in a new TS Packet. (The standard rules require the header 1134 of this new TS Packet to carry a PUSI value of 1 and a Payload 1135 Pointer value of 0x00.) 1137 (iv) If the TS Packet has more than two bytes of unused payload, the 1138 Encapsulator MAY transmit this partially full TS Packet but MUST 1139 first place the value 0xFF in all remaining unused bytes (i.e. 1140 setting an End Indicator followed by Padding). The Encapsulator MUST 1141 start transmission of the next SNDU in a new TS Packet. (The 1142 standard rules require the header of this new TS Packet to carry a 1143 PUSI value of 1 and a Payload Pointer value of 0x00.) 1145 (v) If at least two bytes are available for payload data in the TS 1146 Packet payload (i.e. three bytes if the PUSI was NOT previously set, 1147 and two bytes if it was previously set), the Encapsulator MAY 1148 encapsulate further queued PDUs, by starting the next SNDU in the 1149 next available byte of the current TS Packet payload. The PUSI MUST 1150 be set. When the Encapsulator packs further SNDUs into a TS Packet 1151 where the PUSI has NOT already been set, this requires the PUSI to 1152 be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted 1153 in the first byte directly following the TS Packet header. The value 1154 MUST be set to the position of the byte following the end of the 1155 first SNDU in the TS Packet payload. If no further PDUs are 1156 available, an Encapsulator MAY wait for additional PDUs to fill the 1157 incomplete TS Packet. The maximum period of time an Encapsulator can 1158 wait, known as the Packing Threshold, MUST be bounded and SHOULD be 1159 configurable in the Encapsulator. If sufficient additional PDUs are 1160 NOT received to complete the TS Packet within the Packing Threshold, 1161 the Encapsulator MUST insert an End Indicator (using rule iv). 1163 Use of the Packing method (v) by an Encapsulator is optional, and 1164 may be determined on a per-session, per-packet, or per-SNDU basis. 1166 When a SNDU is less than the size of a TS Packet payload, a TS 1167 Packet may be formed that carries a PUSI value of one and also an 1168 End Indicator (using rule iv). 1170 7. Receiver Processing 1172 A Receiver tunes to a specific TS Multiplex and sets a receive 1173 filter to accept all TS Packets with a specific PID. These TS 1174 Packets are associated with a specific TS Logical Channel and are 1175 reassembled to form a stream of SNDUs. A single Receiver may be 1176 able to receive multiple TS Logical Channels, possibly using a range 1177 of TS Multiplexes. In each case, reassembly MUST be performed 1178 independently for each TS Logical Channel. To perform this 1179 reassembly, the Receiver may use a buffer to hold the partially 1180 assembled SNDU, referred to here as the Current SNDU buffer. Other 1181 implementations may choose to use other data structures, but MUST 1182 provide equivalent operations. 1184 Receipt of a TS Packet with a PUSI value of 1 indicates that the TS 1185 Packet contains the start of a new SNDU. It also indicates the 1186 presence of the Payload Pointer (indicating the number of bytes to 1187 the start of the first SNDU in the TS-Packet currently being 1188 reassembled). It is illegal to receive a Payload Pointer value 1189 greater than 181, and this MUST cause the SNDU reassembly to be 1190 aborted and the Receiver to enter the Idle State. This event SHOULD 1191 be recorded as a payload pointer error. 1193 A Receiver MUST support the use of both the Packing and Padding 1194 method for any received SNDU, and MUST support reception of SNDUs 1195 with or without a Destination Address Field (i.e. D=0 and D=1). 1197 7.1 Idle State 1199 After initialisation, errors, or on receipt of an End Indicator, the 1200 Receiver enters the Idle State. In this state, the Receiver discards 1201 all TS Packets until it discovers the start of a new SNDU, when it 1202 then enters the Reassembly State. Figure 16 outlines these state 1203 transitions: 1205 +-------+ 1206 | START | 1207 +---+---+ 1208 | 1209 \/ 1210 +----------+ 1211 \| Idle |/ 1212 +-------/| State |\-------+ 1213 Insufficient | +----+-----+ | 1214 unused space | | PUSI set | MPEG-2 TS Error 1215 or | \/ | or 1216 End Indicator| +----------+ | SNDU Error 1217 | |Reassembly| | 1218 +--------| State |--------+ 1219 +----------+ 1221 Figure 16: Receiver state transitions 1223 7.1.1 Idle State Payload Pointer Checking 1225 A Receiver in the Idle State MUST check the PUSI value in the header 1226 of all received TS Packets. A PUSI value of 1 indicates the presence 1227 of a Payload Pointer. Following a loss of synchronisation, values 1228 between 1 and 182 are permitted, in which case the Receiver MUST 1229 discard the number of bytes indicated by the Payload Pointer from 1230 the start of the TS Packet payload, before leaving the Idle State. 1231 It then enters the Reassembly State, and starts reassembly of a new 1232 SNDU at this point. 1234 7.2 Processing of a Received SNDU 1236 When in the Reassembly State, the Receiver reads a 2 byte SNDU 1237 Length Field from the TS Packet payload. If the value is less than 1238 or equal to 4, or equal to 0xFFFF, the Receiver discards the Current 1239 SNDU and the remaining TS Packet payload and returns to the Idle 1240 State. Receipt of an invalid Length Field is an error event and 1241 SHOULD be recorded as an SNDU length error. 1243 If the Length of the Current SNDU is greater than 4, the Receiver 1244 accepts bytes from the TS Packet payload to the Current SNDU buffer 1245 until either Length bytes in total are received, or the end of the 1246 TS Packet is reached. When Current SNDU length equals the value of 1247 the Length Field, the Receiver MUST calculate and verify the CRC 1248 value (section 4.6). SNDUs that contain an invalid CRC value MUST be 1249 discarded, causing the Receiver to processes the next in-sequence 1250 SNDU (if any). 1252 When the Destination Address is present (D=0), the Receiver accepts 1253 SNDUs that match one of a set of addresses specified by the Receiver 1254 (this includes the NPA address of the Receiver, the NPA broadcast 1255 address and any required multicast NPA addresses). The Receiver MUST 1256 silently discard an SNDU with an unmatched address. 1258 After receiving a valid SNDU, the Receiver MUST check the Type Field 1259 (and process any Type 1 extensions specified). The SNDU payload is 1260 then passed to the next protocol layer specified. An SNDU with an 1261 unknown Type value < 1536 MUST be discarded. This error event SHOULD 1262 be recorded as a SNDU type error. 1264 The Receiver then starts reassembly of the next SNDU. This MAY 1265 directly follow the previously reassembled SNDU within the TS Packet 1266 payload. 1268 (i) If the Current SNDU finishes at the end of a TS Packet payload, 1269 the Receiver MUST enter the Idle State. 1271 (ii) If only one byte remains unprocessed in the TS Packet payload 1272 after completion of the Current SNDU, the Receiver MUST discard this 1273 final byte of TS Packet payload. It then enters the Idle State. It 1274 MUST NOT record an error when the value of the remaining byte is 1275 identical to 0xFF. 1277 (iii) If two or more bytes of TS Packet payload data remain after 1278 completion of the Current SNDU, the Receiver accepts the next 2 1279 bytes and examines if this is an End Indicator. When an End 1280 Indicator is received, a Receiver MUST silently discard the 1281 remainder of the TS Packet payload and transition to the Idle State. 1282 Otherwise this is the start of the next Packed SNDU, and the 1283 Receiver continues by processing this SNDU. 1285 7.2.1 Reassembly Payload Pointer Checking 1287 A Receiver that has partially received a SNDU (in the Current SNDU 1288 buffer) MUST check the PUSI value in the header of all subsequent TS 1289 Packets with the same PID (i.e. same TS Logical Channel). If it 1290 receives a TS Packet with a PUSI value of 1, it MUST then verify the 1291 Payload Pointer. If the Payload Pointer does NOT equal the number of 1292 bytes remaining to complete the Current SNDU, i.e., the difference 1293 between the SNDU Length field and the number of reassembled bytes, 1294 the Receiver has detected a delimiting error. 1296 Following a delimiting error, the Receiver MUST discard the 1297 partially assembled SNDU (in the Current SNDU buffer), and SHOULD 1298 record a reassembly error. It MUST then re-enter the Idle State. 1300 7.3 Other Error Conditions 1302 The Receiver SHOULD check the MPEG-2 Transport Error Indicator 1303 carried in the TS Packet header. This flag indicates a transmission 1304 error for a TS Logical Channel. If the flag is set to a value of 1305 one, a transmission error event SHOULD be recorded. Any partially 1306 received SNDU MUST be discarded. The Receiver then enters the Idle 1307 State. 1309 The Receiver MUST check the MPEG-2 Continuity Counter carried in the 1310 TS Packet header [ISO-MPEG]. If two (or more) successive TS Packets 1311 within the same TS Logical Channel carry the same Continuity Counter 1312 value, the duplicate TS Packets MUST be silently discarded. If the 1313 received value is NOT identical to that in the previous TS Packet, 1314 and it does NOT increment by one for successive TS Packets (modulo 1315 16), the Receiver has detected a continuity error. Any partially 1316 received SNDU MUST be discarded. A continuity counter error event 1317 SHOULD be recorded. The Receiver then enters the Idle State. 1319 Note that an MPEG2-2 Transmission network is permitted to carry 1320 duplicate TS Packets [ISO-MPEG], which are normally detected by the 1321 MPEG-2 Continuity Counter. A Receiver that does not perform the 1322 above Continuity Counter check, would accept duplicate copies of TS 1323 Packets to the reassembly procedure. In most cases, the SNDU CRC-32 1324 integrity check will result in discard of these SNDUs, leading to 1325 unexpected PDU loss, however in some cases, duplicate PDUs (fitting 1326 into one TS Packet) could pass undetected to the next layer 1327 protocol. 1329 8. Summary 1331 This document defines an Ultra Lightweight Encapsulation (ULE) to 1332 perform efficient and flexible support for IPv4 and IPv6 network 1333 services over networks built upon the MPEG-2 Transport Stream (TS). 1334 The encapsulation is also suited to transport of other protocol 1335 packets and bridged Ethernet frames. 1337 ULE also provides an extension header format and defines an 1338 associated IANA registry for efficient and flexible support of both 1339 mandatory and optional SNDU headers. This allows for future 1340 extension of the protocol, while providing backwards capability with 1341 existing implementations. In particular, Optional Extension Headers 1342 may safely be ignored by drivers that do not implement them, or 1343 choose not to process them. 1345 9. Acknowledgments 1347 This draft is based on a previous draft authored by: Horst D. 1348 Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry 1349 Fairhurst. The authors wish to thank the members of the ip-dvb 1350 mailing list for their input provided. In particular, the many 1351 comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar 1352 Linder, Alain Ritoux, and William Stanislaus. Alain also provided 1353 the original examples of usage. 1355 10. Security Considerations 1357 The security considerations for ULE resemble those that arise when 1358 the exiting Multi-Protocol Encapsulation (MPE) is used. ULE does 1359 not add specific new threats that will impact the security of the 1360 general Internet. 1362 There is a known security issue with un-initialised stuffing bytes. 1363 In ULE, these bytes are set to 0xFF (normal practice in MPEG-2). 1365 There are known integrity issues with the removal of the LAN FCS in 1366 a bridged networking environment. The removal for bridged frames 1367 exposes the traffic to potentially undetected corruption while being 1368 processed by the Encapsulator and/or Receiver. 1370 There is a potential security issue when a Receiver receives a PDU 1371 with two length fields: The Receiver would need to validate the 1372 actual length and the Length Field and ensure that inconsistent 1373 values are not propagated by the network. In ULE, this is avoided by 1374 including only one SNDU Length Field. However, this issue still 1375 arises in bridged LLC frames, and frames with a LLC Length greater 1376 than the SNDU payload size MUST be discarded, and a SNDU payload 1377 length error SHOULD be recorded. 1379 ULE supports optional link level encryption of the SNDU payload. 1380 This is as an additional security mechanism to IP, transport or 1381 application layer security - not a replacement [ID-ipdvb-arch]. The 1382 approach is generic and decouples the encapsulation from future 1383 security extensions. The operation provides functions that resemble 1384 those currently used with the MPE encapsulation. 1386 A ULE Mandatory Extension Header may in future be used to define a 1387 mechanism to perform link encryption . Additional security control 1388 fields may be provided as a part of the extension header, e.g. to 1389 associate an SNDU with one of a set of Security Association (SA) 1390 parameters. As a part of the encryption process, it may also be 1391 desirable to authenticate some/all of the SNDU headers. The method 1392 of encryption and the way in which keys are exchanged is beyond the 1393 scope of this specification, as also are the definition of the SA 1394 format and that of the related encryption keys. 1396 11. References 1398 11.1 Normative References 1400 [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic 1401 coding of moving pictures and associated audio information: 1402 Systems", International Standards Organisation (ISO). 1404 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 1405 3", BCP 9, RFC 2026, BCP 9, 1996. 1407 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 1408 Requirement Levels", BCP 14, RFC 2119, 1997. 1410 11.2 Informative References 1412 [ID-ipdvb-arch] "Requirements for transmission of IP datagrams over 1413 MPEG-2 networks", Internet Draft, Work in Progress. 1415 [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television 1416 Systems Committee (ATSC), Doc. A/53, 1995. 1418 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 1419 Systems Committee (ATSC), Doc. A/090, 2000. 1421 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 1422 for the ATSC Data Broadcast Standard", Advanced Television Systems 1423 Committee (ATSC), Doc. A/91, 2001. 1425 [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television 1426 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1427 1995. 1429 [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for 1430 Terrestrial Broadcast and Cable", Advanced Television Systems 1431 Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A, 2000. 1433 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV 1434 (DTV) Applications over Satellite", Advanced Television Systems 1435 Committee (ATSC), Doc. A/80, 1999. 1437 [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet 1438 over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. 1440 [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", 1441 European Telecommunications Standards Institute (ETSI). 1443 [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB 1444 interaction channel for Cable TV distribution systems (CATV)", 1445 European Telecommunications Standards Institute (ETSI). 1447 [ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation 1448 and Coding for DBS satellite systems at 11/12 GHz", European 1449 Telecommunications Standards Institute (ETSI). 1451 [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing 1452 structure, channel coding and modulation for digital terrestrial 1453 television (DVB-T)", European Telecommunications Standards Institute 1454 (ETSI). 1456 [ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB); 1457 Interaction Channel for Satellite Distribution Systems", European 1458 Telecommunications Standards Institute (ETSI). 1460 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic 1461 coding of moving pictures and associated audio information -- Part 1462 6: Extensions for DSM-CC is a full software implementation", 1463 International Standards Organisation (ISO). 1465 [ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification 1466 Type AAL5, International Standards Organisation (ISO), 1996. 1468 [LLC] "IEEE Logical Link Control" (ANSI/IEEE Std 802.2/ ISO 8802.2), 1469 1985. 1471 [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link 1472 Layer Tunneling Mechanism for Unidirectional Links", RFC3077, 1473 Proposed Standard, 2001. 1475 [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control 1476 Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed 1477 Standard, 2001. 1479 12. Authors' Addresses 1481 Godred Fairhurst 1482 Department of Engineering 1483 University of Aberdeen 1484 Aberdeen, AB24 3UE 1485 UK 1486 Email: gorry@erg.abdn.ac.uk 1487 Web: http://www.erg.abdn.ac.uk/users/Gorry 1489 Bernhard Collini-Nocker 1490 Department of Scientific Computing 1491 University of Salzburg 1492 Jakob Haringer Str. 2 1493 5020 Salzburg 1494 Austria 1495 Email: [bnocker]@cosy.sbg.ac.at 1496 Web: http://www.cosy.sbg.ac.at/sc/ 1497 13. IPR Notices 1499 13.1 Intellectual Property Statement 1501 The IETF takes no position regarding the validity or scope of any 1502 Intellectual Property Rights or other rights that might be claimed 1503 to pertain to the implementation or use of the technology described 1504 in this document or the extent to which any license under such 1505 rights might or might not be available; nor does it represent that 1506 it has made any independent effort to identify any such rights. 1507 Information on the procedures with respect to rights in RFC 1508 documents can be found in BCP 78 and BCP 79. 1510 Copies of IPR disclosures made to the IETF Secretariat and any 1511 assurances of licenses to be made available, or the result of an 1512 attempt made to obtain a general license or permission for the use 1513 of such proprietary rights by implementers or users of this 1514 specification can be obtained from the IETF on-line IPR repository 1515 at http://www.ietf.org/ipr. 1517 The IETF invites any interested party to bring to its attention any 1518 copyrights, patents or patent applications, or other proprietary 1519 rights that may cover technology that may be required to implement 1520 this standard. Please address the information to the IETF at ietf- 1521 ipr@ietf.org. 1523 13.2 Disclaimer of Validity 1525 This document and the information contained herein are provided on 1526 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1527 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1528 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1529 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1530 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1533 14. Copyright Statement 1535 Copyright (C) The Internet Society (2004). This document is 1536 subject to the rights, licenses and restrictions contained in 1537 BCP 78, and except as set forth therein, the authors retain all 1538 their rights. 1540 15. IANA Considerations 1542 This document will require IANA involvement. 1544 The ULE type field defined in this document requires a registry. The 1545 payload type field defined in this document requires creation of a 1546 new IANA registry: 1548 ULE Next-Protocol-Header registry 1550 This registry allocates values 0-512 (decimal). 1552 15.1 IANA Guidelines 1554 The following contains the IANA guidelines for management of the ULE 1555 Next-Protocol-Header registry. This registry allocates values 1556 decimal 0-512 (0x0000-0x01FF, hexadecimal). It MUST NOT allocate 1557 values greater than 0x01FF (decimal). 1559 It subdivides the Next-Layer-Header registry in the following way: 1561 1) 0-255 (decimal) IANA assigned values indicating Mandatory 1562 Extension Headers (or link-dependent type fields) for ULE, 1563 requiring prior issue of an IETF RFC. 1565 Assignments made in this document: 1567 0: Test-SNDU 1568 1: Bridged-SNDU 1570 2) 256-511 (decimal) IANA assigned values indicating Optional 1571 Extension Headers for ULE, requiring prior issue of an IETF RFC. 1573 Assignments made in this document: 1575 256: Padding 1576 ANNEXE A: Informative Appendix 1578 This appendix provides some examples of use. The appendix is 1579 informative. It does not provide a description of the protocol. The 1580 examples provide the complete TS Packet sequence for some sample 1581 encapsulated IP packets. 1583 The specification of the TS Packet header operation and field values 1584 is provided in [ISO-MPEG]. The specification of ULE is provided in 1585 the body of this document. 1587 The key below is provided for the following examples. 1589 HDR 4B TS Packet Header 1590 PUSI Payload Unit Start Indicator 1591 PP Payload Pointer 1592 *** TS Packet Payload Pointer (PP) 1594 Example A.1: Two 186B PDUs. 1596 SNDU A is 200 bytes (including destination MAC address) 1597 SNDU B is 200 bytes (including destination MAC address) 1599 The sequence comprises 3 TS Packets: 1601 SNDU 1602 PP=0 Length 1603 +-----+------+------+------+- -+------+ 1604 | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | 1605 +-----+----*-+-*----+------+- -+------+ 1606 PUSI=1 * * 1607 ***** 1608 SNDU 1609 PP=17 CRC for A Length 1610 +-----+------+------+- -+--- --+------+------+- -+------+ 1611 | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 | 1612 +-----+----*-+------+- -+------+-*----+------+- -+------+ 1613 PUSI=1 * * 1614 ************************* 1616 End Stuffing 1617 CRC for A Indicator Bytes 1618 +-----+------+- -+------+----+----+- -+----+ 1619 | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF| 1620 +-----+------+- -+------+----+----+- -+----+ 1621 PUSI=0 1622 Example A.2: Usage of last byte in a TS-Packet 1624 SNDU A is 183 bytes 1625 SNDU B is 182 bytes 1626 SNDU C is 181 bytes 1627 SNDU D is 185 bytes 1629 The sequence comprises 4 TS Packets: 1631 SNDU 1632 PP=0 Length CRC for A 1633 +-----+------+------+------+- -+------+ 1634 | HDR | 0x00 | 0x00 | 0x63 | ... | A182 | 1635 +-----+----*-+-*----+------+- -+------+ 1636 PUSI=1 * * 1637 ***** 1638 SNDU Unused 1639 PP=0 Length CRC for B byte 1640 +-----+------+------+------+- -+------+------+ 1641 | HDR | 0x00 | 0x00 | 0x62 | ... | B181 | 0xFF | 1642 +-----+---*--+-*----+------+- -+------+------+ 1643 PUSI=1 * * 1644 ****** 1645 SNDU SNDU 1646 PP=0 Length CRC for C Length 1647 +-----+------+------+------+- -+------+------+------+ 1648 | HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 | 1649 +-----+---*--+-*----+------+- -+------+------+------+ 1650 PUSI=1 * * 1651 ****** Unused 1652 byte 1653 +-----+------+- -+------+------+ 1654 | HDR | D002 | ... | D184 | 0xFF | 1655 +-----+------+- -+------+------+ 1656 PUSI=0 1657 Example A.3: Large SNDUs 1659 SNDU A is 732 bytes 1660 SNDU B is 284 bytes 1662 The sequence comprises 6 TS Packets: 1664 SNDU 1665 PP=0 Length 1666 +-----+------+------+------+- -+------+ 1667 | HDR | 0x00 | 0x02 | 0xD8 | ... | A182 | 1668 +-----+---*--+-*----+------+- -+------+ 1669 PUSI=1 * * 1670 ****** 1672 +-----+------+- -+------+ 1673 | HDR | A183 | ... | A366 | 1674 +-----+------+- -+------+ 1675 PUSI=0 1677 +-----+------+- -+------+ 1678 | HDR | A367 | ... | A550 | 1679 +-----+------+- -+------+ 1680 PUSI=0 1682 SNDU 1683 PP=181 CRC for A Length 1684 +-----+------+------+- -+------+------+------+ 1685 | HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 | 1686 +-----+---*--+------+- -+------+*-----+------+ 1687 PUSI=1 * * 1688 ************************* 1690 +-----+------+- -+------+ 1691 | HDR | B002 | ... | B185 | 1692 +-----+------+- -+------+ 1693 PUSI=0 1695 End Stuffing 1696 Indicator Bytes 1697 +-----+------+- -+------+------+------+- -+------+ 1698 | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF | 1699 +-----+------+- -+------+------+------+- -+------+ 1700 PUSI=0 1701 Example A.4: Packing of SNDUs 1703 SNDU A is 200 bytes 1704 SNDU B is 60 bytes 1705 SNDU C is 60 bytes 1707 The sequence comprises two TS Packets: 1709 SNDU 1710 PP=0 Length 1711 +-----+------+------+------+- -+------+ 1712 | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 | 1713 +-----+----*-+-*----+------+- -+------+ 1714 PUSI=1 * * + + 1715 ***** ++++++++ 1716 + 1717 +++++++++++++++++ 1718 + SNDU 1719 PP=17 CRC for A + Length 1720 +-----+------+------+- -+------+-+----+------+- 1721 | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ... 1722 +-----+----*-+------+- -+------+*-----+------+- 1723 PUSI=1 * * + + 1724 ************************ +++++++++ 1725 + 1726 +++++++++++++++++++++++++++++++++++++++ 1727 + 1728 + SNDU End Stuffing 1729 + Length Indicator bytes 1730 + -+------+------+------+ -+------+------+------+- -+------+ 1731 + ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF | 1732 + -+------+-+----+------+ -+------+-+----+------+- -+------+ 1733 + + + + + 1734 + + ++++++++ + 1735 + + + + 1736 ++++++++++++++++ ++++++++++++++++++++++ 1738 *** TS Packet Payload Pointer (PP) 1739 +++ ULE Length Indicator 1740 Example A.5: Three 44B PDUs. 1742 SNDU A is 52 bytes (no destination MAC address) 1743 SNDU B is 52 bytes (no destination MAC address) 1744 SNDU C is 52 bytes (no destination MAC address) 1746 The sequence comprises 1 TS Packet: 1748 SNDU 1749 PP=0 Length 1750 +-----+------+------+------+- -+-----+------+-----+- -+-----+- 1751 | HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | .. 1752 +-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+- 1753 PUSI=1 * * 1754 ***** 1756 End Stuffing 1757 Indicator bytes 1758 -----+------+- -+-----+---------+- -+------+ 1759 ... 0x80 | 0x34 | ... | C51 |0xFF|0xFF| | 0xFF | 1760 -*---+------+- -+-----+---------+- -+------+ 1761 ANNEXE B: Informative Appendix - SNDU Encapsulation 1763 An example of ULE encapsulation carrying an ICMPv6 packet generated 1764 by ping6. 1766 ULE SNDU Length : 63 decimal 1767 D-bit value : 0 (NPA Present) 1768 ULE Protocol Type : 0x86dd (IPv6) 1769 Destination ULE NPA Address: 01:02:03:04:05:06 1770 ULE CRC32 : 0x784679a5 1772 Source IPv6: 2001:660:3008:1789::5 1773 Destination IPv6: 2001:660:3008:1789::6 1775 SNDU contents (including CRC-32): 1777 0000: 00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d 1778 0010: 3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00 1779 0020: 00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00 1780 0030: 00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 78 1781 0040: 46 79 a5 1783 >>>> Author Note : This packet is not a valid IPv6 packet since it 1784 has a unicast L3 IP address and a multicast L2 MAC address. A new 1785 packet decode is required. <<<