idnits 2.17.1 draft-byun-ipdvb-ule-header-comp-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 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 437. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 ([DVB-S2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (April 23, 2007) is 6212 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC4259' is mentioned on line 86, but not defined == Missing Reference: 'IEEE-802.3' is mentioned on line 102, but not defined == Missing Reference: 'ETSI-DAT' is mentioned on line 107, but not defined == Missing Reference: 'ATSC-DAT' is mentioned on line 107, but not defined == Missing Reference: 'ATSC-DATG' is mentioned on line 107, but not defined Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Do J. Byun 2 November 20, 2006 John Border 3 Category: Experimental Roderick Ragland 4 Expiration: April 23, 2007 6 Header Compression over Unidirectional Lightweight Encryption (ULE) 7 draft-byun-ipdvb-ule-header-comp-01.txt 9 Status of This Memo 11 This memo defines an Experimental Protocol for the Internet 12 community. It does not specify an Internet standard of any kind. 13 Discussion and suggestions for improvement are requested. 14 Distribution of this memo is unlimited. 16 Copyright Notice 18 Copyright (C) The Internet Society (2006). 20 Intellectual Property Right 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Abstract 44 Multi-Protocol Encapsulation (MPE) is widely deployed in DVB-S and 45 DVB-S2 networks [DVB-S2]. Replacing MPE with Unidirectional 46 Lightweight Encryption (ULE) has been proposed to gain flexibility 47 and reduce overhead. This paper introduces a signaling method for 48 sending header-compressed unicast packets over satellite networks 49 using ULE, taking advantage of ULE's increased flexibility. 51 Ed. Note: This is a quick first draft to get the discussion going. 53 Header Compression over ULE October 2006 55 Table of Contents 57 1. Introduction ...................................................1 58 2. Terminology ....................................................1 59 3. Signaling Method ...............................................3 60 3.1. SNDU Format ...............................................3 61 3.2. Header Compression Algorithm ..............................4 62 3.3. Multicast and Broadcast Traffic ...........................5 63 4. Summary ........................................................5 64 5. Acknowledgements ...............................................6 65 6. Security Considerations ........................................6 66 7. IANA Considerations ............................................6 67 8. References .....................................................6 69 1. Introduction 71 Header compression is a mechanism that compresses the header fields 72 that do not change or change in predictable ways. RFC 3095 73 defines "Robust Header Compression (ROHC)" as a standard for 74 compressing RTP/UDP/IP, UDP/IP and ESP/IP headers. [RFC3095]. There 75 could be other proprietary compression schemes besides ROHC. 77 To support header compression, the link-layer has to be flexible 78 enough to indicate whether the payload is header-compressed or not. 79 Such indication has been difficult with MPE due to its limited 80 flexibility in its header format. 82 Unidirectional Lightweight Encryption has been proposed to overcome 83 this shortcoming of MPE and there had been numerous proposals to 84 standardize one as the link-layer protocol of DVB-S2 [GSE]. This 85 document describes how ULE is used to support header compression 86 over ISO MPEG-2 transport streams [ISO-MPEG2, RFC4259] for 87 peer-to-peer traffic. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119. 95 DVB 96 Digital Video Broadcast. A framework and set of associated 97 standards published by the European Telecommunications Standards 98 Institute (ETSI) for the transmission of video, audio, and data 99 using the ISO MPEG-2 Standard [ISO-MPEG2]. 101 MAC 102 Medium Access Control [IEEE-802.3]. A link-layer protocol defined 103 by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). 105 Header Compression over ULE October 2006 106 MPE 107 Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. A 108 scheme that encapsulates PDUs, forming a DSM-CC Table Section. 109 Each Section is sent in a series of TS Packets using a single TS 110 Logical Channel. 112 MPEG-2 113 A set of standards specified by the Motion Picture Experts 114 Group (MPEG) and standardized by the International Standards 115 Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 116 [ITU-H222]). 118 PSI 119 Program Specific Information [ISO-MPEG2]. Tables used to convey 120 information about the service carried in a TS Multiplex. The 121 information is carried in one of four specifically identified 122 Table Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table. 124 PDU 125 Protocol Data Unit. Examples of a PDU include Ethernet frames, 126 IPv4 or IPv6 datagrams, and other network packets. 128 Receiver 129 Equipment that processes the signal from a TS Multiplex and 130 performs filtering and forwarding of encapsulated PDUs to the 131 network-layer service (or bridging module when operating at the 132 link layer). 134 SI Table 135 Service Information Table [ISO-MPEG2]. In this document, this 136 term describes a table that is defined by another standards body 137 to convey information about the services carried in a TS 138 Multiplex. A Table may consist of one or more Table Sections; 139 however, all sections of a particular SI Table must be carried 140 over a single TS Logical Channel [ISO-MPEG2]. 142 SNDU 143 SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 144 Payload Unit. 146 TS 147 Transport stream (TS) is a format specified in MPEG-2 Part 1, 148 Systems (ISO/IEC standard 13818-1). Its design goal is to allow 149 multiplexing of digital video and audio and to synchronize the 150 output. Transport stream offers features for error correction for 151 transportation over unreliable media, and is used in broadcast 152 applications such as DVB and ATSC. 154 ULE Stream 155 An MPEG-2 TS Logical Channel that carries only ULE encapsulated 156 PDUs. ULE Streams may be identified by definition of a 157 stream_type in SI/PSI [ISO-MPEG2]. 159 Header Compression over ULE October 2006 161 3. Signaling Method 163 Header compression shall be indicated by the EtherType field of the 164 ULE header. When this this field is set to header compression type, 165 the payload is header-compressed. The actual type of header 166 compression is determined during the context establishment between 167 the two peers (one compressor and one decompressor). Therefore, the 168 method by which the payload is compressed and decompressed is part of 169 the compression context. Moreover, compression context control 170 messages can also be header-compressed but their context will be 171 different from the one for the actual user data. 173 Decompressor Compressor 175 | | 176 | <----- (EtherType=IPv4) Uncompressed Payload ------ | 177 | ------ (EtherType=IPv4) Compression Request -----> | 178 | <----- (EtherType=IPv4) Compression Ack ------ | 179 | <----- (EtherType=Comp) Compressed Header Payload ------ | 180 | <----- (EtherType=Comp) Compressed Header Payload ------ | 181 Something Bad Happens 182 | ------ (EtherType=IPv4) Compression Error -----> | 183 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 184 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 186 Figure 1: Header compression example 188 Figure 1 illustrates an example where control messages (that signal 189 and synchronize peers to compress/decompress) are not 190 header-compressed but the user data messages are. When EtherType is 191 set to 'Comp' whose hex value is TBD, the ULE payload contains 192 header-compressed user data messages. 194 The EtherType of TBD will be a newly registered IANA EtherType number 195 that indicates a compression algorithm that is agreed by both the 196 sender and receiver. In other words, it could be any proprietary 197 header compression algorithm as long as the receiver knows how to 198 decompress it. EtherType of 0x876B (TCP/IP Compression [RFC1144]) 199 was intentionally not used because it is currently defined to imply 200 a specific header-compression algorithm. 202 3.1. SNDU Format 204 This section describes the SNDU format of the MPEG-2 PDU with ULE 205 where headers for PDU are compressed. 207 < ----------------------------- SNDU ----------------------------- > 208 +-+-------------------------------------------------------+--------+ 209 |D| Length | Type | Dest Address* | PDU | CRC-32 | 210 +-+-------------------------------------------------------+--------+ 212 Figure 2: SNDU Encapsulation (* optional Destination Address) 213 Header Compression over ULE October 2006 215 The definition of all of the fields in Figure 2 stays the same as the 216 definition in [RFC4326]. The 16-bit type field will have a new 217 EtherType to indicate the PDU is header-compressed with an algorithm 218 that both sender and received agreed on. The hex value for this type 219 is TBD. Note that the new header-compressed PDU EtherType does not 220 indicate a specific header-compression algorithm. It is the sender 221 and receiver's responsibility to make sure the algorithm is 222 synchronized. 224 Ed. Note: This is one of the main points we want to discuss on the 225 mailing list. 227 3.2. Header Compression Algorithm 229 In order to use the proposed EtherType to indicate the PDU is 230 header-compressed, both the sender and receiver have to agree with 231 the compression algorithm. This is not an issue because such 232 synchronization is always required in peer-to-peer header compression 233 anyway. 235 Incapable Incompatible 236 Decompressor Compressor 238 | | 239 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 240 | Waiting for 241 | Comp Request 242 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 243 | Waiting for 244 | Comp Request 245 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 246 | Waiting for 247 | Comp Request 248 | | 250 Figure 3: Incapable decompressor 252 Figure 3 illustrates a scenario where the decompressor (receiver) is 253 not capable of decompressing the packets that the compressor (sender) 254 sent. The decompressor does not send any compression request to the 255 compressor and the compressor continues to send uncompressed headers 256 to the decompressor with non-header-compression EtherType. 258 Header Compression over ULE October 2006 260 Incompatible Incompatible 261 Decompressor Compressor 263 | | 264 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 265 | ------ (EtherType=IPv4) Compression Request -----> | 266 | detects 267 | incompatible 268 | decompressor 269 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 270 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 271 | <----- (EtherType=IPv4) Uncompressed Header Payload ------ | 272 | | 274 Figure 4: Incompatible compressor and decompressor 276 Figure 4 illustrates a scenario where the compressor is not 277 compatible with the decompressor and therefore it continues to send 278 uncompressed headers to the decompressor with non-header-compression 279 EtherType. 281 Specifics of a header compression algorithm may differ widely. They 282 include the way header-compression is initiated and synchronized. 283 For example, compression request messages can be initiated by the 284 compressor instead of decompressor. Regardless of the algorithm, 285 the header-compression indication method proposed here signals the 286 decompressor that the payload is header-compressed with the algorithm 287 that it agreed to use. 289 3.3. Multicast and Broadcast Traffic 291 Since out of band synchronization is also assumed for multicast and 292 broadcast, the proposed header-compressed PDU signaling scheme 293 supports multicast and broadcast as well. 295 4. Summary 297 This document defines a mechanism to signal the receiver that the 298 payload is header-compressed using ULE as the link layer. The 299 mechansim is compatible with any peer-to-peer header compression 300 algorithm. It uses a newly proposed EtherType to indicate that the 301 payload is header-compressed. The EtherType has the value of TBD 302 which is not tied to a specific header compression algorithm. 304 The proposed method to indicate header-compressed payload is not for 305 multicast and broadcast as there is no gaurantee that the receivers 306 are compatible decompressors. 308 Header Compression over ULE October 2006 310 5. Acknowledgements 312 TBD 314 6. Security Considerations 316 The proposed header compression signaling method does not introduce 317 any additional security concerns. 319 7. IANA Considerations 321 A new EtherType number will be proposed to the IANA EtherType 322 registry. This number will be used to indicate that the ULE PDU is 323 header-compressed as described in this document. 325 8. References: 327 8.1. Normative References 329 [ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding 330 of moving pictures and associated audio information -- 331 Part 1: Systems", International Standards Organization 332 (ISO), 2000. 334 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for 335 Low-Speed Serial Links", 1990. 337 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., et al, 338 "Robust Header Compression (ROHC): Framework and four 339 profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 340 2001. 342 [RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional 343 Lightweight Encapsulation (ULE) for Transmission of IP 344 Datagrams over an MPEG-2 Transport Stream (TS)", 345 RFC 4326, 2005. 347 [DVB-S2] Digital Video Broadcasting (DVB); Second generation 348 framing structure, channel coding and modulation 349 systems for Broadcasting, Interactive Services, News 350 Gathering and other broadband satellite applications, 351 ETSI EN 302 307 V1.1.1, 2005. 353 8.2. Informative References 355 [GSE] Fairhurst, G., "A Network-Layer Interface To The 356 Second Generation Standard For DVB Over Satellite", 357 Work in Progress, September 2006. 359 Header Compression over ULE October 2006 361 [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, 362 "Ethernet Local Area Network Specification" Version 363 2.0, November 1982. 365 [ITU-H222] H.222.0, "Information technology - Generic coding of 366 moving pictures and associated audio information: 367 Systems", International Telecommunication Union, 368 (ITU-T), 1995. 370 Authors' Addresses 372 Do J. Byun 373 Hughes Network Systems 374 11717 Exploration Lane 375 Germantown, MD, 20876 376 USA 378 EMail: dbyun@hns.com 380 John Border 381 Hughes Network Systems 382 11717 Exploration Lane 383 Germantown, MD, 20876 384 USA 386 EMail: border@hns.com 388 Roderick Ragland 389 Hughes Network Systems 390 11717 Exploration Lane 391 Germantown, MD, 20876 392 USA 394 EMail: rragland@hns.com 396 Comments are solicited and should be addressed to the authors. 398 Header Compression over ULE October 2006 399 Full Copyright Statement 401 Copyright (C) The Internet Society (2006). 403 This document is subject to the rights, licenses and restrictions 404 contained in BCP 78, and except as set forth therein, the authors 405 retain all their rights. 407 This document and the information contained herein are provided on an 408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 410 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 415 Intellectual Property 417 The IETF takes no position regarding the validity or scope of any 418 Intellectual Property Rights or other rights that might be claimed to 419 pertain to the implementation or use of the technology described in 420 this document or the extent to which any license under such rights 421 might or might not be available; nor does it represent that it has 422 made any independent effort to identify any such rights. Information 423 on the procedures with respect to rights in RFC documents can be 424 found in BCP 78 and BCP 79. 426 Copies of IPR disclosures made to the IETF Secretariat and any 427 assurances of licenses to be made available, or the result of an 428 attempt made to obtain a general license or permission for the use of 429 such proprietary rights by implementers or users of this 430 specification can be obtained from the IETF on-line IPR repository at 431 http://www.ietf.org/ipr. 433 The IETF invites any interested party to bring to its attention any 434 copyrights, patents or patent applications, or other proprietary 435 rights that may cover technology that may be required to implement 436 this standard. Please address the information to the IETF at ietf- 437 ipr@ietf.org.