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