Movatterモバイル変換

Network Working Group                                       L-E. JonssonRequest for Comments: 3243                                      EricssonCategory: Informational                                       April 2002RObust Header Compression (ROHC):Requirements and Assumptions for 0-byte IP/UDP/RTP CompressionStatus of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   This document contains requirements for the 0-byte IP/UDP/RTP   (Internet Protocol/User Datagram Protocol/Real-Time Transport   Protocol) header compression scheme to be developed by the Robust   Header Compression (ROHC) Working Group.  It also includes the basic   assumptions for the typical link layers over which 0-byte compression   may be implemented, and assumptions about its usage in general.1.  Introduction   The goal of the Robust Header Compression (ROHC) Working Group is to   develop header compression schemes that perform well over links with   high error rates and long link roundtrip times.  The schemes must   perform well for cellular links, using technologies such as WCDMA,   EDGE, and CDMA-2000.  However, the schemes should also be applicable   to other future link technologies with high loss and long roundtrip   times.   ROHC RTP has become a very efficient, robust and capable compression   scheme, able to compress the IP/UDP/RTP headers down to a total size   of only one octet.  This makes ROHC RTP an excellent solution for   future cellular environments with new air interfaces, such as WCDMA,   making even speech services possible over IP with an insignificantly   lower spectrum efficiency compared to existing circuit switched   solutions.Jonsson                      Informational                      [Page 1]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 2002   However, all-IP cellular networks will also be built with already   existing air interfaces such as GSM and IS-95, which are less   flexible using radio bearers optimized for specific frame sizes   matching the speech codecs used.  This means that not a single octet   of header can be added without switching to the next higher fixed   packet size supported by the link, something which is obviously very   costly.  In the long term, this drawback should of course be   eliminated with new, more flexible air interfaces, but in the short   term it would be desirable if an efficiency comparable to the circuit   switched case could also be achieved for already deployed speech   codecs when used over the existing air interfaces.  To achieve that,   it must be possible to completely eliminate the headers for a   majority of the packets during normal operation, and this is the   purpose of 0-byte header compression.  All functionality normally   provided by the 1-octet header must then be provided by some other   means, typically by utilizing functionality from the lower layer.  It   is important to remember that the purpose of 0-byte header   compression is to provide optimal efficiency for applications   matching the link layer characteristics, not efficiency in general.   As a starting point for these requirements, the well-established   requirements base developed in the ROHC WG has been used.  From that,   the requirements have evolved through input from the 3GPP2 community   and from discussions within the WG.2.  Assumptions for the Applicability of 0-byte RTP Header Compression   The purpose of 0-byte header compression is to provide optimal usage   of certain links when the traffic pattern of a packet stream   completely matches the characteristics of that link.  There are no   assumptions that only packet streams complying with that pattern will   occur, but optimal efficiency cannot of course be provided when this   is not the case.   To make 0-byte header compression feasible, it is assumed that lower   layers can provide the necessary functionality needed to replace the   1-octet headers and fulfill the requirements defined insection 3.   An example is the synchronized nature of most cellular links, which   can provide sequencing and timing information and make packet loss   detection possible.3.  Requirements on 0-byte RTP Header Compression   Since 0-byte header compression for ROHC IP/UDP/RTP is a variant of   regular ROHC RTP compression [ROHC], these requirements are described   as deltas to those defined in the regular RTP requirements [RTP-REQ].   For simplicity, this section is also separated into the same three   subsections as the requirements in [RTP-REQ], where the first dealsJonsson                      Informational                      [Page 2]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 2002   with the impact of header compression on the rest of the Internet   infrastructure, the second concerns the headers to be compressed, and   the third covers efficiency and link technology related issues.3.1.  Impact on Internet Infrastructure   The meaning of header compression is in no way changed by the   introduction of 0-byte header compression.  No additional impact on   the Internet infrastructure is thus allowed.  The "Transparency" and   "Ubiquity" requirements of [RTP-REQ,section 2.1] therefore also   apply to 0-byte RTP compression without any modifications.3.2.  Supported Headers and Kinds of RTP Streams   The 0-byte RTP compression scheme in general imposes the same   requirements on supported headers and RTP streams as regular ROHC RTP   [RTP-REQ,section 2.2].  However, there are some aspects regarding   the "Genericity" and IPSEC requirements that should be noted.   The "Genericity" requirement of [RTP-REQ] states that compression of   headers of arbitrary RTP streams must be supported, and this is also   true for the 0-byte compression scheme to the extent that it is not   allowed to assume certain RTP behavior.  However, as also stated in   [RTP-REQ], this does not preclude optimizations for certain media   types where the traffic pattern is known.  For 0-byte RTP, this means   that the scheme must be able to handle arbitrary RTP streams in order   to fulfill the requirements ofsection 3.1.  However, due to the   typical characteristics of 0-byte compression, by requiring a traffic   pattern that suits the link over which it is implemented to be able   to compress down to 0-byte headers, it becomes optimized for   applications with link-suited traffic patterns.  For traffic that   does not comply with the link properties, the scheme must   automatically and immediately fall back to non-0-byte RTP compression   and must not have any impact on the packet stream.   Regarding IPSEC, it should be noted that 0-byte compression cannot be   achieved if parts of the original headers are encrypted or carry   randomly changing fields.  IPSEC and 0-byte RTP header compression   therefore do not go well together.  If IPSEC is used and prevents 0-   byte compression, the scheme must fall back to a less efficient   compression that can handle all present header fields.  Of course,   this applies not only to IPSEC but to all cases where headers cannot   be compressed down to 0-byte.Jonsson                      Informational                      [Page 3]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 20023.3.  Performance Issues   All the performance requirements of [RTP-REQ] also apply to 0-byte   RTP header compression, with the following additions and exceptions:   -  Performance/Spectral Efficiency: For packet streams with traffic      patterns that match the characteristics of the link over which 0-      byte header compression is implemented, the performance should be      such that 0-byte header packets are generated during normal      operation, most of the time.  0-byte headers would then replace      most of the 1-octet headers used by regular ROHC RTP [ROHC].      Justification: Spectrum efficiency is a primary goal.  Studies      have shown that for certain applications and link technologies,      even a single octet of header may result in a significant decrease      in spectrum efficiency, compared to existing circuit switched      solutions.   -  Header Compression Coexistence: The scheme must fit into the ROHC      framework together with other ROHC profiles.      Justification: Implementation simplicity is an important issue and      the 0-byte RTP compression scheme should therefore have as much as      possible in common with the regular IP/UDP/RTP profile.   -  Unidirectional links: It is of less importance that the 0-byte      header compression scheme be able to also work over unidirectional      links.      Justification: 0-byte header compression targets links that      typically are bi-directional.4.  IANA Considerations   A protocol which meets these requirements, e.g., [LLA], will require   the IANA to assign various numbers.  This document by itself,   however, does not require any IANA involvement.5.  Security Considerations   A protocol specified to meet these requirements, e.g., [LLA], may   have a number of security aspects that need to be considered.  This   document by itself, however, does not add any security risks.Jonsson                      Informational                      [Page 4]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 20026.  References   [RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header             compression",RFC 3096, July 2001.   [ROHC]    Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,             Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,             Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,             T., Yoshimura, T. and H. Zheng, "Robust Header Compression             (ROHC)",RFC 3095, July 2001.   [LLA]     Jonsson, L-E. and G. Pelletier, "RObust Header Compression             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP",RFC3242, April 2002.7.  Author's Address   Lars-Erik Jonsson   Ericsson AB   Box 920   SE-971 28 Lulea   Sweden   Phone: +46 (920) 20 21 07   Fax: +46 (920) 20 20 99   EMail: lars-erik.jonsson@ericsson.comJonsson                      Informational                      [Page 5]

RFC 3243        Reqs and Assumptions for 0-byte ROHC RTP      April 20028.  Full Copyright Statement   Copyright (C) The Internet Society (2002).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Jonsson                      Informational                      [Page 6]