idnits 2.17.1 draft-ietf-rohc-lower-layer-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 23, 2000) is 8732 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) ** Obsolete normative reference: RFC 2509 (Obsoleted by RFC 3544) -- Possible downref: Non-RFC (?) normative reference: ref. 'ROCCO' Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Krister Svanbro, Ericsson 2 INTERNET-DRAFT Sweden 3 Expires: November 2000 May 23, 2000 5 Lower Layer Guidelines for Robust Header Compression 6 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/lid-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 This document is a submission of the IETF ROHC WG. Comments should be 29 directed to its mailing list, rohc@cdt.luth.se. 31 Abstract 33 This document describes lower layer guidelines for robust header 34 compression (HC). The purpose of this document is to support the 35 incorporation of robust header compression algorithms, as specified 36 in the ROHC working group, into different systems such as those 37 specified by 3GPP, 3GPP2, ETSI, etc. This document treats general 38 guidelines as well as guidelines specific for cellular systems. 40 TABLE OF CONTENTS 42 1. Introduction..................................................3 44 2. Terminology...................................................3 46 3. Guidelines for robust RTP/UDP/IP header compression...........3 48 3.1 General guidelines..........................................3 50 3.1.1 Error detection on (compressed) headers.............3 52 3.1.2 Indication of erroneous headers.....................4 54 3.1.3 Inferred header field information...................4 56 3.1.4 Handling of header size variation...................4 58 3.1.5 Negotiation of header compression parameters........5 60 3.1.6 Demultiplexing of flows onto logically 61 separated channels..................................5 63 3.1.7 Packet type identification...........................5 65 3.2 Cellular system specific guidelines.........................5 67 3.2.1 Handover procedures..................................6 69 4. Guidelines for Robust TCP/IP Header Compression...............7 71 5. Author's addresses............................................7 73 6. References....................................................7 75 1. Introduction 77 Almost all header compression algorithms [RFC1144, RFC2507, RFC2508] 78 rely on some functionality from underlying link layer. Headers 79 (compressed or not) are expected to be delivered without any residual 80 bit errors, IP length fields are inferred from link layer length 81 fields and packet type identification may be separated from the 82 header compression scheme and instead done at underlying link layer. 83 [RFC2509], for example, elaborates on how to incorporate IP header 84 compression [RFC2507] in PPP [RFC1661]. 86 It is important to be aware of such assumptions on required 87 functionality from underlying layers when incorporating a header 88 compression scheme into a system. The functionality required by a 89 specific header compression scheme from lower layers may also be 90 needed if incorporation of a header compression scheme is to be 91 prepared without knowing the exact details of the final scheme. 93 This document describes lower layer guidelines for robust header 94 compression as being specified by the ROHC working group. These 95 guidelines should simplify incorporation of the robust header 96 compression algorithms into cellular system like those standardized 97 by 3GPP, 3GPP2, ETSI, etc, and also into specific link layer 98 protocols such as PPP. The document should also enable preparation of 99 this incorporation without requiring detailed knowledge about the 100 final header compression scheme. Relevant standardization groups 101 standardizing link layers should, aided by this document, include 102 required functionality in "their" link layers to support robust 103 header compression. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119. 111 3. Guidelines for robust RTP/UDP/IP header compression 113 This chapter treats guidelines for robust RTP/UPD/IP header 114 compression. 116 3.1 General guidelines 118 3.1.1 Error detection on (compressed) headers 120 All current header compression schemes [RFC1144, RFC2507, RFC2508] 121 rely on lower layers to detect errors in (compressed) headers. The 122 link layer underlying header compression MUST provide error detection 123 to the de-compressor if the compressed header do not have an internal 124 error detection. Headers passed up to the header decompressor should 125 have a residual bit error rate (undetected bit error rate) very close 126 to zero. (Further work is needed to find a numerical value or 127 interval on the required residual bit error rate.) 129 3.1.2 Indication of erroneous headers 131 It is RECOMMENDED that erroneous headers are passed up to the 132 decompressor, but in that case an indication that the header has 133 errors MUST be included to the decompressor together with erroneous 134 headers. 136 3.1.3 Inferred header field information 138 Some fields of the RTP/UDP/IP headers may be classified as inferred, 139 that is their values are to be inferred from other values or from an 140 underlying link layer. An underlying link layer MUST therefore 141 provide the header decompressor with the following information: 143 Packet Length (IPv4) 145 Information about the received packet (with the compressed header) 146 length MUST be provided by the link layer. 148 Payload Length (IPv6) 150 Information about the received packet (with the compressed header) 151 length MUST be provided by the link layer. 153 Length (UDP) 155 This field is redundant with the Packet Length (IPv4) or the 156 Payload Length (IPv6) field. Hence, the value of this field MUST in 157 some way be provided to the decompressor. 159 In summary, all of the fields above relate to the length of the 160 packet the compressed header is included in. All three fields may 161 thus be inferred by the decompressor if one packet length value is 162 signaled from the link layer to the decompressor on a per packet 163 basis. This packet length value should be the length of the received 164 packet including the (compressed) header. 166 3.1.4 Handling of header size variations 168 It is desirable for many cellular link layer technologies that bit 169 rate variations are minimized. However, there will always be some 170 variation in compressed header sizes since there is a trade-off 171 between header size variations and compression efficiency, and also 172 due to events in the header flow and on the channel. The link layer 173 MUST in some manner support varying header sizes from 40 bytes (full 174 RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6) down to 1 byte 175 for the minimal compressed header. It is likely that the small 176 compressed headers are dominating the flow of headers, and that the 177 largest headers are sent rarely, e.g. only a few times in the 178 initialization phase of the header compression scheme. 180 (Further work is needed to gain more accurate numbers on header size 181 distributions; the number of different header sizes and the 182 distribution among these sizes in typical cases.) 184 3.1.5 Negotiation of header compression parameters 186 The ROHC header compression scheme will have some parameters that 187 needs to be set at an initial setup phase. For instance, the header 188 compression profile to use may have to be determined [ROCCO]. 189 Compressor and decompressor capabilities may also be negotiated. 190 Hence, the link layer supporting robust header compression MUST 191 include mechanisms for negotiating header compression parameters such 192 as, header compression profiles, compressor and decompressor 193 capabilities. 195 It also RECOMMENDED that the link layer have mechanisms that support 196 re-negotiations of such parameters. 198 3.1.6 Demultiplexing of flows onto logically separated channels 200 In some cellular technologies there are a demultiplexing of flows 201 onto radio bearers suitable to the particular flows, i.e., onto 202 logically separated channels. For instance, real-time flows such as 203 voice and video may be carried on logically separated bearers. It is 204 RECOMMENDED that this kind of demultiplexing is done in the link 205 layer technology supporting robust header compression. By doing so, 206 the need for context identification in the header compression scheme 207 is reduced. If there is a one to one mapping between flow and logical 208 channel, there is no need at all for context identification at the 209 header compression level. 211 3.1.7 Packet type identification 213 Header compression schemes like [RFC2507, RFC2508] have relied on the 214 underlying link layer to identify different kinds of headers. This 215 kind of mechanism is not necessary for robust RTP/UDP/IP header 216 compression. The packet type identification will be incorporated in 217 the header compression scheme and there is thus, no need for such a 218 mechanism in the link layer. 220 3.2 Cellular system specific guidelines 222 An important group of link layer technologies where robust header 223 compression will be needed are future cellular systems, which may 224 have a very large number of users in some years. The need for header 225 compression is large in these kinds of systems to achieve spectrum 226 efficiency. Hence, it is important that future cellular systems can 227 efficiently incorporate the robust header compression scheme. 229 3.2.1 Handover procedures 231 One cellular specific property that may affect header compression is 232 mobility and thus, handover (i.e., change of serving base station or 233 radio network controller). 235 The main characteristics of handovers relevant for robust header 236 compression are: the length of the longest packet loss event due to 237 handover (i.e. the number of consecutive packet losses); relocation 238 of header compression context when necessary. 240 Depending on the location of the header compressor/decompressor in 241 the radio access network and the type of handover, handover may or 242 may not cause disruptions or packet loss events in the (compressed) 243 header flow relevant for the header compression scheme. For instance, 244 if soft handover is used and if the header compressor/decompressor 245 resides above the combining point for soft handover, there will be no 246 extra packet losses visible to the decompressor due to handover. In 247 hard handovers, where packet loss events due to handover is 248 introduced, the length of the longest consecutive packet loss is most 249 relevant and should thus, be minimized. 251 Handover SHOULD NOT cause significant long events of consecutive 252 packet loss. Significant in this context relates to the kind of loss 253 tolerable for the carried real-time application. 255 If hard handovers are performed, which may cause significant long 256 events of consecutive packet loss, it is RECOMMENDED that the radio 257 access network notifies the compressor that such a handover is 258 occurring. 260 The cellular system supporting robust header compression MAY also 261 have internal mechanisms for transferring the header compression 262 context between nodes where contexts may reside, at or before 263 handover. 265 If the cellular system does not have any internal mechanism for 266 transferring header compression context between nodes, the transfer 267 of context may be done by the header compression scheme. The header 268 compression scheme may perform a new header compression 269 initialization, e.g. by sending "full" headers. This will, however, 270 introduce an increase in the average header size dependent on how 271 often a transfer of context is needed. 273 In this latter case, the lower layers MUST indicate to the header 274 compressor that a handover has occurred, so that it knows when to 275 perform the initialization. 277 4. Guidelines for Robust TCP/IP Header Compression 279 This chapter treats guidelines for robust TCP/IP header compression. 281 To be written. 283 5. Author's Addresses 285 Krister Svanbro Tel: +46 920 20 20 77 286 Ericsson Research Mobile: +46 70 621 69 42 287 Lulea, Sweden EMail: krister.svanbro@ericsson.com 289 6. References 291 [RFC1144] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed 292 Serial Links", RFC 1144, February 1990. 294 [RFC2507] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP 295 Header Compression", RFC 2507, February 1999. 297 [RFC2508] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP 298 Headers for Low-Speed Serial Links", RFC 2508, February 299 1999. 301 [RFC2509] Mattias Engan, Steven Cassner, "IP Header Compression 302 over PPP", RFC2509, February 1999 304 [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", 305 STD 51, RFC 1661, July 1994. 307 [ROCCO] Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, Krister 308 Svanbro, "RObust Checksum-based header COmpression 309 ROCCO)", Internet-Draft (work in progress), May 2000. 310 312 This Internet-Draft expires in November 2000.