idnits 2.17.1 draft-ietf-ipdvb-ule-ext-05.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 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 712. 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 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2007) is 6032 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 (~~), 2 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: April 2007 University of Salzburg 5 October 19, 2007 7 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) 8 and the Generic Stream Encapsulation (GSE) 9 draft-ietf-ipdvb-ule-ext-05.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. Acknowledgements 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 Unidirectional Lightweight Encapsulation, ULE, [RFC4326] 70 and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for 71 links that employ the MPEG-2 Transport Stream, and supports a wide 72 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 common network interface to that of ULE and uses a 81 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 receivers that are not addressed by 97 the NPA, since these receivers may then skip several PDUs in one 98 operation. The method is defined as a generic Extension Header and 99 may be used for IPv4 or IPv6 packets. If and when a compression 100 format is defined for ULE or Ethernet, the method may also be used 101 in combination with this method. 103 A third Extension Header provides an optional timestamp value for an 104 SNDU. Examples of the use of this timestamp option include 105 monitoring and benchmarking of ULE and GSE links. Receivers that do 106 not wish to decode (or do not support) the timestamp extension may 107 discard the extension and process the remaining PDU or Extension 108 Headers. 110 An appendix includes a summary of key design issues and 111 considerations based on the GSE Specification defined by the DVB 112 Technical Module [GSE]. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 117 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 RFC 2119 [RFC2119]. 121 b: bit. For example, one byte consists of 8b. 123 B: Byte. Groups of bytes are represented in Internet byte order. 125 BBFrame payload [ETSI-S2]: The data field part of a Baseband frame 126 that may be used for the communication of data. Typical BBFrames 127 range in size from 3072 to 58192 bits according to the choice of 128 modulation format and FEC in use. 130 DVB: Digital Video Broadcasting. A framework and set of associated 131 standards published by the European Telecommunications Standards 132 Institute (ETSI) for the transmission of video, audio, and data. 134 E: A one-bit flag field defined in [GSE]. 136 Encapsulator: A network device that receives PDUs and formats these 137 into Payload Units (known here as SNDUs) for output in DVB-S or the 138 Generic Mode of DVB-S2. 140 GS: Generic Stream [ETSI-S2]. A stream of BBFrames identified by a 141 common Input Stream Identifier, and which does not use the MPEG-2 TS 142 format. It represents layer 2 of the ISO/OSI reference model. 144 GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating 145 PDUs to form a Generic Stream, which is sent using a sequence of 146 BBFrames. This encapsulation format shares the same extension 147 format, and basic processing rules of ULE and uses a common IANA 148 Registry. 150 LT: A two-bit flag field defined in [GSE]. 152 MAC: Medium Access Control [IEEE-802.3]. A link layer protocol 153 defined by the IEEE 802.3 standard (or by Ethernet v2). 155 MPEG-2: A set of standards specified by the Motion Picture Experts 156 Group (MPEG), and standardized by the International Standards 157 Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). 159 Next-Header: A Type value indicating an Extension Header [RFC4326]. 161 NPA: Network Point of Attachment [RFC4326]. In this document, refers 162 to a destination address (resembling an IEEE MAC address) within the 163 DVB-S/S2 transmission network that is used to identify individual 164 Receivers or groups of Receivers. 166 PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the 167 header of each TS Packet. This identifies the TS Logical Channel to 168 which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the 169 parts of a Table Section, or other Payload Unit must all carry the 170 same PID value. The all ones PID value indicates a Null TS Packet 171 introduced to maintain a constant bit rate of a TS Multiplex. There 172 is no required relationship between the PID values used for TS 173 Logical Channels transmitted using different TS Multiplexes. 175 PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include 176 Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. 178 PSI: Program Specific Information [ISO-MPEG2]. 180 S: A one-bit flag field defined in [GSE]. 182 SI Table: Service Information Table [ISO-MPEG2]. In this document, 183 this term describes a table that is been defined by another 184 standards body to convey information about the services carried on a 185 DVB Multiplex. 187 SNDU: SubNetwork Data Unit [RFC4259]. In this document this is an 188 encapsulated PDU sent using ULE or GSE. 190 Stream: A logical flow from an Encapsulator to a set of Receivers. 192 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 193 MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 194 reference model. 196 ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A 197 method that encapsulates PDUs, into SNDUs that are sent in a series 198 of TS Packets using a single TS Logical Channel. The encapsulation 199 defines an extension format and an associated IANA Registry. 201 3. Description of the Method 203 In ULE, a Type field value that is less than 1536 Decimal indicates 204 an Extension Header. This section describes a set of three 205 extension formats for the ULE encapsulation. [GSE] uses a Type field 206 that adopts the same semantics as specified by RFC 4326. The 207 encapsulation format differs in that GSE does not include a per-SNDU 208 CRC, has different header flags, and utilises a different SNDU 209 length calculation [GSE]. 210 There is a natural ordering of extension headers, which is 211 determined by the fields upon which the extension header operates. A 212 suitable ordering for many applications is presented in the list 213 below (from first to last header within an SNDU). This does not 214 imply that all types of Extensions should be present in a single 215 SNDU. The presented ordering may serve as a guideline for 216 optimisation of Receiver processing. 218 +----------------------------------+-------------------------------+ 219 |Fields related to Extension Header| Example Extension Headers | 220 +----------------------------------+-------------------------------+ 221 | Link framing and transmission | Timestamp Extension | 222 +----------------------------------+-------------------------------+ 223 | Entire remaining SNDU Payload | Encryption Extension | 224 +----------------------------------+-------------------------------+ 225 | Group of encapsulated PDUs | PDU-Concat or TS-Concat | 226 +----------------------------------+-------------------------------+ 227 | Specific encapsulated PDU | IEEE-defined type | 228 | | Test or MAC bridging Extension| 229 +----------------------------------+-------------------------------+ 231 Table 1: Recommended ordering of Extension Headers 233 3.1 MPEG-2 TS-Concat Extension 235 The MPEG-2 TS-Concat Extension Header is specified by an IANA 236 assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory 237 Next-Header Extension. 239 The extension is used to transport one or more MPEG-2 TS Packets 240 within a ULE SNDU. The number of TS Packets carried in a specific 241 SNDU is determined from the size of the remainder of the payload 242 following the MPEG-2 TS Extension Header. The number of TS Packets 243 contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N 244 is the number of bytes associated with Extension Headers that 245 precede the MPEG-2 TS-Concat Extension (zero if there are none). 247 A Receiver MUST check the validity of the Length value prior to 248 processing the payload. A valid Length contains an integral number 249 of TS Packets. An invalid Length (a remainder from the division by 250 188) MUST result in the discard of all encapsulated TS Packets and 251 SHOULD be recorded as TS-Concat size mismatch error. 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |0| Length (15b) | Type = 0x0002 | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Receiver Destination NPA Address (6B) | 258 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 261 | TS-Packet 1 | 262 = = 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | TS-Packet 2 (if Length > 2*188) | 266 = = 267 | etc. | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | (CRC-32) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) 274 Figure 1 illustrates the format of this Extension Header for ULE 275 with a value D=0, which indicates the presence of a NPA address 276 [RFC4326]. In this case, the valid payload Length for a ULE SNDU 277 with no other extensions is (Length-10) / 188. 279 The method used to define the Length in GSE differs to that of ULE. 280 The equivalent case for GSE would result in a payload Length value 281 of (Length-6) / 188 (Figure 2). 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |S|E|0 0| Length (12b) | Type = 0x0002 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Receiver Destination NPA Address (6B) | 288 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 291 | TS-Packet 1 | 292 = = 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | TS-Packet 2 (if Length > 2*188) | 296 = = 297 | etc. | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00) 301 Fragmented GSE SNDUs are protected by a CRC-32 carried in the final 302 fragment. After reassembly, this CRC-32 is removed and the resulting 303 SNDU carries a Total Length field. The fields labelled S and E are 304 defined by [GSE] and contain control flags used by the GSE link 305 layer. The Label Type field (LT) specifies the presence and format 306 of the GSE label. The LT field is only specified for the first 307 fragment (or a non-fragmented) GSE SNDU (i.e. when S=1). 309 In ULE, a value of D=1, is also permitted and indicates the absence 310 of a NPA address (Figure 3). A similar format is supported in GSE. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |1| Length (15b) | Type = 0x0002 | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | TS-Packet 1 | 318 = = 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | TS-Packet 2 (if Length > 2*188) | 322 = = 323 | etc. | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | (CRC-32) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) 330 This extension may be used to transport one or more MPEG-2 TS 331 Packets of arbitrary content, interpreted according to [ISO-MPEG2]. 332 One expected use is for the transmission of MPEG-2 SI/PSI 333 signalling. 335 NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this 336 encapsulation. To reduce transmission overhead and processing, an 337 Encapsulator SHOULD specify a maximum period of time that it can 338 wait before sending all queued TS Packets. This is known as the TS 339 Packing Threshold. This value MUST be bounded and SHOULD be 340 configurable in the Encapsulator. A larger value can improve 341 efficiency, but incurs higher jitter and could increase the 342 probability of corruption. If additional TS Packets are NOT received 343 within the TS Packing Threshold, the Encapsulator MUST immediately 344 send any queued TS Packets. 346 The use of this format to transfer MPEG-2 clock references (e.g. a 347 Network Clock Reference, NCR) over ULE/GSE framing raises timing 348 considerations at the encapsulation gateway, including the need to 349 update/modify the timing information prior to transmission by the 350 physical layer. These issues are not considered here, but this 351 operation may be simplified in GSE by ensuring that all SNDUs that 352 carry this Extension Header are placed before other data within the 353 BBFrame DataField [GSE]. 355 This document does not specify how TS Packets are to be handled at 356 the Receiver, however it notes that a poorly configured Encapsulator 357 could lead to a Multiplex carrying multiple (possibly conflicting) 358 sets of TS Logical Channels and SI information encapsulated at 359 different levels or with different NPA addresses. The need for 360 consistency in the use of PIDs and the related SI information is 361 described in [RFC4947]. 363 3.2 PDU-Concat Extension 365 The PDU-Concat Extension Header is specified by an IANA assigned H- 366 Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header 367 Extension. It enables a sequence of (usually short) PDUs to be sent 368 within a single SNDU payload. 370 The base header contains the Length of the entire SNDU. This carries 371 the value of the combined length of all PDUs to be encapsulated, 372 including each set of encapsulation headers. The base header MAY be 373 followed by one or more additional Extension Headers that precede 374 the PDU-Concat Extension Header. These Extension Headers (e.g. a 375 TimeStamp Extension) apply to the composite concatenated PDU. 377 The Extension Header also contains a 16-bit ULE Type field 378 describing the encapsulated PDU, PDU-Concat-Type. Although any Type 379 value specified in the ULE Next-Header Registry (including Extension 380 Header Types) may be assigned to the encapsulated PDU (except the 381 recursive use of a PDU-Concat type), all concatenated PDUs MUST have 382 a common ULE Type (i.e. all concatenated PDUs passed by the network 383 layer must be associated with the same Type value). This simplifies 384 the receiver design, and reduces the transmission overhead for 385 common use cases. 387 Each PDU is prefixed by its length in bytes (shown as PDU-Length in 388 the following diagrams). Encapsulated PDUs are of arbitrary length 389 (in bytes) and are not necessarily aligned to 16-bit or 32-bit 390 boundaries within the SNDU (as shown in the figure). The most 391 significant bit of the first byte is reserved, R, and this 392 specification requires that this MUST be set to zero. Receivers MUST 393 ignore the value of the R bit. The length of each PDU MUST be less 394 than 32758 bytes, but will generally be much smaller. 396 When the SNDU header indicates the presence of an SNDU Destination 397 Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA, 398 field directly follows the fourth byte of the SNDU header. NPA 399 destination addresses are 6 Byte numbers, normally expressed in 400 hexadecimal, used to identify the Receiver(s) in a transmission 401 network that should process a received SNDU. When present the 402 Receiver MUST associate the same specified MAC/NPA address with all 403 PDUs within the SNDU Payload. This MAC/NPA address MUST also be 404 forwarded with each PDU, if required by the forwarding interface. 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |0| Length (15b) | Type = 0x0003 | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Receiver Destination NPA Address (6B) | 411 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | PDU-Concat-Type | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |R| PDU-Length-1 (15b) | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 416 = PDU-1 = 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |R| PDU-Length-2 (15b) | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 421 = PDU-2 = 422 | | 423 More PDUs as required 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | (CRC-32) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 |S|E|0 0| Length (12b) | Type = 0x0003 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Receiver Destination NPA Address (6B) | 436 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | PDU-Concat-Type | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |R| PDU-Length-1 (15b) | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 441 = PDU-1 = 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |R| PDU-Length-2 (15b) | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 446 = PDU-2 = 447 | | 448 More PDUs as required 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_ 453 When the SNDU header indicates the absence of an SNDU Destination 454 Address field (i.e. D=1 in ULE) all encapsulated PDUs MUST be 455 processed as if they had been received without an NPA address. 457 The value of D in the ULE header indicates whether a NPA/MAC address 458 is in use [RFC4326]. A similar format is supported in GSE (using the 459 LT field). 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 | PDU-Concat-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 all queued PDUs. 491 The Receiver processes this Extension Header by verifying that it 492 supports the specified PDU-Concat Type (unsupported Types MUST be 493 discarded, but the receiver SHOULD record a PDU-Type error 494 [RFC4326]). It then extracts each encapsulated PDU in turn. The 495 Receiver MUST verify the Length of each PDU. It MUST also ensure 496 that the sum of the Lengths of all processed PDUs equals the Length 497 specified in the SNDU base header. A Receiver SHOULD discard the 498 whole SNDU if the total and PDU sizes are not consistent and this 499 event SHOULD be recorded as a PDU-Concat size mismatch error. A 500 receiver MUST NOT forward a partial PDU with an indicated PDU-Length 501 greater than the number of unprocessed bytes remaining in the SNDU 502 payload field. 504 3.3 Timestamp Extension 506 The Timestamp Extension Header is an Optional Next-Header Extension 507 that permits an Encapsulator to add a timestamp field to an SNDU. 508 The Timestamp Extension Header is specified by the IANA-assigned H- 509 Type value of 257 decimal. This extension is an Optional Extension 510 Header ([RFC4326], Section 5). 512 This extension is designed to support monitoring and measurement of 513 the performance of a link to indicate the quality of an operational 514 ULE link. This may be useful for GSE links (e.g. where significant 515 complexity exists in the scheduling provided by the lower layers). 516 Possible uses of this extension include: 518 * Validation of in-sequence ordering per Logical Channel, 519 * Measurement of one-way delay (when synchronised with the sender) 520 * Measurement of PDU Jitter introduced by the link, 521 * Measurement of PDU loss (with additional information from sender). 523 Figure 7 shows the format of this extension with a HLEN value of 3 524 indicating a timestamp of length 4B with a Type field (there is no 525 implied byte-alignment). 527 0 7 15 23 31 528 +---------------+---------------+---------------+---------------+ 529 | 0x03 | 0x01 | time stamp HI | 530 +---------------+---------------+---------------+---------------+ 531 | time stamp LO | Type | 532 +---------------+---------------+---------------+---------------+ 534 Figure 7 The format of the 32-bit Timestamp Extension Header 536 The extension carries a 32-bit value (time stamp HI plus time stamp 537 LO). The specified resolution is 1 microsecond. The value therefore 538 indicates the number of 1 microsecond ticks past the hour in 539 Universal Time when the PDU was encapsulated. This value may be 540 earlier than the time of transmission due for example to Packing, 541 queuing and other Encapsulator processing. The value is right- 542 justified to the 32-bit field. Systems unable to insert timestamps 543 at the specified resolution may use an arbitrary (and varying) value 544 to pad the unused least-significant bits. 546 The last two bytes carry a 16-bit Type field that indicates the type 547 of payload carried in the SNDU, or the presence of a further Next- 548 Header ([RFC4326], Section 4.4). 550 Receivers MAY process the timestamp when the PDU encapsulation is 551 removed. Receivers that do not implement, or do not wish to process, 552 the Timestamp Extension MAY skip this extension header. Receivers 553 MUST continue to process the remainder of the SNDU, forwarding the 554 encapsulated PDU. 556 4. IANA Considerations 558 This document requires IANA involvement for the assignment of three 559 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 following assignments have been made in this document, and 564 registered by IANA: 566 Type Name Reference 568 2: TS-Concat Section 3.1 569 3: PDU-Concat Section 3.2 571 Type Name H-LEN Reference 573 257: Timestamp 3 Section 3.3 575 The TS-Concat Extension is a Mandatory next-type Extension Header, 576 specified in section 3.1 of this document. The value of this next- 577 header is defined by an IANA assigned H-Type value of 0x0002. 579 The PDU-Concat Extension is a Mandatory next-type Extension Header 580 specified in section 3.2 of this document. The value of this next- 581 header is defined by an IANA assigned H-Type value of 0x0003. 583 The Timestamp Extension is an Optional next-type Extension Header 584 specified in section 3.3 of this document. The value of this next- 585 header is defined by an IANA assigned H-Type value of 257 decimal. 586 This documents defines format for a HLEN value of 0x3. 588 5. Acknowledgements 590 The author gratefully acknowledges the inputs, comments and 591 assistance offered by the members of the DVB-GBS ad hoc group on 592 DVB-S2 encapsulation, in particular contributions on DVB-S2 593 transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. 594 Juan Cantillo provided a significant contribution to the informative 595 annexe. The authors thank Christian Praehauser for his insight and 596 contribution on header extension processing issues. 598 6. Security Considerations 600 This document does not raise new security concerns. 602 Security considerations for ULE are described in [RFC4326] and 603 further information on security aspects of using ULE are described 604 in the security considerations of [RFC4259] and [ID-Sec-Req]. 606 7. References 608 7.1 Normative References 610 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, 1997. 613 [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 614 Lightweight Encapsulation (ULE) for transmission of IP datagrams 615 over an MPEG-2 Transport Stream", RFC 4326, December 2005. 617 [GSE] "Generic Stream Encapsulation", DVB Document A116, DVB 618 Technical Module (GBS Group), May 2007. 620 7.2 Informative References 622 [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second 623 generation framing structure, channel coding and modulation systems 624 for Broadcasting, Interactive Services, News Gathering and other 625 broadband satellite applications", European Telecommunication 626 Standards Institute (ETSI). 628 [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- 629 S2", Internet-Draft , Work in 630 Progress. 632 [ID-Sec-Req] "Security requirements for the Unidirectional 633 Lightweight Encapsulation (ULE) protocol", Internet-Draft < draft- 634 ietf-ipdvb-sec-req-04.txt>, Work in Progress. 636 [IEEE-802.3] "Local and metropolitan area networks - Specific 637 requirements Part 3: Carrier sense multiple access with collision 638 detection (CSMA/CD) access method and physical layer 639 specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC 640 8802-3), 2002. 642 [ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology; 643 Generic Coding of Moving Pictures and Associated Audio Information 644 Systems", International Standards Organisation (ISO). 646 [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- 647 Nocker, B., and H. Linder, "A Framework for Transmission of IP 648 Datagrams over MPEG-2 Networks", RFC 4259, November 2006. 650 [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution 651 Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 652 2007. 654 Authors' Addresses 656 Godred Fairhurst 657 School of Engineering 658 University of Aberdeen 659 Aberdeen AB24 3UE 660 UK 662 Email: gorry@erg.abdn.ac.uk 663 URI: http://www.erg.abdn.ac.uk 665 Bernhard Collini-Nocker 666 Department of Computer Sciences 667 University of Salzburg 668 Jakob Haringer Str. 2 669 5020 Salzburg 670 Austria 672 EMail: bnocker@cosy.sbg.ac.at 673 URI: http://www.cosy.sbg.ac.at 674 Full Copyright Statement 676 Copyright (C) The IETF Trust (2007). 678 This document is subject to the rights, licenses and restrictions 679 contained in BCP 78, and except as set forth therein, the authors 680 retain all their rights. 682 This document and the information contained herein are provided on an 683 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 684 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 685 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 686 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 687 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 688 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 690 Intellectual Property Statement 692 The IETF takes no position regarding the validity or scope of any 693 Intellectual Property Rights or other rights that might be claimed 694 to pertain to the implementation or use of the technology described 695 in this document or the extent to which any license under such 696 rights might or might not be available; nor does it represent that 697 it has made any independent effort to identify any such rights. 698 Information on the procedures with respect to rights in RFC 699 documents can be found in BCP 78 and BCP 79. 701 Copies of IPR disclosures made to the IETF Secretariat and any 702 assurances of licenses to be made available, or the result of an 703 attempt made to obtain a general license or permission for the use 704 of such proprietary rights by implementers or users of this 705 specification can be obtained from the IETF on-line IPR repository 706 at http://www.ietf.org/ipr. 708 The IETF invites any interested party to bring to its attention any 709 copyrights, patents or patent applications, or other proprietary 710 rights that may cover technology that may be required to implement 711 this standard. Please address the information to the IETF at ietf- 712 ipr@ietf.org. 714 Copyright Statement 716 Copyright (C) The IETF Trust (2007). 718 This document is subject to the rights, licenses and restrictions 719 contained in BCP 78, and except as set forth therein, the authors 720 retain all their rights. 722 APPENDIX: The Second Generation DVB Transmission Specifications 724 This section provides informative background to the network layer 725 requirements of the second generation DVB Transmission 726 Specifications. The second generation waveforms specified by the 727 Digital Video Broadcasting project offer two main enhancements. 728 First, more efficient physical layer methods that employ higher 729 order modulation with stronger FEC and permit adaptive coding and 730 modulation response to changes in traffic and propagation 731 conditions. Second, at the link layer, they offer greater 732 flexibility in framing. Support is provided for a range of stream 733 formats including the classical Transport Stream (TS) [RFC4259]. In 734 addition, a new method called Generic Streams (GS) (or the Generic 735 Mode) is supported. A GS can be packetized or continuous and is 736 intended to provide native transport of other network-layer 737 services. One such method is that provided by the Generic Stream 738 Encapsulation (GSE) [GSE]. 740 For example, the DVB-S2 [ETSI-S2] transmission link sequentially 741 multiplexes a series of baseband frames (BBFrames). Each BBFrame 742 comprises a fixed-size 10B header and a payload. The payload carries 743 a DataField and uses padding to fill any unused space. A stream 744 comprises a sequence of BBFrames associated with an Input Stream 745 Identifier (ISI) that is carried in the header of each BBFrame. The 746 simplest scheme uses a single stream (with just one ISI value), but 747 multiple streams are permitted. The BBFrames forming a stream may be 748 of variable size (selected from a set of allowed sizes), and must 749 use the same stream format (e.g. TS or GSE). Each stream represents 750 an independent link with independent address resolution [RFC4947]. 752 GSE provides functions that are equivalent to those of the 753 Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It 754 supports the transmission of IP packets and other network-layer 755 protocols. The network-layer interface resembles that of ULE, where 756 it adopts common mechanisms for a Length field, a 16-bit Type field, 757 and support for Extension Headers. As in ULE, GSE permits multiple 758 address formats, indicated by the LT field (functionally equivalent 759 to the D field in ULE). The default addressing mode uses a 6-byte 760 NPA and a suppressed NPA address (functionally equivalent to D=1 in 761 ULE). 763 GSE also provides more flexible fragmentation at the interface to 764 the physical layer (using the S and E flags). This adapts the SNDUs 765 to a variable-sized link-layer frame, and reflects the more complex 766 requirements in terms of fragmentation and assembly that arise when 767 using point-to-multipoint adaptive physical layers. The integrity of 768 a reassembled SNDUs is provided by a CRC-32 in the last fragment for 769 the corresponding PDU. 771 [RFC EDITOR NOTE: 772 This section must be deleted prior to publication] 774 DOCUMENT HISTORY 776 Individual Draft 00 777 This draft complements a study item in the DVB-GBS in this area to 778 define a Generic Stream Encapsulation (GSE). Comments relating to 779 this document will be gratefully received by the author(s) and may 780 also be sent to ip-dvb mailing list. 782 Individual Draft 01 783 Co-Author Added. 784 This draft updates the language and format. 785 This draft fixes problems with the concatenation mode, and defines a 786 new header format that restricts the use of the Type field so that 787 all concatenated PDUs MUST have the same Type. 789 Future versions of this draft may define additional Extension 790 Headers, proposals and ideas are welcome via the IETF ipdvb mailing 791 list. Possible extensions include those for encapsulation FEC, Link 792 parameter negotiation (e.g. for header compression), and support for 793 ATM/ULE. 795 Working Group Draft 00 796 Fixed editorial mistakes from Christian Praehauser and ID style for 797 WG adoption. 799 Working Group Draft 01 800 Corrected contact info for Bernhard. 801 Added TimeStamp Options 802 Corrected NITS in draft 804 Working Group Draft 01 805 Amended diagrams and text to follow tentative IANA assignments for 806 the codepoints. 808 Working Group Draft 01 809 Amended text to follow IANA assignments for the codepoints. 810 Added issues raised at ipdvb meeting by C Praehauser. 811 Revised appendix with text from GSE Spec, J Cantillo, et al. 812 Revised wording to clarify corner cases. 813 Removed references to documents not in public domain. 814 Updated conventions and abbreviations for consistency. 815 Updated text referencing ULE. 817 Working Group Draft 02 819 Added rules for Types of PDUs in PDU-Concat. 820 Added appendix on DVB 2 nd generation. 821 Added new text on timers to control concat (from list). 823 Working Group Draft 03 825 Added a table to the start of the method defining recommended. 826 Fixed NiTs. 828 Working Group Draft 04 Draft 829 Editorial changes to prepare the document for WGLC. 830 Updated IANA section to comply with RFC4326 IANA Guidelines. 832 Reduced Security considerations section by reference to other 833 documents that give a fuller discussion. 835 There were no intentional changes to the protocol specification. 837 [END of RFC EDITOR NOTE]