Network Working Group Lars-Erik Jonsson INTERNET-DRAFT Ericsson Expires: December 2002 June 14, 2002 RObust Header Compression (ROHC): The ROHC Architecture Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). Various concepts are introduced within the standard, which might be difficult to understand, and especially how these relate to the surrounding environments where header compression may be used. This document aims at clarifying the architectural aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, ROHC contexts, and how these terms relate to other terms like network elements and IP interfaces, commonly used when for example addressing MIB issues. Jonsson [Page 1] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 Table of Contents 1. Introduction..................................................2 2. ROHC External Terminology.....................................3 2.1. Network Elements and IP Interfaces.....................3 2.2. Channels...............................................3 2.3. A Unidirectional Point-to-Point Link Example...........4 2.4. A Bi-directional Point-to-Point Link Example...........5 2.5. A Bi-directional Multipoint Link Example...............5 2.6. A Multi-Channel Point-to-Point Link Example............6 3. ROHC Instances................................................7 3.1. ROHC Compressors.......................................8 3.2. ROHC Decompressors.....................................8 4. ROHC Channels.................................................9 5. ROHC Feedback Channels.......................................10 5.1. Single-Channel Dedicated ROHC FB Channel Example......11 5.2. Piggybacked/Interspersed ROHC FB Channel Example......11 5.3. Dual-Channel Dedicated ROHC FB Channel Example........12 6. ROHC Contexts................................................13 7. Implementation Implications..................................14 8. Security Considerations......................................15 9. Acknowledgements.............................................15 10. References..................................................15 11. Author's Address............................................15 1. Introduction In RFC 3095, the RObust Header Compression (ROHC) standard framework is defined along with 4 compression profiles [RFC-3095]. Various concepts are introduced within the standard, which might not all be very extensively defined and described, and that can easily be an obstacle when trying to understand the standard. This can especially be the case when one consider how the various parts of ROHC relate to the surrounding environments where header compression may be used. The purpose of this document is to clarify the architectural aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, ROHC contexts. This especially means to clarify how these terms relate to other terms, such as network elements and IP interfaces, which are commonly used when for example addressing MIB issues. One explicit goal with this document is to support and simplify the MIB development work for ROHC. The main part of this document, section 2 to 6, focuses on clarifying the conceptual aspects, entity relationships, and terminology of ROHC [RFC-3095]. After that, section 7 explains some implementation implications that arise from these conceptual aspects. Jonsson [Page 2] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 2. ROHC External Terminology When considering aspects of ROHC that relate to the surrounding networking environment where header compression may be applied, unnecessary confusion is easily created because a common, well understood and well defined, terminology is missing. One major goal with this document is to define the preferred terminology to use when discussing header compression network integration issues. 2.1. Network Elements and IP Interfaces Header compression is applied over certain links, between two communicating entities in a network. Such entities may be referred to as "nodes", "network devices", or "network elements", all terms usually having the same meaning. However, practices within the area of network management recommends to use the term "network element", which is therefore consistently used throughout the rest of this document. A network element is communicating through one or several network interfaces, which are often subject to network management, as defined by MIB specifications. In all IP internetworking, each such interface has its own IP identity, providing a common network interface abstraction, independent of the link technology hidden below the interface. Throughout the rest of this document, such interfaces will be referred to as "IP interfaces". To visualize the above terms, the top level hierarchy at a network element will thus be the following, with 1 or several IP interfaces: +-----------------------------------------------------+ | Network Element | +---------------+--+---------------+------------------+ | IP | | IP | | Interface | | Interface | +---------------+ +---------------+ ... The next section further builds on this top level hierarchy by looking at what is below an IP interface. 2.2. Channels As mentioned in previous section, an IP interface can be implemented on top of almost any link technology, although different link technologies have different characteristics, and provide communication by different means. However, all link technologies provide the common capability to send and/or receive data to/from the IP interface. A generic way of visualizing the common ability to communicate is to envision it as one or several communication Jonsson [Page 3] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 channels provided by the link, where each channel can be either bi- directional or unidirectional. Such logical point-to-point connections will throughout the rest of this document be referred to as "channels", either bi-directional or unidirectional. Note that this definition of "channels" is less restrictive than the definition of "ROHC channels", as given in section 4. Extending the above network element hierarchy with the concept of channels would then lead to the following: +-----------------------------------------------------+ | Network Element | +---------------+--+---------------+------------------+ | IP | | IP | | Interface | | Interface | ++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ... |C| |C| |C| |C| |C| |C| |h| |h| |h| |h| |h| |h| |a| |a| |a| |a| |a| |a| |n| |n| |n| ... |n| |n| |n| ... |n| |n| |n| |n| |n| |n| |e| |e| |e| |e| |e| |e| |l| |l| |l| |l| |l| |l| : : : : : : : : : : : : Whether there is more than one channel, and whether the channel(s) is/are bi-directional or unidirectional (or a mix of both) is link technology dependent, as well as the way channels are logically created. The following subsection 2.3-2.6 gives a number of different link examples, and relate these to the general descriptions above. Further, each section discusses how header compression might be applied in that particular case. The core questions for header compression are: - Are channels bi- or unidirectional? - Is the link point-to-point? If not, a lower layer addressing scheme is needed to create logical point-to-point channels. Note that these subsections talk about header compression in general, while later sections will address the case of ROHC in more detail. Further, one should remember that the general channel definition is slightly enhanced for header compression by the definition of ROHC channels (see section 4) and ROHC feedback channels (see section 5). 2.3. A Unidirectional Point-to-Point Link Example The simplest possible link example one can derive from the general overview above, is the case with one single unidirectional channel between two communicating network elements. Jonsson [Page 4] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 +-----------------+ +-----------------+ | Network Element | | Network Element | +-----------------+ +-----------------+ | IP | | IP | | Interface | | Interface | +------+ +------+ +------+ +------+ | | | | | +--------------------------------+ | | -> Unidirectional channel -> | +----------------------------------------+ A typical example of a point-to-point link with one unidirectional channel like this is a satellite link. Since there is no return path present, only unidirectional header compression can here be applied. 2.4. A Bi-directional Point-to-Point Link Example Starting from the example above, the natural next step example would be one with one single bi-directional channel between two communicating network elements. In this example, we still have just two endpoints and one single channel, it is just enhanced to allow bi-directional communication. +-----------------+ +-----------------+ | Network Element | | Network Element | +-----------------+ +-----------------+ | IP | | IP | | Interface | | Interface | +------+ +------+ +------+ +------+ | | | | | +--------------------------------+ | | <-> Bi-directional channel <-> | +----------------------------------------+ A typical example of a point-to-point link with one bi-directional channel like this is a PPP modem connection over a regular telephone line. Header compression can easily be applied here as well, as usually done over e.g. PPP, and the compression scheme can utilize the return path to improve compression performance. 2.5. A Bi-directional Multipoint Link Example Leaving the simple point-to-point link examples, this section addresses the case of a bi-directional link between more than two communicating network elements. To simplify the example, the case with three endpoints is used. Jonsson [Page 5] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 +-----------------+ +-----------------+ +-----------------+ | Network Element | | Network Element | | Network Element | +-----------------+ +-----------------+ +-----------------+ | IP | | IP | | IP | | Interface | | Interface | | Interface | +------+ +------+ +------+ +------+ +------+ +------+ | | | | | | | | | | | | | +-----------------+ +-----------------+ | | <-> Bi-directional "shared channel" <-> | +-----------------------------------------------+ A typical example of a multipoint link with a bi-directional "shared channel" like this is an Ethernet. Since the channel is shared, applying header compression would require a lower layer addressing scheme, to provide logical point-to-point channels, according to the definition of "channels". As a side point, it should be noted that a case of unidirectional multipoint links is basically the same as a number of unidirectional point-to-point links. For receivers, there is only one single sender, and the sender is not at all affected by the receivers. 2.6. A Multi-Channel Point-to-Point Link Example This final example addresses a scenario which is expected to be typical in many environments where ROHC will applied. The key point with the example is the multi-channel property, which is common in for example cellular environments. Data through the same IP interface might here be transmitted on different channels, depending on characteristics. In this example, there are three channels present, one bi-directional, and one unidirectional in each direction, but the channel configuration could of course be arbitrary. Jonsson [Page 6] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 +-----------------+ +-----------------+ | Network Element | | Network Element | +-----------------+ +-----------------+ | IP | | IP | | Interface | | Interface | +-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+ | | | | | | | | | | | | | | | | | +--------------------------+ | | | | | | | | | | <- Unidirectional channel <- | | | | | | | | | +------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | +--------------------------------------+ | | | | | | <-> Bi-directional channel <-> | | | | | +------------------------------------------+ | | | | | | | | | | | +--------------------------------------------------+ | | -> Unidirectional channel -> | +------------------------------------------------------+ As mentioned above, a typical example of a multi-channel link is a cellular wireless link. In this example, header compression would be applicable on a per-channel basis, for each channel operating either in a bi-directional or unidirectional manner, depending on the channel properties. 3. ROHC Instances For e.g. the purpose of network management on an IP interface implementing ROHC, it is necessary to identify the various ROHC entities that might be present on an interface. Such a minimal ROHC entity will from now on be referred to as a "ROHC instance". A ROHC instance can be one of two different types, either a "ROHC compressor" or a "ROHC decompressor" instance, and an IP interface can have N ROHC compressors and M ROHC decompressors, where N and M are arbitrary numbers. It should be noted that although a compressor is often co-located with a decompressor, a ROHC instance can never include both a compressor and a decompressor, but they will then be referred to as two ROHC instances. The following two subsections describe the two kinds of ROHC instances and their external interfaces, while sections 4 and 5 address how communication over these interfaces is realized through "ROHC channels" and "ROHC feedback channels". Section 6 builds on top of the instance, channel and feedback channel concepts and clarifies how ROHC contexts map to this. Jonsson [Page 7] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 3.1. ROHC Compressors A ROHC compressor instance supports header compression according to one or several ROHC profiles. Apart from potential configuration or control interfaces, a compressor instance receives and sends data through 3 inputs and 1 output, as illustrated by the figure below: +--------------+ -> UI -> | | -> CO -> | ROHC | | Compressor | -> PI -> | | <- FI <- +--------------+ Uncompressed Input (UI): Uncompressed packets are delivered from higher layers to the compressor through the UI. Compressed Output (CO): Compressed packets are sent from the compressor through the CO, which is always connected to the input end of a ROHC channel (see section 4). Feedback Input (FI): Feedback from the decompressor at the other end of the channel is received by the compressor through the FI, which (if present) is connected to the output end of a ROHC feedback channel of some kind (see section 5). When a ROHC feedback channel is not available, bi-directional compression will not be possible. Piggyback Input (PI): If the compressor is associated with a co-located decompressor, for which the compressor delivers feedback to the other end of the channel, feedback data for piggybacking is delivered to the compressor through the PI. If this input is used, it is connected to the FO of the co-located decompressor (see section 3.2). 3.2. ROHC Decompressors A ROHC decompressor instance supports header decompression according to one or several ROHC profiles. Apart from potential configuration or control interfaces, a decompressor instance receives and sends data through 1 input and 3 outputs, as illustrated by the figure below: Jonsson [Page 8] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 +--------------+ -> CI -> | | -> DO -> | ROHC | | Decompressor | <- FO <- | | -> PO -> +--------------+ Compressed Input (CI): Compressed packets are received by the decompressor through the CI, which is always connected to the output end of a ROHC channel (see section 4). Decompressed Output (DO): Decompressed packets are delivered from the decompressor to higher layers through the DO. Feedback Output (FO): Feedback to the compressor at the other end of the channel is sent through the FO, which (if present) is connected to the input end of a ROHC feedback channel of some kind (see section 5). When a ROHC feedback channel is not available, bi- directional compression will not be possible. Piggyback Output (PO): If the decompressor is associated with a co-located compressor, to which the decompressor delivers feedback it receives piggybacked from the other end of the channel, the received feedback data is delivered from the decompressor through the PO. If this output is used, it is connected to the FI of the co- located compressor (see section 3.1). 4. ROHC Channels In section 2, a general concept of channels was introduced. According to that definition, a channel is basically a logical point-to-point connection between IP interfaces at two communicating network elements. By that definition, a channel represents the kind of logical connection needed to make header compression generally applicable, and then the channel properties control whether compression can operate in a unidirectional or bi-directional manner. The channel concept thus facilitates general header compression discussions, but since it groups unidirectional and bi-directional connections together it does not provide the means for describing details of the logical ROHC design. Therefore, for the case of ROHC, Jonsson [Page 9] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 the channel concept is enhanced and a more restricted concept of "ROHC channels" is defined. A ROHC channel has exactly the same properties as a channel, but with the difference that a ROHC channel always is unidirectional. A ROHC channel therefore has one single input endpoint, connected to the CO of one single ROHC compressor instance, and one single output endpoint, connected to the CI of one single ROHC decompressor instance. A ROHC channel must thus in this way be logically dedicated to one ROHC compressor/decompressor pair, hereafter referred to as ROHC peers, creating a one-to-one mapping between a ROHC channel and a pair of ROHC compressor/decompressor instances. +--------------+ --->-->-->-->--- +--------------+ | | -> CO -> ROHC Channel -> CI -> | | | ROHC | --->-->-->-->--- | ROHC | | Compressor | | Decompressor | | | | | +--------------+ +--------------+ Of course, in many cases the channel is by nature bi-directional, but for ROHC communication over that channel, a ROHC channel would only represent one communication direction of the channel. For bi- directional channels, a common case would be to logically allocate one ROHC channel in each direction, allowing ROHC compression to be performed in two directions. The reason for defining ROHC channels as unidirectional is basically to separate and generalize the concept of feedback, as described and exemplified in section 5. 5. ROHC Feedback Channels Since ROHC can be implemented over various kind of links, unidirectional or bi-directional one-channel links as well as multi- channel links, the logical transmission of feedback from decompressor to compressor has been separated out from other ROHC data transport through the definition of ROHC channels as always unidirectional. This means an additional channel concept must be defined for feedback, which is what further will be referred to as "ROHC feedback channels". In the same way as a ROHC channel is a logically dedicated unidirectional channel from a ROHC compressor to its ROHC peer decompressor, a ROHC feedback channel is a logically dedicated unidirectional channel from a ROHC decompressor to its ROHC peer compressor. A ROHC feedback channel thus has one single input endpoint, connected to the FO of one single ROHC decompressor instance, and one single output endpoint, connected to the FI of one single ROHC compressor instance. Jonsson [Page 10] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 +--------------+ +--------------+ | | | | | ROHC | | ROHC | | Compressor | --<--<--<--<--<-- | Decompressor | | | <- FI <- ROHC FB Channel <- FO <- | | +--------------+ --<--<--<--<--<-- +--------------+ It might not be obvious why this extreme simplicity is needed, but the reason is generality for handling of feedback. ROHC has been designed with the assumption of logical separation, which creates flexibility for how to realize feedback transport, as discussed in [RFC-3095, section 5.2.1]. There are no restrictions on how to implement a ROHC feedback channel, more than that it must be made available and be logically dedicated to the ROHC peers. The following subchapters provides some, not at all exclusive, examples of how a ROHC feedback channel might possibly be implemented. 5.1. Single-Channel Dedicated ROHC Feedback Channel Example This chapter illustrates a one-way compression example where one bi- directional channel has been configured to represent a ROHC channel in one direction and a dedicated ROHC feedback channel in the other direction. Bi-directional channel .................. +--------------+ : -->-->-->-->-- : +--------------+ --> |UI CO| --> : ROHC Channel : --> |CI DO| --> | ROHC | : -->-->-->-->-- : | ROHC | | Compressor | : : | Decompressor | | | : --<--<--<--<-- : | | ñ |PI FI| <-- : FB Channel : <-- |FO PO| ñ +--------------+ : --<--<--<--<-- : +--------------+ :................: In this example, feedback is sent on its own channel, as discussed in e.g. feedback realization example 1-3 of ROHC [RFC-3095, page 44]. This means that the piggybacking mechanism of ROHC is not used, and the PI/PO connections are thus not used (marked with a "ñ"). To facilitate communication with ROHC compression in a two-way example with this approach, an identical configuration must be provided for the other direction. 5.2. Piggybacked/Interspersed ROHC Feedback Channel Example This chapter illustrates how a bi-directional channel has been configured to represent one ROHC channel in each direction, while Jonsson [Page 11] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 still allowing feedback to be transmitted through ROHC piggybacking and interspersing. Bi-directional channel .................. +--------------+ : -->-->-->-->-- : +--------------+ --> |UI CO| --> : ROHC Channel A : --> |CI DO| --> | ROHC | : -->-->-->-->-- : | ROHC | | Compressor | : : | Decompressor | | A | : : | A | +-> |PI FI| <-+ : : +-- |PO FO| --+ | +--------------+ | : : | +--------------+ | | | : : | | | | : : | | | +--------------+ | : : | +--------------+ | +-- |FO PO| --+ : : +-> |FI PI| <-+ | ROHC | : : | ROHC | | Decompressor | : : | Compressor | | B | : --<--<--<--<-- : | B | <-- |DO CI| <-- : ROHC Channel B : <-- |CO UI| <-- +--------------+ : --<--<--<--<-- : +--------------+ :................: In this example, feedback is sent piggybacked on compressed packets in the ROHC channels, as discussed in e.g. feedback realization example 4-6 of ROHC [RFC-3095, page 44]. Feedback from decompressor A to compressor A is here sent through FO(A)->PI(B), piggybacked on a compressed packet over ROHC channel B, and delivered to compressor A through PO(B)->FI(A). A logical ROHC feedback channel is thus provided from the PI input at decompressor B to the PO output at compressor B. It should be noted that in this picture, PO and FO at the decompressors have been swapped to simplify drawing. 5.3. Dual-Channel Dedicated ROHC Feedback Channel Example This chapter illustrates how two bi-directional channels have been configured to represent two ROHC channels and two dedicated ROHC feedback channels, respectively. Jonsson [Page 12] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 Bi-directional channel .................. +--------------+ : -->-->-->-->-- : +--------------+ ->|UI CO| --> : ROHC Channel A : --> |CI DO|-> | ROHC | : -->-->-->-->-- : | ROHC | | Compressor | : : | Decompressor | | A | : : | A | | | : : | | +-> |FI PI|ñ : : ñ|PO FO| --+ | +--------------+ : --<--<--<--<-- : +--------------+ | | +- : ROHC Channel B :<-+ | | | : --<--<--<--<-- : | | | +--------------+ | :................: | +--------------+ | | <-|FO CI|<-+ +- |CO UI|<- | | | ROHC | | ROHC | | | | Decompressor | Bi-directional channel | Compressor | | | | B | .................. | B | | | | | : -->-->-->-->-- : | | | | ñ|PO FO| --> : FB Channel B : --> |FI PI|ñ | | +--------------+ : -->-->-->-->-- : +--------------+ | | : : | | : --<--<--<--<-- : | +----------------------- : FB Channel A : <----------------------+ : --<--<--<--<-- : :................: In this example, feedback is in both directions sent on its own channel, as discussed in e.g. feedback realization example 1-3 of ROHC [RFC-3095, page 44]. With this configuration, the piggybacking mechanism of ROHC is not used, and the PI/PO connections are thus not used (marked with a "ñ"). It should be noted that also in this picture, PO and FO at the decompressors have been swapped to simplify drawing, as well as the B-instances have been horizontally mirrored. 6. ROHC Contexts In previous sections it has been clarified that one network element may have multiple IP interfaces, one IP interfaces may have multiple ROHC instances running, not necessary both compressors and decompressors, and for each ROHC instance there is exactly one ROHC channel and optionally one ROHC feedback channel. Each compressor/decompressor can further compress/decompress an arbitrary (but normally limited on a per-channel basis) number of concurrent packet streams sent over the ROHC channel connected to that compressor/decompressor. Each packet stream relates to one particular context state in the compressor/decompressor. When sent over the ROHC channel, compressed packets are labeled with a context identifier (CID), indicating which context the compressed packet corresponds to. There is thus a one-to-one mapping between the number Jonsson [Page 13] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 of contexts that can be present in a compressor/decompressor and the context identifier (CID) space used in compressed packets over that ROHC channel. This is illustrated by the following figure: +------------------------------------------------------------------+ | IP Interface | +---------------+----+---------------+----+---------------+--------+ | ROHC HC | | ROHC HC | | ROHC HD | | Context 0...N | | Context 0...M | | Context 0...K | ... +--+---------+--+ +--+---------+--+ +--+---------+--+ ^ | ^ | : ^ : CID | : CID | : CID | : 0...N | : 0...M | : 0...K | : v : v v | ROHC ROHC ROHC ROHC ROHC ROHC Feedback Channel Feedback Channel Feedback Channel Channel Channel Channel It should be noted that each ROHC instance at an IP interface therefore has its own context and CID space, which size must be agreed with the corresponding ROHC instance peer at the other end of the ROHC channel. 7. Implementation Implications This section will address some questions related to how the conceptual aspects discussed above affect implementations of ROHC. ROHC is defined with a general header compression framework on top of which compression profiles can be defined for each specific set of headers to compress. Although the framework holds a number of important mechanisms, the separation between framework and profiles is mainly a standardization wise separation, to indicate what must be common for all profiles, what must be defined by all profiles, and what is profile-specific details. To implement the framework as a separate module is thus not an obvious thing to do, especially if one wants to use profile implementations from different vendors. However, optimized implementations will probably separate the common parts and implement those separately, and add profile modules to that. A ROHC instance might thus consist of various pieces of implementation modules, profiles and potentially also a ROHC-common module, possibly from different vendors. If vendor and implementation version information is made available for network management purposes, this should thus be done on a per-profile basis, and in addition to that potentially also for the instance as a whole. Jonsson [Page 14] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 8. Security Considerations This document is of informative nature, and does not have any security aspects to address. 9. Acknowledgements Thanks to Juergen Quittek and Hans Hannu for fruitful discussions, improvement suggestions, and review. 10. References [RFC-3095] 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. 11. Author's Address Lars-Erik Jonsson Tel: +46 920 20 21 07 Ericsson AB Fax: +46 920 20 20 99 Box 920 SE-971 28 Lulea Sweden EMail: lars-erik.jonsson@ericsson.com Jonsson [Page 15] INTERNET-DRAFT RObust Header Compression Architecture June 14, 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. This Internet-Draft expires December 14, 2002. Jonsson [Page 16]