idnits 2.17.1 draft-ietf-ipdvb-ule-ext-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 686. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in 'Category: WG Draft intended for PS', 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 (June 2007) is 6132 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'GSE' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gorry Fairhurst 2 Internet Draft University of Aberdeen 3 Expires November 2007 B. Collini-Nocker 4 University of Salzburg 6 Category: WG Draft intended for PS June 2007 8 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) 9 and the Generic Stream Encapsulation (GSE) 10 draft-ietf-ipdvb-ule-ext-03.txt 12 Status of this Draft 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a set of Extension Headers for the 35 Unidirectional Lightweight Encapsulation (ULE), RFC4326. 37 The Extension Header formats defined in this document define new 38 extensions that are common extensions to both ULE and the Generic 39 Stream Encapsulation (GSE) defined to support the second generation 40 framing structure defined by Digital Video Broadcasting (DVB) family 41 of specifications. 43 Table of Contents 45 1. Introduction 47 2. Conventions used in this document 49 3. Description of method 50 3.1 MPEG-2 TS-Concat Extension 51 3.2 PDU-Concat Extension 52 3.3 TimeStamp Extension 54 4. IANA Considerations 56 5. Acknowledgements 58 6. Security Considerations 60 7. References 61 7.1 Normative References 62 7.2 Informative References 64 8. Authors' Addresses 66 9. IPR Notices 67 9.1 Intellectual Property Statement 68 9.2 Disclaimer of Validity 70 10. Copyright Statement 72 Appendix: The Second Generation DVB Transmission Specifications 73 1. Introduction 75 This document describes three Header Extensions that may be used 76 with both Unidirectional Lightweight Encapsulation, ULE, [RFC4326] 77 and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for 78 links that employ the MPEG-2 Transport Stream, and supports a wide 79 variety of physical-layer bearers [RFC4259]. 81 GSE has been designed for the Generic Mode (also known as the 82 Generic Stream (GS)), offered by second-generation DVB physical 83 layers, and in the first instance for DVB-S2 [ETSI-S2]. The 84 requirements for the Generic Stream are described in [ID-S2-REQ]. 85 The important characteristics of this encapsulation are described in 86 an Appendix to this document. GSE maintains a design philosophy that 87 presents a common network interface to that of ULE and uses a 88 similar construction for Subnetwork Data Unit (SNDUs). 90 The first Extension Header defines a method that allows one or more 91 TS-Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may 92 be used to provide control plane information including the 93 transmission of MPEG-2 Program Specific Information (PSI) for the 94 Multiplex. In GSE, there is no native support for transport stream 95 packets and this method is therefore suitable for providing an MPEG- 96 2 control plane. 98 A second Extension Header allows one or more PDUs to be sent within 99 the same ULE SNDU. This method is designed for cases where a large 100 number of small PDUs are directed to the same Network Point of 101 Attachment (NPA) address. The method may improve transmission 102 efficiency (by removing duplicated MAC layer overhead). It can also 103 reduce processing overhead for receivers that are not addressed by 104 the NPA, since these receivers may then skip several PDUs in one 105 operation. The method is defined as a generic Extension Header and 106 may be used for IPv4 or IPv6 packets. If and when a compression 107 format is defined for ULE or Ethernet, the method may also be used 108 in combination with this method. 110 A third Extension Header provides an optional timestamp value for an 111 SNDU. Examples of the use of this timestamp option include 112 monitoring and benchmarking of ULE and GSE links. Receivers that do 113 not wish to decode (or do not support) the timestamp extension may 114 discard the extension and process the remaining PDU or Extension 115 Headers. 117 An appendix includes a summary of key design issues and 118 considerations based on the GSE Specification defined by the DVB 119 Technical Module [GSE]. 121 2. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 124 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 RFC 2119 [RFC2119]. 128 b: bit. For example, one byte consists of 8b. 130 B: Byte. Groups of bytes are represented in Internet byte order. 132 BBFrame payload [ETSI-S2]: The data field part of a Baseband frame 133 that may be used for the communication of data. Typical BBFrames 134 range in size from 3072 to 58192 bits according to the choice of 135 modulation format and FEC in use. 137 DVB: Digital Video Broadcasting. A framework and set of 138 associated standards published by the European Telecommunications 139 Standards Institute (ETSI) for the transmission of video, audio, and 140 data. 142 E: A one-bit flag field defined in [GSE]. 144 Encapsulator: A network device that receives PDUs and formats these 145 in to Payload Units (known here as SNDUs) for output in DVB-S or the 146 Generic Mode of DVB-S2. 148 GS: Generic Stream [ETSI-S2]. A stream of BBFrames identified by a 149 common Input Stream Identifier, and which does not use the MPEG-2 TS 150 format. 152 GSE: Generic Stream Encapsulation [GSE]. A method that encapsulates 153 PDUs that form a Generic Stream, which is sent using a sequence of 154 BBFrames. This encapsulation format shares the same extension 155 format, and basic processing rules of ULE and uses a common IANA 156 Registry. 158 LT: A two-bit flag field defined in [GSE]. 160 MAC: Medium Access Control [IEEE-802.3]. A link layer protocol 161 defined by the IEEE 802.3 standard (or by Ethernet v2). 163 MPEG-2: A set of standards specified by the Motion Picture Experts 164 Group (MPEG), and standardized by the International Standards 165 Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). 167 Next-Header: A Type value indicating an Extension Header [RFC4326]. 169 NPA: Network Point of Attachment [RFC4326]. In this document, refers 170 to a destination address (resembling an IEEE MAC address) within the 171 DVB-S/S2 transmission network that is used to identify individual 172 Receivers or groups of Receivers. 174 PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the 175 header of each TS Packet. This identifies the TS Logical Channel to 176 which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the 177 parts of a Table Section, or other Payload Unit must all carry the 178 same PID value. The all ones PID value indicates a Null TS Packet 179 introduced to maintain a constant bit rate of a TS Multiplex. There 180 is no required relationship between the PID values used for TS 181 Logical Channels transmitted using different TS Multiplexes. 183 PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include 184 Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. 186 PSI: Program Specific Information [ISO-MPEG2]. 188 S: A one-bit flag field defined in [GSE]. 190 SI Table: Service Information Table [ISO-MPEG2]. In this document, 191 this term describes a table that is been defined by another 192 standards body to convey information about the services carried on a 193 DVB Multiplex. 195 SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an 196 encapsulated PDU sent using ULE or GSE. 198 Stream: A logical flow from an Encapsulator to a set of Receivers. 200 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 201 MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 202 reference model. 204 ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A 205 method that encapsulates PDUs, into SNDUs that are sent in a series 206 of TS Packets using a single TS Logical Channel. The encapsulation 207 defines an extension format and an associated IANA Registry. 209 3. Description of the Method 211 In ULE, a Type field value that is less than 1536 Decimal indicates 212 an Extension Header. This section describes a set of two extension 213 formats for the ULE encapsulation. The GSE [GSE] follows the same 214 format as used in the ULE Type field. The encapsulation format 215 differs in that GSE does not include a per-SNDU CRC, has different 216 header flags, and utilises a different SNDU length calculation 217 [GSE]. 219 There is a natural ordering of Extension Headers, which is 220 determined by the fields that they are associated with. A suitable 221 ordering for many applications is presented in the list below (from 222 first to last header within an SNDU). This does not imply that all 223 types of Extensions should be present in a single SNDU. The 224 presented ordering may serve as a guideline for optimisation of 225 Receiver processing. 227 +----------------------------------+-------------------------------+ 228 |Fields related to Extension Header| Example Extension Headers | 229 +----------------------------------+-------------------------------+ 230 | Link framing and transmission | Timestamp Extension | 231 +----------------------------------+-------------------------------+ 232 | Entire remaining SNDU Payload | Encryption Extension | 233 +----------------------------------+-------------------------------+ 234 | Group of encapsulated PDUs | PDU-Concat or TS-Concat | 235 +-----------------------------------+------------------------------+ 236 | Specific encapsulated PDU | IEEE-defined type | 237 | | Test or MAC bridging Extension| 238 +-----------------------------------+------------------------------+ 240 Table 1: Recommended ordering of Extension Headers 242 3.1 MPEG-2 TS-Concat Extension 244 The MPEG-2 TS-Concat Extension Header is specified by an IANA 245 assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory 246 Next-Header Extension. 248 The extension is used to transport one or more MPEG-2 TS Packets 249 within a ULE SNDU. The number of TS Packets carried in a specific 250 SNDU is determined from the size of the remainder of the payload 251 following the MPEG-2 TS Extension Header. The number of TS Packets 252 contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N 253 is the number of bytes associated with Extension Headers that 254 precede the MPEG-2 TS-Concat Extension (zero if there are none). 256 A Receiver MUST check that the validity of the value of the payload 257 Length prior to processing. Any mismatch (remainder from the 258 division) MUST result in discard of all encapsulated PDUs and SHOULD 259 be recorded as TS-Concat size mismatch error. 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |0| Length (15b) | Type = 0x0002 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Receiver Destination NPA Address (6B) | 266 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 269 | TS-Packet 1 | 270 = = 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | TS-Packet 2 (if Length > 2*188) | 274 = = 275 | etc. | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | (CRC-32) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) 282 Figure 1 illustrates the format of this Extension Header for ULE 283 with a value D=0, which indicates the presence of a NPA address 284 [RFC4326]. In this case, the valid payload Length for a ULE SNDU 285 with no other extensions is (Length-10) / 188. 287 The method used to define the Length in GSE differs to that of ULE. 288 The equivalent case for GSE would result in a payload Length value 289 of (Length-6) / 188 (Figure 2). 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |S|E|0 0| Length (12b) | Type = 0x0002 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Receiver Destination NPA Address (6B) | 296 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 299 | TS-Packet 1 | 300 = = 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | TS-Packet 2 (if Length > 2*188) | 304 = = 305 | etc. | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00) 309 Fragmented GSE SNDUs are protected by a CRC-32 carried in the final 310 fragment. The fields labelled S and E are defined by [GSE} and 311 contains control flags used by the GSE link layer. The Label Type 312 field (LT) specifies the presence and format of the GSE label. 314 In ULE, a value of D=1, is also permitted and indicates the absence 315 of a NPA address (Figure 3). A similar format is supported in GSE. 317 0 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |1| Length (15b) | Type = 0x0002 | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | TS-Packet 1 | 323 = = 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | TS-Packet 2 (if Length > 2*188) | 327 = = 328 | etc. | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | (CRC-32) | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) 335 This extension may be used to transport one or more MPEG-2 TS 336 Packets of arbitrary content, interpreted according to [ISO-MPEG2]. 337 One expected use is for the transmission of MPEG-2 SI/PSI 338 signalling. 340 Null TS Packets are not normally sent using this encapsulation. To 341 reduce transmission overhead and processing, an Encapsulator SHOULD 342 specify a maximum period of time that it can wait before sending all 343 queued TS Packets. This is known as the TS Packing Threshold. This 344 value MUST be bounded and SHOULD be configurable in the 345 Encapsulator. A larger value can improve efficiency, but incurs 346 higher jitter and could increase the probability of corruption. If 347 additional TS Packets are NOT received within the TS Packing 348 Threshold, the Encapsulator MUST immediately send any queued TS 349 Packets. 351 The use of this format to transfer MPEG-2 clock references (e.g. a 352 Network Clock Reference, NCR, SI Table) over ULE/GSE framing raises 353 timing considerations at the encapsulation gateway, including the 354 need to update/modify the timing information prior to transmission 355 by the physical layer. These issues are not considered here, but 356 this operation may be simplified in GSE by ensuring that all SNDUs 357 that carry this Extension Header are placed before other data within 358 the BBFrame DataField [GSE]. 360 This document does not specify how TS Packets are to be handled at 361 the Receiver, however it notes that a poorly configured Encapsulator 362 could lead to a Multiplex carrying multiple (possibly conflicting) 363 sets of TS Logical Channels and SI information encapsulated at 364 different levels or with different NPA addresses. The need for 365 consistency in the use of PIDs and the related SI information is 366 described in [RFCxARx]. 368 3.2 PDU-Concat Extension 370 The PDU-Concat Extension Header is specified by an IANA assigned H- 371 Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header 372 Extension. It enables a sequence of (usually short) PDUs to be sent 373 within a single SNDU payload. 375 The base header contains the Length of the entire SNDU. This carries 376 the value of the combined length of all PDUs to be encapsulated, 377 including each set of encapsulation headers. The base header MAY be 378 followed by one or more additional Extension Headers that precede 379 the PDU-Concat Extension Header. These Extension Headers (e.g. a 380 TimeStamp Extension) apply to the composite concatenated PDU. 382 The Extension Header also contains a 16-bit ULE Type field 383 describing the encapsulated PDU, CONCAT-PDU-Type. Although any Type 384 value specified in the ULE Next-Header Registry (including Extension 385 Header Types) may be assigned to the encapsulated PDU (except the 386 recursive use of a PDU-Concat type), all concatenated PDUs MUST have 387 a common ULE Type (i.e. all concatenated PDUs passed by the network 388 layer must be associated with the same Type value). This simplifies 389 the receiver design, and reduces the transmission overhead for 390 common use cases. 392 Each PDU is prefixed by its length in bytes (shown as PDU-Length in 393 the following diagrams). Encapsulated PDUs are of arbitrary length 394 (in bytes) and are not necessarily aligned to 16-bit or 32-bit 395 boundaries within the SNDU (as shown in the figure). The most 396 significant bit of the first byte is reserved, R, and this 397 specification requires that this MUST be set to zero. The length of 398 each PDU MUST be less than 32758 bytes, but will generally be much 399 smaller. 401 When the SNDU header indicates the presence of an SNDU Destination 402 Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA, 403 field directly follows the fourth byte of the SNDU header. NPA 404 destination addresses are 6 Byte numbers, normally expressed in 405 hexadecimal, used to identify the Receiver(s) in a transmission 406 network that should process a received SNDU. When present the 407 Receiver MUST associate the same specified MAC/NPA address with all 408 PDUs within the SNDU Payload. This MAC/NPA address MUST also be 409 forwarded with each PDU, if required by the forwarding interface. 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |0| Length (15b) | Type = 0x0003 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Receiver Destination NPA Address (6B) | 416 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | CONCAT-PDU-Type | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |R| PDU-Length-1 (15b) | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 421 = PDU-1 = 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |R| PDU-Length-2 (15b) | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 426 = PDU-2 = 427 | | 428 More PDUs as required 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | (CRC-32) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) 436 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 |S|E|0 0| Length (12b) | Type = 0x0003 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Receiver Destination NPA Address (6B) | 441 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | | CONCAT-PDU-Type | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |R| PDU-Length-1 (15b) | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 446 = PDU-1 = 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |R| PDU-Length-2 (15b) | | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 451 = PDU-2 = 452 | | 453 More PDUs as required 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_ 458 The value of D in the ULE header indicates whether a NPA/MAC address 459 is in use [RFC4326]. A similar format is supported in GSE. 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 |1| Length (15b) | Type = 0x0003 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | CONCAT-PDU-Type |R| PDU-Length-1 (15b) | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 = PDU-1 = 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 |R| PDU-Length-2 (15b) | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 472 = PDU-2 = 473 | | 474 More PDUs as required 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | (CRC-32) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) 482 To reduce transmission overhead and processing, an Encapsulator 483 SHOULD specify a maximum period of time it will wait before sending 484 a Concatenated PDU. This is known as the PDU Packing Threshold. This 485 value MUST be bounded and SHOULD be configurable in the 486 Encapsulator. A larger value can improve efficiency, but incurs 487 higher jitter and could increase the probability of corruption. If 488 additional PDUs are NOT received within the PDU Packing Threshold, 489 the Encapsulator MUST immediately send any queued PDUs. 491 The Receiver processes this Extension Header by verifying that it 492 supports the specified CONCAT-PDU Type (unsupported Types MUST be 493 discarded but the receiver SHOULD record a PDU-Type error). It then 494 extracts each encapsulated PDU in turn. The Receiver MUST verify the 495 Length of each PDU. It MUST also ensure that the sum of the Lengths 496 of all processed PDUs equals the Length specified in the SNDU base 497 header. A Receiver SHOULD discard the whole SNDU if the total and 498 PDU sizes are not consistent and this event SHOULD be recorded as a 499 PDU-Concat size mismatch error. 501 3.3 Timestamp Extension 503 The Timestamp Extension Header permits an Encapsulator to add a 504 timestamp field to an SNDU. This is designed to support monitoring 505 and measurement of ULE performance over a link to indicate the 506 quality of an operational ULE link. This may be useful for GSE links 507 (where significant complexity exists in the scheduling provided by 508 the lower layers). This extension may be (optionally) checked at the 509 Receiver. 511 Possible uses of this extension include: 513 * Validation of in-sequence ordering per Logical Channel, 514 * Measurement of one-way delay (when synchronised with the sender), 515 * Measurement of PDU Jitter introduced by the link, 516 * PDU loss (with additional information from the sender). 518 The Timestamp Extension Header is specified by the IANA-assigned H- 519 Type value of 257 decimal. This extension is an Optional Extension 520 Header ([RFC4326], Section 5). 522 Figure 7 shows the format of this extension with a HLEN value of 3 523 indicating a timestamp of length 4B with a Type field (there is no 524 implied byte-alignment). 526 0 7 15 23 31 527 +---------------+---------------+---------------+---------------+ 528 | 0x03 | 0x01 | time stamp HI | 529 +---------------+---------------+---------------+---------------+ 530 | time stamp LO | Type | 531 +---------------+---------------+---------------+---------------+ 533 Figure 7 The format of the 32-bit Timestamp Extension Header 535 The extension carries a 32-bit value (time stamp HI plus time stamp 536 LO). The specified resolution is 1 microsecond. The value therefore 537 indicates the number of 1 microsecond ticks past the hour in 538 Universal Time when the PDU was encapsulated. This value may be 539 earlier than the time of transmission due for example to Packing, 540 queuing and other Encapsulator processing. The value is right- 541 justified to the 32-bit field. Systems unable to insert timestamps 542 at the specified resolution may use an arbitrary (and varying) value 543 to pad the unused least-significant bits. 545 The last two bytes carry a 16-bit Type field that indicates the type 546 of payload carried in the SNDU, or the presence of a further Next- 547 Header ([RFC4326], Section 4.4). 549 This is an Optional Extension Header. Receivers SHOULD process the 550 timestamp when the PDU is decapsulated. Receivers that do not 551 implement, or do not wish to process, the Timestamp Extension MAY 552 skip this extension and continue to process the remainder of the 553 SNDU, forwarding the encapsulated PDU. 555 4. IANA Considerations 557 This document requires IANA involvement for the assignment of two 558 new Next-Header Type values from the IANA ULE Next-Header Registry. 560 These options are defined for specific use cases envisaged by GSE, 561 but are compatible with ULE. 563 The TS-Concat Extension is a Mandatory next-type Extension Header, 564 specified in section 3.1 of this document. The value of this next- 565 header is defined by an IANA assigned H-Type value of 0x0002. 567 The PDU-Concat Extension is a Mandatory next-type Extension Header 568 specified in section 3.2 of this document. The value of this next- 569 header is defined by an IANA assigned H-Type value of 0x0003. 571 The Timestamp Extension is an Optional next-type Extension Header 572 specified in section 3.3 of this document. The value of this next- 573 header is defined by an IANA assigned H-Type value of 257 decimal. 574 This documents defines format for a HLEN value of 0x3. 576 5. Acknowledgements 578 The author gratefully acknowledges the inputs, comments and 579 assistance offered by the members of the DVB-GBS ad hoc group on 580 DVB-S2 encapsulation, in particular contributions on DVB-S2 581 transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. 582 Juan Cantillo provided a significant contribution to the informative 583 annexe. The authors thank Christian Praehauser for his insight and 584 contribution on header extension processing issues. 586 6. Security Considerations 588 No specific security issues are raised within this document. 590 Additional security control fields may be provided as a part of a 591 link encryption Extension Header, e.g. to associate an SNDU with one 592 of a set of Security Association (SA) parameters. As a part of the 593 encryption process, it may also be desirable to authenticate 594 some/all of the headers. The method of encryption and the way in 595 which keys are exchanged is beyond the scope of this specification, 596 as also are the definition of the SA format and that of the related 597 encryption keys. 599 7. References 601 7.1 Normative References 603 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, 1997. 606 [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 607 Lightweight Encapsulation (ULE) for transmission of IP datagrams 608 over an MPEG-2 Transport Stream", RFC 4326, December 2005. 610 [GSE] "Generic Stream Encapsulation", DVB Document A116, DVB 611 Technical Module (GBS Group), May 2007. 613 7.2 Informative References 615 [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second 616 generation framing structure, channel coding and modulation systems 617 for Broadcasting, Interactive Services, News Gathering and other 618 broadband satellite applications", European Telecommunication 619 Standards Institute (ETSI). 621 [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- 622 S2", Internet Draft , Work in 623 Progress. 625 [IEEE-802.3] "Local and metropolitan area networks - Specific 626 requirements Part 3: Carrier sense multiple access with collision 627 detection (CSMA/CD) access method and physical layer 628 specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC 629 8802-3), 2002. 631 [ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology; 632 Generic Coding of Moving Pictures and Associated Audio Information 633 Systems", International Standards Organisation (ISO). 635 [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- 636 Nocker, B., and H. Linder, "A Framework for Transmission of IP 637 Datagrams over MPEG-2 Networks", RFC 4259, November 2006. 639 [RFCxARx] Montpetit, M.-J., Fairhurst, G., "Address Resolution 640 Mechanisms for IP Datagrams over MPEG-2 Networks", RFC Ed Queue, 641 , 2007. 643 8. Authors' Addresses 645 Godred Fairhurst 646 Department of Engineering 647 University of Aberdeen 648 Aberdeen, AB24 3UE 649 UK 650 Email: gorry@erg.abdn.ac.uk 651 Web: http://www.erg.abdn.ac.uk/users/Gorry 653 Bernhard Collini-Nocker 654 Department of Computer Sciences 655 University of Salzburg 656 Jakob Haringer Str. 2 657 5020 Salzburg 658 Austria 659 EMail: bnocker@cosy.sbg.ac.at 660 Web: http://www.cosy.sbg.ac.at/ 662 9. IPR Notices 664 9.1 Intellectual Property Statement 666 The IETF takes no position regarding the validity or scope of any 667 Intellectual Property Rights or other rights that might be claimed 668 to pertain to the implementation or use of the technology described 669 in this document or the extent to which any license under such 670 rights might or might not be available; nor does it represent that 671 it has made any independent effort to identify any such rights. 672 Information on the procedures with respect to rights in RFC 673 documents can be found in BCP 78 and BCP 79. 675 Copies of IPR disclosures made to the IETF Secretariat and any 676 assurances of licenses to be made available, or the result of an 677 attempt made to obtain a general license or permission for the use 678 of such proprietary rights by implementers or users of this 679 specification can be obtained from the IETF on-line IPR repository 680 at http://www.ietf.org/ipr. 682 The IETF invites any interested party to bring to its attention any 683 copyrights, patents or patent applications, or other proprietary 684 rights that may cover technology that may be required to implement 685 this standard. Please address the information to the IETF at ietf- 686 ipr@ietf.org. 688 9.2 Disclaimer of Validity 690 This document and the information contained herein are provided on 691 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 692 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 693 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 694 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 695 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 696 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 697 FOR A PARTICULAR PURPOSE. 699 10. Copyright Statement 701 Copyright (C) The IETF Trust (2007). 703 This document is subject to the rights, licenses and restrictions 704 contained in BCP 78, and except as set forth therein, the authors 705 retain all their rights. 707 APPENDIX: The Second Generation DVB Transmission Specifications 709 This section provides informative background to the network layer 710 requirements of the second generation DVB Transmission 711 Specifications. The second generation waveforms specified by the 712 Digital Video Broadcasting project offer two main enhancements. 713 First, more efficient physical layer methods that employ higher 714 order modulation with stronger FEC and permit adaptive coding and 715 modulation response to changes in traffic and propagation 716 conditions. Second, at the link layer, they offer greater 717 flexibility in framing. Support is provided for a range of stream 718 formats including the classical Transport Stream (TS) [RFC4259]. In 719 addition, a new method called Generic Streams (GS) (or the Generic 720 Mode) is supported. A GS can be packetized or continuous and is 721 intended to provide native transport of other network-layer 722 services. One such method is that provided by the Generic Stream 723 Encapsulation (GSE) [GSE]. 725 A transmission link sequentially multiplexes a series of baseband 726 frames (BBFrames). Each BBFrame comprises a fixed-size 10B header 727 and a payload. The payload carries a DataField and uses padding to 728 fill any unused space. A stream comprises a sequence of BBFrames 729 associated with an Input Stream Identifier (ISI) that is carried in 730 the header of each BBFrame. The simplest scheme uses a single 731 stream (with just one ISI value), but multiple streams are 732 permitted. The BBFrames forming a stream may be of variable size 733 (selected from a set of allowed sizes), and must use the same stream 734 format (e.g. TS or GSE). Each stream represents an independently 735 link with independent address resolution [RFCxARx]. 737 GSE provides functions that are equivalent to those of the 738 Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It 739 supports the transmission of IP packets and other network-layer 740 protocols. The network-layer interface resembles that of ULE, where 741 it adopts common mechanisms for a Length field, a 16-bit Type field, 742 support for Extension Headers, and addressing using a 6-byte NPA and 743 a suppressed NPA address (functionally equivalent to D=1 in ULE). In 744 addition GSE also supports other addressing modes. It employs a CRC 745 method in which a CRC is placed at the end of a BBFrame, covering 746 multiples SNDUs. This is a result of more advanced physical layer 747 coding and a larger link frame size that differs to than used by the 748 MPEG-2 TS. In some systems the CRC may be suppressed and replaced by 749 cross-layer signalling from the physical layer. 751 GSE also provides more flexible fragmentation at the interface to 752 the physical layer. This adapts the SNDUs to a variable-sized link- 753 layer frame, and reflects the more complex requirements in terms of 754 fragmentation and assembly that arise when using point-to-multipoint 755 adaptive physical layers. 757 [RFC EDITOR NOTE: 758 This section must be deleted prior to publication] 760 DOCUMENT HISTORY 762 Individual Draft 00 763 This draft complements a study item in the DVB-GBS in this area to 764 define a Generic Stream Encapsulation (GSE). Comments relating to 765 this document will be gratefully received by the author(s) and may 766 also be sent to ip-dvb mailing list at: ip-dvb@erg.abdn.ac.uk 768 Individual Draft 01 769 Co-Author Added. 770 This draft updates the language and format. 771 This draft fixes problems with the concatenation mode, and defines a 772 new header format that restricts the use of the Type field so that 773 all concatenated PDUs MUST have the same Type. 775 Future versions of this draft may define additional Extension 776 Headers, proposals and ideas are welcome via the IETF ipdvb mailing 777 list. Possible extensions include those for encapsulation FEC, Link 778 parameter negotiation (e.g. for header compression), and support for 779 ATM/ULE. 781 Working Group Draft 00 782 Fixed editorial mistakes from Christian Praehauser and ID style for 783 WG adoption. 785 Working Group Draft 01 786 Corrected contact info for Bernhard. 787 Added TimeStamp Options 788 Corrected NITS in draft 790 Working Group Draft 01 791 Amended diagrams and text to follow tentative IANA assignments for 792 the codepoints. 794 Working Group Draft 01 795 Ammended text to follow IANA assignments for the codepoints. 796 Added issues raised at ipdvb meeting by C Praehauser. 797 Revised annexe with text from GSE Spec, J Cantillo, et al. 798 Revised wording to clarify corner cases. 799 Removed references to documents not in public domain. 800 Updated conventions and abbreviations for consistency. 801 Updated text referencing ULE. 803 Working Group Draft 02 804 Added rules for Types of PDUs in PDU-Concat 805 Added appendix on DVB 2 nd generation 806 Added new text on timers to control concat (from list) 808 Working Group Draft 03 809 Added a table to the start of the method defining recommended 810 ordering 811 Fixed NiTs 813 [END of RFC EDITOR NOTE]