idnits 2.17.1 draft-clausen-ipdvb-enc-01.txt: -(295): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(320): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(369): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(503): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(611): 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 7 instances 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 223 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** 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 259: '... sender, the AFC MUST be assigned in t...' RFC 2119 keyword, line 269: '... 00, and 10, MUST NOT be used for ...' RFC 2119 keyword, line 469: '... Packet MUST carry a value of o...' RFC 2119 keyword, line 475: '...he last byte of the SNDU MUST carry an...' RFC 2119 keyword, line 593: '...e last byte of a SNDU MUST always have...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 264 has weird spacing: '...sed for carry...' == Line 349 has weird spacing: '...nd Type field...' == Line 701 has weird spacing: '...cations over ...' == Line 715 has weird spacing: '... Coding for ...' == Line 725 has weird spacing: '...ensions for ...' == 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 (May 2003) is 7646 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-RCS' is mentioned on line 83, but not defined == Missing Reference: 'ETSI-DVB' is mentioned on line 129, but not defined == Missing Reference: 'DIX' is mentioned on line 369, but not defined == Unused Reference: 'ATSC-DAT' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'ATSC-DATG' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'ATSC-G' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'ATSC-PSIP-TC' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'ATSC-S' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'CLC99' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBC' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBS' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBT' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'LLC' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC3095' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'SI-DAT' is defined on line 750, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC-DAT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC-DATG' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC-G' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC-PSIP-TC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC-S' -- Possible downref: Non-RFC (?) normative reference: ref. 'CLC99' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-DAT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-DVBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-DVBS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-DVBT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-DSMCC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-VID' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-AUD' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SI-DAT' Summary: 6 errors (**), 0 flaws (~~), 22 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Horst D. Clausen 3 Internet Draft Bernhard Collini-Nocker 4 Document: draft-clausen-ipdvb-enc-01.txt Hilmar Linder 5 University of Salzburg, A 6 Gorry Fairhurst 7 University of Aberdeen, U.K. 9 Category: Draft May 2003 11 Simple Encapsulation for transmission of IP datagrams 12 over MPEG-2/DVB networks 14 Status of this Draft 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Document history 35 This draft is intended as a study item for proposed future work by 36 the IETF in this area. Comments relating to this document will be 37 gratefully received by the authors and the ip-dvb mailing list at: 38 ip-dvb@erg.abdn.ac.uk 40 Abstract 42 This document contains the Simple Encapsulation, a simple and lean 43 encapsulation mechanism for the transport of IP Datagrams over ISO 44 MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted 45 not only for providing digital TV services, but also as a subnetwork 46 technology for building IP networks. One example is the Digital Video 47 Broadcast (DVB), specified by standards published by the European 48 Telecommunications Standards Institute (ETSI). 50 Table of Contents 52 1. Introduction 53 2. Conventions used in this document 54 3. Description of method 55 4. SNDU Format 56 4.1 Bridged Payload 57 4.2 IPv4 Encapsulation 58 4.3 Ipv6 59 5. Processing at the Encapsulator and Receiver 60 5.1 Encapsulator processing 61 5.2 Flushing the bitstream 62 5.3 Receiver Processing 63 6. Summary 64 7. Acknowledgments 65 8. Security Considerations 66 9. References 67 10. Authors' Addresses 68 11. IANA Considerations 69 1. Introduction 71 This document describes an encapsulation for transport of IP 72 datagrams or other network layer packets over ISO MPEG-2 Transport 73 Streams [ISO-MPEG]. This is suited to services based on MPEG-2, for 74 example the Digital Video Broadcast (DVB) architecture, the Advanced 75 Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other 76 similar MPEG-2 based transmission systems. Such systems typically 77 provide unidirectional (simplex) physical and link layer standards, 78 and have been defined for a wide range of physical media (e.g. 79 Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS; 80 ATSC-S],Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). Bi- 81 directional (duplex) links may also be established using these 82 standards (e.g., DVB defines a range of return channel technologies, 83 including the use of two-way satellite links [ETSI-RCS] and dial-up 84 modem links [RFC3077]). 86 The service provided by a MPEG-2 transport multiplex offers a number 87 of parallel channels, which correspond to logical links (forming the 88 MPEG Transport Stream (TS)). Each MPEG-2 TS channel is uniquely 89 identified by the Packet ID (PID) value carried in the header of 90 fixed length MPEG-2 TS Packets. The PID value is a 13 bit field and, 91 thus, the number of channels is limited to 8192, some of which are 92 reserved for transmission of SI tables. Non-reserved TS logical 93 channels may be use to carry audio [ISO-AUD], video [ISO-VID], IP 94 datagrams [ISO-DSMCC;ETSI-DAT;ATSC-DAT], or other private data [ISO- 95 DSMCC;ETSI-DAT; ATSC-DAT]. 97 Data for transmission over the MPEG-2 transport multiplex is passed 98 to an encapsulator that typically receives PDUs (Ethernet 99 Frames, IP datagrams or other network layer packets). It formats 100 each PDU into a series of TS Packets (usually after adding an 101 encapsulation header), which is sent over a TS logical channel. 103 In a simple example, one or more TS logical channels are processed 104 by a MPEG-2 multiplexor resulting in a TS Multiplex. In more complex 105 examples, the same TS logical channel may be fed to multiple MPEG-2 106 multiplexors and these may, in turn, feed other MPEG-2 multiplexors 107 (remultiplexing). In all cases, the final result is a "TS Multiplex" 108 which is transmitted over the physical bearer towards the receiver. 110 2. Conventions used in this document 112 ADAPTATION FIELD: An optional variable-length extension field of the 113 fixed-length TS Packet header, intended to convey clock references 114 and timing and synchronization information as well as stuffing over 115 an MPEG-2 multiplex [ISO-MPEG]. 117 AFC: Adaptation Field Control. 119 ATSC: Advanced Television Systems Committee [ATSC]. A set of 120 framework and associated standards for the transmission of video, 121 audio, and data, using the ISO MPEG-2 standard. 123 CA: DVB Conditional Access encryption and key management scheme. 125 DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC]. 126 A formatting defined by the ISO MPEG-2 standard, which is carried in 127 an MPEG-2 private section. 129 DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and 130 associated standards for the transmission of video, audio, and data, 131 using the ISO MPEG-2 standard. 133 ENCAPSULATOR: A network device which receives PDUs (Ethernet frames 134 or IP datagrams) and formats these for output as a transport stream 135 of TS Packets. 137 FORWARD DIRECTION: The dominant direction of data transfer over a 138 network path. Data transfer in the forward direction is called 139 "forward transfer". Packets travelling in the forward direction 140 follow the forward path through the IP network. 142 MAC: Medium Access and Control of the Ethernet IEEE 802 standard of 143 protocols. 145 MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that 146 encapsulates Ethernet frames or IP Datagrams, creating a 147 DSM-CC Section. The Section will be sent in a series of TS Packets 148 over a TS logical channel. 150 MPEG-2: A set of standards specified by the Motion Picture Experts 151 Group (MPEG), and standardized by the International Standards 152 Organisation (ISO) [ISO-MPEG]. 154 PES: Programme Elementary Scheme of MPEG-2 [ISO-MPEG]. 156 PID: Packet Identifier. A field carried in the header of all MPEG-2 157 Transport Stream packets. This is used to identify the TS logical 158 channel to which it belongs [ISO-MPEG]. 160 PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A PUSI 161 value of zero indicates that the TS Packet does not carry the start 162 of a new payload. In this document, a PUSI value of one indicates 163 that the TS Packet does carry the start of a new payload. 165 REVERSE DIRECTION: The direction in which feedback control messages 166 generally flow (e.g. acknowledgments of a forward TCP transfer 167 flow). Data transfer could also happen in this direction (and it is 168 termed "reverse transfer"). 170 PRIVATE SECTION: a syntactic structure used for mapping all service 171 information (e.g. an SI table) into TS Packets. A table may be 172 divided into a number of sections. All sections of a table must be 173 carried over a single TS logical channel. 175 SI TABLE: Service Information Table. In this document, the term is 176 used to describe any table used to convey information about the 177 service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are 178 carried in MPEG-2 private sections. 180 SNDU: Subnetwork Data Unit, an IPv4 or IPv6 datagram (or other 181 subnetwork packet, e.g., an arp message or bridged Ethernet frame). 183 TS: Transport Stream [ISO-MPEG], a method of transmission at the 184 MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI 185 reference model. See also TS logical channel and TS Multiplex. 187 TS LOGICAL CHANNEL: a channel identified at the MPEG-2 level; it 188 represents level 2 of the ISO/OSI reference model. All packets sent 189 over a channel carry the same PID value 191 TS MULTIPLEX: A set of MPEG-2 transport stream channels sent over a 192 single common physical link (i.e. a transmission at a specified 193 symbol rate, FEC setting, and transmission frequency). 195 TS PACKET: A fixed-length 188B unit of data sent over an MPEG-2 196 multiplex [ISO-MPEG]; it corresponds to the cells, of e.g. ATM 197 networks, and is frequently also referred to as a TS_cell. Each TS 198 Packet carries a 4B header, plus optional overhead including an 199 adaptation field, encryption details and time stamp information to 200 synchronise a set of Transport Streams. 202 3. Description of method 204 Routed IP packets and bridged Ethernet frames shall be encapsulated 205 to form a Subnetwork Data Unit (SNDU). The method encapsulates IP 206 packets, Ethernet frames or packets from other network protocols 207 within a SNDU. The SNDU transmitted over an MPEG-2 transmission 208 system, by placing it in the payload of a single TS Packet, or, if 209 required, the SNDU may be fragmented into a series of TS Packets. 210 Where there is sufficient space, the method allows a single TS 211 Packet to carry more than one SNDU (or part there of). 213 All packets from a SNDU shall be assigned the same PID, and shall 214 therefore form a part of the same logical TS channel. 216 The method relies upon use of two fields present in the 4 byte 217 header of each TS Packet. The use of these values is intended to be 218 compatible with their use for video, audio, and other streams as 219 specified by MPEG-2 [ISO-MPEG]. 221 The header of each TS Packet carries a one bit Payload Unit Start 222 Indicator (PUSI) field whose semantics is defined for PES and PSI 223 packets; for private data its use is not defined in the MPEG-2 224 standard [The meaning of this bit for Transport Stream packets 225 carrying only private data is not defined in this Specification]. 227 In analogy with the use for PES and Section packets this bit is used 228 to identify the start of a payload unit within the MPEG-2 TS Packet 229 Payload. Hence, when used with this encapsulation, the following 230 PUSI values are defined: 232 0 - the TS Packet does not contain the start of a SNDU but the 233 continuation or end of a SNDU; 235 1 - the TS Packet contains the start of a SNDU. 237 The TS Packet Header also carries a two bit Adaptation Field Control 238 (AFC) value. The values of these two bits (adaptation field present 239 and data present) are defined by the standard 13818-1 as follows: 241 00 - Reserved for future use by ISO/IEC 242 01 - No adaptation_field, payload only 243 10 - Adaptation_field only, no payload 244 11 - Adaptation_field followed by payload 246 The usage of the adaptation field is being specified and supported 247 both by PES and Section encapsulation. It maintains a 4-byte 248 alignment of the MPEG-2 TS Packet Payload. SNDUs can be encapsulated 249 both in PES private streams, private Sections, and TS private 250 streams with the same semantics. 252 Standard decoders shall discard TS Packets with the 253 adaptation_field_control field set to a value of '00'; in the case 254 of a null packet the value of the adaptation_field_control shall be 255 set to '01'. The purpose of the adaptation field is primarily to 256 carry timing and synchronisation information and occasionally to 257 include stuffing bytes. 259 For the sender, the AFC MUST be assigned in the following way: 261 00 - Reserved for future use 262 01 - No adaptation field - only SNDU data is 263 contained in the payload field of the TS Packet 264 10 - Adaptation field only - currently not used for carrying 265 SNDU data 266 11 - Adaptation field followed by payload - the TS Packet 267 contains an adaptation field followed by SNDU data 269 00, and 10, MUST NOT be used for transport of an encapsulated SNDU. 271 The combinations 01 and 11 are obviously available for carrying SNDU 272 data, the 10 pattern indicates an extended adaptation field, but for 273 private data it is not specified how this field might be used. Hence 274 the pattern 10 might be used in the future for carrying differently 275 encapsulated datagrams. The 11 pattern is used to signal the start 276 of an SNDU that does not directly start after the Transport Stream 277 header. 279 In TS private streams, one could define the use of PUSI, AFC, and 280 adaptation field as appropriate. Such an encapsulation method 281 differs from that described here, since it is then limited to TS 282 private streams only. 284 4. SNDU Format 286 The encapsulation format to be used for IP packets and bridged 287 Ethernet frames is shown below: 289 +---------------------------------------------------+--------+ 290 | length | type | SNDU field | CRC-32 | 291 +---------------------------------------------------+--------+ 293 Figure 1: SNDU Encapsulation 295 Note that the SNDU field might include a �label� or some other form 296 of discriminator field, which in combination with the PID value, 297 could be interpreted as a �Link-Level address�. 299 Length Field 300 A 16-bit value indicates the length in bytes of the SNDU 301 (encapsulated Ethernet frame, IP datagram or other packet) counted 302 from the byte following the type field up to and including the CRC. 303 The special value 0x0000 indicates that there are no further SNDUs 304 within the current TS packet (see section 5.1). The maximum value is 305 65531 bytes. 307 Type Field 308 The 16-bit type field indicates the type of payload being sent. 309 Three types are suggested in this document. These are: 311 0x0800 : IPv4 Payload (according to IANA EtherTypes) 312 0x86DD : IPv6 Payload (according to IANA EtherTypes) 313 0x8847 : MPLS frame (according to IANA EtherTypes) 314 0x????: ROHC Compressed IPv4 Packet 315 0x????: ROHC Compressed IPv6 Packet 316 0x6558: Bridged Ethernet Frame (i.e. MAC header follows) 318 All other assignments should be coordinated with the values defined 319 for IANA EtherTypes encapsulations. 320 [Authors� note: suitable values for bridged Ethernet Frames to be 321 determined; suitable values for ROHC types to be determined] 323 IPv4 SNDU 324 The payload shall be a complete IPv4 datagram. 326 IPv6 SNDU 327 The payload shall be a complete IPv6 datagram. 329 Bridged SNDU 330 The payload shall be a bridged MAC frame (see section 4.1). 332 CRC 333 The CRC field carries a CRC value calculated by the encapsulator and 334 checked by the receiver this protects the entire SNDU. A CRC-32 is 335 recommended for SNDUs up to 12 KB in size. The primary purpose of 336 this CRC is to protect an IP payload from undetected resassembly 337 errors and errors introduced by unexpected software / hardware 338 operation at the IP encapsulation gateway and/or the receiver. It 339 may also be used to detect the presence of uncorrected errors from 340 the physical link (these however may, in some case, also be detected 341 by other means). 343 4.1 Bridged Payload 345 The Bridged Payload shall carry an SNDU field with the following 346 format shown in figure 2. 348 +-------------------------------+ 349 | Length and Type fields (4B) | 350 +-------------------------------+ 351 | MAC destination address (6B) | 352 +-------------------------------+ 353 | MAC source address (6B) | 354 +-------------------------------+ 355 | Ethernet (DIX) Type (2B) | 356 +-------------------------------+ 357 | | 358 | (remainder of MAC frame) | 359 | | 360 +-------------------------------+ 361 | CRC_32 (4B) | 362 +-------------------------------+ 364 Figure 2: SNDU Format for a Bridged Payload 366 The MAC addresses shall be assigned according to the rules specified 367 by the IEEE and may denote unknown, unicast, broadcast, and 368 multicast link addresses. The type of frame shall be defined 369 according to Ethernet [DIX]. Note that �arp messages� relate to the 370 binding of MAC addresses to IP addresses are carried in this format 371 and are identified by the appropriate DIX Ethernet frame type. 373 In normal operation, it is expected that any padding appended to the 374 Ethernet frame will be removed prior to forwarding. This requires the 375 sender to be aware of such padding. 377 32-bit CRC 378 The LAN FCS field, is in this case not forwarded by the 379 encapsulation, and is replaced by a CRC-32 calculated by the IP 380 encapsulator. Note: It is assumed the LAN FCS is checked prior to 381 removal. 383 4.2 IPv4 Encapsulation 384 IPv4 datagrams will be transported over the MPEG-2 Transport Stream 385 using the SNDU structure shown in figure 3. 387 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 388 | Length (2B) | Type = 0x0800 | 389 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 390 | | 391 | IPv4 datagram | 392 | | 393 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 394 | (CRC_32) | 395 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 397 Figure 3: SNDU Format for an IPv4 Datagram 399 4.3 IPv6 Encapsulation 401 IPv6 datagrams will be transported over the MPEG-2 Transport Stream 402 using the SNDU structure shown in figure 4. 404 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 405 | Length (2B) | Type = 0x86DD | 406 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 407 | | 408 | IPv6 datagram | 409 | | 410 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 411 | (CRC_32) | 412 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 414 Figure 4: SNDU Format for an IPv6 Datagram 415 5. Processing at the Encapsulator and Receiver 417 5.1 Encapsulator processing 419 The encapsulator shall fragment the SNDU into a series of MPEG-2 TS 420 Packets belonging to the same logical TS channel (figure 5). 422 +-----------------------------------------+ 423 |Encap Header| Subnetwork PU | 424 +-----------------------------------------+ 425 / / \ \ 426 / / \ \ 427 / / \ \ 428 +------*----------* +------*----------* +------*----------+ 429 |MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 | 430 |Header| Payload | |Header| Payload | |Header| Payload | 431 +------+----------+ +------+----------+ +------+----------+ 433 Figure 5: Encapsulation of a subnetwork Payload_Unit (SNDU) e.g. an 434 IP datagram into a series of TS Packets (each TS Packet carries a 435 header with a common Packet ID, PID, value). 437 The encapsulation layer will first wrap each payload unit (IP 438 datagram or Ethernet frame) to form a SNDU. (This is similar to an 439 AAL5 encapsulation in ATM networks). This SNDU will then be 440 segmented into payload units of TS Packets; the resulting set of TS 441 Packets will all use the same PID value and successive values for 442 the continuation counter. This set will then be sent as a sequence 443 over a TS multiplex or possibly as one burst over a satellite link. 445 Measurements of IP traffic have shown that the overwhelming majority 446 of the datagrams have lengths of 1500 or 576 bytes for data and 40 447 or 48 bytes for control traffic; for example, these values represent 448 almost 96% of the typical world-wide-web traffic. 450 The most frequent situations for the encapsulator are: 451 - a short control packet using only a fraction of the 452 TS payload of 184 bytes; 453 - a long data packet using a number of TS Packets with 454 the last one containing only a remainder. 455 Both of the most frequent values (576 and 1500) lead 456 to a fairly high overhead in the last TS Packet. 458 Since satellite bandwidth is an expensive resource, as opposed to 459 bandwidth in LANs, it is necessary to look for improvements. One 460 possibility is header compression but this is outside the scope of 461 this proposal. Another one is to pack SNDUs densely into TS Packets, 462 i.e. whenever the encapsulator has more than one SNDU available it 463 fills the TS Packets completely by appending the data of the 464 following SNDU directly to the preceding one before segmentation. 466 When the encapsulator has not previously sent a TS Packet for the 467 specified logical TS channel, or after an idle period, it will start 468 sending the SNDU in the first available TS Packet. This first TS 469 Packet MUST carry a value of one in the payload_unit_start_indicator 470 (PUSI) to indicate it contains the start of a SNDU. 472 The encapsulator will continue to fill subsequent TS Packets, until 473 the end of the SNDU. 475 The TS Packet that carries the last byte of the SNDU MUST carry an 476 adaptation field. This implies that the last packet contains an 477 MPEG-2 adaptation field. Note that a packet sufficiently small to 478 fit into one TS Packet will carry both a PUSI value of one and an 479 AFC value of 11 (see below). 481 If more packets are waiting at the encapsulator, it may start the 482 next SNDU in the next available byte of the TS Packet payload. (The 483 PUSI is set, if it is not already set). If this is the final packet 484 of a burst (i.e., there are no additional packets waiting), the 485 encapsulator becomes idle. 487 The adaptation field is either a single byte set to 0 (defined by 488 the 13818-1 standard) or it has the structure specified by the 489 standard recommendations (figure 6). 491 0 7 8 15 16 31 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 |ad.hdr.length=3| flags 1 | priv.length=1 | pointer | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 ^ 496 transport_private_data_flag 498 Figure 6: Adaptation FIELD Format 500 For this encapsulation the adaptation header length is always 4 501 bytes, hence the value of the first byte must be 3. The second byte 502 is required by the standard and contains various flags; only bit 7 503 (�transport_private_data_flag�) will be set to �1� indicating 504 private data. This requires in the next byte the length of the 505 private data, here the value of 1, and in the next byte the private 506 data which is to be a pointer to the start of the next SNDU or the 507 value of zero in case no further SNDU follows in this TS Packet. 509 Adding 4 bytes instead of the required one or two bytes adds 510 overhead but does not destroy the 16/32 bit alignment of the data 511 which may be important for performance. 513 The type field of the encapsulation format together with the 514 transport_private_data_flag in the adaptation field can be used to 515 construct an encapsulation that supports MPLS switching (e.g. type 516 field must be set to 0x8847 (see section 4), 517 transport_private_data_flag set to 1 and the private length byte in 518 the adaptation field specifies the length of a MPLS header (a value 519 of 5 which means that the adaptation field contains an MPLS header 520 followed by a one byte pointer field). 522 The operation of the Adaptation Field Control (AFC) bits and the 523 PUSI bits in the TS Packet Header may be summarised as follows: 525 PUSI AFC Meaning 527 1 01 first byte of a SNDU payload_unit is in the payload 528 of this TS Packet 529 0 01 payload of this TS Packet does not contain the start 530 of a new payload_unit, but is a continuation 531 0 11 this TS Packet contains the end of a payload_unit 532 1 11 this TS Packet contains the end of a payload_unit which 533 is followed by the first byte of a new payload_unit 535 The use of the AFC bits is mandatory for the operation of the 536 receiver to find the beginning of an SNDU in two cases when a SNDU 537 starts not right after the TS packet header although the PUSI flag 538 is set (indicating a new SNDU in this respective TS packet). 540 The first case occurs, when a SNDU is smaller than the TS packet 541 payload length and stuffing bytes are used. 543 +-------------------+ 544 |Encap | Subnetwork | 545 |Header| PU | 546 +-------------------+ 547 \ / 548 \ / 549 \ / 550 +------*--------*--------------+------------+ 551 |MPEG-2| Adapt. | Stuffing | SNDU | 552 |Header| Header | bytes | | 553 +------+--------+--------------+------------+ 555 Figure 7: Stuffing using the Adaptation Field 557 In this case the PUSI/AFC combination 1/11 indicates that the SNDU 558 header starts after the adaptation field. 560 The second case occurs when the remaining bytes of an SNDU are 561 carried together with (the start of) a new SNDU in one TS packet. 563 +------------------+ +------------------+ 564 | Subnetwork | | Subnetwork | 565 | DU 1 | | DU 2 | 566 +------------------+ +------------------+ 567 \ \ / / 568 \ \ / / 569 \ \ / / 570 +------*--------*--------+----------+ 571 |MPEG-2| Adapt. | end of | start of | 572 |Header| Header | SNDU 1 | SNDU 2 | 573 +------+--------+--------+----------+ 575 Figure 8: Packing using the Adaptation FIELD 577 The presence of the adaptation field (PUSI/AFC combination 1/11) 578 guarantees that the receiver does not interpret the end of SNDU 1 as 579 start of SNDU 2, hence failing reassembly. This case is likely to 580 occur during the tuning and synchronisation phase of a receiver, 581 when a number of consecutive 0x47 flags are searched and the 582 receiver locks to the data signal. If only the length field of SNDU 583 1 indicated the start of SNDU 2, the receiver would not know this 584 and would consider the PUSI set to 1 as a start of SNDU 2 directly 585 following the TS Packet header. The adaptation field length 586 therefore allows the start of SNDU 2 to be calculated. 588 In general the PUSI/AFC combinations of 1/01 and 0/01 indicate that 589 a TS Packet contains 184 bytes of the SNDU. The combinations 0/11 590 and 1/11 indicate an adaptation header of length 4, leaving 180 591 bytes for SNDU data. 593 The TS Packet that carries the last byte of a SNDU MUST always have 594 an adaptation field (1/11 PUSI/AFC) when one or more SNDUs are 595 following. Note that once the position and length of the first SNDU 596 starting in a particular Transport Stream packet is known, 597 subsequent SNDUs can follow without the need of another pointer. 599 In case the SNDU or its final portion exactly fits into one TS 600 Packet no adaptation field (0/00 PUSI/AFC) shall be used. 602 When there are no more SNDUs ready for encapsulation the TS Packet 603 (0/01 PUSI/AFC) shall be padded with stuffing bytes of value FF. 605 5.2 Flushing the bitstream 607 MPEG-2 multiplexers do not usually flush their buffers, but store TS 608 Packets until the buffer fills, assuming that the data comes in a 609 more or less continuous stream. In the case of data traffic, this 610 assumption no longer holds, leading to the problem that the last IP 611 datagram will be only partly transmitted unless a special �push� 612 packet is appended. This introduces additional overhead and is not 613 an appealing solution. 615 A further SNDU within the same TS Packet is only started if it is 616 already available in the encapsulator�s buffer at the time the 617 previous one is encapsulated. The encapsulator does not wait for 618 another SNDU to fill a TS Packet, because this would introduce 619 additional latency. 621 5.3 Receiver Processing 623 A receiver reassembles SNDUs from the TS Packets received from a 624 logical TS channel. The receiver determines the start of the first 625 SNDU by waiting for a TS Packet with a PUSI value of 1. 627 The receiver identifies the end of the SNDU by interpreting the 628 PUSI/AFC bits and the information in the adaptation fields and by 629 keeping a record of the total number of bytes received since the 630 start of the current SNDU and comparing this value with the SNDU 631 length field. 633 The CRC MUST be calculated and verified. SNDUs that contain an 634 invalid CRC MUST be discarded. 636 Receipt of a non-zero PUSI value also indicates that the TS Packet 637 contains the start of a new SNDU. If the receiver has not completed 638 the current SNDU, and the Length Field indicates that it is awaiting 639 a greater number of bytes than one less the adaptation header 640 length, then the receiver has detected a delimiting error. The 641 partially received SNDU MUST be discarded. 643 The receiver MUST also check the MPEG-2 Continuity Counter carried 644 in the TS Packet Header. This counter should increment by one for 645 each TS Packet received on a logical TS channel. If the value is not 646 incremented by one in successive packets (modulo 16), any partially 647 received SNDU MUST be discarded. The receiver then waits for the 648 next TS Packet with a PUSI value of 1. 650 The receiver MUST also check the MPEG-2 Transport Error indicator 651 carried in the TS Packet Header. This flag indicates a transmission 652 error for the logical TS channel. If the flag is set to a one, any 653 partially received SNDU MUST be discarded. The receiver then waits 654 for the next TS Packet with a PUSI value of 1. 656 After receiving a valid SNDU, the receiver MUST check the Type 657 Field. The SNDU payload is then passed to the next protocol layer 658 specified. An SNDU with an unknown Type value MUST be discarded. 660 The receiver then starts reassembly of the next SNDU. This may 661 directly follow the previously reassembled SNDU within the TS Packet 662 Payload. 664 6. Summary 666 This document defines a Simple Encapsulation to perform efficient 667 and flexible support for IPv4 and IPv6 network services over 668 networks built upon the MPEG-2 Transport Stream (TS). 670 7. Acknowledgments 672 The authors wish to thank the members of the ip-dvb mailing list 673 (ip-dvb@erg.abdn.ac.uk) for the input provided. In particular, we 674 thank the many comments received from Patrick Cipiere, 676 8. Security Considerations 678 Security issues are not addressed in this document. 680 9. References 682 [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television 683 Systems Committee (ATSC), Doc. A/53, 1995. 685 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 686 Systems Committee (ATSC), Doc. A/090, 26 July 00 688 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 689 for the ATSC Data Broadcast Standard", Advanced Television Systems 690 Committee (ATSC),Doc. A/91. 10 June 2001 692 [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television 693 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 694 4 Oct 95 696 [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for 697 Terrestrial Broadcast and Cable", Advanced Television Systems 698 Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A - 31 May 2000 700 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV 701 (DTV) Applications over Satellite", Advanced Television Systems 702 Committee (ATSC), Doc. A/80, 17 July 99 704 [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet 705 over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. 707 [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European 708 Telecommunications Standards Institute (ETSI). 710 [ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB 711 interaction channel for Cable TV distribution systems (CATV), 712 European Telecommunications Standards Institute (ETSI). 714 [ETSI-DVBS] EN 301 421 Digital Video Broadcasting (DVB); Modulation 715 and Coding for DBS satellite systems at 11/12 GHz, European 716 Telecommunications Standards Institute (ETSI). 718 [ETSI-DVBT] EN 300 744 Digital Video Broadcasting (DVB); Framing 719 structure, channel coding and modulation for digital terrestrial 720 television (DVB-T), European Telecommunications Standards Institute 721 (ETSI). 723 [ISO-DSMCC] ISO/IEC IS 13818-6 Information technology -- Generic 724 coding of moving pictures and associated audio information -- Part 725 6: Extensions for DSM-CC is a full software implementation, 726 International Standards Organisation (ISO). 728 [ISO-MPEG] ISO/IEC DIS 13818-1 Information technology -- Generic 729 coding of moving pictures and associated audio information: Systems, 730 International Standards Organisation (ISO). 732 [ISO-VID] ISO/IEC DIS 13818-2 Information technology -- Generic 733 coding of moving pictures and associated audio information: Video, 734 International Standards Organisation (ISO). 736 [ISO-AUD] ISO/IEC 13818-3:1995 Information technology -- Generic 737 coding of moving pictures and associated audio information -- Part 738 3: Audio, International Standards Organisation (ISO). 740 [LLC] IEEE Logical Link Control (ANSI/IEEE Std 802.2/ ISO 8802.2), 741 1985 743 [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link 744 Layer Tunneling Mechanism for Unidirectional Links", RFC3077. 746 [RFC3095] C. Bormann, et al, "RObust Header Compression (ROHC): 747 Framework and four profiles: RTP, UDP ESP and uncompressed", 748 RFC3095. 750 [SI-DAT] SI-DAT group, "Second Draft DVB Specification for Data 751 Broadcasting", Geneva, 15 Jan. 1997 753 10.Authors' Addresses 755 Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder 756 Institute of Computer Sciences 757 University of Salzburg 758 Jakob Haringer Str. 2 759 5020 Salzburg 760 Austria 761 Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at 762 Web: http://www.cosy.sbg.ac.at/cs/ 764 Godred Fairhurst 765 Department of Engineering 766 University of Aberdeen 767 Aberdeen, AB24 3UE 768 UK 769 Email: gorry@erg.abdn.ac.uk 770 Web: http://www.erg.abdn.ac.uk/users/gorry 772 Full Copyright Statement 774 "Copyright (C) The Internet Society (date). All Rights Reserved. 775 This document and translations of it may be copied and furnished to 776 others, and derivative works that comment on or otherwise explain it 777 or assist in its implementation may be prepared, copied, published 778 and distributed, in whole or in part, without restriction of any 779 kind, provided that the above copyright notice and this paragraph 780 are included on all such copies and derivative works. However, this 781 document itself may not be modified in any way, such as by removing 782 the copyright notice or references to the Internet Society or other 783 Internet organizations, except as needed for the purpose of 784 developing Internet standards in which case the procedures for 785 copyrights defined in the Internet Standards process must be 786 followed, or as required to translate it into languages other than 787 English. 789 The limited permissions granted above are perpetual and will not be 790 revoked by the Internet Society or its successors or assigns. 792 11. IANA Considerations 794 This document will require IANA involvement. 796 The payload type field defined in this document must be aligned with 797 an existing IANA registry or the following values need to be 798 assigned by the IANA: 800 Payload Type Field