idnits 2.17.1 draft-fair-ipdvb-ule-01.txt: -(151): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(433): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(491): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 337 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 271 has weird spacing: '...cell in an AT...' == Line 984 has weird spacing: '... coding of m...' == Line 1014 has weird spacing: '...cations over ...' == Line 1022 has weird spacing: '...cations for ...' == Line 1030 has weird spacing: '... Coding for ...' == (3 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7492 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 176, but not defined == Missing Reference: 'ISO-MPEG2' is mentioned on line 307, but not defined == Unused Reference: 'RFC2026' is defined on line 987, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'ATSC-DAT' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'ATSC-DATG' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'ATSC-G' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: 'ATSC-PSIP-TC' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'ATSC-S' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'CLC99' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'ETSI-DAT' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBC' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBS' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBT' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'RFC3095' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'SI-DAT' is defined on line 1059, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG' -- No information found for draft-clausen-ipdvb-enc-XX - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 25 warnings (==), 4 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-01.txt Bernhard Collini-Nocker 5 University of Salzburg, A 6 Revision 1d 8 Category: Draft -Intended Standards Track October 2003 10 Ultra Lightweight Encapsulation (ULE) for transmission of 11 IP datagrams over MPEG-2/DVB networks 13 Status of this Draft 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The MPEG-2 TS has been widely accepted not only for providing 35 digital TV services, but also as a subnetwork technology for 36 building IP networks. This document describes an Ultra Lightweight 37 Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 38 Datagrams and other network protocol packets directly over ISO MPEG- 39 2 Transport Streams (TS) as TS Private Data. 41 [RFC EDITOR NOTE - 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 DRAFT -01 Text corrected. Protocol amended following discussion on 52 the list. 54 1) Padding sequence modified to 0x0000, from 0xFFFF, this change 55 aligns with other usage by MPEG-2 streams. Treatment remains the 56 same as specified for ULE. 58 2) SDNU Format updated. 60 3) Procedure added for TS Packet carrying the final part of a SNDU 61 with either less than two bytes of unused payload updated. 63 4) 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. 69 5) Payload Pointer (PP) description updated. 71 6) CRC Calculation added. 73 7) Decapsulator processing revised. 75 8) Type field split into two parts. 77 9) References updated 79 10) Security considerations added (first draft) 81 11) Appendix added with examples. 83 KNOWN ISSUES (to be addressed by WG): 84 (i) No method is mandated to select the SNDU format without MAC 85 destination address. 87 [END of RFC EDITOR NOTE] 88 Table of Contents 90 1. Introduction 91 2. Conventions used in this document 92 3. Description of method 93 4. SNDU Format 94 4.1 Destination Address Present Field 95 4.2 Length Field 96 4.3 End Indicator 97 4.4 Type Field 98 4.4.1 Type 1: IANA Assigned Type Fields 99 4.4.2 Type 2: Ethertype Compatible Type Fields 100 4.5 SNDU Destination Address Field 101 4.6 SNDU Trailer CRC 102 4.7 Description of SNDU Formats 103 4.7.1 End Indicator 104 4.7.2 IPv4 SNDU Encapsulation 105 4.7.3 IPv6 SNDU Encapsulation 106 4.7.4 Test SNDU 107 5. Processing at the Encapsulator and Receiver 108 5.1 Encapsulator processing 109 5.1.1 Flushing the Bitstream 110 5.2 Receiver Processing 111 5.2.1 Idle State 112 5.2.2 Processing of Received SNDUs 113 5.2.3 Payload Pointer Checking 114 5.3 SNDU Packing 115 5.3.1 Encapsulator Packing 116 5.3.2 Processing of Packed SNDUs at the Receiver 117 6. Summary 118 7. Acknowledgments 119 8. Security Considerations 120 9. References 121 9.1 Normative References 122 9.2 Informative References 123 10. Authors' Addresses 124 11. IANA Considerations 125 Appendix A. 127 1. Introduction 129 This document describes an encapsulation for transport of IP 130 datagrams, or other network layer packets, over ISO MPEG-2 Transport 131 Streams [ISO-MPEG]. It is suited to services based on MPEG-2, for 132 example the Digital Video Broadcast (DVB) architecture, the Advanced 133 Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other 134 similar MPEG-2 based transmission systems. Such systems typically 135 provide unidirectional (simplex) physical and link layer standards. 136 Support has been defined for a wide range of physical media (e.g. 137 Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS; 138 ATSC-S], Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). Bi- 139 directional (duplex) links may also be established using these 140 standards (e.g., DVB defines a range of return channel technologies, 141 including the use of two-way satellite links [ETSI-RCS] and dial-up 142 modem links [RFC3077]). 144 Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other 145 network layer packets) for transmission over an MPEG-2 Transport 146 Multiplex are passed to an Encapsulator. This formats each PDU into 147 a Subnetwork Data Unit (SNDU) by adding an encapsulation header and 148 an integrity check trailer. The SNDU is fragmented into a series of 149 TS Packets) that are sent over a single TS Logical Channel. 151 [Author�s NOTE: The draft describes a mechanism aimed at a subset of 152 the services supported by [DRAFT-ENC]. The format of this document 153 resembles [DRAFT-ENC]for ease of comparison and much of the 154 background text is common, although the encapsulation protocol is 155 different and more lightweight.] 156 2. Conventions used in this document 158 ADAPTATION FIELD: An optional variable-length extension field of the 159 fixed-length TS Packet header, intended to convey clock references 160 and timing and synchronization information as well as stuffing over 161 an MPEG-2 Multiplex [ISO-MPEG]. 163 AFC: Adaptation Field Control, a pair of bits carried in the TS 164 Packet header that signal the presence of the Adaptation Field 165 and/or TS Packet payload. 167 ATSC: Advanced Television Systems Committee [ATSC]. A framework and 168 a set of associated standards for the transmission of video, audio, 169 and data using the ISO MPEG-2 standard. 171 DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC]. 172 A format for transmission of data and control information defined by 173 the ISO MPEG-2 standard that is carried in an MPEG-2 Private 174 Section. 176 DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of 177 associated standards published by the European Telecommunications 178 Standards Institute (ETSI) for the transmission of video, audio, and 179 data, using the ISO MPEG-2 Standard. 181 ENCAPSULATOR: A network device that receives PDUs and formats these 182 into Payload Units (known here as SNDUs) for output as a stream of 183 TS Packets. 185 MAC: Medium Access and Control. The link layer header of the 186 Ethernet IEEE 802 standard of protocols, consisting of a 6B 187 destination address, 6B source address, and 2B type field. 189 MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A 190 scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each 191 Section is sent in a series of TS Packets using a single TS Logical 192 Channel. 194 MPEG-2: A set of standards specified by the Motion Picture Experts 195 Group (MPEG), and standardized by the International Standards 196 Organisation (ISO) [ISO-MPEG] 198 NPA: Network Point of Attachment. In this document, refers to a 6 B 199 destination address within the MPEG-2 transmission network used to 200 identify individual Receivers or groups of Receivers. 202 PDU: Protocol Data Unit. Examples of PDU include Ethernet frames, 203 IPv4 or IPv6 datagrams, and other network packets 205 PES: Programme Elementary Scheme of MPEG-2 [ISO-MPEG]. 207 PID: Packet Identifier. A field carried in the header of TS Packets. 208 This is used to identify the TS Logical Channel to which a TS Packet 209 belongs [ISO-MPEG]. The TS Packets forming the parts of a Table 210 Section, PES, or other payload unit must all carry the same PID value. 211 The all 1s PID value indicates a Null TS Packet introduced to maintain 212 a constant bit rate of a TS Multiplex. 214 PP: Payload Pointer. An optional one byte pointer that directly 215 follows the TS Packet header. It contains the number of bytes 216 between the end of the TS Packet header and the start of a Payload 217 Unit. The presence of the Payload Pointer is indicated by the value 218 of the PUSI bit in the TS Packet header. The Payload Pointer is 219 present in DSM-CC, and Table Sections, it is not present in TS 220 Logical Channels that use the PES-format. 222 PU: Payload Unit. A sequence of bytes sent using a TS. Examples of 223 Payload Units include: an MPEG-2 Table Section or a ULE SNDU. 225 PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single 226 bit flag carried in the TS Packet header. A PUSI value of zero 227 indicates that the TS Packet does not carry the start of a new 228 Payload Unit. A PUSI value of one indicates that the TS Packet does 229 carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 230 also indicates the presence of a one byte Payload Pointer (PP). 232 PRIVATE SECTION: a syntactic structure used for mapping all service 233 information (e.g. an SI table) into TS Packets. A Table may be 234 divided into a number of Table Sections, however all Table Sections 235 must be carried over a single TS Logical Channel. 237 PSI: Programme SI. An table used to convey information about the 238 service carried in a TS Multiplex. The set of PSI tables is defined 239 by [ISO-MPEG], see also SI Table. 241 SI TABLE: Service Information Table. In this document, this term 242 describes any table used to convey information about the service 243 carried in a TS Multiplex. SI tables are carried in MPEG-2 private 244 sections. 246 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 247 Payload Unit. 249 TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table. 251 TS: Transport Stream [ISO-MPEG], a method of transmission at the 252 MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI 253 reference model. See also TS Logical Channel and TS Multiplex. 255 TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel 256 identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of 257 the ISO/OSI reference model. All packets sent over a TS Logical 258 Channel carry the same PID value. According to MPEG-2, some TS 259 Logical Channels are reserved for specific signalling purposes. 260 Other standards (e.g., ATSC, DVB) also reserve specific TS Logical 261 Channels. 263 TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single 264 common physical link (i.e. a transmission at a specified symbol 265 rate, FEC setting, and transmission frequency). The same TS Logical 266 Channel may be repeated over more than one TS Multiplex, for example 267 to redistribute the same multicast content to two terrestrial TV 268 transmission cells. 270 TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex 271 [ISO-MPEG]. Operation resembles that of cell in an ATM network, and 272 may also be referred to as a TS_Cell. Each TS Packet carries a 4B 273 header, plus optional overhead including an Adaptation Field, 274 encryption details and time stamp information to synchronise a set of 275 related Transport Streams. 277 3. Description of the Method 279 PDUs (IP packets, Ethernet frames or packets from other network 280 protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). 281 The SNDU is transmitted over an MPEG-2 transmission network by 282 placing it either in the payload of a single TS Packet. If required, 283 a SNDU may be fragmented into a series of TS Packets. Where there is 284 sufficient space, the method permits a single TS Packet to carry 285 more than one SNDU (or part there of), sometimes known as Packing. 286 All TS Packets comprising a SNDU MUST be assigned the same PID, and 287 therefore form a part of the same TS Logical Channel. 289 The ULE encapsulation is limited to TS private streams only. The 290 header of each TS Packet carries a one bit Payload Unit Start 291 Indicator (PUSI) field. The PUSI identifies the start of a payload 292 unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of 293 the PUSI bit are defined differently for PES and PSI packets [ISO- 294 MPEG]; for private data, its use is not defined in the MPEG-2 295 Standard. In ULE, the operation follows that of PSI packets. Hence, 296 the following PUSI values are defined: 298 0: The TS Packet does NOT contain the start of a SNDU, but 299 contains the continuation, or end of a SNDU; 301 1: The TS Packet contains the start of a SNDU, and a one byte 302 Payload Pointer follows the last byte of the TS Packet header. 304 If a Payload Unit (SNDU) finishes before the end of a TS Packet 305 payload, but it is not convenient to start another Payload Unit, a 306 stuffing procedure fills the remainder of the TS Packet payload with 307 bytes with a value 0xFF [ISO-MPEG2], known as Padding or Stuffing. 309 A Receiver processing MPEG-2 Table Sections is aware that when it 310 receives a table_id value of 0xFF, this indicates Padding/Stuffing 311 occurred and silently discards the remainder of the TS Packet 312 payload. The payload of the next TS Packet for the same TS Logical 313 Channel will begin with a Payload Pointer of value 0x00, indicating 314 that the next Payload Unit immediately follows the TS Packet header. 315 The ULE protocol resembles this, but differs in the exact procedure 316 (see the following sections). 318 The TS Packet Header also carries a two bit Adaptation Field Control 319 (AFC) value. The purpose of the adaptation field is primarily to 320 carry timing and synchronisation information and may be used to also 321 include stuffing bytes before a TS Packet payload. Standard 322 Receivers discard TS Packets with an adaptation_field_control field 323 value of '00'. Adaptation Field stuffing is NOT used in this 324 encapsulation method, and TS packets from a ULE Encapsulator MUST be 325 sent with an AFC value of '01'. Receivers MUST discard TS Packets 326 that carry other AFC values. 328 [XXX Author's NOTE: The enc encapsulation defines how to use the AF] 329 4. SNDU Format 331 PDUs are encapsulated using ULE to form a SNDU. Each SNDU is sent as 332 an MPEG-2 Payload Unit. The encapsulation format to be used for PDUs 333 (IP packets and bridged Ethernet frames) is illustrated below: 335 .-------------------------- SNDU ---------------------------. 336 +---+---------------------------------------------------+--------+ 337 | R | Length | Type | PDU | CRC-32 | 338 +---+---------------------------------------------------+--------+ 340 Figure 1: SNDU Encapsulation 342 The Length, Type, and Destination fields are transmitted most 343 significant byte first (Appendix A provides informative examples of 344 usage). 346 4.1 Reserved Field 348 The most significant bit of the Length Field is reserved. All 349 transmitted SNDUs MUST set this to the value 0. One exception is 350 transmission of an End Indicator (see 4.3), in which this bit MUST 351 be set to the value of 1. 353 At the receiver, the value of this bit MUST be checked ignored, 354 except for the special case defined in 4.3. 356 4.2 Length Field 358 A 15-bit value that indicates the length, in bytes, of the SNDU 359 (encapsulated Ethernet frame, IP datagram or other packet) counted 360 from the byte following the type field up to and including the CRC. 361 Also note the special case described in 4.3. 363 4.3 End Indicator 365 When the first two bytes of a SNDU has the value 0xFFFF, this 366 denotes an End Indicator (i.e., all 1�s length combined with a 367 Reserved Field set to a value of 1). It indicates that there are no 368 further SNDU are present within the current TS packet (see section 369 5.1). The value 0xFF has specific semantics in MPEG-2 framing, where 370 it is used to indicate the presence of stuffing. This use resembles 371 this. 373 4.4 Type Field 375 The 16-bit Type field indicates the type of payload carried in a 376 SNDU. The set of values that may be assigned to this field is 377 divided into two parts, similar to the allocations for Ethernet. 379 Ethertypes were originally by Xerox under the DIX framework. After 380 specification of IEEE 802.3, the set of Ethertypes less than 1500, 381 assumed the role of a length indicator. Receivers use this feature 382 to discriminate LLC format frames. Hence any Ethertype <= 1500 383 indicates an LLC frame, and the actual value indicates the length of 384 the LLC frame. This mode of identification is not required in ULE, 385 since the SNDU format always carries an explicit Length Field. 386 Specification of two independent length fields is undesirable, and 387 therefore the procedure in ULE is modified, as below: 389 The first set of ULE Type Field values apply to a Type Field value 390 <= 1500. These Type Field values are IANA assigned (see 4.4.1). 392 The second set of ULE Type Field values apply to a Type Field value 393 > 1500. In ULE, this indicates that the value is identical to the 394 corresponding type codes specified by the IEEE/DIX type assignments 395 for Ethernet 397 4.4.1 Type 1: IANA Assigned Type Fields 399 The first part of the Type space corresponds to the values 0x0000 to 400 1500 Decimal. These values are assigned to an IANA registry. 402 The following types are defined: 404 [XXX IANA ACTION REQUIRED XXX] 406 0x0000: Test SNDU, discarded by the Receiver. 407 0x0001: Bridged Ethernet Frame (i.e. MAC source address follows) 408 0x0002: LLC header follows in SNDU Payload 410 [XXX END OF IANA ACTION REQUIRED XXX] 412 [Author NOTE: Type allocation and appropriate IANA Procedure 413 to be determined.] 415 4.4.2 Type 2: Ethertype compatible Type Fields 417 The second part of the Type space corresponds to the values 1500 418 Decimal and 0xFFFF. This set of type assignments follow DIX/IEEE 419 assignments (not including use of LLC) [LLC]. The following types 420 are defined in this document for part 2: 422 0x0800 : IPv4 Payload (according to IANA EtherTypes) 423 0x86DD : IPv6 Payload (according to IANA EtherTypes) 425 All other assignments in part two of this space should be coordinated 426 with the values defined for IANA EtherType encapsulations. 428 [Author Note: Suitable values for ROHC types may in future 429 need to be added] 431 4.5 SNDU Destination Address Field 433 [Author�s note: Location of the D-bit, or the use of appropriate 434 Type Field allocations within the SNDU header is still to be 435 determined by the WG] 437 The SNDU Destination Address Field is optional. 439 This field MUST be carried for IP unicast packets destined to 440 routers. A sender MAY omit this field IP unicast packet and/or 441 multicast packets delivered to Receivers that are able to utilise a 442 discriminator field (e.g. the IPv4/IPv6 destination address), which 443 in combination with the PID value, could be interpreted as a Link- 444 Level address. 446 The default SNDU format MUST carry this field, 448 When the SNDU header indicates the presence of a SNDU destination 449 address field, a Network Point of Attachment, NPA, field directly 450 follows the SNDU Type Field. NPA destination addresses are 6 B 451 numbers, normally expressed in hexadecimal, used to identify the 452 Receiver(s) that should process a received SNDU within a MPEG-2 453 transmission network. 455 4.6 SNDU Trailer CRC 457 Each SNDU MUST carry a 32-bit CRC field in the last four bytes of 458 the SNDU. This position eases CRC computation by hardware. The CRC 459 polynomial to be used is the Reverse CRC-32. The reverse order of 460 calculation (i.e. where the CRC operates on successive bytes, 461 processing the lsb of each byte first) is compatible with both a 462 hardware or software implementation. The CRC-32 is calculated 463 according to the following generator polynomial: 465 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. 467 This description may be suited for hardware implementation, but this 468 document does not imply any specific implementation. Software-based 469 table-lookup or hardware-assisted software-based implementations are 470 also possible. 472 [Author NOTE: We need to specify initial register value!!!] 474 The Encapsulator calculates a transmit value for the CRC32 including 475 all bytes from the start of the SNDU header to the end of the 476 trailer, and places this in the CRC Field. The receiver performs an 477 integrity check by independently calculating the CRC value and 478 comparing this with the transmitted value in the SNDU trailer. SNDUs 479 that do not have a valid CRC-32, are discarded. 481 The primary purpose of this CRC is to protect the SNDU payload from 482 undetected resassembly errors and errors introduced by unexpected 483 software / hardware operation while the SNDU is in transit across 484 the MPEG-2 subnetwork and during processing at the encapsulation 485 gateway and/or the receiver. It may also detect the presence of 486 uncorrected errors from the physical link (these may however, in 487 some cases, also be detected by other means). 489 4.7 Description of SNDU Formats 491 [>>> Author�s Note: The mechanism for communicating the presence of 492 the Destination Address Field (D) is to be determined by the WG. 493 Early implementers should note the default value of D is 0, 494 indicating presence of the Destination Address Field <<<] 496 The Format of a SNDU is determined by the combination of the 497 Destination Address bit (D) and the SNDU Type field. The simplest 498 encapsulation places a PDU directly into a SNDU payload. Some Type 499 1 encapsulations may require additional header fields. These are 500 inserted in the SNDU directly preceding the PDU. 502 The following SNDU Formats are defined here: 504 End Indicator: The Receiver should enter the Idle State. 506 IPv4 SNDU: The payload is a complete IPv4 datagram. 508 IPv6 SNDU: The payload is a complete IPv6 datagram. 510 Test SNDU: The payload will be discarded by the Receiver. 512 Bridged SNDU: The payload carries a bridged MAC or LLC frame. 514 All other formats are currently reserved. 516 4.7.1 End Indicator 518 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 519 |1 | 0x7FFF | 520 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 521 | | 522 = Arbitrary number of bytes >= 0 = 523 | | 524 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 526 Figure 2: SNDU Formats for an End Indicator. 528 4.7.2 IPv4 SNDU 530 IPv4 datagrams are transported using one of the two standard SNDU 531 structures, in which the PDU is placed directly in the SNDU payload. 532 The two encapsulations are shown in figures 2 and 3. 534 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 535 |R | Length (2B) | Type = 0x0800 | 536 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 537 | MAC Destination Address (6B) | 538 + +--+--+--+--+--+--+--+--+ 539 | | | 540 +--+--+--+--+--+--+--+--+ + 541 | | 542 | IPv4 datagram | 543 | | 544 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 545 | (CRC_32) | 546 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 548 Figure 3: SNDU Formats for an IPv4 Datagram using L2 filtering. 550 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 551 |R | Length (2B) | Type = 0x0800 | 552 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 553 | | 554 | IPv4 datagram | 555 | | 556 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 557 | (CRC_32) | 558 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 560 Figure 4: SNDU Formats for an IPv4 Datagram using L3 filtering. 562 4.7.3 IPv6 SNDU Encapsulation 564 IPv6 datagrams are transported using one of the two standard SNDU 565 structures, in which the PDU is placed directly in the SNDU payload. 566 The two encapsulations are shown in figures 4 and 5. 568 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 569 |R | Length (2B) | Type = 0x086DD | 570 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 571 | MAC Destination Address (6B) | 572 + +--+--+--+--+--+--+--+--+ 573 | | | 574 +--+--+--+--+--+--+--+--+ + 575 | | 576 | IPv6 datagram | 577 | | 578 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 579 | (CRC_32) | 580 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 582 Figure 5: SNDU Formats for an IPv6 Datagram using L2 filtering. 584 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 585 |R | Length (2B) | Type = 0x86DD | 586 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 587 | | 588 | IPv6 datagram | 589 | | 590 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 591 | (CRC_32) | 592 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 594 Figure 6: SNDU Formats for an IPv6 Datagram using L3 filtering. 596 4.7.4 Test SNDU 598 A Test SNDU is of Type 1 (figure 6). The structure of the Data 599 portion of this SNDU is not defined by this document. All Receivers 600 MAY record reception in a log file, but MUST then discard any Test 601 SNDUs. 603 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 604 |R | Length (2B) | Type = 0x0000 | 605 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 606 | | 607 = Data (ignored by Receivers) = 608 | | 609 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 610 | | 611 + ULE CRC-32 (4B) + 612 | | 613 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 615 Figure 7: SNDU Format for a Test SNDUs 617 4.7.5 Bridge Frame SNDU Encapsulation 619 A bridged SNDU is of Type 1. The payload includes a MAC source and 620 Ether-Type field together with the contents of a bridged MAC frame. 621 The SNDU has the format shown in figure 8. 623 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 624 |R | Length (2B) | Type = 0x0800 | 625 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 626 | MAC Destination Address (6B) | 627 + +--+--+--+--+--+--+--+--+ 628 | | | 629 +--+--+--+--+--+--+--+--+ + 630 | MAC Source Address (6B) | 631 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 632 | EtherType (2B) | | 633 +--+--+--+--+--+--+--+--+ | 634 = = 635 | (Contents of bridged MAC frame) | 636 | | 637 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 638 | | 639 + ULE CRC-32 (4B) + 640 | | 641 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 643 Figure 8: SNDU Format for a Bridged Payload 645 The MAC addresses are those specified in the frame being bridged and 646 are SHOULD be assigned according to the rules specified by the IEEE 647 and may denote unknown, unicast, broadcast, and multicast link 648 addresses. These MAC addresses denote the intended recipient in the 649 destination LAN, and therefore have a different function to the NPA 650 addresses carried in the SNDU header. The EtherType field of frame 651 is defined according to Ethernet/LLC [LLC]. 653 In normal operation, it is expected that any padding appended to the 654 Ethernet frame will be removed prior to forwarding. This requires 655 the sender to be aware of such padding. 657 Most bridged frames will also carry a Local Area Network Frame Check 658 sequence, LAN FCS, field (e.g. CRC-32 for Ethernet). The LAN-FCS 659 value of all received frames MUST be checked by the Encapsulator 660 prior to processing. Frames received with an invalid LAN FCS MUST 661 be discarded. The LAN FCS is then removed (i.e., it is NOT forwarded 662 in the bridged SNDU). As in other ULE frames, the Encapsulator 663 appends a CRC-32 to the transmitted SNDU. At the Receiver, an 664 appropriate LAN-FCS field may be appended to the bridged frame prior 665 to onward transmission. 667 This design is readily implemented using existing network interface 668 cards, and does not introduce an efficiency cost by transmitting two 669 integrity check fields for bridged frames. However, it also 670 introduces the possibility that a frame corrupted within the 671 processing performed at an Encapsulator and/or Receiver may not be 672 detected by the final recipient(s) (i.e. such corruption would not 673 normally result in an invalid LAN FCS). 675 [Author Note: Is dest address signaled by the type or by the D- 676 bit. What is required in this case? - or should D=1 signify a MPEG- 677 2 transmission network MAC + and Ethernet dst MAC? - i.e. two 678 addresses - does this have nay practical sue - e.g. In Skyplex/RCS 679 scenarios?] 680 5. Processing at the Encapsulator and Receiver 682 The Encapsulator forms the PDUs awaiting transmission into SNDUs and 683 then segments these into a series of TS Packet payloads (figure 9). 684 These are transmitted using a single TS Logical Channel over a TS 685 Multiplex. The TS Multiplex may be processed by a number of MPEG-2 686 (re)multiplexors before it is finally delivered to a Receiver. 688 +----------------------------------------------+ 689 |Encap Header| SubNetwork Data Unit | CRC-32 | 690 +----------------------------------------------+ 691 / / \ \ 692 / / \ \ 693 / / \ \ 694 +------+----------+ +------+----------+ +------+----------+ 695 |MPEG-2| MPEG-2 |... |MPEG-2| MPEG-2 |... |MPEG-2| MPEG-2 | 696 |Header| Payload | |Header| Payload | |Header| Payload | 697 +------+----------+ +------+----------+ +------+----------+ 699 Figure 9: Encapsulation of a SNDU into a series of TS Packets 701 A Receiver tunes to a specific TS Multiplex and sets a receive 702 filter to accept all TS Packets with a specific PID. These TS 703 Packets are associated with a specific TS Logical Channel and are 704 reassembled to form a stream of SNDUs. A single receiver may be 705 able to receive multiple TS Logical Channels, possibly using a range 706 of TS Multiplexes. In each case, reassembly is performed 707 independently for each TS Logical Channel. 709 5.1 Encapsulator Processing 711 The Encapsulator adds a header and trailer to each PDU to form a 712 SNDU. This SNDU is then segmented into a series of MPEG-2 TS Packets 713 belonging to the same logical TS Logical Channel. This set is sent 714 as a sequence over a TS Multiplex. 716 5.1.1 Flushing the Bitstream 718 MPEG-2 multiplexers do not usually flush their buffers, but store TS 719 Packets until the buffer fills, assuming that the data comes in a 720 more or less continuous stream. In the case of data traffic, this 721 assumption no longer holds, leading to the problem that the last IP 722 datagram will be only partly transmitted unless a special "push" TS 723 Packet is appended. This introduces additional overhead. 725 [Author Note: Do we need to specify functionality here ???] 726 5.2 Receiver Processing 728 Receipt of a TS Packet with a non-zero PUSI value indicates that the 729 TS Packet contains the start of a new SNDU. It also indicates the 730 presence of the Payload Pointer. The Payload Pointer value indicates 731 that there are Payload Pointer bytes of the SNDU currently being 732 reassembled at the start of the TS Packet payload. A Payload Pointer 733 value equal to greater than 183 is illegal in ULE, and the SNDU 734 reassembly MUST be aborted. This event SHOULD be recorded as an 735 error. 737 A Receiver reassembles SNDUs from the TS Packets received from a TS 738 Logical Channel. To perform this reassembly, the receiver may use a 739 buffer to hold the partially assembled SNDU, referred to here as the 740 Current SNDU buffer. Other implementations may choose to use other 741 data structures, but must provide equivalent operations. 743 [Author Note: Should we validate the CC field in TS Packet- or 744 ignore this. The strong CRC-32 suggests this is unnecessary, and it 745 does increase the required complexity of the (re)multiplexor - WG 746 thoughts please?] 748 5.2.1 Idle State 750 After initialisation or on receipt of an End Indicator, the Receiver 751 enters the Idle State. In this state, the Receiver discards the 752 contents of the Current SNDU buffer and waits for the start of the 753 next SNDU by waiting for a TS Packet with a PUSI value of 1. All 754 other TS Packets are discarded in this mode. 756 A PUSI value of 1, indicates the presence of a Payload Pointer. For 757 the first TS Packet received, the Payload Pointer will also have a 758 value of 0. Following a loss of synchronisation, values between 1 759 and 182 are permitted, in which case the receiver MUST discard the 760 number of bytes indicated by the Payload Pointer, before starting 761 reassembly of the next SNDU. 763 5.2.2 Processing of Received SNDUs 765 The Receiver reads the SNDU Length field from the current SNDU. If 766 this Length is less than or equal to 3, the Receiver discards the 767 Current SNDU and the remaining TS Packet payload and returns to the 768 search mode waiting for the next TS Packet with a PUSI value of 1. 770 If the Length of the Current SNDU is greater than 4, it then accepts 771 bytes from the TS Packet payload to the Current SNDU buffer until 772 either Length bytes in total are received, or the end of the TS 773 Packet is reached. When Length bytes are received, the receiver MUST 774 calculate and verify the CRC value. SNDUs that contain an invalid 775 CRC value MUST be discarded. After receiving a valid SNDU, the 776 receiver MUST check the Type Field. The SNDU payload is then passed 777 to the next protocol layer specified. An SNDU with an unknown Type 778 value MUST be discarded. This error event SHOULD be recorded in a 779 log file. 781 The receiver then starts reassembly of the next SNDU. This MAY 782 directly follow the previously reassembled SNDU within the TS Packet 783 Payload. 785 If there is either 0 or 1 byte of payload data remaining in the TS 786 Packet after completion of the Current SNDU, the receiver MUST 787 discard this remaining TS payload, and wait for the next TS Packet 788 with the PUSI value set to 1 (the Idle State). 790 If there is more than one byte of payload data remaining in the TS 791 Packet after completion of the Current SNDU, the Receiver MUST 792 accept the next bytes as the start of the next SNDU (or an End 793 Indicator), and continue with processing the next SNDU. 795 5.2.3 Payload Pointer Checking 797 An idle Receiver (i.e. one that is not currently reassembling a PDU) 798 MUST check the PUSI value in the header of all received TS Packets. 799 If it receives a TS Packet with a PUSI value of 1, and MUST discard 800 a number of bytes equal to the Payload Pointer value from the start 801 of the TS Packet payload, before it commence reassembly of a new 802 SNDU at this point. Normally, the Payload Pointer will have a value 803 of 0. 805 A Receiver that has partially received a SNDU (in the Current SNDU 806 buffer) MUST check the PUSI value in the header of all received TS 807 Packets. If it receives a TS Packet with a PUSI value of 1, it MUST 808 then verify the Payload Pointer. If the Payload Pointer does NOT 809 equal the number of bytes remaining to complete the Current SNDU, 810 i.e., the difference between the SNDU Length field and the number of 811 reassembled bytes, the Receiver has detected a delimiting error. 813 Following a delimiting error, the Receiver MUST discard the 814 partially assembled SNDU (in the Current SNDU buffer), and SHOULD 815 record a reassembly error. It MUST also discard a number of bytes 816 equal to the Payload Pointer value from the start of the TS Packet 817 payload, and commence reassembly of a new SNDU at this point. 819 5.2.4 Other Error Conditions 821 [Author Note: Should we check the MPEG-2 CC??] 823 The Receiver SHOULD also check the MPEG-2 Continuity Counter carried 824 in the TS Packet header. This value MUST be incremented by one for 825 each TS Packet sent using a TS Logical Channel. If the received 826 value does not increment by one in successive TS Packets (modulo 827 16), the Receiver has detected a continuity error. Any partially 828 received SNDU MUST be discarded. The receiver then enters a mode to 829 wait for the next TS Packet with a PUSI value of 1. 831 The Receiver SHOULD check the MPEG-2 Transport Error indicator 832 carried in the TS Packet header. This flag indicates a transmission 833 error for a TS Logical Channel. If the flag is set to a value of 834 one, an error event SHOULD be recorded. Any partially received SNDU 835 MUST be discarded. The Receiver then enters the Idle State. 837 5.3 SNDU Packing 839 When an Encapsulator has not previously sent a TS Packet for a 840 specific TS Logical Channel, or after an idle period, it starts to 841 send a SNDU in the first available TS Packet. This first TS Packet 842 generated MUST carry a PUSI value of 1. It MUST also carry a Payload 843 Pointer value of zero indicating the SNDU starts in the first 844 available byte of the TS Packet payload. 846 If the TS Packet carrying the final part of a SNDU has one byte of 847 unused payload, the Encapsulator MUST place the value 0xFF in this 848 final byte. 850 If there are at least two bytes remaining in the TS Packet payload 851 after processing the Current SNDU and further PDUs are queued at an 852 Encapsulator, it MAY append the bytes of the next SNDU directly to 853 the preceding one before segmentation (figure 9). This procedure is 854 known as Packing. If there are no further SNDUs available, an 855 Encapsulator MAY wait for additional PDUs to fill the incomplete TS 856 Packet. 858 [Author Note: Should this waiting period be bounded?] 860 +------------------+ +------------------+ 861 | Subnetwork | | Subnetwork | 862 | DU 1 | | DU 2 | 863 +------------------+ +------------------+ 864 \ \ / /\ 865 \ \ / / \ 866 \ \ / / \ 867 +------+--------+--------+----------+ 868 |MPEG-2| Payload| end of | start of | 869 |Header| Pointer| SNDU 1 | SNDU 2 | 870 +------+--------+--------+----------+ 871 | ^ 872 PUSI=1 | | 873 +--------------+ 875 Figure 10: A TS Packet with the end of SNDU 1, followed by SNDU 2 876 If an Encapsulator decides NOT to wait for another SNDU, it MUST 877 instead transmit an End Indicator directly after the end of the last 878 SNDU. This informs the Receiver that there are no more SNDUs in this 879 TS Packet payload. The End Indicator is followed by stuffing bytes 880 until the end of the TS Packet payload (figure 10). The latter 881 procedure trades decreased efficiency against improved latency. 883 +-------------+ 884 | Subnetwork | 885 | DU 3 | 886 +-------------+ 887 \ \ 888 \ \ 889 \ \ 890 +------+--------+--------+----------+ 891 |MPEG-2| End of | 0xFFFF | Unused | 892 |Header| SNDU 3 | | Bytes | 893 +------+--------+--------+----------+ 895 PUSI=0 End 896 Indicator 898 Figure 10: A TS Packet carrying the end of SNDU 3, followed by an 899 End Indicator 901 [Author Note: Should we mandate ALL stuffing bytes are 0xFF??? 902 Why?] 904 5.3.1 Encapsulator Packing 906 If more packets are waiting at the Encapsulator, and a TS Packet has 907 more than two bytes of unused payload, it MAY start the next SNDU in 908 the next available byte of the TS Packet payload. The PUSI MUST be 909 set, if not already set. When an Encapsulator packs a further SNDU 910 into an already formed TS Packet, this may require the PUSI value in 911 the TS Packet header to be updated, also requiring a Payload Pointer 912 to be inserted in the TS Packet. 914 If the PUSI is set by this operation, the 8-bit Payload Pointer MUST 915 be inserted in the first byte directly following the TS Packet 916 header. The value MUST be set to the position of the byte following 917 the end of the first SNDU in the TS Packet payload. The value 0x00 918 indicates that a SNDU starts immediately after the Payload Pointer. 920 If the TS Packet carrying the final part of a SNDU has less than two 921 bytes of unused payload, the Encapsulator MUST start transmission of 922 the next SNDU in a new TS Packet. (The standard rules require the 923 header of this new TS Packet to carry a PUSI value of 1.) This rule 924 provides a simple mechanism to resolve the complex behaviour that 925 may arise when the TS Packet has no PUSI set. In ULE, this would 926 otherwise require the addition of a Payload Pointer that would 927 consume the last remaining byte of TS Packet payload. The behaviour 928 follows similar practice for other MPEG-2 payload types. 930 When a SNDU is less than the size of a TS Packet payload, a TS 931 Packet may be formed which carries a PUSI value of one and also an 932 End Indicator. 934 5.3.2 Processing of Packed SNDUs at the Receiver 936 All Receivers MUST support the use of the Packing method for any 937 received SNDU. Use of the Packing method by an Encapsulation Gateway 938 is optional, and may be determined on a per session, per-packet, or 939 per-SNDU basis. 941 A Receiver MUST silently discard the remainder of a TS Packet 942 Payload when two or less bytes remain unprocessed following the end 943 of a SNDU, irrespective of the PUSI value in the received TS Packet. 944 It MUST NOT record an error when the value of the remaining byte(s) 945 is identical to 0xFF or 0xFFFF. The receiver MUST then enter the 946 Idle State. 948 6. Summary 950 This document defines an Ultra Lightweight Encapsulation (ULE) to 951 perform efficient and flexible support for IPv4 and IPv6 network 952 services over networks built upon the MPEG-2 Transport Stream (TS). 953 The encapsulation is also suited to transport of other protocol 954 packets and bridged Ethernet frames. 956 7. Acknowledgments 958 This draft is based on a previous draft authored by: Horst D. 959 Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry 960 Fairhurst. The authors wish to thank the members of the ip-dvb 961 mailing list for their input provided. In particular, the many 962 comments received from Patrick Cipiere, and Alain Ritoux. 964 8. Security Considerations 966 There is a known security issue with un-initialised stuffing bytes. 968 There are also a potential security issue when an encapsulation 969 permits two length fields - as in the use of bridged LLC packets. 970 The Encapsulator and Receiver MUST validate the actual length and 971 the Length field and ensure that inconsistent values are not 972 propagated by the network. 974 There are known integrity issues with the removal of the LAN FCS in 975 a bridged networking environment. The removal exposes the traffic to 976 potentially undetected corruption while being processed by the 977 Encapsulator and/or Receiver. 979 9. References 981 9.1 Normative References 983 [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic 984 coding of moving pictures and associated audio information: 985 Systems", International Standards Organisation (ISO). 987 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 988 3", BCP 9, RFC 2026, October 1996. 990 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, March 1997. 993 9.2 Informative References 995 [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television 996 Systems Committee (ATSC), Doc. A/53, 1995. 998 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 999 Systems Committee (ATSC), Doc. A/090, 26 July 00 1001 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 1002 for the ATSC Data Broadcast Standard", Advanced Television Systems 1003 Committee (ATSC),Doc. A/91. 10 June 2001 1005 [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television 1006 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1007 4 Oct 95 1009 [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for 1010 Terrestrial Broadcast and Cable", Advanced Television Systems 1011 Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A - 31 May 2000 1013 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV 1014 (DTV) Applications over Satellite", Advanced Television Systems 1015 Committee (ATSC), Doc. A/80, 17 July 99 1017 [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet 1018 over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. 1020 [DRAFT-ENC] IETF Work in Progress, draft-clausen-ipdvb-enc-XX.txt 1022 [ETSI-DAT] EN 301 192 "Specifications for Data Broadcasting", 1023 European Telecommunications Standards Institute (ETSI). 1025 [ETSI-DVBC] EN 300 800 "Digital Video Broadcasting (DVB); DVB 1026 interaction channel for Cable TV distribution systems (CATV)", 1027 European Telecommunications Standards Institute (ETSI). 1029 [ETSI-DVBS] EN 301 421 "Digital Video Broadcasting (DVB); Modulation 1030 and Coding for DBS satellite systems at 11/12 GHz", European 1031 Telecommunications Standards Institute (ETSI). 1033 [ETSI-DVBT] EN 300 744 "Digital Video Broadcasting (DVB); Framing 1034 structure, channel coding and modulation for digital terrestrial 1035 television (DVB-T)", European Telecommunications Standards Institute 1036 (ETSI). 1038 [ETSI-RCS] XXX Reference Required XXX 1040 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic 1041 coding of moving pictures and associated audio information -- Part 1042 6: Extensions for DSM-CC is a full software implementation", 1043 International Standards Organisation (ISO). 1045 [ISO-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic 1046 coding of moving pictures and associated audio information: 1047 Systems", International Standards Organisation (ISO). 1049 [LLC] "IEEE Logical Link Control" (ANSI/IEEE Std 802.2/ ISO 8802.2), 1050 1985 1052 [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link 1053 Layer Tunneling Mechanism for Unidirectional Links", RFC3077. 1055 [RFC3095] C. Bormann, et al, "RObust Header Compression (ROHC): 1056 Framework and four profiles: RTP, UDP ESP and uncompressed", 1057 RFC3095. 1059 [SI-DAT] SI-DAT group, "Second Draft DVB Specification for Data 1060 Broadcasting", Geneva, 15 Jan. 1997 1062 10.Authors' Addresses 1064 Godred Fairhurst 1065 Department of Engineering 1066 University of Aberdeen 1067 Aberdeen, AB24 3UE 1068 UK 1069 Email: gorry@erg.abdn.ac.uk 1070 Web: http://www.erg.abdn.ac.uk/users/gorry 1072 Bernhard Collini-Nocker 1073 Institute of Computer Sciences 1074 University of Salzburg 1075 Jakob Haringer Str. 2 1076 5020 Salzburg 1077 Austria 1078 Email: [bnocker]@cosy.sbg.ac.at 1079 Web: http://www.cosy.sbg.ac.at/cs/ 1081 Full Copyright Statement 1083 "Copyright (C) The Internet Society (date). All Rights Reserved. 1084 This document and translations of it may be copied and furnished to 1085 others, and derivative works that comment on or otherwise explain it 1086 or assist in its implementation may be prepared, copied, published 1087 and distributed, in whole or in part, without restriction of any 1088 kind, provided that the above copyright notice and this paragraph 1089 are included on all such copies and derivative works. However, this 1090 document itself may not be modified in any way, such as by removing 1091 the copyright notice or references to the Internet Society or other 1092 Internet organizations, except as needed for the purpose of 1093 developing Internet standards in which case the procedures for 1094 copyrights defined in the Internet Standards process must be 1095 followed, or as required to translate it into languages other than 1096 English. 1098 The limited permissions granted above are perpetual and will not be 1099 revoked by the Internet Society or its successors or assigns. 1101 11. IANA Considerations 1103 This document will require IANA involvement. 1105 The payload type field defined in this document must be aligned with 1106 an existing IANA registry or the following values need to be 1107 assigned by the IANA: 1109 Payload Type Field 1110 ANNEXE A: Informative Appendix 1112 This appendix provides some examples of use. The appendix is 1113 informative. It does not provide a description of the protocol. The 1114 examples provide the complete TS Packet sequence for some sample 1115 encapsulated IP packets. 1117 The specification of the TS Packet header operation and field values 1118 is provided in [ISO-MPEG]. The specification of ULE is provided in 1119 the body of this document. 1121 The key below is provided for the following examples. 1123 HDR 4B TS Packet Header 1124 PUSI Payload Unit Start Indicator 1125 PP Payload Pointer 1126 *** TS Packet Payload Pointer (PP) 1128 [XXX Editor note: Can someone please provide us with a hex-dump 1129 including the TS Packet headers for these examples??? XXX] 1131 Example A.1: Two 186B PDUs. 1133 SNDU A is 200 bytes (including destination MAC address) 1134 SNDU B is 200 bytes (including destination MAC address) 1136 The sequence comprises 3 TS Packets: 1138 SNDU 1139 PP=0 Length 1140 +-----+------+------+------+- -+------+ 1141 | HDR | 0x00 | 0x00 | 0xC8 | ... | A182 | 1142 +-----+----*-+-*----+------+- -+------+ 1143 PUSI=1 * * 1144 ***** 1145 SNDU 1146 PP=16 Length 1147 +-----+------+------+- -+--- --+------+------+- -+------+ 1148 | HDR | 0x10 | A183 | ... | A199 | 0x00 | 0xC0 | ... | B165 | 1149 +-----+----*-+------+- -+------+-*----+------+- -+------+ 1150 PUSI=1 * * 1151 ************************* 1153 End Stuffing 1154 Indicator Bytes 1155 +-----+------+- -+------+----+----+- -+ 1156 | HDR | B166 | ... | B199 |0xFF|0xFF| ... | 1157 +-----+------+- -+------+----+----+- -+ 1158 PUSI=0 1159 Example A.2: Usage of last byte in a TS-Packet 1161 SNDU A is 183 bytes 1162 SNDU B is 182 bytes 1163 SNDU C is 181 bytes 1164 SNDU D is 185 bytes 1166 The sequence comprises 4 TS Packets: 1168 PP=0 1169 +-----+------+------+- -+------+ 1170 | HDR | 0x00 | A000 | ... | A182 | 1171 +-----+----*-+-*----+- -+------+ 1172 PUSI=1 * * 1173 ***** 1174 Unused 1175 PP=0 byte 1176 +-----+------+------+- -+------+------+ 1177 | HDR | 0x00 | B000 | ... | B181 | 0xFF | 1178 +-----+---*--+-*----+- -+------+------+ 1179 PUSI=1 * * 1180 ****** 1182 PP=0 1183 +-----+------+------+- -+------+------+------+ 1184 | HDR | 0x00 | C000 | ... | C180 | D000 | D001 | 1185 +-----+---*--+-*----+- -+------+------+------+ 1186 PUSI=1 * * 1187 ****** Unused 1188 byte 1189 +-----+------+- -+------+------+ 1190 | HDR | D002 | ... | D184 | 0xFF | 1191 +-----+------+- -+------+------+ 1192 PUSI=0 1193 Example A.3: Large SNDUs 1195 SNDU A is 732 bytes 1196 SNDU B is 284 bytes 1198 The sequence comprises 6 TS Packets: 1200 PP=0 1201 +-----+------+------+- -+------+ 1202 | HDR | 0x00 | A000 | ... | A182 | 1203 +-----+---*--+-*----+- -+------+ 1204 PUSI=1 * * 1205 ****** 1207 +-----+------+- -+------+ 1208 | HDR | A183 | ... | A366 | 1209 +-----+------+- -+------+ 1210 PUSI=0 1212 +-----+------+- -+------+ 1213 | HDR | A367 | ... | A550 | 1214 +-----+------+- -+------+ 1215 PUSI=0 1217 PP=181 1218 +-----+------+------+- -+------+------+------+ 1219 | HDR | 0xB5 | A551 | ... | A731 | B000 | B001 | 1220 +-----+---*--+------+- -+------+*-----+------+ 1221 PUSI=1 * * 1222 ************************* 1224 +-----+------+- -+------+ 1225 | HDR | B002 | ... | B186 | 1226 +-----+------+- -+------+ 1227 PUSI=0 1229 End Stuffing 1230 Indicator Bytes 1231 +-----+------+- -+------+------+------+- -+ 1232 | HDR | B187 | ... | B283 | OxFF | 0xFF | ... | 1233 +-----+------+- -+------+------+------+- -+ 1234 PUSI=0 1235 Example A.4: Packing of SNDUs 1237 SNDU A is 200 bytes 1238 SNDU B is 60 bytes 1239 SNDU C is 60 bytes 1241 The sequence comprises two TS Packets: 1243 PP=0 SNDU A Length 1244 +-----+------+------+------+- -+------+ 1245 | HDR | 0x00 | A000 | A001 | ... | A182 | 1246 +-----+----*-+-*----+------+- -+------+ 1247 PUSI=1 * * + + 1248 ***** ++++++++ 1249 + 1250 +++++++++++++++++ 1251 + 1252 PP=17 +SNDU B Length 1253 +-----+------+------+- -+------+-+----+------+- 1254 | HDR | 0x11 | A183 | ... | A199 | B000 | B001 | ... 1255 +-----+----*-+------+- -+------+*-----+------+- 1256 PUSI=1 * * + + 1257 ************************ +++++++++ 1258 + 1259 +++++++++++++++++++++++++++++++++++ End Stuffing 1260 + SNDU C Length Indicator bytes 1261 + -+------+------+------+ -+------+------+------+- -+ 1262 + ... | B059 | C000 | C001 | ... | C059 | 0xFF | 0xFF | ... | 1263 + -+------+-+----+------+ -+------+-+----+------+- -+ 1264 + + + + + 1265 + + ++++++++ + 1266 + + + + 1267 ++++++++++++++++++ ++++++++++++++++++++++++ 1269 *** TS Packet Payload Pointer (PP) 1270 +++ ULE Length Indicator