idnits 2.17.1 draft-ietf-ipdvb-ule-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 638. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4236], [GSE], [S2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in 'Category: WG Draft intended for PS', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6250 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) == Missing Reference: 'IEEE-802.3' is mentioned on line 154, but not defined == Missing Reference: 'RFC4326' is mentioned on line 493, but not defined Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gorry Fairhurst 2 Internet Draft University of Aberdeen 3 Expires July 2007 B. Collini-Nocker 4 University of Salzburg 6 Category: WG Draft intended for PS March 2007 8 Extension Formats for Unidirectional Link Encapsulation (ULE) 9 and the Generic Stream Encapsulation (GSE) 10 draft-ietf-ipdvb-ule-ext-01.txt 12 Status of this Draft 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a set of Extension Headers for the 35 Unidirectional Link Encapsulation (ULE) [RFC4236]. 37 The Extension Header formats defined in this document define new 38 extensions that are common extensions to both ULE and the Generic 39 Stream Encapsulation (GSE) [GSE] defined by the second generation 40 framing structure DVB-S2 standard [S2]. 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. Summary 55 5. IANA Considerations 57 6. Acknowledgments 59 7. Security Considerations 61 8. References 62 8.1 Normative References 63 8.2 Informative References 65 9. Authors' Addresses 67 10. IPR Notices 68 10.1 Intellectual Property Statement 69 10.2 Disclaimer of Validity 71 11. Copyright Statement 72 11.1 Intellectual Property Statement 73 11.2 Disclaimer of Validity 75 Appendix A: 77 1. Introduction 79 This document describes two new Header Extensions that may be used 80 with both Unidirectional Link Encapsulation, ULE, [RFC4236] and the 81 Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links 82 that employ the MPEG-2 Transport Stream, and supports a wide variety 83 of physical-layer bearers [RFC4259]. 85 GSE has been designed for the Generic Mode (also known as the 86 Generic Stream (GS)), offered by second-generation DVB physical 87 layers, and specifically for DVB-S2 [ETSI-S2]. The requirements for 88 the Generic Stream are defined in [S2-REQ], [S2-REQ-RCS], and [ID- 89 S2-REQ]. The important characteristics of this encapsulation are 90 described in an Appendix to this document. GSE maintains a design 91 philosophy that presents a common network interface to that of ULE 92 and uses a similar construction for Subnetwork Data Unit (SNDUs). 94 One extension header defines a method that allows one or more TS- 95 Packets [ISO-MPEG] to be sent within a ULE SNDU. This method may be 96 used to provide control plane information including the transmission 97 of MPEG-2 Program Specific Information (PSI) for the Multiplex. In 98 GSE, there is no native support for transport stream packets and 99 this method is therefore suitable for providing an MPEG-2 control 100 plane. 102 A second extension header allows one or more PDUs to be sent within 103 the same ULE SNDU. This method is designed for cases where a large 104 number of small PDUs are directed to the same Network Point of 105 Attachment (NPA) address. The method may improve transmission 106 efficiency (by removing duplicated MAC layer overhead). It can also 107 reduce processing overhead for receivers that are not addressed by 108 the NPA, since these receivers may then skip several PDUs in one 109 operation. The method is defined as a generic extension header and 110 may be used for IPv4 or IPv6 packets. If and when a compression 111 format is defined for ULE or Ethernet, the method may also be used 112 in combination with this method. 114 A third extension header provides an optional timestamp value for an 115 SNDU. Examples of the use of this timestamp option include 116 monitoring and benchmarking of ULE and GSE links. Receivers that do 117 not wish to decode (or do not support) the timestamp extension may 118 discard the extension and process the remaining PDU or extension 119 headers. 121 The appendix includes a summary of key design issues and 122 considerations based on the GSE Specification defined by the DVB 123 Technical Module [GSE]. 125 2. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 128 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 RFC 2119 [RFC2119]. 132 b: bit. For example, one byte consists of 8b. 134 B: Byte. Groups of bytes are represented in Internet byte order. 136 BBFrame payload [ETSI-S2]: The data field part of a Baseband frame 137 that may be used for the communication of data. Typical BBFrames 138 range in size from 3072 to 58192 bits according to the choice of 139 modulation format and FEC in use. 141 DVB: Digital Video Broadcast. A framework and set of 142 associated standards published by the European Telecommunications 143 Standards Institute (ETSI) for the transmission of video, audio, and 144 data. 146 Encapsulator: A network device that receives PDUs and formats these 147 into Payload Units (known here as SNDUs) for output in DVB-S or the 148 Generic Mode of DVB-S2. 150 GS: Generic Stream [S2]. 152 GSE: Generic Stream Encapsulation [GSE]. 154 MAC: Medium Access Control [IEEE-802.3]. A link layer protocol 155 defined by the IEEE 802.3 standard (or by Ethernet v2). 157 MPEG-2: A set of standards specified by the Motion Picture Experts 158 Group (MPEG), and standardized by the International Standards 159 Organisation (ISO/IEC 113818-1) [ISO-MPEG], and ITU-T (in H.220). 161 Next-Header: A Type value indicating an Extension Header [RFC4236]. 163 NPA: Network Point of Attachment [RFC4236]. 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 PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include 169 Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. 171 PSI: Program Specific Information [ISO-MPEG]. 173 SI Table: Service Information Table [ISO-MPEG]. In this document, 174 this term describes a table that is been defined by another 175 standards body to convey information about the services carried on a 176 DVB carrier. 178 SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an 179 encapsulated PDU sent using ULE or GSE. 181 Stream: A logical flow from an Encapsulator to a set of Receivers. . 183 TS: Transport Stream [ISO-MPEG], a method of transmission at the 184 MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 185 reference model. 187 ULE: Unidirectional Link Encapsulation (ULE) [RFC4236]. A scheme 188 that encapsulates PDUs, into SNDUs that are sent in a series of TS 189 Packets using a single TS Logical Channel. The encapsulation format 190 defined by this document shares the same extension format, and basic 191 processing rules and uses a common IANA Registry. 193 3. Description of the Method 195 In ULE, a Type field value that is less than 1536 Decimal indicates 196 an Extension Header. This section describes a set of two extension 197 formats for the ULE encapsulation. The GSE specification is defined 198 in [GSE] and follows these formats, but as in other SNDU formats, 199 GSE does not include a per-SNDU CRC and utilises a different SNDU 200 length calculation [GSE]. 202 3.1 MPEG-2 TS-Concat Extension 204 >>> IANA Action required, please replace < #NH-TS-CAT> with assigned 205 value from the Next-Header Registry>>> 207 The MPEG-2 TS-Concat Extension Header is specified by an IANA 208 assigned H-Type value of <#NH-TS-CAT>. This is a Mandatory Next- 209 Header Extension. 211 The extension is used to transport 1 or more MPEG-2 TS Packets 212 within a ULE SNDU. The number of TS Packets carried in a specific 213 SNDU is determined from the size specified by the remainder of the 214 Payload following the MPEG-2 TS Extension. The number of TS packets 215 contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N 216 is the number of bytes associated with Extension Headers that 217 precede the MPEG-2 TS-Concat Extension (zero if there are none). A 218 Receiver MUST check that the payload length is correct prior to 219 processing it. Any mismatch (remainder from the division) MUST 220 result in discard of all encapsulated PDUs and SHOULD be recorded as 221 TS-concat size mismatch error. 223 A value D=0 indicates the presence of a NPA address. In that case 224 the correct payload length for ULE is (Length-10) / 188, whereas in 225 case of GSE the correct payload length is (Length-6) / 188. 227 >>> IANA Action required, please replace < #NH-TS-CAT> with assigned 228 value from the Next-Header Registry>>> 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |0| Length (15b) | Type = 0x <#NH-TS-CAT> | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Receiver Destination NPA Address (6B) | 234 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 237 | TS-Packet 1 | 238 = = 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | TS-Packet 2 (if Length > 2*188) | 242 = = 243 | etc. | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | (CRC-32) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) 250 >>> IANA Action required, please replace <#NH-TS-CAT> with assigned 251 value from the Next-Header Registry>>> 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 =0x <#NH-TS-CAT> | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 2: GSE/SNDU Format for a TS-Packet Payload (D=0) 272 Note that fragmented GSE SNDUs are protected by a CRC-32 carried in 273 the final fragment, and that non-fragmented GSE SNDUs are protected 274 by a CRC-32 in the final bytes of the GS DataField. 276 A value of D=1, is also permitted and indicates the absence of a NPA 277 address, as defined in ULE. A similar format is supported in GSE. 279 >>> IANA Action required, please replace <#NH-TS-CAT> with assigned 280 value from the Next-Header Registry>>> 282 0 1 2 3 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 |1| Length (15b) | Type = 0x<#NH-TS-CAT> | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | TS-Packet 1 | 288 = = 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | TS-Packet 2 (if Length > 2*188) | 292 = = 293 | etc. | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | (CRC-32) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) 300 The extension may be used to transport one or more MPEG-2 TS Packets 301 of arbitrary content, interpreted according to [ISO-MPEG]. One 302 expected use is for the transmission of MPEG-2 SI/PSI signalling. 304 The use of this format to transfer MPEG-2 clock references (e.g. a 305 Network Clock Reference, NCR, SI Table) over ULE/GSE framing raises 306 timing considerations at the encapsulation gateway, including the 307 need to update/modify the timing information prior to transmission 308 by the physical layer. These issues are not considered here, but it 309 is noted that the operation may be simplified by ensuring that all 310 SNDUs that carry this Extension Header are placed before other data 311 within the GSE DataField [GSE]. 313 3.2 PDU-Concat Extension 315 >>> IANA Action required, please replace <#NH-PDU-CAT> with assigned 316 value from the Next-Header Registry>>> 318 The PDU-Concat Extension is specified by an IANA assigned H-Type 319 value of <#NH-PDU-CAT> This is a Mandatory Next-Header Extension. 320 It enables a sequence of (usually short) PDUs to be sent within a 321 single SNDU payload. 323 The base header contains the Length of the entire SNDU. This carries 324 the value of the combined length of all PDUs to be encapsulated, 325 including each set of encapsulation headers. The base header also 326 caries a 16-bit ULE Type field. Although any Type value specified in 327 the ULE Next-Header Registry may be assigned to the encapsulated 328 PDU, all PDUs included in the SNDU payload MUST have a common ULE 329 Type (i.e. all concatenated PDUs passed by the network layer must be 330 associated with the same Type value). This simplifies the receiver 331 design, and reduces the transmission overhead for common use cases. 333 Each PDU is prefixed by its length in bytes (shown as PDU-Length in 334 the following diagrams). Encapsulated PDUs are of arbitrary length 335 (in bytes) and are not necessarily aligned to 16-bit or 32-bit 336 boundaries within the SNDU (as shown in the figure). The most 337 significant bit of the first byte MUST be set to zero. The length of 338 each PDU MUST be less than 32 758 bytes, but will generally be much 339 smaller. 341 When the SNDU header indicates the presence of an SNDU Destination 342 Address field (i.e. D=0), a Network Point of Attachment, NPA, field 343 directly follows the fourth byte of the SNDU header. NPA destination 344 addresses are 6 Byte numbers, normally expressed in hexadecimal, 345 used to identify the Receiver(s) in a transmission network that 346 should process a received SNDU. When present the Receiver MUST 347 associate the same specified MAC/NPA address with all PDUs within 348 the SNDU Payload. This MAC/NPA address MUST also be forwarded with 349 each PDU, if required by the forwarding interface. 351 >>> IANA Action required, please replace <#NH-PDU-CAT> with assigned 352 value from the Next-Header Registry in the next two figures>>> 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 |1| Length (15b) | Type = 0x<#NH-PDU-CAT> | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Receiver Destination NPA Address (6B) | 359 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | CONCAT-PDU-Type | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |0| PDU-Length-1 (15b) | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 364 = PDU-1 = 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |0| PDU-Length-2 (15b) | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 369 = PDU-2 = 370 | | 372 More PDUs as required 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | (CRC-32) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0) 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 |1| Length (15b) | Type = 0x<#NH-PDU-CAT> | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Receiver Destination NPA Address (6B) | 385 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | CONCAT-PDU-Type | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |0| PDU-Length-1 (15b) | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 390 = PDU-1 = 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |0| PDU-Length-2 (15b) | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 395 = PDU-2 = 396 | | 398 More PDUs as required 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 5: GSE/SNDU Format for a PDU-Concat Payload (D=0) 403 A value of D=1 indicates there is no NPA/MAC address in use. This 404 field MUST be carried (i.e. D=0) for IP unicast packets destined to 405 routers that are sent using shared links (i.e., where the same link 406 connects multiple Receivers). A sender MAY omit this field (D=1) for 407 a set of packets delivered to a Receiver or group of receivers that 408 are able to utilise a discriminator field (e.g. the IPv4/IPv6 409 destination address, or a bridged MAC destination address), which in 410 combination with the PID value, could be interpreted as a Link-Level 411 address. A similar format is supported in GSE. 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |1| Length (15b) | Type = 0x<#NH-PDU-CAT> | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | CONCAT-PDU-Type |0| PDU-Length-1 (15b) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 = PDU-1 = 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |0| PDU-Length-2 (15b) | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 424 = PDU-2 = 425 | | 427 More PDUs as required 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | (CRC-32) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1) 435 The Receiver processes this Extension Header by verifying that it 436 supports the specified CONCAT-PDU Type (unsupported Types MUST be 437 discarded but the receiver SHOULD record a PDU-Type error). It then 438 extracts each encapsulated PDU in turn. The Receiver MUST verify the 439 Length of each PDU. It MUST also ensure the sum of the Lengths of 440 all processed PDUs is less than the Length specified in the SNDU 441 base header. A Receiver MUST discard the whole SNDU if the sizes do 442 not match and this event SHOULD be recorded as a PDU-concat size 443 mismatch error. 445 3.3 Timestamp Extension 447 The timestamp extension header permits an Encapsulator to add a 448 timestamp field to an SNDU. This is designed to support monitoring 449 and measurement of ULE performance over a link to indicate the 450 quality of an operational ULE link. This may be useful for GSE links 451 (where significant complexity exists in the scheduling provided by 452 the lower layers). This extension may be (optionally) checked at the 453 Receiver. 455 Possible uses of this extension include: 457 * Validation of in-sequence ordering per Logical Channel, 458 * Measurement of one-way delay (when synchronised with the sender) 459 * Measurement of PDU Jitter introduced by the link, 460 * PDU loss (with additional information from the sender). 462 >>> IANA please insert a value for the H-Type from the Optional part 463 of the Next-Header Registry, and replace in the sentence 464 below, and the figure following <<< 466 The Timestamp Extension Header is specified by the IANA-assigned H- 467 Type of . This extension is an Optional Extension Header 468 ([RFC4326], Section 5). 470 0 7 15 23 31 471 +---------------+---------------+---------------+---------------+ 472 | 0x03 | | time stamp HI | 473 +---------------+---------------+---------------+---------------+ 474 | time stamp LO | Type | 475 +---------------+---------------+---------------+---------------+ 477 Figure 7 The format of the 32-bit Timestamp Extension Header 479 Figure 7 shows the format of this extension with a HLEN value of 3 480 indicating a timestamp of length 4B with a Type field (there is no 481 implied byte-alignment). 483 The extension carries a 32-bit value (time stamp HI plus time stamp 484 LO). The specified resolution is 1 microsecond. The value therefore 485 indicates the number of 1 microsecond ticks past the hour in 486 Universal Time when the timestamp option was inserted, right- 487 justified to the 32-bit field. Systems unable to insert timestamps 488 at the specified resolution may use an arbitrary (and varying) value 489 to pad the unused least-significant bits. 491 The last two bytes carry a 16-bit Type field that indicates the type 492 of payload carried in the SNDU, or the presence of a further Next- 493 Header ([RFC4326], Section 4.4). 495 This is an Optional Extension Header. Receivers that do not 496 implement, or do not wish to process, the Timestamp Extension MAY 497 skip this extension and continue to process the remainder of the 498 SNDU, forwarding the encapsulated PDU. 500 4. Summary 502 This document defines a set of Next_Header Extensions for the 503 Unidirectional Link Encapsulation (ULE). 505 5. IANA Considerations 507 This document requires IANA involvement for the assignment of two 508 new Next-Header Type values from the IANA ULE Next-Header Registry. 509 These options are defined for specific use cases envisaged by GSE, 510 but are compatible with ULE. 512 The TS-Concat Extension is a Mandatory next-type extension header, 513 specified in section 3.1 of this document. The value of this next- 514 header is defined by an IANA assigned H-Type value of <#NH-TS-CAT>. 516 The PDU-Concat Extension is a Mandatory next-type extension header 517 specified in section 3.2 of this document. The value of this next- 518 header is defined by an IANA assigned H-Type value of <#NH-PDU-CAT>. 520 The Timestamp Extension is an Optional next-type extension header 521 specified in section 3.3 of this document. The value of this next- 522 header is defined by an IANA assigned H-Type value of <#NH-TStamp>. 523 This documents defines format for a HLEN value of 0x3. 525 6. Acknowledgments 527 The author gratefully acknowledges the inputs, comments and 528 assistance offered by the members of the DVB-GBS ad hoc group on S2 529 encapsulation, in particular contributions on transmission aspects 530 from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. 532 7. Security Considerations 534 No specific security issues are raised within this document. 536 Additional security control fields may be provided as a part of a 537 link encryption Extension Header, e.g. to associate a PFU with one 538 of a set of Security Association (SA) parameters. As a part of the 539 encryption process, it may also be desirable to authenticate 540 some/all of the headers. The method of encryption and the way in 541 which keys are exchanged is beyond the scope of this specification, 542 as also are the definition of the SA format and that of the related 543 encryption keys. 545 8. References 547 8.1 Normative References 549 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 1997. 552 [RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 553 Link Encapsulation (ULE) for transmission of IP datagrams over an 554 MPEG-2 Transport Stream", RFC 4236, December 2006. 556 8.2 Informative References 558 [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", 559 European Telecommunications Standards Institute (ETSI). 561 [ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second 562 generation framing structure, channel coding and modulation systems 563 for Broadcasting, Interactive Services, News Gathering and other 564 broadband satellite applications", European Telecommunication 565 Standards Institute (ETSI). 567 [GSE] "Generic Stream Encapsulation", Work in Progress, DVB 568 Technical Module (GBS Group), 2006. 570 [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- 571 S2", Internet Draft , Work in 572 Progress. 574 [ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology; 575 Generic Coding of Moving Pictures and Associated Audio Information 576 Systems", International Standards Organisation (ISO). 578 [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- 579 Nocker, B., and H. Linder, "A Framework for Transmission of IP 580 Datagrams over MPEG-2 Networks", RFC 4259, November 2006. 582 [S2] EN 302 307, "Digital Video Broadcasting (DVB); Second 583 generation framing structure, channel coding and modulation systems 584 for Broadcasting, Interactive Services, News Gathering and other 585 broadband satellite applications", European Telecommunication 586 Standards Institute (ETSI). 588 [S2-REQ] GBS0339, "Functional and performance requirements for 589 IP/S2", DVB-TM (GBS WG). 591 [S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB Technical 592 Module (RCS WG). 594 9. Authors' Addresses 596 Godred Fairhurst 597 Department of Engineering 598 University of Aberdeen 599 Aberdeen, AB24 3UE 600 UK 601 Email: gorry@erg.abdn.ac.uk 602 Web: http://www.erg.abdn.ac.uk/users/Gorry 604 Bernhard Collini-Nocker 605 Department of Computer Sciences 606 University of Salzburg 607 Jakob Haringer Str. 2 608 5020 Salzburg 609 Austria 611 EMail: bnocker@cosy.sbg.ac.at 612 Web: http://www.cosy.sbg.ac.at/ 614 10. IPR Notices 616 10.1 Intellectual Property Statement 618 The IETF takes no position regarding the validity or scope of any 619 Intellectual Property Rights or other rights that might be claimed 620 to pertain to the implementation or use of the technology described 621 in this document or the extent to which any license under such 622 rights might or might not be available; nor does it represent that 623 it has made any independent effort to identify any such rights. 624 Information on the procedures with respect to rights in RFC 625 documents can be found in BCP 78 and BCP 79. 627 Copies of IPR disclosures made to the IETF Secretariat and any 628 assurances of licenses to be made available, or the result of an 629 attempt made to obtain a general license or permission for the use 630 of such proprietary rights by implementers or users of this 631 specification can be obtained from the IETF on-line IPR repository 632 at http://www.ietf.org/ipr. 634 The IETF invites any interested party to bring to its attention any 635 copyrights, patents or patent applications, or other proprietary 636 rights that may cover technology that may be required to implement 637 this standard. Please address the information to the IETF at ietf- 638 ipr@ietf.org. 640 10.2 Disclaimer of Validity 642 This document and the information contained herein are provided on 643 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 644 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 645 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 646 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 647 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 648 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 649 FOR A PARTICULAR PURPOSE. 651 11. Copyright Statement 653 Copyright (C) The IETF Trust (2007). 655 This document is subject to the rights, licenses and restrictions 656 contained in BCP 78, and except as set forth therein, the authors 657 retain all their rights. 659 APPENDIX: DVB-S.2 661 PDUs, (Ethernet Frames, IP datagrams or other network layer packets) 662 are encapsulated to form a Subnetwork Data Unit (SNDU) [RFC4236] 663 associated with a specific Stream at the link layer. The SNDU is 664 transmitted over an DVB-S2 link by placing it either in a single 665 BBFrame, or if required, an SNDU may be fragmented into a series of 666 BBFrames [ID-S2-REQ]. A mode also permits an SNDU to be fragmented 667 with the remaining fragments sent in a later BBFrame(s), while 668 preserving the original order of each SNDU sent to a specific 669 MAC/NPA address over a Stream. Where there is sufficient space, the 670 method permits a BBFrame to carry more than one SNDU (or part there 671 of), sometimes known as Packing. All parts comprising an SNDU are 672 assigned to the same Stream. 674 In ULE and MPE [ETSI-DAT], each SNDU carries a 32-bit CRC field in 675 the last four bytes of the SNDU. The purpose of this CRC is to 676 protect the SNDU (header, and payload) from undetected reassembly 677 errors and errors introduced by unexpected software / hardware 678 operation. This also serves to verify the delineation (framing) of 679 PDUs and may detect the presence of uncorrected errors from the 680 physical link 682 When an SNDU is sent over a DVB-S2 subnetwork using GSE, the 683 Integrity protection is provided by a CRC at the baseband frame 684 level, using a CRC in the final bytes of the DataField. 686 [RFC EDITOR NOTE: 687 This section must be deleted prior to publication] 689 DOCUMENT HISTORY 691 Individual Draft 00 692 This draft complements a study item in the DVB-GBS in this area to 693 define a Generic Stream Encapsulation (GSE). Comments relating to 694 this document will be gratefully received by the author(s) and may 695 also be sent to ip-dvb mailing list at: ip-dvb@erg.abdn.ac.uk 697 Individual Draft 01 698 Co-Author Added. 699 This draft updates the language and format. 700 This draft fixes problems with the concatenation mode, and defines a 701 new header format that restricts the use of the Type field so that 702 all concatenated PDUs MUST have the same Type. 704 Future versions of this draft may define additional Extension 705 Headers, proposals and ideas are welcome via the IETF ipdvb mailing 706 list. Possible extensions include those for encapsulation FEC, Link 707 parameter negotiation (e.g. for header compression), and support for 708 ATM/ULE. 710 Working Group Draft 00 712 Fixed editorial mistakes from Christian Praehauser and ID style for 713 WG adoption. 715 Working Group Draft 01 717 Corrected contact info for Bernhard. 718 Added TimeStamp Options 719 Corrected NITS in draft 721 [END of RFC EDITOR NOTE]