idnits 2.17.1 draft-ietf-ipdvb-ule-ext-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 725. 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 == Line 855 has weird spacing: '... Review by IE...' -- 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 (January 07, 2008) is 5916 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' == Outdated reference: A later version (-09) exists of draft-ietf-ipdvb-sec-req-04 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 G. Fairhurst 2 Internet-Draft University of Aberdeen 3 Intended status: Proposed Standard B. Collini-Nocker 4 Expires: June 2008 University of Salzburg 5 January 07, 2008 7 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) 8 and the Generic Stream Encapsulation (GSE) 9 draft-ietf-ipdvb-ule-ext-07.txt 11 Status of this Draft 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes a set of Extension Headers for the 34 Unidirectional Lightweight Encapsulation (ULE), RFC4326. 36 The Extension Header formats specified in this document define 37 extensions appropriate to both ULE and the Generic Stream 38 Encapsulation (GSE) defined to support the second generation framing 39 structure defined by Digital Video Broadcasting (DVB) family of 40 specifications. 42 Table of Contents 44 1. Introduction 46 2. Conventions used in this document 48 3. Description of method 49 3.1 MPEG-2 TS-Concat Extension 50 3.2 PDU-Concat Extension 51 3.3 TimeStamp Extension 53 4. IANA Considerations 55 5. Acknowledgments 57 6. Security Considerations 59 7. References 60 7.1 Normative References 61 7.2 Informative References 63 Authors' Addresses 65 Appendix: The Second Generation DVB Transmission Specifications 66 1. Introduction 68 This document describes three Header Extensions that may be used 69 with both the Unidirectional Lightweight Encapsulation, ULE, 70 [RFC4326] and the Generic Stream Encapsulation (GSE) [GSE]. ULE is 71 defined for links that employ the MPEG-2 Transport Stream, and 72 supports a wide variety of physical-layer bearers [RFC4259]. 74 GSE has been designed for the Generic Mode (also known as the 75 Generic Stream (GS)), offered by second-generation DVB physical 76 layers, and in the first instance for DVB-S2 [ETSI-S2]. The 77 requirements for the Generic Stream are described in [ID-S2-REQ]. 78 The important characteristics of this encapsulation are described in 79 an Appendix to this document. GSE maintains a design philosophy that 80 presents a network interface that is common to that presented by ULE 81 and uses a similar construction for SubNetwork Data Unit (SNDUs). 83 The first Extension Header defines a method that allows one or more 84 TS-Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may 85 be used to provide control plane information including the 86 transmission of MPEG-2 Program Specific Information (PSI) for the 87 Multiplex. In GSE, there is no native support for transport stream 88 packets and this method is therefore suitable for providing an MPEG- 89 2 control plane. 91 A second Extension Header allows one or more PDUs to be sent within 92 the same ULE SNDU. This method is designed for cases where a large 93 number of small PDUs are directed to the same Network Point of 94 Attachment (NPA) address. The method may improve transmission 95 efficiency (by removing duplicated MAC layer overhead). It can also 96 reduce processing overhead for a receiver that is not configured to 97 receive the NPA address associated with an SNDU, allowing this 98 receiver to then skip several PDUs in one operation. The method is 99 defined as a generic Extension Header and may be used for IPv4 or 100 IPv6 packets. If, and when, a compression format is defined for ULE 101 or Ethernet, the method may also be used in combination with this 102 method. 104 A third Extension Header provides an optional timestamp value for an 105 SNDU. Examples of the use of this timestamp option include 106 monitoring and benchmarking of ULE and GSE links. Receivers that do 107 not wish to decode (or do not support) the timestamp extension may 108 discard the extension and process the remaining PDU or Extension 109 Headers. 111 An appendix includes a summary of key design issues and 112 considerations relating to the GSE Specification defined by the DVB 113 Technical Module [GSE]. 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 118 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 RFC 2119 [RFC2119]. 122 b: bit. For example, one byte consists of 8b. 124 B: Byte. Groups of bytes are represented in Internet byte order. 126 BBFrame payload: The data field part of a Baseband frame [ETSI-S2] 127 that may be used for the communication of data. Typical BBFrames 128 range in size from 3072 to 58192 bits according to the choice of 129 modulation format and Forward Error Correction (FEC) in use. 131 DVB: Digital Video Broadcasting. A framework and set of associated 132 standards published by the European Telecommunications Standards 133 Institute (ETSI) for the transmission of video, audio, and data. 135 E: A one-bit flag field defined in GSE [GSE]. 137 Encapsulator: A network device [RFC4259] that receives PDUs and 138 formats these into Payload Units (known here as SNDUs) for output in 139 DVB-S or the Generic Mode of DVB-S2. 141 GS: Generic Stream. A stream of BBFrames identified by a common 142 Input Stream Identifier, and which does not use the MPEG-2 TS format 143 [ETSI-S2]. It represents layer 2 of the ISO/OSI reference model. 145 GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating 146 PDUs to form a Generic Stream, which is sent using a sequence of 147 BBFrames. This encapsulation format shares the same extension 148 format, and basic processing rules of ULE and uses a common IANA 149 Registry. 151 LT: A two-bit flag field defined in GSE [GSE]. 153 MAC: Medium Access Control [IEEE-802.3]. A link layer protocol 154 defined by the IEEE 802.3 standard. 156 MPEG-2: A set of standards specified by the Motion Picture Experts 157 Group (MPEG), and standardized by the International Organization for 158 Standardization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in 159 H.220). 161 Next-Header: A Type value indicating an Extension Header [RFC4326]. 163 NPA: Network Point of Attachment [RFC4326]. In this document, refers 164 to a destination address (resembling an IEEE MAC address) within the 165 DVB-S/S2 transmission network that is used to identify individual 166 Receivers or groups of Receivers. 168 PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the 169 header of each TS Packet. This identifies the TS Logical Channel to 170 which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the 171 parts of a Table Section, or other Payload Unit must all carry the 172 same PID value. The all ones PID value indicates a Null TS Packet 173 introduced to maintain a constant bit rate of a TS Multiplex. There 174 is no required relationship between the PID values used for TS 175 Logical Channels transmitted using different TS Multiplexes. 177 PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include 178 Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. 180 PSI: Program Specific Information [ISO-MPEG2]. 182 S: A one-bit flag field defined in [GSE]. 184 SI Table: Service Information Table [ISO-MPEG2]. In this document, 185 this term describes a table that is been defined by another 186 standards body to convey information about the services carried on a 187 DVB Multiplex. 189 SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an 190 encapsulated PDU sent using ULE or GSE. 192 Stream: A logical flow from an Encapsulator to a set of Receivers. 194 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 195 MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 196 reference model. 198 ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A 199 method that encapsulates PDUs into SNDUs that are sent in a series 200 of TS Packets using a single TS Logical Channel. The encapsulation 201 defines an extension format and an associated IANA Registry. 203 3. Description of the Method 205 In ULE, a Type field value that is less than 1536 in decimal 206 indicates an Extension Header. This section describes a set of 207 three extension formats for the ULE encapsulation. [GSE] uses a Type 208 field that adopts the same semantics as specified by RFC 4326. The 209 encapsulation format differs in that GSE does not include a Cyclic 210 Redundancy Check (CRC) for each SNDU, has different header flags, 211 and utilizes a different SNDU length calculation [GSE]. 213 There is a natural ordering of extension headers, which is 214 determined by the fields upon which the extension header operates. A 215 suitable ordering for many applications is presented in the list 216 below (from first to last header within an SNDU). This does not 217 imply that all types of Extensions should be present in a single 218 SNDU. The presented ordering may serve as a guideline for 219 optimization of Receiver processing. 221 +----------------------------------+-------------------------------+ 222 |Fields related to Extension Header| Example Extension Headers | 223 +----------------------------------+-------------------------------+ 224 | Link framing and transmission | Timestamp Extension | 225 +----------------------------------+-------------------------------+ 226 | Entire remaining SNDU Payload | Encryption Extension | 227 +----------------------------------+-------------------------------+ 228 | Group of encapsulated PDUs | PDU-Concat or TS-Concat | 229 +----------------------------------+-------------------------------+ 230 | Specific encapsulated PDU | IEEE-defined type | 231 | | Test or MAC bridging Extension| 232 +----------------------------------+-------------------------------+ 234 Table 1: Recommended ordering of Extension Headers 236 3.1 MPEG-2 TS-Concat Extension 238 The MPEG-2 TS-Concat Extension Header is specified by an IANA 239 assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory 240 Next-Header Extension. 242 The extension is used to transport one or more MPEG-2 TS Packets 243 within a ULE SNDU. The number of TS Packets carried in a specific 244 SNDU is determined from the size of the remainder of the payload 245 following the MPEG-2 TS Extension Header. The number of TS Packets 246 contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N 247 is the number of bytes associated with Extension Headers that 248 precede the MPEG-2 TS-Concat Extension (zero if there are none). 250 A Receiver MUST check the validity of the Length value prior to 251 processing the payload. A valid Length corresponds to an integral 252 number of TS Packets. An invalid Length (a remainder from the 253 division by 188) MUST result in the discard of all encapsulated TS 254 Packets and SHOULD be recorded as TS-Concat size mismatch error. 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |0| Length (15b) | Type = 0x0002 | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Receiver Destination NPA Address (6B) | 261 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 264 | TS-Packet 1 | 265 = = 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | TS-Packet 2 (if Length > 2*188) | 269 = = 270 | etc. | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | (CRC-32) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) 277 Figure 1 illustrates the format of this Extension Header for ULE 278 with a value D=0, which indicates the presence of a NPA address 279 [RFC4326]. In this case, the valid payload Length for a ULE SNDU 280 with no other extensions is (Length-10) / 188. 282 The method used to define the Length in GSE differs to that of ULE. 283 The equivalent case for GSE would result in a payload Length value 284 of (Length-6) / 188 (Figure 2). 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |S|E|0 0| Length (12b) | Type = 0x0002 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Receiver Destination NPA Address (6B) | 291 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 294 | TS-Packet 1 | 295 = = 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | TS-Packet 2 (if Length > 2*188) | 299 = = 300 | etc. | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00) 304 Fragmented GSE SNDUs are protected by a CRC-32 carried in the final 305 fragment. After reassembly, this CRC-32 is removed and the resulting 306 SNDU carries a Total Length field. The fields labeled S and E are 307 defined by [GSE] and contain control flags used by the GSE link 308 layer. The Label Type field (LT) specifies the presence and format 309 of the GSE label. The LT field is only specified for the first 310 fragment (or a non-fragmented) GSE SNDU (i.e., when S=1). 312 In ULE, a value of D=1, is also permitted and indicates the absence 313 of a NPA address (Figure 3). A similar format is supported in GSE. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |1| Length (15b) | Type = 0x0002 | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | TS-Packet 1 | 321 = = 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | TS-Packet 2 (if Length > 2*188) | 325 = = 326 | etc. | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | (CRC-32) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) 333 This extension may be used to transport one or more MPEG-2 TS 334 Packets of arbitrary content, interpreted according to [ISO-MPEG2]. 335 One expected use is for the transmission of MPEG-2 SI/PSI signalling 336 [RFC4259]. 338 NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this 339 encapsulation. To reduce transmission overhead and processing, an 340 Encapsulator SHOULD specify a maximum period of time that it can 341 wait before sending all queued TS Packets. This is known as the TS 342 Packing Threshold. This value MUST be bounded and SHOULD be 343 configurable in the Encapsulator. A larger value can improve 344 efficiency, but incurs higher jitter and could increase the 345 probability of corruption. If additional TS Packets are NOT received 346 within the TS Packing Threshold, the Encapsulator MUST immediately 347 send any queued TS Packets. 349 The use of this format to transfer MPEG-2 clock references (e.g., a 350 Network Clock Reference, NCR) over ULE/GSE framing raises timing 351 considerations at the encapsulation gateway, including the need to 352 update/modify the timing information prior to transmission by the 353 physical layer. These issues are not considered here, but this 354 operation may be simplified in GSE by ensuring that all SNDUs that 355 carry this Extension Header are placed before other data within the 356 BBFrame DataField [GSE]. 358 This document does not specify how TS Packets are to be handled at 359 the Receiver, however it notes that a poorly configured Encapsulator 360 could lead to a Multiplex carrying multiple (possibly conflicting) 361 sets of TS Logical Channels and SI information encapsulated at 362 different levels or with different NPA addresses. The need for 363 consistency in the use of PIDs and the related SI information is 364 described in [RFC4947]. 366 3.2 PDU-Concat Extension 368 The PDU-Concat Extension Header is specified by an IANA assigned H- 369 Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header 370 Extension. It enables a sequence of (usually short) PDUs to be sent 371 within a single SNDU payload. 373 The base header contains the Length of the entire SNDU. This carries 374 the value of the combined length of all PDUs to be encapsulated, 375 including each set of encapsulation headers. The base header MAY be 376 followed by one or more additional Extension Headers that precede 377 the PDU-Concat Extension Header. These Extension Headers (e.g., a 378 TimeStamp Extension) apply to the composite concatenated PDU. 380 The Extension Header also contains a 16-bit ULE Type field 381 describing the encapsulated PDU, PDU-Concat-Type. Although any Type 382 value specified in the ULE Next-Header Registry (including Extension 383 Header Types) may be assigned to the encapsulated PDU (except the 384 recursive use of a PDU-Concat type), all concatenated PDUs MUST have 385 a common ULE Type (i.e., all concatenated PDUs passed by the network 386 layer must be associated with the same Type value). This simplifies 387 the receiver design, and reduces the transmission overhead for 388 common use cases. 390 Each PDU is prefixed by its length in bytes (shown in the following 391 diagrams as PDU-x-Length for the xth PDU). Encapsulated PDUs are of 392 arbitrary length (in bytes) and are not necessarily aligned to 16- 393 bit or 32-bit boundaries within the SNDU (as shown in the figure). 394 The most significant bit of the first byte is reserved, R, and this 395 specification requires that this MUST be set to zero. Receivers MUST 396 ignore the value of the R bit. The length of each PDU MUST be less 397 than 32758 bytes, but will generally be much smaller. 399 When the SNDU header indicates the presence of an SNDU Destination 400 Address field (i.e., D=0 in ULE), a Network Point of Attachment, 401 NPA, field directly follows the fourth byte of the SNDU header. NPA 402 destination addresses are 6 Byte numbers, normally expressed in 403 hexadecimal, used to identify the Receiver(s) in a transmission 404 network that should process a received SNDU. When present, the 405 Receiver MUST associate the same specified MAC/NPA address with all 406 PDUs within the SNDU Payload. This MAC/NPA address MUST also be 407 forwarded with each PDU, if required by the forwarding interface. 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |0| Length (15b) | Type = 0x0003 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Receiver Destination NPA Address (6B) | 414 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | PDU-Concat-Type | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |R| PDU-1-Length (15b) | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 419 = PDU-1 = 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |R| PDU-2-Length (15b) | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 424 = PDU-2 = 425 | | 426 More PDUs as required 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | (CRC-32) | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |S|E|0 0| Length (12b) | Type = 0x0003 | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Receiver Destination NPA Address (6B) | 439 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | PDU-Concat-Type | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |R| PDU-1-Length (15b) | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 444 = PDU-1 = 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |R| PDU-2-Length (15b) | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 449 = PDU-2 = 450 | | 451 More PDUs as required 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00) 456 When the SNDU header indicates the absence of an SNDU Destination 457 Address field (i.e., D=1 in ULE) all encapsulated PDUs MUST be 458 processed as if they had been received without an NPA address. 460 The value of D in the ULE header indicates whether a NPA/MAC address 461 is in use [RFC4326]. A similar format is supported in GSE (using the 462 LT field). 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 |1| Length (15b) | Type = 0x0003 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | PDU-Concat-Type |R| PDU-1-Length (15b) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 = PDU-1 = 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |R| PDU-2-Length (15b) | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 475 = PDU-2 = 476 | | 477 More PDUs as required 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | (CRC-32) | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) 485 To reduce transmission overhead and processing, an Encapsulator 486 SHOULD specify a maximum period of time it will wait before sending 487 a Concatenated PDU. This is known as the PDU Packing Threshold. This 488 value MUST be bounded and SHOULD be configurable in the 489 Encapsulator. A larger value can improve efficiency, but incurs 490 higher jitter and could increase the probability of corruption. If 491 additional PDUs are NOT received within the PDU Packing Threshold, 492 the Encapsulator MUST immediately send all queued PDUs. 494 The Receiver processes this Extension Header by verifying that it 495 supports the specified PDU-Concat Type (unsupported Types MUST be 496 discarded, but the receiver SHOULD record a PDU-Type error 497 [RFC4326]). It then extracts each encapsulated PDU in turn. The 498 Receiver MUST verify the Length of each PDU. It MUST also ensure 499 that the sum of the Lengths of all processed PDUs equals the Length 500 specified in the SNDU base header. A Receiver SHOULD discard the 501 whole SNDU if the total and PDU sizes are not consistent and this 502 event SHOULD be recorded as a PDU-Concat size mismatch error. A 503 receiver MUST NOT forward a partial PDU with an indicated PDU-Length 504 greater than the number of unprocessed bytes remaining in the SNDU 505 payload field. 507 3.3 Timestamp Extension 509 The Timestamp Extension Header is an Optional Next-Header Extension 510 that permits an Encapsulator to add a timestamp field to an SNDU. 511 The Timestamp Extension Header is specified by the IANA-assigned H- 512 Type value of 257 decimal. This extension is an Optional Extension 513 Header ([RFC4326], Section 5). 515 This extension is designed to support monitoring and measurement of 516 the performance of a link to indicate the quality of an operational 517 ULE link. This may be useful for GSE links (e.g., where significant 518 complexity exists in the scheduling provided by the lower layers). 519 Possible uses of this extension include: 521 * Validation of in-sequence ordering per Logical Channel, 522 * Measurement of one-way delay (when synchronized with the sender) 523 * Measurement of PDU Jitter introduced by the link, 524 * Measurement of PDU loss (with additional information from sender). 526 Figure 7 shows the format of this extension with a HLEN value of 3 527 indicating a timestamp of length 4B with a Type field (there is no 528 implied byte-alignment). 530 0 7 15 23 31 531 +---------------+---------------+---------------+---------------+ 532 | 0x03 | 0x01 | time stamp HI | 533 +---------------+---------------+---------------+---------------+ 534 | time stamp LO | Type | 535 +---------------+---------------+---------------+---------------+ 537 Figure 7 Format of the 32-bit Timestamp Extension Header 539 The extension carries a 32-bit value (time stamp HI plus time stamp 540 LO). The specified resolution is 1 microsecond. The value therefore 541 indicates the number of 1 microsecond ticks past the hour in 542 Universal Time when the PDU was encapsulated. This value may be 543 earlier than the time of transmission, due for example to Packing, 544 queuing and other Encapsulator processing. The value is right- 545 justified to the 32-bit field. Systems unable to insert timestamps 546 at the specified resolution may use an arbitrary (and varying) value 547 to pad the unused least-significant bits. 549 The last two bytes carry a 16-bit Type field that indicates the type 550 of payload carried in the SNDU, or the presence of a further Next- 551 Header ([RFC4326], Section 4.4). 553 Receivers MAY process the timestamp when the PDU encapsulation is 554 removed. Receivers that do not implement, or do not wish to process, 555 the Timestamp Extension MAY skip this extension header. Receivers 556 MUST continue to process the remainder of the SNDU, forwarding the 557 encapsulated PDU. 559 4. IANA Considerations 561 This document requires IANA involvement for the assignment of three 562 new Next-Header Type values from the IANA ULE Next-Header Registry. 563 These options are defined for specific use cases envisaged by GSE, 564 but are compatible with ULE. 566 The following assignments have been made in this document, and 567 registered by IANA: 569 Type Name Reference 571 2: TS-Concat Section 3.1 572 3: PDU-Concat Section 3.2 574 Type Name H-LEN Reference 576 257: Timestamp 3 Section 3.3 578 The TS-Concat Extension is a Mandatory next-type Extension Header, 579 specified in section 3.1 of this document. The value of this next- 580 header is defined by an IANA assigned H-Type value of 0x0002. 582 The PDU-Concat Extension is a Mandatory next-type Extension Header 583 specified in section 3.2 of this document. The value of this next- 584 header is defined by an IANA assigned H-Type value of 0x0003. 586 The Timestamp Extension is an Optional next-type Extension Header 587 specified in section 3.3 of this document. The value of this next- 588 header is defined by an IANA assigned H-Type value of 257 decimal. 589 This documents defines format for a HLEN value of 0x3. 591 5. Acknowledgments 593 The authors gratefully acknowledge the inputs, comments and 594 assistance offered by the members of the DVB-GBS ad hoc group on 595 DVB-S2 encapsulation, in particular contributions on DVB-S2 596 transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. 597 Juan Cantillo provided a significant contribution to the informative 598 appendix. The authors thank Christian Praehauser for his insight and 599 contribution on header extension processing issues. 601 6. Security Considerations 603 Security considerations for ULE are described in [RFC4326] and 604 further information on security aspects of using ULE are described 605 in the security considerations of [RFC4259] and [ID-Sec-Req]. 607 An attacker that is able to inject arbitrary TS Packets in a ULE or 608 GSE Stream may modify layer 2 signalling information transmitted by 609 the MPEG-2 TS-Concat extension. Since this attack requires access to 610 the link and/or layer 2 equipment, such an attack could also 611 directly attack signalling information sent as native TS Packets 612 (not encapsulated by ULE/GSE). Security issues relating to the 613 transmission and interpretation of layer 2 signalling information 614 (including Address Resolution) within a TS Multiplex are described 615 in [RFC4947]. The use of security mechanisms to protect the MPEG-2 616 signalling information is discussed by [ID-Sec-Req]. 618 7. References 620 7.1 Normative References 622 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 1997. 625 [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 626 Lightweight Encapsulation (ULE) for transmission of IP datagrams 627 over an MPEG-2 Transport Stream", RFC 4326, December 2005. 629 [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream 630 Encapsulation (GSE) Protocol, "European Telecommunication Standards, 631 Institute (ETSI), 2007. 633 7.2 Informative References 635 [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second 636 generation framing structure, channel coding and modulation systems 637 for Broadcasting, Interactive Services, News Gathering and other 638 broadband satellite applications", European Telecommunication 639 Standards Institute (ETSI). 641 [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- 642 S2", Internet-Draft , Work in 643 Progress. 645 [ID-Sec-Req] "Security requirements for the Unidirectional 646 Lightweight Encapsulation (ULE) protocol", Internet Draft < draft- 647 ietf-ipdvb-sec-req-04.txt>, Work in Progress. 649 [IEEE-802.3] "Local and metropolitan area networks - Specific 650 requirements Part 3: Carrier sense multiple access with collision 651 detection (CSMA/CD) access method and physical layer 652 specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC 653 8802-3), 2002. 655 [ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology; 656 Generic Coding of Moving Pictures and Associated Audio Information 657 Systems", International Organization for Standardization (ISO). 659 [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- 660 Nocker, B., and H. Linder, "A Framework for Transmission of IP 661 Datagrams over MPEG-2 Networks", RFC 4259, November 2006. 663 [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution 664 Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 665 2007. 667 Authors' Addresses 669 Godred Fairhurst 670 School of Engineering, 671 University of Aberdeen, 672 Aberdeen, AB24 3UE 673 UK 674 Email: gorry@erg.abdn.ac.uk 675 URI: http://www.erg.abdn.ac.uk/users/gorry 677 Bernhard Collini-Nocker 678 School of Computer Sciences, 679 University of Salzburg, 680 Jakob Haringer Str. 2, 681 5020 Salzburg, 682 Austria 683 Email: bnocker@cosy.sbg.ac.at 684 URI: http://www.cosy.sbg.ac.at 686 Full Copyright Statement 688 Copyright (C) The IETF Trust (2008). 690 This document is subject to the rights, licenses and restrictions 691 contained in BCP 78, and except as set forth therein, the authors 692 retain all their rights. 694 This document and the information contained herein are provided on 695 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 696 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 697 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 698 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 699 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 700 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 701 FOR A PARTICULAR PURPOSE. 703 Intellectual Property Statement 705 The IETF takes no position regarding the validity or scope of any 706 Intellectual Property Rights or other rights that might be claimed 707 to pertain to the implementation or use of the technology described 708 in this document or the extent to which any license under such 709 rights might or might not be available; nor does it represent that 710 it has made any independent effort to identify any such rights. 711 Information on the procedures with respect to rights in RFC 712 documents can be found in BCP 78 and BCP 79. 714 Copies of IPR disclosures made to the IETF Secretariat and any 715 assurances of licenses to be made available, or the result of an 716 attempt made to obtain a general license or permission for the use 717 of such proprietary rights by implementers or users of this 718 specification can be obtained from the IETF on-line IPR repository 719 at http://www.ietf.org/ipr. 721 The IETF invites any interested party to bring to its attention any 722 copyrights, patents or patent applications, or other proprietary 723 rights that may cover technology that may be required to implement 724 this standard. Please address the information to the IETF at ietf- 725 ipr@ietf.org. 727 APPENDIX: The Second Generation DVB Transmission Specifications 729 This section provides informative background to the network-layer 730 requirements of the second generation DVB Transmission 731 Specifications. The second generation waveforms specified by the 732 Digital Video Broadcasting project offer two main enhancements. 733 First, more efficient physical layer methods that employ higher 734 order modulation with stronger FEC and permit adaptive coding and 735 modulation response to changes in traffic and propagation 736 conditions. Second, at the link layer, they offer greater 737 flexibility in framing. Support is provided for a range of stream 738 formats including the classical Transport Stream (TS) [RFC4259]. In 739 addition, a new method called Generic Streams (GS) (or the Generic 740 Mode) is supported. A GS can be packetized or continuous and is 741 intended to provide native transport of other network-layer 742 services. One such method is that provided by the Generic Stream 743 Encapsulation (GSE) [GSE]. 745 For example, the DVB-S2 [ETSI-S2] transmission link sequentially 746 multiplexes a series of baseband frames (BBFrames). Each BBFrame 747 comprises a fixed-size 10B header and a payload. The payload carries 748 a DataField and uses padding to fill any unused space. A stream 749 comprises a sequence of BBFrames associated with an Input Stream 750 Identifier (ISI) that is carried in the header of each BBFrame. The 751 simplest scheme uses a single stream (with just one ISI value), but 752 multiple streams are permitted. The BBFrames forming a stream may be 753 of variable size (selected from a set of allowed sizes), and must 754 use the same stream format (i.e., TS or GSE). Each stream represents 755 an independent link with independent address resolution [RFC4947]. 757 GSE provides functions that are equivalent to those of the 758 Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It 759 supports the transmission of IP packets and other network-layer 760 protocols. The network-layer interface resembles that of ULE, where 761 it adopts common mechanisms for a Length field, a 16-bit Type field, 762 and support for Extension Headers. As in ULE, GSE permits multiple 763 address formats, indicated by the LT field (functionally equivalent 764 to the D field in ULE). The default addressing mode uses a 6-byte 765 NPA and a suppressed NPA address (functionally equivalent to D=1 in 766 ULE). 768 GSE also provides more flexible fragmentation at the interface to 769 the physical layer (using the S and E flags). This adapts the SNDUs 770 to a variable-sized link-layer frame, and reflects the more complex 771 requirements in terms of fragmentation and assembly that arise when 772 using point-to-multipoint adaptive physical layers. The integrity of 773 a reassembled SNDUs is provided by a CRC-32 in the last fragment for 774 the corresponding PDU. 776 [RFC EDITOR NOTE: 777 This section must be deleted prior to publication] 779 DOCUMENT HISTORY 781 Individual Draft 00 782 This draft complements a study item in the DVB-GBS in this area to 783 define a Generic Stream Encapsulation (GSE). Comments relating to 784 this document will be gratefully received by the author(s) and may 785 also be sent to ip-dvb mailing list. 787 Individual Draft 01 788 Co-Author Added. 789 This draft updates the language and format. 790 This draft fixes problems with the concatenation mode, and defines a 791 new header format that restricts the use of the Type field so that 792 all concatenated PDUs MUST have the same Type. 794 Future versions of this draft may define additional Extension 795 Headers, proposals and ideas are welcome via the IETF ipdvb mailing 796 list. Possible extensions include those for encapsulation FEC, Link 797 parameter negotiation (e.g., for header compression), and support 798 for ATM/ULE. 800 Working Group Draft 00 801 Fixed editorial mistakes from Christian Praehauser and ID style for 802 WG adoption. 804 Working Group Draft 01 805 Corrected contact info for Bernhard. 806 Added TimeStamp Options 807 Corrected NITS in draft 809 Working Group Draft 01 810 Amended diagrams and text to follow tentative IANA assignments for 811 the codepoints. 813 Working Group Draft 01 814 Amended text to follow IANA assignments for the codepoints. 815 Added issues raised at ipdvb meeting by C Praehauser. 816 Revised appendix with text from GSE Spec, J Cantillo, et al. 817 Revised wording to clarify corner cases. 818 Removed references to documents not in public domain. 819 Updated conventions and abbreviations for consistency. 820 Updated text referencing ULE. 822 Working Group Draft 02 824 Added rules for Types of PDUs in PDU-Concat. 825 Added appendix on DVB 2 nd generation. 826 Added new text on timers to control concat (from list). 828 Working Group Draft 03 830 Added a table to the start of the method defining recommended. 831 Fixed NiTs. 833 Working Group Draft 04 834 Editorial changes to prepare the document for WGLC. 835 Updated IANA section to comply with RFC4326 IANA Guidelines. 837 Reduced Security considerations section by reference to other 838 documents that give a fuller discussion. 840 There were no intentional changes to the protocol specification. 842 Working Group Draft 05 844 Addressed review comments. 846 Working Group Draft 06 848 Updated reference to GSE (now an ETSI Spec) - This spec has a 849 normative reference to the current document. 851 Minor editorial corrections to English 853 Working Group Draft 07 855 Updated following Gen-Art Review & SECDIR Review by IETF. 857 [END of RFC EDITOR NOTE]