Network Working Group Ghyslain Pelletier INTERNET-DRAFT Ericsson Expires: August 2002 February 22, 2002 RObust Header Compression (ROHC): Profiles for UDP Lite 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 This document defines ROHC (Robust Header Compression) profiles for compression of IP/UDP Lite/RTP packets (Internet Protocol, User Datagram Protocol Lite, Real-Time Transport Protocol) and IP/UDP Lite. These profiles are defined based on their differences with the profiles specified in [RFC-3095] for the classic UDP [RFC-768]. Although both transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP Lite headers Pelletier [Page 1] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 because it does not share protocol identifier with the classic UDP. Also, the UDP Lite Checksum Coverage field does not either share the semantics of the corresponding classic UDP Length field and as a consequence cannot always be inferred anymore. In addition, this coverage field may open new possibilities for additional compression efficiency when compared to the UDP profiles defined in [RFC-3095]. Table of contents 1. Introduction....................................................3 2. Terminology.....................................................4 3. Background......................................................4 3.1. The UDP Lite Protocol....................................4 3.2. Checksum Coverage........................................6 4. Rationale behind the design of UDP Lite ROHC profiles...........8 4.1. UDP Lite Considerations..................................8 4.2. ROHC Considerations......................................8 4.3. Header Compression strategies for UDP Lite...............9 4.4. UPD Lite checksum and ROHC CRC..........................10 5. ROHC UDP Lite profiles.........................................10 5.1. Initialization of the UDP Lite header [UDPLITE]..........11 5.2. States and modes.........................................11 5.3. Packet type format.......................................11 5.4. IP/UDP Lite/RTP compression: ROHC RTP/UDPLite............12 5.4.1. Initialization........................................12 5.4.2. Packet types..........................................12 5.4.2.1 Packet type 0: TBD...................................12 5.4.2.2 Packet type 1: TBD...................................13 5.4.2.3 Packet types 2, IR, IR-DYN and extensions............13 5.5. Non-RTP IP/UPD Lite compression: ROHC UDPLite............13 5.5.1. Initialization........................................13 5.5.2. Packet types..........................................13 6. Security considerations........................................13 7. Acknowledgements...............................................14 8. Intellectual Property Right Claim Considerations...............14 9. References.....................................................14 10. Authors address................................................14 Pelletier [Page 2] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 1. Introduction The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets, or for different compression strategies. Due to the demands of the cellular industry for an efficient way of transporting voice over IP over wireless, the main focus of ROHC [RFC-3095] has so far been on compression of IP/UDP/RTP headers, which are generous in size, especially compared to the payloads often carried by the packets with these headers. ROHC RTP has become a very efficient, robust and capable compression scheme, able to compress the headers down to a total size of one octet only. Also, transparency is guaranteed to an extremely high extent even when residual bit errors are present in compressed headers delivered to the decompressor. UDP Lite is a transport protocol similar to the classic UDP protocol [RFC-768]. UDP Lite is useful for applications that are designed with the capability to tolerate errors in the payload and for which receiving damaged data is better than dealing with the loss of entire packets. The protocol is particularly suitable for link technologies where data can be partially damaged, such as wireless links. New ROHC profiles are needed for UDP Lite because it does not share protocol identifier with the classic UDP. Also, the UDP Lite Checksum Coverage field does not either share the semantics of the corresponding Length field of the classic UDP and cannot always be inferred. In addition, the coverage field may open new possibilities for additional compression efficiency when compared to ROHC RTP. This document thus defines two ROHC profiles to allow compression of UDP Lite headers. The objectives of these profiles are to provide simple modifications to the existing profiles for compressing classic UDP headers, as well as introducing a simple method by which the UDP Lite checksum may be entirely compressed away in certain specific scenarios, without threats to the end-to-end nature of this checksum. This document therefore focuses on differences to the compression profiles for classic UDP headers, as specified in [RFC-3095], to define corresponding profiles for UDP Lite header compression. Revision history: 00: First version of this document, including: Motivation for the work, the problematic and some possible directions. This first draft is currently showing the initial state of the work, and will hopefully generate fruitful discussions around header compression for UDP Lite within the ROHC WG. Pelletier [Page 3] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ROHC Robust Header Compression Classic UDP Classic UDP, as defined in [RFC-768] UDP Lite UDP Lite, as defined in [UDPLite] ROHC RTP ROHC RTP in this document refers to the RTP/UDP/IP profile 0x0001 as defined in [RFC-3095]. ROHC UDP ROHC UDP in this document refers to the non-RTP UDP/IP profile 0x0002 as defined in [RFC-3095]. ROHC UDPLite ROHC UDPLite in this document refers to the non-RTP UDP Lite/RTP profile, as defined in this document. ROHC RTP/UDPLite ROHC RTP/UDPLite in this document refers to the RTP/UDP Lite profile, as defined in this document. 3. Background 3.1. The UDP Lite Protocol UDP Lite is a datagram transport protocol defined as an independant variant of the classic UDP transport protocol [RFC-768]. UDP Lite is very similar to the classic UDP, and allow applications that can tolerate errors in the payload to use a checksum with optionally partial coverage. See [UDPLite] for further information about the motivations and benefits of the protocol. UDP Lite replaces the classic UDP Length field of the header with a Checksum Coverage field indicating the number of octets covered by the 16-bit checksum, applied on a per-packet basis. The coverage area must minimally always include the entire UDP Lite header and may cover the entire datagram, in which case UDP Lite becomes semantically identical to the classic UDP. However, UDP Lite and classic UDP do not share protocol identifier. Pelletier [Page 4] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 UDP Lite Header Format: 0 15 16 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | Checksum | | | Coverage | Checksum | +--------+--------+--------+--------+ | | | data bytes ... | +---------------- ...---------------+ The UDP Lite checksum, like the classic UDP checksum, is an end-to- end mechanism against erroneous delivery of error sensitive data. In the case where the checksum is enabled for classic UDP (mandatory for IPv6 [RFC-2460]), such an unpredictable field cannot be compressed and is sent unmodified. The classic UDP Length field, however, is redundant and can be provided by the IP module. Header compression schemes do not normally transmit any bits of information for this field, as its value can be inferred. For UDP Lite, the Length field being redefined as the Checksum Coverage field leads to different properties for both the Checksum Coverage and the Checksum fields from a header compression perspective. The following table summarizes a possible classification for the UDP Lite header fields, using the same classes as in [RFC- 3095]. UDP Lite header fields and Classic UDP fields: +-------------------+-------------+ | UDP Lite | Classic UDP | +-------------------+--------+-------------------+-------------+ | Header | Size | Class | Class | | Field | (bits) | | | +-------------------+--------+-------------------+-------------+ | Source Port | 16 | STATIC-DEF | STATIC-DEF | | Destination Port | 16 | STATIC-DEF | STATIC-DEF | | Checksum Coverage | 16 | CHANGING/INFERRED | | | Length | 16 | | INFERRED | | Checksum | 16 | CHANGING/INFERRED | CHANGING | +-------------------+--------+-------------------+-------------+ One difference from the classic UDP header fields behavior is that only in some cases may the Checksum Coverage be inferred, more specifically when either only the header(s) (UDP Lite header only or UDP Lite/RTP headers) or the entire datagram is covered. Another difference lies in the nature of the UDP Lite checksum field itself: the checksum value depends on the Checksum Coverage field and Pelletier [Page 5] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 may exclude payload. An interesting consideration from a header compression perspective is that it may be acceptable under certain circumstances to replace the UDP Lite checksum and its functionality by a stronger cyclic redundancy check (CRC) using less bits, similar to the CRC currently used in ROHC profiles. Using the ROHC CRC could in some specific and potentially frequently occurring cases allow the UDP Lite checksum to be replaced and inferred at the receiver. In this respect, the presence of a stronger CRC using less bits would thus make the Checksum field redundant and make it acceptable not to transmit its uncompressed value. 3.2. Checksum Coverage It is of interest to consider the semantics of the UDP Lite checksum when considering header compression, to find out if those semantics allow for some additional compression efficiency gains. Referring to [RFC-1144] section 3.1, when addressing the IP checksum: It seems rather silly to protect the transmission of information that is not being transmitted. The semantics of the UDP Lite Checksum allow for partial coverage of the datagram. It must minimally cover the transport-layer header [UDPLite]. This is particularly useful with IPv6, where the transport-layer checksum is mandatory [RFC-2460]. In this specific case, no information other than the checksum coverage and the actual checksum needs to be transmitted in the header compressed stream. It thus seem justified to not transmit those four octets, as this checksum in this case protects bits that are not transmitted. Moving forward in this line of reasoning, the case where the checksum also covers the entire RTP header in addition to the UDP Lite header may offer a similar opportunity. When operating with a high compression ratio, very few information bits are being sent as part of the compressed stream. It this case, it may also be acceptable to not transmit the checksum value, provided equal or superior protection is provided within the header compression scheme to replace the checksum functionality, for example transmitting a strong enough CRC within the compressed header. At the receiver, the checksum may then be regenerated locally when decompressing the headers and then validated using the CRC. The following figure shows the relationship between the possible UDP Lite checksum coverage and the ROHC CRC coverage. UDP Lite Checksum and ROHC CRC coverage: +--------+--------------+---------+-------------+ | IP hdr | UDP Lite hdr | RTP hdr | RTP Payload | +--------+--------------+---------+-------------+ <----- ROHC CRC coverage --------> <- UDP Lite Checksum --><- Optional coverage --> Pelletier [Page 6] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 The UDP Lite Checksum Coverage field has four possible different behaviors embodied via the following assignments for its value: a. set to the UDP datagram length (or is set to 0) b. set to the UDP Lite header size (set to 8) c. set to the UDP Lite/RTP header size d. set to an unpredictable value, fluctuating between the UDP Lite (or UDP Lite/RTP) header length and the entire datagram length. The semantics of the Checksum Coverage field thus yields a number of different transport scenarios each having different properties from a header compression perspective. These properties are further summarized in the following figures, for each identified scenarios. Note that c is a special case of d, for which optimal compression efficiency may also be desirable. Note also that it is possible that an application use any of the possible coverage values within a single packet stream, and this is unpredictable from a header compression perspective. Total size of the fields in each class, for each scenarios: Scenario #1 û Assignment a.: +------------+---------------+ | Class | Size (octets) | +------------+---------------+ | INFERRED | 2 | Checksum Coverage | STATIC-DEF | 4 | Source Port / Destination Port | CHANGING | 2 | Checksum +------------+---------------+ Scenario #2 û Assignment b. or c.: +------------+---------------+ | Class | Size (octets) | +------------+---------------+ | INFERRED | 4 | Checksum Coverage / Checksum | STATIC-DEF | 4 | Source Port / Destination Port | CHANGING | 0 | +------------+---------------+ Scenario #3 û Assignment d.: +------------+---------------+ | Class | Size (octets) | +------------+---------------+ | INFERRED | 0 | | STATIC-DEF | 4 | Source Port / Destination Port | CHANGING | 4 | Checksum Coverage / Checksum +------------+---------------+ Pelletier [Page 7] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 For scenario #1, corresponding to the classic UDP semantics, the checksum coverage field is inferred as in classic UDP case. The checksum (if enabled for IPv4) has completely random values and this field must be included as-is in the compressed header. For scenario #2, the checksum coverage field may be inferred from the size of the UDP Lite (UDP Lite or UDP Lite/RTP streams) or the size of the UDP Lite/RTP header (UDP Lite/RTP streams only). The checksum field can then be recalculated at the receiver and the ROHC CRC applied on the entire decompressed to validate the checksum recalculation. For scenario #3, the checksum coverage field and the checksum field have completely random values and these fields must both be included as-is in the compressed header. 4. Design Rationale for UDP Lite ROHC profiles A strong motivation for the design of the UDP Lite header compression profiles is to use the semantics and properties of the UDP Lite checksum coverage to improve efficiency when the transport-layer checksum is enabled. 4.1. UDP Lite considerations The UDP Lite checksum, like the classic UDP checksum, is an end-to- end mechanism against erroneous delivery of error sensitive data. Care must be taken not to violate this end-to-end functionality. The checksum coverage of UDP Lite is applied on a per-packet basis. As per the protocol definition, there is no guarantee that one of the scenarios identified in section 3.2 will occur more often than another. This in turn makes it difficult to maintain state in a header compression for the coverage field. The UDP Lite Checksum Coverage field may vary unpredictably and thus cannot always be inferred, as opposed to the corresponding Length field of the classic UDP. 4.2. ROHC considerations The ROHC CRC ROHC packets may carry a CRC calculated over the uncompressed header. This CRC is defined at the framework level and is used by the decompressor to verify that the decompressed header is correct. This verification serves three purposes: - Detection of longer losses than can be covered by the sequence number LSBs - Protection against failures caused by residual bit errors in the Pelletier [Page 8] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 compressed header - Protection against faulty implementations or other error causes Replacing the transport-layer checksum Since this document suggests that the end-to-end UDPLite checksum may be completely compressed away and replaced by the ROHC CRC, care must be taken to ensure that the CRC used offers equal or stronger robustness than what is provided by the UDP Lite checksum. Specifically, the ROHC CRC cannot replace the UDP Lite checksum unless the UDP Lite Checksum Coverage field covers only the UDP Lite or the UDP Lite/RTP headers. Otherwise, it must be sent uncompressed. This is necessary to ensure that the end-to-end nature of the checksum is maintained. It is thus reasonable to assume that compression and decompression transparency can be guaranteed even without explicitly carrying the uncompressed UPD Lite coverage field and/or uncompressed UDP Lite Checksum field in header compressed packets, in certain specific cases. Reuse of ROHC RTP and ROHC UDP mechanisms A ROHC compressor will initially behave as for ROHC RTP, however based on the UDP Lite profile identifier. The initialization of other headers than the UDP Lite header (IPv4, IPv6, RTP) is the same as [RFC-3095]. The same actions are taken upon CRC failure as in ROHC 5.3.2.2.3. Additional notes A mechanism, for example via the definition of new packet types, must be defined to allow the compressor to segregate the different scenarios from each other (section 3.2), to allow the proper parsing and decompression of both the coverage and checksum fields, if these scenarios are to be used as a basis to improve compression efficiency. This mechanism may be defined in combination with a context value indicating if the checksum is enabled or not, similar to [RFC-3095]. Additionally, for scenario #2 (section 3.2) it may be possible to achieve a minimal compressed header of one octet, similar to PT-0 defined for ROHC RTP, even for IPv6 when the transport protocol checksum is mandated. 4.3. Header compression strategies for UDP Lite This table revisits the corresponding table for the classic UDP from [RFC-3095] section A.3 and classifies the changing fields, based on Pelletier [Page 9] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 the previously identified scenarios and for the case when the UDP Lite checksum is enabled. Header compression strategies for UDP Lite: +----------------------------+-------------+-----------+-----------+ | Field | Value/Delta | Class | Knowledge | +============================+=============+===========+===========+ | Datagram| Value | STATIC | KNOWN | + --------+-------------+-----------+-----------+ | Checksum Coverage: Header | Value | STATIC | KNOWN | + --------+-------------+-----------+-----------+ | Partial | Value | IRREGULAR | UNKNOWN | +----------------------------+-------------+-----------+-----------+ | Datagram| Value | IRREGULAR | UNKNOWN | + --------+-------------+-----------+-----------+ | Checksum(Enabled): Header | Value | IRREGULAR | UNKNOWN | + --------+-------------+-----------+-----------+ | Partial | Value | IRREGULAR | UNKNOWN | +----------------------------+-------------+-----------+-----------+ Datagram: Scenario #1; Header: Scenario #2; Partial: Scenario #3 4.4. UPD Lite checksum and ROHC CRC It is possible to replace the transport-layer checksum and the ROHC checksum by a stronger CRC, without removing the protection required by the transport-layer. Note well that the idea is to maintain the transport-layer checksum protection and keep the strong CRC for header reconstruction verification. Specifically, it consists into having both the header compression CRC and the transport-layer checksum replaced with a single checksum with the following properties: - offers equal or stronger protection than transport-layer checksum - protects all bits covered by the transport-layer checksum - offers equal or stronger robustness than the header compression CRC - protects the original transport-layer checksum A header compression CRC having these properties would allow the transport-layer checksum to be recalculated at the decompressor side before the entire decompressed header, including the recalculated checksum, is verified and validated using the CRC. 5. ROHC UDP Lite profiles The profiles defined in this document borrows as much as possible the mechanisms defined in [RFC-3095]. This section summarizes the necessary additions and exceptions required from section 5.11 of [RFC-3095]. Pelletier [Page 10] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 This chapter is incomplete and is an initial proposal for directions. 5.1. Initialization of the UDP Lite header [UDPLITE] The IR and IR-DYN packets structure and initialization procedures are the same as for ROHC UDP, unless explicitly stated otherwise. For ROHC UDPLite, the dynamic part of a UDP packet is different than from [RFC-3095] (sections 5.11.1 and 5.7.7.5): a two-octet field containing the UDP Lite Checksum Coverage field is added before the Checksum field. This affects the format of dynamic chains in IR and IR-DYN packets. Static part: +---+---+---+---+---+---+---+---+ / Source Port / 2 octets +---+---+---+---+---+---+---+---+ / Destination Port / 2 octets +---+---+---+---+---+---+---+---+ Dynamic part: +---+---+---+---+---+---+---+---+ / Checksum Coverage / 2 octets +---+---+---+---+---+---+---+---+ / Checksum / 2 octets +---+---+---+---+---+---+---+---+ CRC-DYNAMIC: Checksum Coverage field, Checksum (octets 5-8). CRC-STATIC: All other fields (octets 1-4). 5.2. States and modes ROHC UDPLite uses the same states, state logic and transitions as ROHC UDP, except when explicitly stated otherwise. It has not yet been determined whether ROHC UDPLite can use the same modes as ROHC RTP, and if so - how. This will require more explanations. 5.3. Packet type format The general format of a ROHC UDPLite packet is the same as for ROHC UDP (see [RFC-3095] section 5.11). Padding and CIDs are the same, as are the feedback packet type (see [RFC-3095] section 5.7.6.1) and the feedback. IR and IR-DYN packets differ as described in section 5.1. The general format of compressed packets is also the same, but there are differences in specific formats as detailed below. These Pelletier [Page 11] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 differences are introduced by the UPD Lite semantics of the Checksum Coverage field and the Checksum. The same notation as in ROHC RTP is used in this section: -- 5.4. IP/UPD Lite/RTP compression: ROHC RTP/UDPLite (Profile TBD) Unless stated otherwise, the mechanisms of ROHC RTP are used also for ROHC RTP/UDPLite. 5.4.1. Initialization The static context is initialized in the same way as for ROHC RTP ([RFC-3095], section 5.11.1). 5.4.2 Packet types The notation used in this section is the same as in [RFC-3095] section 5.7. The general packet format is the same as for a compressed ROHC RTP header, with an exception for the field pertaining to the UDP Lite checksum and the addition of a field for the Checksum Coverage. --- --- --- --- --- --- --- --- : : + UDP Lite Checksum Coverage + 2 octets, : : if context(UDP Lite Checksum) != 0 --- --- --- --- --- --- --- --- : : + UDP Lite Checksum + 2 octets, : : if context(UDP Lite Checksum) != 0 --- --- --- --- --- --- --- --- Note that the order of the fields following the optional extension is the same as the order between the fields in an uncompressed header. Note that the presence of the UDP Lite Checksum and Checksum Coverage fields is inferred in a similar manner than for [RFC-3095] for every packet formats, with the exception of PT-0 and PT-1 where it is instead dependent on the packet format. 5.4.2.1 Packet type 0: PT-0 PT-0: TBA It has not yet been determined if a 3-bit CRC is suitable to achieve the desired properties mentioned in section 4.4, and as a consequence if the U/O-0 packet format of ROHC RTP could be used as PT-0 for this profile. Pelletier [Page 12] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 5.4.2.2 Packet type 1: TBD Packet type 1: TBA The following header bits should be useful when defining PT-1: - Packet type (2 bits) : 1 0, for packet type 1 - Checksum Coverage Flag (1 bit): 1, if field is present - Checksum Flag (1 bit) : 1, if field is present - CRC (? bits) : ROHC ?-bit CRC ([ROHC], section 5.9.2) - Other bits, depending on the packet type properties, based on ROHC RTP PT-0 and PT-1. Note that the flags are used to identify how the values of the Checksum Coverage and Checksum fields are to be decompressed, based on the different scenarios described in section 3.2. 5.4.2.3 Packet types 2, IR, IR-DYN and extensions Packet type 2 and extensions are the same as [RFC-3095]. Packet types IR and IR-DYN are the same as in [RFC-3095], except for the changes of section 5.1. 5.5. Non-RTP IP/UPD Lite compression: ROHC UDPLite (Profile TBD) Unless stated otherwise, the mechanisms of ROHC UDP are used also for ROHC UDPLite, with the same considerations regarding the UDP SN taking the role of the RTP Sequence Number ([RFC-3095] section 5.11). 5.5.1. Initialization The static context for ROHC UDPLite streams can be initialized in similar ways as for ROHC UDP, however using the modified IR packet from section 5.1 and with the profile value set to (TBD) or reusing an existing context of a stream compressed using ROHC RTP/UDPLite. Note: In the case where an existing context is reused, the stream may have originally been assumed a UDP Lite/RTP stream, based on the UDP Lite protocol identifier (as opposed to assuming profile 0x0001). 5.5.2. Packet types TBA 6. Security considerations The security considerations of [RFC-3095] apply integrally to this document without modifications. Pelletier [Page 13] INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002 7. Acknowledgements The author would like to thank Lars-Erik Jonsson, Krister Svanbro for reviews and discussions around this document. 8. Intellectual Property Right Claim Considerations The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 9. References [RFC-3095] C. Bormann, "Robust Header Compression (ROHC)", RFC 3095, July 2001. [UDPLite] L. Larzon, M. Degermark, "The UDP Lite Protocol", Internet draft (work in progress), January 2002. [RFC-1144] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [RFC-791] J. Postel, "Internet Protocol", RFC 791, September 1981. [RFC-2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC-768] J. Postel, "User Datagram Protocol", RFC 768, August 1980. [RFC-1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. 10. Authors address Ghyslain Pelletier Tel: +46 920 20 24 32 Ericsson Erisoft AB Fax: +46 920 20 20 99 Box 920 SE-971 28 Lulea Sweden EMail: ghyslain.pelletier@epl.ericsson.se This Internet-Draft expires August 22, 2002. Pelletier [Page 14]