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