idnits 2.17.1 draft-fair-ipdvb-ule-02.txt: -(446): 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 is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 12. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 478 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([ISO-MPEG2], [ETSI-DVB], [RFC2119], [RFC2026], [ISO-DSMCC], [ETSI-RCS], [ATSC-DATG], [ITU3563], [SI-DAT], [ETSI-DAT], [ATSC-PSIP-TC], [ATSC], [ITU-I363], [ETSI-DVBC], [CLC99], [ATSC-S], [ATSC-G], [ATSC-DAT], [RFC3077], [ISO-MPEG], [ETSI-DVBS], [ETSI-DVBT], [RFC3309], [LLC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 63: '... * A Receiver MUST silently discard...' RFC 2119 keyword, line 66: '... It MUST NOT record an error wh...' RFC 2119 keyword, line 67: '...FF. The receiver MUST then wait for a...' RFC 2119 keyword, line 96: '... Error Indicator SHOULD be used - Hila...' RFC 2119 keyword, line 98: '... * MPEG-2 CC MAY be used (since CR...' (65 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 349 has weird spacing: '...cell in an AT...' == Line 410 has weird spacing: '...or PDUs is il...' == Line 1173 has weird spacing: '...cations over ...' == 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 (November 2003) is 7469 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 section? 'ISO-MPEG' on line 1277 looks like a reference -- Missing reference section? 'ETSI-RCS' on line 1195 looks like a reference -- Missing reference section? 'RFC3077' on line 1210 looks like a reference -- Missing reference section? 'ATSC' on line 1154 looks like a reference -- Missing reference section? 'ISO-DSMCC' on line 1199 looks like a reference -- Missing reference section? 'ETSI-DVB' on line 254 looks like a reference -- Missing reference section? 'ISO-MPEG2' on line 385 looks like a reference -- Missing reference section? 'LLC' on line 1207 looks like a reference -- Missing reference section? 'ITU3563' on line 558 looks like a reference -- Missing reference section? 'RFC3309' on line 1214 looks like a reference -- Missing reference section? 'RFC2026' on line 1146 looks like a reference -- Missing reference section? 'RFC2119' on line 1149 looks like a reference -- Missing reference section? 'ATSC-DAT' on line 1157 looks like a reference -- Missing reference section? 'ATSC-DATG' on line 1160 looks like a reference -- Missing reference section? 'ATSC-G' on line 1164 looks like a reference -- Missing reference section? 'ATSC-PSIP-TC' on line 1168 looks like a reference -- Missing reference section? 'ATSC-S' on line 1172 looks like a reference -- Missing reference section? 'CLC99' on line 1176 looks like a reference -- Missing reference section? 'ETSI-DAT' on line 1179 looks like a reference -- Missing reference section? 'ETSI-DVBC' on line 1182 looks like a reference -- Missing reference section? 'ETSI-DVBS' on line 1186 looks like a reference -- Missing reference section? 'ETSI-DVBT' on line 1190 looks like a reference -- Missing reference section? 'ITU-I363' on line 1204 looks like a reference -- Missing reference section? 'SI-DAT' on line 1218 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 26 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-fair-ipdvb-ule-02.txt Bernhard Collini-Nocker 5 University of Salzburg, A 7 Category: Draft Intended Standards Track November 2003 9 Ultra Lightweight Encapsulation (ULE) for transmission of 10 IP datagrams over MPEG-2/DVB networks 12 Status of this Draft 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The MPEG-2 TS has been widely accepted not only for providing 34 digital TV services, but also as a subnetwork technology for 35 building IP networks. This document describes an Ultra Lightweight 36 Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 37 Datagrams and other network protocol packets directly over ISO MPEG- 38 2 Transport Streams (TS) as TS Private Data. 40 [RFC EDITOR NOTE: 41 This section must be deleted prior to publication] 43 DOCUMENT HISTORY 45 Draft -00 46 This draft is intended as a study item for proposed future work by 47 the IETF in this area. Comments relating to this document will be 48 gratefully received by the author(s) and the ip-dvb mailing list at: 49 ip-dvb@erg.abdn.ac.uk 51 -------------------------------------------------------------------- 52 DRAFT 01 (Protocol update) 54 * Padding sequence modified to 0xFFFF, this change aligns with other 55 usage by MPEG-2 streams. Treatment remains the same as specified for 56 ULE. 58 * SDNU Format updated to include R-bit (reserved). 60 * Procedure for TS Packet carrying the final part of a SNDU with 61 either less than two bytes of unused payload updated. 63 * A Receiver MUST silently discard the remainder of a TS Packet 64 Payload when two or less bytes remain unprocessed following the end 65 of a SNDU, irrespective of the PUSI value in the received TS Packet. 66 It MUST NOT record an error when the value of the remaining byte(s) 67 is identical to 0xFF or 0xFFFF. The receiver MUST then wait for a 68 TS Packet with a PUSI value set to 1. 70 * Payload Pointer description updated. 72 * CRC Calculation added. 74 * Decapsulator processing revised. 76 * Type field split into two. 78 * References updated. 80 * Security considerations added (first draft). 82 * Appendix added with examples. 84 -------------------------------------------------------------------- 85 DRAFT - 02 (Improvement of clarity) 87 * Corrected CRC-32 to follow standard practice in DSM-CC. 89 * Removed LLC frame type, now redundant by Bridge-Type (==1) 91 * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain, 92 Bernhard 94 * Changes to description of minimum payload length. - Gorry 96 * MPEG-2 Error Indicator SHOULD be used - Hilamr & Gorry 98 * MPEG-2 CC MAY be used (since CRC-32 is strong anyway) - Hilmar & 99 Gorry 101 * Corrected CRC-32 to now follow standard practice in DSM-CC - 102 Gorry, Hilmar, Alain. 104 * Changed description of Encapsulator action for Packing, Gorry & 105 Hilmar. 107 * Changed description of Receiver to clarify packing, Gorry & Alain. 109 * Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG - 110 Hilmar/Bernhard. 112 * Recommend removal of section on Flushing bit stream - Gorry 114 * Updated SNDU figures to reflect D-bit and correct a mistake in the 115 bridged type field - Alain 117 * Reorganised section 5 to form sections 5 and 6, separating 118 encapsulation and receiver processing - Gorry, Hilmar, Alain. 120 * Added concept of Idle State and Reassembly State to the Receiver. 121 Renumbered sections 5,6 and following, - Gorry. 123 * Nits from Alain, Hilmar and Gorry. 124 Moved security issue on the design of the protocol to appropriate 125 sections, since this is not a concern for deployment: Length field 126 usage and padding initialisation. 128 * Changed wording: All multi-byte values in ULE (including Length, 129 Type, and Destination fields) are transmitted in network byte order 130 (most significant byte first) - old NiT from Alain, now fixed. 132 * Frame byte size in diagrams now updated to -standard- format, and 133 D bit action corrected, as requested by Alain. 135 * Frame format diagrams, redrawn to 32-bit format below: 136 0 1 2 3 137 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 139 * Additional diagram requested by Alain for D=0 bridging (added, and 140 subsequent figures renumbered). 142 * Diagrams of encapsulation process, redrawn for clarity (no change 143 to meaning) - Gorry. 145 * Reworded last para of CRC description. 147 * Clarification to the statements in the CRC coverage - to make it 148 clear that it is the entire SNDU (header AND payload) that is 149 checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at). 151 * References added for RCS (spotted by Alain) and AAL5 (provided by 152 Anthony Ang). 154 * Removed informative reference to MPEG part 1 - Alain. 155 Spelling correction -> Allain to Alain. 157 * Added description of Receiver processing of the address field.- 158 Gorry 160 * Added caution on LLC Length in bridged Packets thanks - 161 Gorry/wolfgang 163 * Removed Authors notes from text after their discussion on the list 164 - Gorry, 166 * Corrected text to now say maximum value of PP = 182 in ULE - 168 * Tidied diagrams at end (again) - Gorry. 169 Authors last call unitl 22-nov-03 - no new comments. 171 [END of RFC EDITOR NOTE] 172 Table of Contents 174 1. Introduction 175 2. Conventions used in this document 176 3. Description of method 177 4. SNDU Format 178 4.1 Destination Address Present Field 179 4.2 Length Field 180 4.3 End Indicator 181 4.4 Type Field 182 4.4.1 Type 1: IANA Assigned Type Fields 183 4.4.2 Type 2: Ethertype Compatible Type Fields 184 4.5 SNDU Destination Address Field 185 4.6 SNDU Trailer CRC 186 4.7 Description of SNDU Formats 187 4.7.1 End Indicator 188 4.7.2 IPv4 SNDU Encapsulation 189 4.7.3 IPv6 SNDU Encapsulation 190 4.7.4 Test SNDU 191 5. Processing at the Encapsulator 192 5.1 SNDU Encapsulation 193 5.2 Procedure for Padding and Packing 194 6. Receiver Processing 195 6.1 Idle State 196 6.1.1 Reassembly Payload Pointer Checking 197 6.2 Processing of a Received SNDU 198 6.2.1 Reassembly Payload Pointer Checking 199 6.3 Other Error Conditions 200 7. Summary 201 8. Acknowledgments 202 9. Security Considerations 203 10. References 204 10.1 Normative References 205 10.2 Informative References 206 11. Authors' Addresses 207 12. IANA Considerations 208 Appendix A. 210 1. Introduction 212 This document describes an encapsulation for transport of IP 213 datagrams, or other network layer packets, over ISO MPEG-2 Transport 214 Streams [ISO-MPEG]. It is suited to services based on MPEG-2, for 215 example the Digital Video Broadcast (DVB) architecture, the Advanced 216 Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other 217 similar MPEG-2 based transmission systems. Such systems typically 218 provide unidirectional (simplex) physical and link layer standards. 219 Support has been defined for a wide range of physical media (e.g. 220 Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS; 221 ATSC-S], Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). Bi- 222 directional (duplex) links may also be established using these 223 standards (e.g., DVB defines a range of return channel technologies, 224 including the use of two-way satellite links [ETSI-RCS] and dial-up 225 modem links [RFC3077]). 227 Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other 228 network layer packets) for transmission over an MPEG-2 Transport 229 Multiplex are passed to an Encapsulator. This formats each PDU into 230 a Subnetwork Data Unit (SNDU) by adding an encapsulation header and 231 an integrity check trailer. The SNDU is fragmented into a series of 232 TS Packets) that are sent over a single TS Logical Channel. 234 2. Conventions used in this document 236 ADAPTATION FIELD: An optional variable-length extension field of the 237 fixed-length TS Packet header, intended to convey clock references 238 and timing and synchronization information as well as stuffing over 239 an MPEG-2 Multiplex [ISO-MPEG]. 241 AFC: Adaptation Field Control, a pair of bits carried in the TS 242 Packet header that signal the presence of the Adaptation Field 243 and/or TS Packet payload. 245 ATSC: Advanced Television Systems Committee [ATSC]. A framework and 246 a set of associated standards for the transmission of video, audio, 247 and data using the ISO MPEG-2 standard. 249 DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC]. 250 A format for transmission of data and control information defined by 251 the ISO MPEG-2 standard that is carried in an MPEG-2 Private 252 Section. 254 DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of 255 associated standards published by the European Telecommunications 256 Standards Institute (ETSI) for the transmission of video, audio, and 257 data, using the ISO MPEG-2 Standard. 259 ENCAPSULATOR: A network device that receives PDUs and formats these 260 into Payload Units (known here as SNDUs) for output as a stream of 261 TS Packets. 263 MAC: Medium Access and Control. The link layer header of the 264 Ethernet IEEE 802 standard of protocols, consisting of a 6B 265 destination address, 6B source address, and 2B type field. 267 MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A 268 scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each 269 Section is sent in a series of TS Packets using a single TS Logical 270 Channel. 272 MPEG-2: A set of standards specified by the Motion Picture Experts 273 Group (MPEG), and standardized by the International Standards 274 Organisation (ISO) [ISO-MPEG] 276 NPA: Network Point of Attachment. In this document, refers to a 6 B 277 destination address within the MPEG-2 transmission network used to 278 identify individual Receivers or groups of Receivers. 280 PDU: Protocol Data Unit. Examples of PDU include Ethernet frames, 281 IPv4 or IPv6 datagrams, and other network packets 283 PES: Programme Elementary Scheme of MPEG-2 [ISO-MPEG]. 285 PID: Packet Identifier. A field carried in the header of TS Packets. 286 This is used to identify the TS Logical Channel to which a TS Packet 287 belongs [ISO-MPEG]. The TS Packets forming the parts of a Table 288 Section, PES, or other payload unit must all carry the same PID 289 value. The all 1s PID value indicates a Null TS Packet introduced 290 to maintain a constant bit rate of a TS Multiplex. 292 PP: Payload Pointer. An optional one byte pointer that directly 293 follows the TS Packet header. It contains the number of bytes 294 between the end of the TS Packet header and the start of a Payload 295 Unit. The presence of the Payload Pointer is indicated by the value 296 of the PUSI bit in the TS Packet header. The Payload Pointer is 297 present in DSM-CC, and Table Sections, it is not present in TS 298 Logical Channels that use the PES-format. 300 PU: Payload Unit. A sequence of bytes sent using a TS. Examples of 301 Payload Units include: an MPEG-2 Table Section or a ULE SNDU. 303 PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single 304 bit flag carried in the TS Packet header. A PUSI value of zero 305 indicates that the TS Packet does not carry the start of a new 306 Payload Unit. A PUSI value of one indicates that the TS Packet does 307 carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 308 also indicates the presence of a one byte Payload Pointer (PP). 310 PRIVATE SECTION: a syntactic structure used for mapping all service 311 information (e.g. an SI table) into TS Packets. A Table may be 312 divided into a number of Table Sections, however all Table Sections 313 must be carried over a single TS Logical Channel. 315 PSI: Programme SI. An table used to convey information about the 316 service carried in a TS Multiplex. The set of PSI tables is defined 317 by [ISO-MPEG], see also SI Table. 319 SI TABLE: Service Information Table. In this document, this term 320 describes any table used to convey information about the service 321 carried in a TS Multiplex. SI tables are carried in MPEG-2 private 322 sections. 324 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 325 Payload Unit. 327 TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table. 329 TS: Transport Stream [ISO-MPEG], a method of transmission at the 330 MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI 331 reference model. See also TS Logical Channel and TS Multiplex. 333 TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel 334 identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of 335 the ISO/OSI reference model. All packets sent over a TS Logical 336 Channel carry the same PID value. According to MPEG-2, some TS 337 Logical Channels are reserved for specific signalling purposes. 338 Other standards (e.g., ATSC, DVB) also reserve specific TS Logical 339 Channels. 341 TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single 342 common physical link (i.e. a transmission at a specified symbol 343 rate, FEC setting, and transmission frequency). The same TS Logical 344 Channel may be repeated over more than one TS Multiplex, for example 345 to redistribute the same multicast content to two terrestrial TV 346 transmission cells. 348 TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex 349 [ISO-MPEG]. Operation resembles that of cell in an ATM network, and 350 may also be referred to as a TS_Cell. Each TS Packet carries a 4B 351 header, plus optional overhead including an Adaptation Field, 352 encryption details and time stamp information to synchronise a set 353 of related Transport Streams. 355 3. Description of the Method 357 PDUs (IP packets, Ethernet frames or packets from other network 358 protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). 359 The SNDU is transmitted over an MPEG-2 transmission network by 360 placing it either in the payload of a single TS Packet. If required, 361 a SNDU may be fragmented into a series of TS Packets. Where there is 362 sufficient space, the method permits a single TS Packet to carry 363 more than one SNDU (or part there of), sometimes known as Packing. 364 All TS Packets comprising a SNDU MUST be assigned the same PID, and 365 therefore form a part of the same TS Logical Channel. 367 The ULE encapsulation is limited to TS private streams only. The 368 header of each TS Packet carries a one bit Payload Unit Start 369 Indicator (PUSI) field. The PUSI identifies the start of a payload 370 unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of 371 the PUSI bit are defined differently for PES and PSI packets [ISO- 372 MPEG]; for private data, its use is not defined in the MPEG-2 373 Standard. In ULE, the operation follows that of PSI packets. Hence, 374 the following PUSI values are defined: 376 0: The TS Packet does NOT contain the start of a SNDU, but 377 contains the continuation, or end of a SNDU; 379 1: The TS Packet contains the start of a SNDU, and a one byte 380 Payload Pointer follows the last byte of the TS Packet header. 382 If a Payload Unit (SNDU) finishes before the end of a TS Packet 383 payload, but it is not convenient to start another Payload Unit, a 384 stuffing procedure fills the remainder of the TS Packet payload with 385 bytes with a value 0xFF [ISO-MPEG2], known as Padding or Stuffing. 387 A Receiver processing MPEG-2 Table Sections is aware that when it 388 receives a table_id value of 0xFF, this indicates Padding/Stuffing 389 occurred and silently discards the remainder of the TS Packet 390 payload. The payload of the next TS Packet for the same TS Logical 391 Channel will begin with a Payload Pointer of value 0x00, indicating 392 that the next Payload Unit immediately follows the TS Packet header. 393 The ULE protocol resembles this, but differs in the exact procedure 394 (see the following sections). 396 The TS Packet Header also carries a two bit Adaptation Field Control 397 (AFC) value. The purpose of the adaptation field is primarily to 398 carry timing and synchronisation information and may be used to also 399 include stuffing bytes before a TS Packet payload. Standard 400 Receivers discard TS Packets with an adaptation_field_control field 401 value of '00'. Adaptation Field stuffing is NOT used in this 402 encapsulation method, and TS packets from a ULE Encapsulator MUST be 403 sent with an AFC value of '01'. Receivers MUST discard TS Packets 404 that carry other AFC values. 406 4. SNDU Format 408 PDUs (IP packets and bridged Ethernet frames)are encapsulated using 409 ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The 410 encapsulation format to be used for PDUs is illustrated below: 412 < ----------------------------- SNDU ----------------------------- > 413 +-+-------------------------------------------------------+--------+ 414 |D| Length | Type | PDU | CRC-32 | 415 +-+-------------------------------------------------------+--------+ 417 Figure 1: SNDU Encapsulation 419 All multi-byte values in ULE (including Length, Type, and 420 Destination fields) are transmitted in network byte order (most 421 significant byte first). Appendix A provides informative examples of 422 usage. 424 4.1 The Destination Address Present Field 426 The most significant bit of the Length Field carries the value of 427 the Destination Address Present Field, the D-bit. A value of 0 428 indicates the presence of the Destination Address Field (see section 429 4.5). A value of 1 indicates that a Destination Address Field is not 430 present (i.e. it is omitted). 432 By default, the D-bit value MUST be set to a value of 0, except for 433 the transmission of an End Indicator (see 4.3), in which this bit 434 MUST be set to the value of 1. 436 4.2 Length Field 438 A 15-bit value that indicates the length, in bytes, of the SNDU 439 (encapsulated Ethernet frame, IP datagram or other packet) counted 440 from the byte following the type field up to and including the CRC. 441 Note the special case described in 4.3. 443 4.3 End Indicator 445 When the first two bytes of a SNDU has the value 0xFFFF, this 446 denotes an End Indicator (i.e., all 1�s length combined with a D-bit 447 value of 1). It indicates to the Receiver that there are no further 448 SNDU are present within the current TS packet (see section 6), and 449 that no Destination Address Field is present. The value 0xFF has 450 specific semantics in MPEG-2 framing, where it is used to indicate 451 the presence of padding. This use resembles [ISO-DSMCC]. 453 4.4 Type Field 454 The 16-bit Type field indicates the type of payload carried in a 455 SNDU. The set of values that may be assigned to this field is 456 divided into two parts, similar to the allocations for Ethernet. 458 Ethertypes were originally specified by Xerox under the DIX 459 framework for Ethernet. After specification of IEEE 802.3 [LLC], the 460 set of Ethertypes less than or equal to 1500 (0x05FC), assumed the 461 role of a length indicator. Ethernet receivers use this feature to 462 discriminate LLC format frames. Hence any IEEE Ethertype <= 1500 463 indicates an LLC frame, and the actual value indicates the length of 464 the LLC frame. 466 There is a potential security issue when a Receiver receives a PDU 467 with two length fields: The Receiver would need to validate the 468 actual length and the Length field and ensure that inconsistent 469 values are not propagated by the network. Specification of two 470 independent length fields is therefore undesirable. In the ULE 471 header, this avoided in the SNDU header by including only one length 472 value, but bridging of LLC frames re-introduces this consideration 473 (section 4.7.5). 475 The Ethernet LLC mode of identification is not required in ULE, 476 since the SNDU format always carries an explicit Length Field, and 477 therefore the procedure in ULE is modified, as below: 479 The first set of ULE Type Field values comprise the set of values <= 480 1500. These Type Field values are IANA assigned (see 4.4.1). 482 The second set of ULE Type Field values comprise the set of values > 483 1500. In ULE, this indicates that the value is identical to the 484 corresponding type codes specified by the IEEE/DIX type assignments 485 for Ethernet and recorded in the IANA EtherType registry. 487 4.4.1 Type 1: IANA Assigned Type Fields 489 The first part of the Type space corresponds to the values 0x0000 to 490 1500 Decimal. These values may be used to identify link-specific 491 protocols and/or to indicate the presence of extension headers that 492 carry additional optional protocol fields (e.g. a bridging 493 encapsulation). Use of these values is co-ordinated by an IANA 494 registry. 496 The following types are defined: 498 [XXX IANA ACTION REQUIRED XXX] 500 0x0000: Test SNDU, discarded by the Receiver. 501 0x0001: Bridged Ethernet Frame (i.e. MAC source address follows) 503 [XXX END OF IANA ACTION REQUIRED XXX] 504 The remaining values within the first part of the Type space are 505 reserved for allocation by the IANA. 507 [Author NOTE: Type allocation and appropriate IANA Procedure to be 508 determined.] 510 4.4.2 Type 2: Ethertype compatible Type Fields 512 The second part of the Type space corresponds to the values 1500 513 Decimal and 0xFFFF. This set of type assignments follow DIX/IEEE 514 assignments (but exclude use of this field as a frame length 515 indicator) [LLC]. The following types are defined in this document 516 for part 2: 518 0x0800 : IPv4 Payload (according to IANA EtherTypes) 519 0x86DD : IPv6 Payload (according to IANA EtherTypes) 521 All other assignments in part two of this space should be 522 coordinated with the values defined for IANA EtherType 523 encapsulations. 525 4.5 SNDU Destination Address Field 527 The SNDU Destination Address Field is optional (see section 4.1). 528 This field MUST be carried for IP unicast packets destined to 529 routers(i.e. D=0). A sender MAY omit this field (D=1) for an IP 530 unicast packet and/or multicast packets delivered to Receivers that 531 are able to utilise a discriminator field (e.g. the IPv4/IPv6 532 destination address), which in combination with the PID value, could 533 be interpreted as a Link-Level address. 535 When the SNDU header indicates the presence of a SNDU Destination 536 Address field (i.e. D=0), a Network Point of Attachment, NPA, field 537 directly follows the SNDU Type Field. NPA destination addresses are 538 6 B numbers, normally expressed in hexadecimal, used to identify the 539 Receiver(s) in a MPEG-2 transmission network that should process a 540 received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as a 541 destination address in a SNDU. The least significant bit of the 542 first byte of the address is set to 1 for multicast frames, and the 543 remaining bytes specify the link layer multicast address. The 544 specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, 545 indicating this SNDU is to be delivered to all Receivers. 547 4.6 SNDU Trailer CRC 549 Each SNDU MUST carry a 32-bit CRC field in the last four bytes of 550 the SNDU. This position eases CRC computation by hardware. The CRC- 551 32 polynomial is to be used. This is a 32 bit value calculated 552 according to the generator polynomial represented 0x04C11DB7 in 553 hexadecimal: 555 x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0. 557 Examples where this polynomial is also employed include Ethernet, 558 DSM-CC section syntax [ISO-DSMCC} and AAL5 [ITU3563]. The use 559 resembles, but is different to that in SCTP [RFC3309]. 561 The Encapsulator initialises the CRC-32 accumulator register to the 562 value 0xFFFF FFFF. It then accumulates a transmit value for the 563 CRC32 that includes all bytes from the start of the SNDU header to 564 the end of the SNDU (excluding the 32-bit trailer), and places this 565 in the CRC Field. The Receiver performs an integrity check by 566 independently calculating the same CRC value and comparing this with 567 the transmitted value in the SNDU trailer. SNDUs that do not have a 568 valid CRC, are discarded, causing the Receiver to enter the Idle 569 State. 571 This description may be suited for hardware implementation, but this 572 document does not imply any specific implementation. Software-based 573 table-lookup or hardware-assisted software-based implementations are 574 also possible. 576 The primary purpose of this CRC is to protect the SNDU (header, and 577 payload) from undetected reassembly errors and errors introduced by 578 unexpected software / hardware operation while the SNDU is in 579 transit across the MPEG-2 subnetwork and during processing at the 580 encapsulation gateway and/or the receiver. It may also detect the 581 presence of uncorrected errors from the physical link (however, in 582 some cases, these may also be detected by other means). 584 4.7 Description of SNDU Formats 586 The format of a SNDU is determined by the combination of the 587 Destination Address Present bit (D) and the SNDU Type Field. The 588 simplest encapsulation places a PDU directly into a SNDU payload. 589 Some Type 1 encapsulations may require additional header fields. 590 These are inserted in the SNDU directly preceding the PDU. 592 The following SNDU Formats are defined here: 594 End Indicator: The Receiver should enter the Idle State.IPv4 SNDU: The 595 payload is a complete IPv4 datagram 596 IPv6 SNDU: The payload is a complete IPv6 datagram.Test SNDU: The 597 payload will be discarded by the Receiver. 598 Bridged SNDU: The payload carries a bridged MAC or LLC frame. 600 All other formats are currently reserved. 602 4.7.1 End Indicator 604 The format of the End Indicator is shown in figure 2. This format 605 MUST carry a D-bit value of 1. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 |1| 0x7FFF | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | 612 = Arbitrary number of bytes >= 0 with value 0xFF = 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Figure 2: SNDU Format for an End Indicator. 618 4.7.2 IPv4 SNDU 620 IPv4 datagrams are transported using one of the two standard SNDU 621 structures, in which the PDU is placed directly in the SNDU payload. 622 The two encapsulations are shown in figures 3 and 4. (Note that in 623 this, and the following figures, the IP datagram payload is of 624 variable size, and is directly followed by the CRC-32). 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 |0| Length (15b) | Type = 0x0800 | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Receiver Destination Address (6B) | 632 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 635 | | 636 = IPv4 datagram = 637 | | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | (CRC-32) | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0). 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 |1| Length (15b) | Type = 0x0800 | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 = IPv4 datagram = 651 | | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | (CRC-32) | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1). 658 4.7.3 IPv6 SNDU Encapsulation 660 IPv6 datagrams are transported using one of the two standard SNDU 661 structures, in which the PDU is placed directly in the SNDU payload. 662 The two encapsulations are shown in figures 5 and 6. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 |0| Length (15b) | Type = 0x086DD | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Receiver Destination Address (6B) | 670 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 673 | | 674 = IPv6 datagram = 675 | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | (CRC-32) | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0). 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 |1| Length (15b) | Type = 0x086DD | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | | 688 = IPv6 datagram = 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | (CRC-32) | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1). 696 4.7.4 Test SNDU 698 A Test SNDU is of Type 1 (figure 6). The structure of the Data 699 portion of this SNDU is not defined by this document. All Receivers 700 MAY record reception in a log file, but MUST then discard any Test 701 SNDUs. The D-bit MAY be set in a TEST SNDU. 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 |D| Length (15b) | Type = 0x0000 | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | | 709 = Data (ignored by Receivers) = 710 | | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | (CRC-32) | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 7: SNDU Format for a Test SNDU 717 4.7.5 Bridge Frame SNDU Encapsulation 719 A bridged SNDU is of Type 1. The payload includes a MAC source and 720 Ether-Type field together with the contents of a bridged MAC frame. 721 The SNDU has the format shown in figures 8 and 9. 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 |0| Length (15b) | Type = 0x0001 | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Receiver Destination Address (6B) | 729 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 732 | MAC Destination Address (6B) | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | MAC Source Address (6B) | 735 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | | EtherType (2B) | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | | 739 = (Contents of bridged MAC frame) = 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | (CRC-32) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Figure 8: SNDU Format for a Bridged Payload (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 = 0x0001 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | MAC Destination Address (6B) | 752 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 755 | MAC Source Address (6B) | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | EtherType (2B) | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 759 | | 760 = (Contents of bridged MAC frame) = 761 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | (CRC-32) | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 Figure 9: SNDU Format for a Bridged Payload (D=1) 768 The MAC addresses are those specified in the frame being bridged and 769 are SHOULD be assigned according to the rules specified by the IEEE 770 and may denote unknown, unicast, broadcast, and multicast link 771 addresses. These MAC addresses denote the intended recipient in the 772 destination LAN, and therefore have a different function to the NPA 773 addresses carried in the SNDU header. The EtherType field of frame 774 is defined according to Ethernet/LLC [LLC]. 776 A frame type <1500 for a bridged frames, introduces a LLC Length 777 Field. The Receiver MUST check this length and discard any frame 778 with a length greater than permitted by the SNDU payload size. 780 In normal operation, it is expected that any padding appended to the 781 Ethernet frame will be removed prior to forwarding. This requires 782 the sender to be aware of such padding. 784 Ethernet frames received at the Encapsulator for onward transmission 785 over ULE carry a Local Area Network Frame Check sequence, LAN FCS, 786 field (e.g. CRC-32 for Ethernet). The Encapsulator MUST check the 787 LAN-FCS value of all frames received, prior to further processing. 788 Frames received with an invalid LAN FCS MUST be discarded. After 789 checking, the LAN FCS is then removed (i.e., it is NOT forwarded in 790 the bridged SNDU). As in other ULE frames, the Encapsulator appends 791 a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate 792 LAN-FCS field will be appended to the bridged frame prior to onward 793 transmission on the Ethernet interface. 795 This design is readily implemented using existing network interface 796 cards, and does not introduce an efficiency cost by transmitting two 797 integrity check fields for bridged frames. However, it also 798 introduces the possibility that a frame corrupted within the 799 processing performed at an Encapsulator and/or Receiver may not be 800 detected by the final recipient(s) (i.e. such corruption would not 801 normally result in an invalid LAN FCS). 803 5. Processing at the Encapsulator 805 The Encapsulator forms the PDUs queued for transmission into SNDUs 806 by adding a header and trailer to each PDU (section 4). It then 807 segments the SNDU into a series of TS Packet payloads (figure 9). 808 These are transmitted using a single TS Logical Channel over a TS 809 Multiplex. The TS Multiplex may be processed by a number of MPEG-2 810 (re)multiplexors before it is finally delivered to a Receiver. 812 +------+--------------------------------+------+ 813 | ULE | Protocol Data Unit | ULE | 814 |Header| |CRC-32| 815 +------+--------------------------------+------+ 816 / / \ \ 817 / / \ \ 818 / / \ \ 819 +--------+---------+ +--------+---------+ +--------+---------+ 820 |MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 | 821 | Header | Payload | | Header | Payload | | Header | Payload | 822 +--------+---------+ +--------+---------+ +--------+---------+ 824 Figure 10: Encapsulation of a SNDU into a series of TS Packets 826 5.1 SNDU Encapsulation 828 When an Encapsulator has not previously sent a TS Packet for a 829 specific TS Logical Channel, or after an idle period, it starts to 830 send a SNDU in the first available TS Packet. This first TS Packet 831 generated MUST carry a PUSI value of 1. It MUST also carry a Payload 832 Pointer value of zero indicating the SNDU starts in the first 833 available byte of the TS Packet payload. 835 The Encapsulation MUST ensure that all TS Packets set the MPEG-2 836 Continuity Counter carried in the TS Packet header. This value MUST 837 be incremented by one (using modulo arithmetic) for each TS Packet 838 sent using a TS Logical Channel [ISO-MPEG]. 840 An Encapsulator may decide not to immediately send another SNDU, 841 even if space is available in a partially filled TS Packet. This 842 procedure is known as Padding (figure 11). It informs the Receiver 843 that there are no more SNDUs in this TS Packet payload. The End 844 Indicator is followed by zero or more unused bytes until the end of 845 the TS Packet payload. All unused bytes MUST be set to the value of 846 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The padding 847 procedure trades decreased efficiency against improved latency. 849 +-/------------+ 850 | SubNetwork | 851 | DU 3 | 852 +-/------------+ 853 \ \ 854 \ \ 855 \ \ 856 +--------+--------+--------+----------+ 857 |MPEG-2TS| End of | 0xFFFF | Unused | 858 | Header | SNDU 3 | | Bytes | 859 +--------+--------+--------+----------+ 860 PUSI=0 ULE 861 End 862 Indicator 864 Figure 11: A TS Packet carrying the end of SNDU 3, followed by an 865 End Indicator. 867 Alternatively, when more packets are waiting at an Encapsulator, and 868 a TS Packet has sufficient space remaining in the payload, the 869 Encapsulator can follow a previously encapsulated SNDU with another 870 SNDU using the next available byte of the TS Packet payload (see 871 5.2). This is called Packing (figure 12). 873 +-/----------------+ +----------------/-+ 874 | Subnetwork | | Subnetwork | 875 | DU 1 | | DU 2 | 876 +-/----------------+ +----------------/-+ 877 \ \ / /\ 878 \ \ / / \ 879 \ \ / / \. . . 880 +--------+--------+--------+----------+ 881 |MPEG-2TS| Payload| end of | start of | 882 | Header | Pointer| SNDU 1 | SNDU 2 | 883 +--------+--------+--------+----------+ 884 PUSI=1 | ^ 885 | | 886 +--------------+ 888 Figure 12: A TS Packet with the end of SNDU 1, followed by SNDU 2. 890 5.2 Procedure for Padding and Packing 892 Five possible actions may occur when an Encapsulator has completed 893 encapsulation of an SNDU: 895 (i) If the TS Packet has no remaining space, the Encapsulator 896 transmits this TS Packet. It starts transmission of the next SNDU in 897 a new TS Packet. (The standard rules require the header of this new 898 TS Packet to carry a PUSI value of 1, and a Payload Pointer value of 899 0x00.) 901 (ii) If the TS Packet carrying the final part of a SNDU has one byte 902 of unused payload, the Encapsulator MUST place the value 0xFF in 903 this final byte, and transmit the TS Packet. This rule provides a 904 simple mechanism to resolve the complex behaviour that may arise 905 when the TS Packet has no PUSI set: To send another SNDU in the 906 current TS Packet, would otherwise require the addition of a Payload 907 Pointer that would consume the last remaining byte of TS Packet 908 payload. The behaviour follows similar practice for other MPEG-2 909 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission 910 of the next SNDU in a new TS Packet. (The standard rules require the 911 header of this new TS Packet to carry a PUSI value of 1 and a 912 Payload Pointer value of 0x00.) 914 (iii) If the TS Packet carrying the final part of a SNDU has exactly 915 two bytes of unused payload, and the PUSI was NOT already set, the 916 Encapsulator MUST place the value 0xFFFF in this final two bytes, 917 providing an End Indicator (4.7.1), and transmit the TS Packet. This 918 rule prevents fragmentation of the SNDU Length Field over two TS 919 Packets. The Encapsulator MUST start transmission of the next SNDU 920 in a new TS Packet. (The standard rules require the header of this 921 new TS Packet to carry a PUSI value of 1 and a Payload Pointer value 922 of 0x00.) 924 (iv) If the TS Packet has more than two bytes of unused payload, the 925 Encapsulator MAY transmit this partially full TS Packet but MUST 926 first place the value 0xFF in all remaining unused bytes (i.e. 927 setting an End Indicator followed by padding). The Encapsulator MUST 928 start transmission of the next SNDU in a new TS Packet. (The 929 standard rules require the header of this new TS Packet to carry a 930 PUSI value of 1 and a Payload Pointer value of 0x00.) 932 (v) If at least two bytes are available for Payload data in the TS 933 Packet payload (i.e. three bytes if the PUSI was NOT previously set, 934 and two bytes if it was previously set), the Encapsulator MAY 935 encapsulate further queued PDUs, by starting the next SNDU in the 936 next available byte of the current TS Packet Payload. The PUSI MUST 937 be set. When the Encapsulator packs further SNDUs into a TS Packet 938 where the PUSI has NOT already been set, this requires the PUSI to 939 be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted 940 in the first byte directly following the TS Packet header. The value 941 MUST be set to the position of the byte following the end of the 942 first SNDU in the TS Packet payload. If no further PDUs are 943 available, an Encapsulator MAY wait for additional PDUs to fill the 944 incomplete TS Packet. The maximum period of time an Encapsulator can 945 wait MUST be bounded and SHOULD be configurable by the user. If no 946 additional PDUs are received after this period of time, it MUST 947 insert an End Indicator instead (using rule iv). 949 Use of the Packing method (v) by an Encapsulation Gateway is 950 optional, and may be determined on a per-session, per-packet, or 951 per-SNDU basis. 953 When a SNDU is less than the size of a TS Packet payload, a TS 954 Packet may be formed that carries a PUSI value of one and also an 955 End Indicator. 957 6. Receiver Processing 959 A Receiver tunes to a specific TS Multiplex and sets a receive 960 filter to accept all TS Packets with a specific PID. These TS 961 Packets are associated with a specific TS Logical Channel and are 962 reassembled to form a stream of SNDUs. A single Receiver may be 963 able to receive multiple TS Logical Channels, possibly using a range 964 of TS Multiplexes. In each case, reassembly is performed 965 independently for each TS Logical Channel. To perform this 966 reassembly, the receiver may use a buffer to hold the partially 967 assembled SNDU, referred to here as the Current SNDU buffer. Other 968 implementations may choose to use other data structures, but must 969 provide equivalent operations. 971 Receipt of a TS Packet with a PUSI value of 1 indicates that the TS 972 Packet contains the start of a new SNDU. It also indicates the 973 presence of the Payload Pointer (indicating the number of bytes to 974 the start of the first SNDU in the TS-Packet currently being 975 reassembled). It is illegal to receive a Payload Pointer value 976 greater than 182, and this MUST cause the SNDU reassembly to be 977 aborted and the Receiver to enter the Idle State. This event SHOULD 978 be recorded as a payload pointer error. 980 A Receiver MUST support the use of both the Packing and Padding 981 method for any received SNDU, and MUST support reception of SNDUs 982 with or without a Destination Address Field (i.e. D=0 and D=1). 984 6.1 Idle State 986 After initialisation or on receipt of an End Indicator, the Receiver 987 enters the Idle State. In this state, the Receiver discards all TS 988 Packets until it discovers the start of a new SNDU, when it then 989 enters the Reassembly State. Figure 13 outlines these state 990 transitions: 992 +-------+ 993 | START | 994 +---+---+ 995 | 996 \/ 997 +----------+ 998 \| Idle |/ 999 +-------/| State |\-------+ 1000 Insufficient | +----+-----+ | 1001 unused space | | PUSI set | MPEG-2 TS Error 1002 or | \/ | or 1003 End Indicator| +----------+ | SNDU Error 1004 | |Reassembly| | 1005 +--------| State |--------+ 1006 +----------+ 1008 Figure 13: Receiver state transitions 1010 6.1.1 Idle State Payload Pointer Checking 1012 A Receiver in the Idle State MUST check the PUSI value in the header 1013 of all received TS Packets. A PUSI value of 1 indicates the presence 1014 of a Payload Pointer. For the first TS Packet received, the Payload 1015 Pointer will also have a value of 0. Following a loss of 1016 synchronisation, values between 1 and 182 are permitted, in which 1017 case the receiver MUST discard the number of bytes indicated by the 1018 Payload Pointer from the start of the TS Packet payload, before 1019 leaving the Idle State. It then enters the Reassembly State, and 1020 starts reassembly of a new SNDU at this point. 1022 6.2 Processing of a Received SNDU 1024 When in the Reassembly State, the Receiver reads a 2 byte SNDU 1025 Length Field from the TS Packet payload. If the value is less than 1026 or equal to 4, or equal to 0xFFFF, the Receiver discards the Current 1027 SNDU and the remaining TS Packet payload and returns to the Idle 1028 State. Receipt of an invalid Length Field is an error event SHOULD 1029 be recorded as an SNDU length error. 1031 If the Length of the Current SNDU is greater than 4, it then accepts 1032 bytes from the TS Packet payload to the Current SNDU buffer until 1033 either Length bytes in total are received, or the end of the TS 1034 Packet is reached. When Current SNDU length equals the value of the 1035 Length Field, the receiver MUST calculate and verify the CRC value. 1036 SNDUs that contain an invalid CRC value MUST be discarded, causing 1037 the Receiver to re-enter the Idle State. 1039 When the Destination Address is present, the Receiver accepts SNDUs 1040 that match one of a set of addresses specified by the Receiver (this 1041 includes the NPA address of the Receiver, the NPA broadcast address 1042 and any required multicast NPA addresses). The Receiver MUST 1043 silently discard an SNDU with an unmatched address. 1045 After receiving a valid SNDU, the receiver MUST check the Type Field 1046 (and process ant Type 1 extensions specified). The SNDU payload is 1047 then passed to the next protocol layer specified. An SNDU with an 1048 unknown Type value MUST be discarded. This error event SHOULD be 1049 recorded as a SNDU type error. 1051 The receiver then starts reassembly of the next SNDU. This MAY 1052 directly follow the previously reassembled SNDU within the TS Packet 1053 Payload. 1055 (i) If the Current SNDU finishes at the end of a TS Packet payload, 1056 the Receiver MUST enter the Idle State. 1058 (ii) If only one byte remains unprocessed in the TS Packet payload 1059 after completion of the Current SNDU, the Receiver MUST discard this 1060 final byte of TS Packet Payload. It then enters the Idle State. It 1061 MUST NOT record an error when the value of the remaining byte is 1062 identical to 0xFF. 1064 (iii) If two or more bytes of TS Packet payload data remain after 1065 completion of the Current SNDU, the Receiver accepts the next 2 1066 bytes and examines if this is an End Indicator. When an End 1067 Indicator is received, a Receiver MUST silently discard the 1068 remainder of the TS Packet Payload and transition to the Idle State. 1069 Otherwise this is the start of the next Packed SNDU, and the 1070 Receiver continues by processing this SNDU. 1072 6.2.1 Reassembly Payload Pointer Checking 1074 A Receiver that has partially received a SNDU (in the Current SNDU 1075 buffer) MUST check the PUSI value in the header of all received TS 1076 Packets. If it receives a TS Packet with a PUSI value of 1, it MUST 1077 then verify the Payload Pointer. If the Payload Pointer does NOT 1078 equal the number of bytes remaining to complete the Current SNDU, 1079 i.e., the difference between the SNDU Length field and the number of 1080 reassembled bytes, the Receiver has detected a delimiting error. 1082 Following a delimiting error, the Receiver MUST discard the 1083 partially assembled SNDU (in the Current SNDU buffer), and SHOULD 1084 record a reassembly error. It MUST then re-enter the Idle State. 1086 6.3 Other Error Conditions 1088 The Receiver SHOULD check the MPEG-2 Transport Error indicator 1089 carried in the TS Packet header. This flag indicates a transmission 1090 error for a TS Logical Channel. If the flag is set to a value of 1091 one, a transmission error event SHOULD be recorded. Any partially 1092 received SNDU MUST be discarded. The Receiver then enters the Idle 1093 State. 1095 The Receiver MAY also check the MPEG-2 Continuity Counter carried in 1096 the TS Packet header. If the Receiver does perform Continuity 1097 Counter checking and the received value does not increment by one 1098 for successive TS Packets (modulo 16), the Receiver has detected a 1099 continuity error. Any partially received SNDU MUST be discarded. A 1100 continuity counter error event SHOULD be recorded. The Receiver then 1101 enters the Idle State. 1103 7. Summary 1105 This document defines an Ultra Lightweight Encapsulation (ULE) to 1106 perform efficient and flexible support for IPv4 and IPv6 network 1107 services over networks built upon the MPEG-2 Transport Stream (TS). 1108 The encapsulation is also suited to transport of other protocol 1109 packets and bridged Ethernet frames. 1111 8. Acknowledgments 1113 This draft is based on a previous draft authored by: Horst D. 1114 Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry 1115 Fairhurst. The authors wish to thank the members of the ip-dvb 1116 mailing list for their input provided. In particular, the many 1117 comments received from Patrick Cipiere, Wolgang Fritsche, and Alain 1118 Ritoux. Alain also provided the original examples of usage. 1120 9. Security Considerations 1122 There is a known security issue with un-initialised stuffing bytes. 1123 In ULE, these bytes are set to 0xFF. 1125 There are known integrity issues with the removal of the LAN FCS in 1126 a bridged networking environment. The removal for bridged frames 1127 exposes the traffic to potentially undetected corruption while being 1128 processed by the Encapsulator and/or Receiver. 1130 There is a potential security issue when a Receiver receives a PDU 1131 with two length fields: The Receiver would need to validate the 1132 actual length and the Length field and ensure that inconsistent 1133 values are not propagated by the network. In the ULE header, this 1134 avoided by including only one SNDU length value. However, this 1135 issue still arises in bridged LLC frames, and frames with a LLC 1136 Length greater than the SNDU payload size MUST be discarded. 1138 10. References 1140 10.1 Normative References 1142 [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic 1143 coding of moving pictures and associated audio information: 1144 Systems", International Standards Organisation (ISO). 1146 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 1147 3", BCP 9, RFC 2026, BCP 9, 1996. 1149 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 1150 Requirement Levels", BCP 14, RFC 2119, 1997. 1152 10.2 Informative References 1154 [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television 1155 Systems Committee (ATSC), Doc. A/53, 1995. 1157 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 1158 Systems Committee (ATSC), Doc. A/090, 2000. 1160 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 1161 for the ATSC Data Broadcast Standard", Advanced Television Systems 1162 Committee (ATSC), Doc. A/91, 2001. 1164 [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television 1165 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1166 1995. 1168 [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for 1169 Terrestrial Broadcast and Cable", Advanced Television Systems 1170 Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A, 2000. 1172 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV 1173 (DTV) Applications over Satellite", Advanced Television Systems 1174 Committee (ATSC), Doc. A/80, 1999. 1176 [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet 1177 over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. 1179 [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", 1180 European Telecommunications Standards Institute (ETSI). 1182 [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB 1183 interaction channel for Cable TV distribution systems (CATV)", 1184 European Telecommunications Standards Institute (ETSI). 1186 [ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation 1187 and Coding for DBS satellite systems at 11/12 GHz", European 1188 Telecommunications Standards Institute (ETSI). 1190 [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing 1191 structure, channel coding and modulation for digital terrestrial 1192 television (DVB-T)", European Telecommunications Standards Institute 1193 (ETSI). 1195 [ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB); 1196 Interaction Channel for Satellite Distribution Systems", European 1197 Telecommunications Standards Institute (ETSI). 1199 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic 1200 coding of moving pictures and associated audio information -- Part 1201 6: Extensions for DSM-CC is a full software implementation", 1202 International Standards Organisation (ISO). 1204 [ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification 1205 Type AAL5, International Standards Organisation (ISO), 1996. 1207 [LLC] "IEEE Logical Link Control" (ANSI/IEEE Std 802.2/ ISO 8802.2), 1208 1985. 1210 [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link 1211 Layer Tunneling Mechanism for Unidirectional Links", RFC3077, 1212 Proposed Standard, 2001. 1214 [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control 1215 Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed 1216 Standard, 2001. 1218 [SI-DAT] SI-DAT Group, "Second Draft DVB Specification for Data 1219 Broadcasting", Geneva, 1997. 1221 11. Authors' Addresses 1223 Godred Fairhurst 1224 Department of Engineering 1225 University of Aberdeen 1226 Aberdeen, AB24 3UE 1227 UK 1228 Email: gorry@erg.abdn.ac.uk 1229 Web: http://www.erg.abdn.ac.uk/users/Gorry 1231 Bernhard Collini-Nocker 1232 Institute of Computer Sciences 1233 University of Salzburg 1234 Jakob Haringer Str. 2 1235 5020 Salzburg 1236 Austria 1237 Email: [bnocker]@cosy.sbg.ac.at 1238 Web: http://www.cosy.sbg.ac.at/cs/ 1240 Full Copyright Statement 1242 "Copyright (C) The Internet Society (date). All Rights Reserved. 1243 This document and translations of it may be copied and furnished to 1244 others, and derivative works that comment on or otherwise explain it 1245 or assist in its implementation may be prepared, copied, published 1246 and distributed, in whole or in part, without restriction of any 1247 kind, provided that the above copyright notice and this paragraph 1248 are included on all such copies and derivative works. However, this 1249 document itself may not be modified in any way, such as by removing 1250 the copyright notice or references to the Internet Society or other 1251 Internet organizations, except as needed for the purpose of 1252 developing Internet standards in which case the procedures for 1253 copyrights defined in the Internet Standards process must be 1254 followed, or as required to translate it into languages other than 1255 English. 1257 The limited permissions granted above are perpetual and will not be 1258 revoked by the Internet Society or its successors or assigns. 1260 12. IANA Considerations 1262 This document will require IANA involvement. 1264 The payload type field defined in this document must be aligned with 1265 an existing IANA registry or the following values need to be 1266 assigned by the IANA: 1268 Payload Type Field 1269 ANNEXE A: Informative Appendix 1271 This appendix provides some examples of use. The appendix is 1272 informative. It does not provide a description of the protocol. The 1273 examples provide the complete TS Packet sequence for some sample 1274 encapsulated IP packets. 1276 The specification of the TS Packet header operation and field values 1277 is provided in [ISO-MPEG]. The specification of ULE is provided in 1278 the body of this document. 1280 The key below is provided for the following examples. 1282 HDR 4B TS Packet Header 1283 PUSI Payload Unit Start Indicator 1284 PP Payload Pointer 1285 *** TS Packet Payload Pointer (PP) 1287 Example A.1: Two 186B PDUs. 1289 SNDU A is 200 bytes (including destination MAC address) 1290 SNDU B is 200 bytes (including destination MAC address) 1292 The sequence comprises 3 TS Packets: 1294 SNDU 1295 PP=0 Length 1296 +-----+------+------+------+- -+------+ 1297 | HDR | 0x00 | 0x00 | 0xC8 | ... | A182 | 1298 +-----+----*-+-*----+------+- -+------+ 1299 PUSI=1 * * 1300 ***** 1301 SNDU 1302 PP=16 CRC for A Length 1303 +-----+------+------+- -+--- --+------+------+- -+------+ 1304 | HDR | 0x10 | A183 | ... | A199 | 0x00 | 0xC0 | ... | B165 | 1305 +-----+----*-+------+- -+------+-*----+------+- -+------+ 1306 PUSI=1 * * 1307 ************************* 1309 End Stuffing 1310 CRC for A Indicator Bytes 1311 +-----+------+- -+------+----+----+- -+----+ 1312 | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF| 1313 +-----+------+- -+------+----+----+- -+----+ 1314 PUSI=0 1315 Example A.2: Usage of last byte in a TS-Packet 1317 SNDU A is 183 bytes 1318 SNDU B is 182 bytes 1319 SNDU C is 181 bytes 1320 SNDU D is 185 bytes 1322 The sequence comprises 4 TS Packets: 1324 SNDU 1325 PP=0 Length CRC for A 1326 +-----+------+------+------+- -+------+ 1327 | HDR | 0x00 | A000 | A001 | ... | A182 | 1328 +-----+----*-+-*----+------+- -+------+ 1329 PUSI=1 * * 1330 ***** 1331 SNDU Unused 1332 PP=0 Length CRC for B byte 1333 +-----+------+------+------+- -+------+------+ 1334 | HDR | 0x00 | B000 | B001 | ... | B181 | 0xFF | 1335 +-----+---*--+-*----+------+- -+------+------+ 1336 PUSI=1 * * 1337 ****** 1338 SNDU SNDU 1339 PP=0 Length CRC for C Length 1340 +-----+------+------+------+- -+------+------+------+ 1341 | HDR | 0x00 | C000 | C001 | ... | C180 | D000 | D001 | 1342 +-----+---*--+-*----+------+- -+------+------+------+ 1343 PUSI=1 * * 1344 ****** Unused 1345 byte 1346 +-----+------+- -+------+------+ 1347 | HDR | D002 | ... | D184 | 0xFF | 1348 +-----+------+- -+------+------+ 1349 PUSI=0 1350 Example A.3: Large SNDUs 1352 SNDU A is 732 bytes 1353 SNDU B is 284 bytes 1355 The sequence comprises 6 TS Packets: 1357 SNDU 1358 PP=0 Length 1359 +-----+------+------+------+- -+------+ 1360 | HDR | 0x00 | A000 | A000 | ... | A182 | 1361 +-----+---*--+-*----+------+- -+------+ 1362 PUSI=1 * * 1363 ****** 1365 +-----+------+- -+------+ 1366 | HDR | A183 | ... | A366 | 1367 +-----+------+- -+------+ 1368 PUSI=0 1370 +-----+------+- -+------+ 1371 | HDR | A367 | ... | A550 | 1372 +-----+------+- -+------+ 1373 PUSI=0 1375 SNDU 1376 PP=181 CRC for A Length 1377 +-----+------+------+- -+------+------+------+ 1378 | HDR | 0xB5 | A551 | ... | A731 | B000 | B001 | 1379 +-----+---*--+------+- -+------+*-----+------+ 1380 PUSI=1 * * 1381 ************************* 1383 +-----+------+- -+------+ 1384 | HDR | B002 | ... | B186 | 1385 +-----+------+- -+------+ 1386 PUSI=0 1388 End Stuffing 1389 Indicator Bytes 1390 +-----+------+- -+------+------+------+- -+------+ 1391 | HDR | B187 | ... | B283 | OxFF | 0xFF | ... | 0xFF | 1392 +-----+------+- -+------+------+------+- -+------+ 1393 PUSI=0 1394 Example A.4: Packing of SNDUs 1396 SNDU A is 200 bytes 1397 SNDU B is 60 bytes 1398 SNDU C is 60 bytes 1400 The sequence comprises two TS Packets: 1402 SNDU 1403 PP=0 Length 1404 +-----+------+------+------+- -+------+ 1405 | HDR | 0x00 | A000 | A001 | ... | A182 | 1406 +-----+----*-+-*----+------+- -+------+ 1407 PUSI=1 * * + + 1408 ***** ++++++++ 1409 + 1410 +++++++++++++++++ 1411 + SNDU 1412 PP=17 CRC for A + Length 1413 +-----+------+------+- -+------+-+----+------+- 1414 | HDR | 0x11 | A183 | ... | A199 | B000 | B001 | ... 1415 +-----+----*-+------+- -+------+*-----+------+- 1416 PUSI=1 * * + + 1417 ************************ +++++++++ 1418 + 1419 +++++++++++++++++++++++++++++++++++++++ 1420 + 1421 + SNDU End Stuffing 1422 + Length Indicator bytes 1423 + -+------+------+------+ -+------+------+------+- -+------+ 1424 + ... | B059 | C000 | C001 |...| C059 | 0xFF | 0xFF |...| 0xFF | 1425 + -+------+-+----+------+ -+------+-+----+------+- -+------+ 1426 + + + + + 1427 + + ++++++++ + 1428 + + + + 1429 ++++++++++++++++++ ++++++++++++++++++++++++ 1431 *** TS Packet Payload Pointer (PP) 1432 +++ ULE Length Indicator