[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-rohc-tcp-taroc) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 4996

Network Working Group               Ghyslain Pelletier, Editor, Ericsson
INTERNET-DRAFT                       Qian Zhang, Microsoft Research Asia
Expires: November 2003                       Lars-Erik Jonsson, Ericsson
                                   HongBin Liao, Microsoft Research Asia
                                         Mark A West, Siemens/Roke Manor

                                                            May 23, 2003

                     RObust Header Compression (ROHC):
                        TCP/IP Profile (ROHC-TCP)
                       <draft-ietf-rohc-tcp-04.txt>


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


Abstract

   This document specifies a ROHC (Robust Header Compression) profile
   for compression of TCP/IP packets. The profile, called ROHC-TCP, is a
   robust header compression scheme for TCP/IP that provides improved
   compression efficiency and enhanced capabilities for compression of
   various header fields including TCP options.

   Existing TCP/IP header compression schemes do not work well when used
   over links with significant error rates and long round-trip times.
   For many bandwidth limited links where header compression is
   essential, such characteristics are common. In addition, existing
   schemes [RFC-1144, RFC-2507] have not addressed how to compress TCP
   options such as SACK (Selective Acknowledgements) [RFC-2018, RFC-
   2883] and Timestamps [RFC-1323].




Pelletier, et al.                                               [Page 1]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


Table of contents

   1.  Introduction....................................................3

   2.  Terminology.....................................................4

   3.  Background......................................................5

       3.1.  Existing TCP/IP header compression schemes................5
       3.2.  Classification of TCP/IP header fields....................6
       3.3.  Characteristics of short-lived TCP transfers..............7

   4.  Overview of the TCP/IP profile..................................8

       4.1.  General concepts..........................................8
       4.1.1.  Feedback channel considerations.........................8
       4.1.2.  Master sequence number (MSN)............................8
       4.1.3.  Context replication.....................................9
       4.2.  ROHC-TCP operation........................................9
       4.3.  Encoding methods..........................................9

   5.  ROHC-TCP - TCP/IP compression (Profile 0x0006).................10

       5.1.  Initialization...........................................10
       5.2.  Packet types.............................................11
       5.2.1.  Initialization and Refresh packets (IR)................11
       5.2.2.  Compressed packets (CO)................................11
       5.3.  Compression logic........................................11
       5.3.1.  Compressor states and logic............................11
       5.3.2.  Initialization and Refresh (IR) state..................12
       5.3.3.  Compression (CO) state.................................12
       5.3.4.  Feedback logic.........................................12
       5.3.5.  State transition logic.................................13
       5.3.5.1.  Optimistic approach, upward transition...............13
       5.3.5.2.  Optional acknowledgements (ACKs), upward transition..13
       5.3.5.3.  Timeouts, downward transition........................13
       5.3.5.4.  Negative ACKs (NACKs), downward transition...........14
       5.3.5.5.  Need for updates, downward transition................14
       5.4.  Decompression logic......................................14
       5.4.1.  Decompressor states and logic..........................14
       5.4.2.  No Context (NC) state..................................15
       5.4.3.  Full Context (FC) state................................15
       5.4.4.  Static Context (SC) state..............................16
       5.4.5.  Allowing decompression.................................16
       5.4.6.  Reconstruction and verification........................16
       5.4.7.  Actions upon CRC failure...............................16
       5.4.8.  Feedback logic.........................................17
       5.5.  Packet formats...........................................17
       5.5.1.  Basic structure of the ROHC-TCP IR and IR-DYN packets..17
       5.5.1.1.  Initialization of the IPv6 Header [RFC-2460].........17
       5.5.1.2.  Initialization of the IPv4 Header [RFC-791]..........17



Pelletier, et al.                                               [Page 2]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


       5.5.1.3.  Initialization of the TCP Header [RFC-793]...........18
       5.5.2.  IP-ID..................................................18
       5.5.3.  Basic structure of the ROHC-TCP IR-REPLICATE packet....18
       5.5.4.  Feedback formats and options for ROHC-TCP..............20
       5.5.4.1.  Feedback formats.....................................20
       5.5.4.2.  Feedback options.....................................21

   6.  Security considerations........................................21

   7.  IANA considerations............................................21

   8.  Acknowledgements...............................................22

   9.  References.....................................................22

       9.1. Normative references......................................22
       9.2. Informative references....................................23

   10.  Authors' addresses............................................24


1.  Introduction

   There are several reasons to perform header compression on low- or
   medium-speed links for TCP/IP traffic, and these have already been
   discussed in [RFC-2507]. [TCP-REQ] introduces additional
   considerations making robustness an important objective for a TCP
   compression scheme. Finally, existing TCP/IP header compression
   schemes [RFC-1144, RFC-2507] are limited in their handling of the TCP
   options field and cannot compress the headers of handshaking packets
   (SYNs and FINs).

   It is thus desirable for a header compression scheme to be able to
   handle loss on the link between the compression and decompression
   point as well as loss before the compression point. The header
   compression scheme also needs to consider how to efficiently compress
   short-lived TCP transfers and TCP options, such as SACK [RFC-2018,
   RFC-2883] and Timestamps [RFC-1323].

   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. This document defines a TCP/IP
   compression profile for the ROHC framework [RFC-3095], compliant with
   the requirements on ROHC TCP/IP header compression [TCP-REQ].
   Specifically, it describes a header compression scheme for TCP/IP
   header compression (ROHC-TCP) that is robust against packet loss and
   that offers enhanced capabilities, in particular for the compression
   of header fields including TCP options. The profile identifier for
   TCP/IP compression is 0x0006.





Pelletier, et al.                                               [Page 3]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


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 RFC2119.

   This document reuses some of the terminology found in [RFC-3095]. In
   addition, this document defines the following terms:


   Base context

     The base context is a context that has been validated by both the
     compressor and the decompressor. A base context can be used as the
     reference when building a new context using replication.


   Base CID

     The Base Context Identifier is the CID used to identify the Base
     Context, where information needed for context replication can
     be extracted from.


   Context replication

     Context replication is the mechanism that establishes and
     initializes a new context based on another existing valid context
     (a base context). This mechanism is introduced to reduce the
     overhead of the context establishment procedure, and is especially
     useful for compression of multiple short-lived TCP connections that
     may be occurring simultaneously or near-simultaneously.


   Short-lived TCP Transfer

     Short-lived TCP transfers refer to the TCP connections transmitting
     only small amounts of data for each single connection. Short TCP
     flows seldom need to operate beyond the slow-start phase of TCP to
     complete their transfer, which also means that the transmission
     ends before any significant increase of the TCP congestion window
     may occur.












Pelletier, et al.                                               [Page 4]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


3.  Background

   This chapter provides some background information on TCP/IP header
   compression.  The fundamentals of general header compression may be
   found in [RFC-3095]. In the following sections, two existing TCP/IP
   header compression schemes are first described along with a
   discussion of their limitations, followed by the classification of
   TCP/IP header fields. Finally, some of the characteristics of short-
   lived TCP transfers are summarized.

   The behavior analysis of TCP/IP header fields among multiple short-
   lived connections may be found in [TCP-BEH].

3.1.  Existing TCP/IP header compression schemes

   Compressed TCP (CTCP) and IP Header Compression (IPHC) are two
   different schemes that may be used to compress TCP/IP headers. Both
   schemes transmit only the differences from the previous header in
   order to reduce the large overhead of the TCP/IP header.

   The CTCP [RFC-1144] compressor detects transport-level
   retransmissions and sends a header that updates the context
   completely when they occur. While CTCP works well over reliable
   links, it is vulnerable when used over less reliable links as even a
   single packet loss results in loss of synchronization between the
   compressor and the decompressor. This in turn leads to the TCP
   receiver discarding all remaining packets in the current window
   because of a checksum error. This effectively prevents the TCP Fast
   Retransmit algorithm [RFC-2001] from being triggered. In such case,
   the compressor must wait until the TCP timeout to resynchronize.

   To reduce the errors due to the inconsistent contexts between
   compressor and decompressor when compressing TCP, IPHC [RFC-2507]
   improves somewhat on CTCP by augmenting the repair mechanism of CTCP
   with a local repair mechanism called TWICE and with a link-level
   nacking mechanism to request a header that updates the context.

   The TWICE algorithm assumes that only the Sequence Number field of
   TCP segments are changing with the deltas between consecutive packets
   being constant in most cases. This assumption is however not always
   true, especially when TCP Timestamps and SACK options are used.

   The full header request mechanism requires a feedback channel that
   may be unavailable in some circumstances. This channel is used to
   explicitly request that the next packet be sent with an uncompressed
   header to allow resynchronization without waiting for a TCP timeout.
   In addition, this mechanism does not perform well on links with long
   round-trip time.

   Both CTCP and IPHC are also limited in their handling of the TCP
   options field. For IPHC, any change in the options field (caused by



Pelletier, et al.                                               [Page 5]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   timestamps or SACK, for example) renders the entire field
   uncompressible, while for CTCP such a change in the options field
   effectively disables TCP/IP header compression altogether.

   Finally, existing TCP/IP compression schemes do not compress the
   headers of handshaking packets (SYNs and FINs). Compressing these
   packets may greatly improve the overall header compression ratio for
   the cases where many short-lived TCP connections share the same link.

3.2.  Classification of TCP/IP header fields

   Header compression is possible due to the fact that there is much
   redundancy between header field values within packets, especially
   between consecutive packets. To utilize these properties for TCP/IP
   header compression, it is important to understand the change patterns
   of the various header fields.

   All fields of the TCP/IP packet header have been classified in detail
   in [TCP-BEH]. The main conclusion is that most of the header fields
   can easily be compressed away since they never or seldom change. The
   following fields do however require more sophisticated mechanisms:

       - IPv4 Identification (16 bits)         - IP-ID
       - TCP Sequence Number (32 bits)         - SN
       - TCP Acknowledgement Number (32 bits)  - ACKN
       - TCP Reserved (4 bits)
       - TCP ECN flags (2 bits)                - ECN
       - TCP Window (16 bits)                  - WINDOW
       - TCP Options
          - Maximum Segment Size (4 octets)    - MSS
          - Window Scale (3 octets)            - WSopt
          - SACK Permitted (2 octets)
          - TCP SACK                           - SACK
          - TCP Timestamp (32 bits)            - TS

   The assignment of IP-ID values can be done in various ways, which are
   Sequential jump, Random, and Sequential, respectively.  However,
   designers of IPv4 stacks for cellular terminals should use an
   assignment policy close to Sequential. In [RFC-3095], the IP-ID is
   generally inferred from the RTP Sequence Number. However, with regard
   to TCP compression, the analysis in [TCP-BEH] reveals that there is
   no obvious candidate to this purpose among the TCP fields.

   The change pattern of several TCP fields (Sequence Number,
   Acknowledgement Number, Window, etc.) are very hard to predict and
   differs entirely from the behavior of RTP fields discussed in [RFC-
   3095]. Of particular importance to a TCP/IP header compression scheme
   is the understanding of the sequence and acknowledgement number [TCP-
   BEH]. Specifically, at any point on the path (i.e. wherever a
   compressor might be deployed), the sequence number can be anywhere
   within a range defined by the TCP window. Missing packets or



Pelletier, et al.                                               [Page 6]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   retransmissions can cause the TCP sequence number to fluctuate within
   the limits of this window. The jumps in acknowledgement number are
   also bounded by this TCP window.

   Another important behavior of the TCP/IP header is the dependency
   between the sequence number and the acknowledgment number. It is
   well-known that most TCP connections only have one-way traffic (web
   browsing and FTP downloading, for example). This means that on the
   forward path (from server to client), only the sequence number is
   changing while the acknowledgement number remains constant for most
   packets; on the backward path (from client to server), only the
   sequence number is changing and the acknowledgement number remains
   constant for most packets.

   With respect to TCP options, it is noted that most options (such as
   MSS, WSopt, SACK-permitted, etc.) may appear only on a SYN segment.
   Every implementation should (and we expect most will) ignore unknown
   options on SYN segments.

   Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any
   special treatment in this document, for similar reasons as those
   described in [RFC-3095].

3.3.  Characteristics of short-lived TCP transfers

   Recent studies shows that the majority of TCP flows are short-lived
   transfers with an average and a median size no larger than 10KB.
   Short-lived TCP transfers will degrade the performance of header
   compression schemes that establish a new context by initially sending
   full headers.

   It is hard to improve the performance for a single, unpredictable,
   short-lived connection. However, there are common cases where there
   will be multiple TCP connections between the same pair of hosts. A
   mobile user browsing several web pages from the same web server (this
   is more the case with HTTP/1.0 than HTTP/1.1) is one example.

   In such case, multiple short-lived TCP/IP flows occur simultaneously
   or near simultaneously within a relatively short time interval. It
   may be expected that most (if not all) of the IP header of the these
   connections will be almost identical to each other, with only small
   relative jumps for the IP-ID field.

   Furthermore, a subset of the TCP fields may also be very similar from
   one connection to another. For example, one of the port numbers may
   be reused (the service port) while the other (the ephemeral port) may
   be changed only by a small amount relative to the just-closed
   connection.

   With regard to header compression, this means that parts of a
   compression context used for a TCP connection may be reusable for



Pelletier, et al.                                               [Page 7]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   another TCP connection. A mechanism supporting context replication,
   where a new context is initialized from an existing one, provide
   useful optimizations for a sequence of short-lived TCP connections.

   Context replication is possible due to the fact that there is much
   similarity in header field values and context values among multiple
   simultaneous or near simultaneous connections. All header fields and
   related context values have been classified in detail in [TCP-BEH].
   The main conclusion is that most part of the IP sub-context, some TCP
   fields, and some context values can easily be replicated since they
   seldom change or change with only a small jump.


4.  Overview of the TCP/IP profile

4.1.  General concepts

   Many of the concepts behind the ROHC-TCP profile are similar to those
   described in [RFC-3095]. Like for other ROHC profiles, ROHC-TCP makes
   use of the ROHC protocol as described in [RFC-3095, sections 5.1 to
   5.2.6 inclusively]. This include data structures, general packet
   formats, reserved packet types, segmentation and initial decompressor
   processing. ROHC-TCP also integrally reuse some of the encoding
   methods defined in [RFC-3095, section 4.5].

4.1.1.  Feedback channel considerations

   The ROHC-TCP profile may be used in environments with or without
   feedback capabilities from decompressor to compressor. ROHC-TCP
   however assumes that if a ROHC feedback channel is available and is
   used at least once by the decompressor, this channel will be present
   during the entire compression operation. The occurrence of this
   channel will be further referred as the "established" feedback
   channel. Otherwise, if the connection is broken and the channel
   disappears, header compression should be restarted.

   To parallel [RFC-3095], this is similar to allowing only one
   transition per compressor state machine: from the initial
   unidirectional mode to the bi-directional mode of operation, with the
   transition being triggered by the reception of the first packet
   containing feedback from the decompressor. This effectively means
   that ROHC-TCP does not explicitly define any operational modes.

4.1.2.  Master sequence number (MSN)

   Feedback packets of types ACK and NACK carry information about
   sequence number or acknowledgement number from decompressor to
   compressor. Unfortunately, there is no guarantee that sequence number
   and acknowledgement number fields will be used by every IP protocol
   stack. In addition, the combined size of the sequence number field




Pelletier, et al.                                               [Page 8]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   and the acknowledgement number field is rather large, and they can
   therefore not be carried efficiently within the feedback packet.

   To overcome this problem, ROHC-TCP introduces a control field called
   the Master Sequence Number (MSN) field. The MSN field is created at
   the compressor, rather than using one of the fields already present
   in the uncompressed header.

   If a feedback channel is established, the MSN field is present in
   every packets sent by the compressor when in the Initialization and
   Refresh state (IR) as well as in every m compressed header. The
   decompressor always sends the MSN as part of the feedback
   information. The MSN can later be used by the compressor to infer
   which packet is being acknowledged by the decompressor.

   The value of m is chosen as trade-off between compression efficiency
   and acknowledgement efficiency.

4.1.3.  Context replication

   For ROHC-TCP, context replication may be particularly useful for
   short-lived TCP flows [TCP-REQ]. ROHC-TCP therefore supports context
   replication as defined in [ROHC-CR], and the basic structure of the
   IR-REPLICATE packet is defined in section 5.5.3.

4.2.  ROHC-TCP operation

   Header compression with ROHC can be characterized as an interaction
   between two state machines, one compressor machine and one
   decompressor machine, each instantiated once per context.

   For ROHC-TCP compression, the compressor has two states and the
   decompressor has three states. The two compressor states are the
   Initialization and Refresh (IR) state, and the Compression (CO)
   state. The three states of the decompressor are No Context (NC),
   Static Context (SC) and Full Context (FC). Transitions need not be
   synchronized between the two state machines.

4.3.  Encoding methods

   <# Editor's Note: This section needs to be completed and formatted #>

   As mentioned earlier, ROHC-TCP integrally reuse some of the encoding
   methods defined in [RFC-3095, section 4.5].

   Considering the changing pattern of several TCP fields, such as
   sequence number, acknowledgement number, etc., Window-based LSB
   encoding [RFC-3095], which does not assume the linear changing
   pattern of the target header fields, is more suitable to encode those
   TCP fields both efficiently and robustly.




Pelletier, et al.                                               [Page 9]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   Fixed-payload encoding

   If the compressor finds that the payload size of consecutive packets
   is a constant value and one of such packets has been removed from the
   context window, which means the decompressor has known the exact
   value of the constant size, it may use fixed-payload encoding scheme
   to improve the compression efficiency.

   For some applications, such as bulk data transfer, the payload size
   of each packet is usually a constant value, e.g. 1460 bytes. In such
   case, the sequence number and acknowledgment number can be
   represented using the following equation:

             SEQ (or ACK) = m * PAYLOAD + n.

   If all the packets in context window have the same 'n', only 'm'
   needs to be transmitted to the decompressor. The decompressor can
   assign the value of æPAYLOADÆ using the packet size of the reference
   packet. The decompressor can then obtain the sequence number or
   acknowledgment number after correctly decoding 'm', and use those as
   reference values. This encoding method is called fixed-payload
   encoding.


5.  ROHC-TCP - TCP/IP compression (Profile 0x0006)

   This section describes a ROHC profile for TCP/IP compression. The
   profile identifier for ROHC-TCP is 0x0006.

   <# Editor's Note: This chapter needs to be completed #>


5.1.  Initialization

   The static context of ROHC TCP streams can be initialized in either
   two ways:

   1) By using an IR packet as in section 5.4.1, where the profile is
   six (6) and the static chain ends with the static part of a TCP
   packet. At the compressor, the MSN is initialized to a random value
   when the IR packet is sent.

   2) By reusing an existing context where using context replication
   [ROHC-CR]. This is done with an IR-REPLICATE packet as in section
   5.4.3, where the profile number is six (6) and the static replication
   chain ends with the static part of a TCP packet. At the compressor,
   the MSN is either reinitialized to <# Editor's Note: Initial value of
   the MSN is TBD #> value if it is sent within the IR-REPLICATE packet,
   or the MSN value already present in the base context is used if the
   it is not sent.




Pelletier, et al.                                              [Page 10]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


5.2.  Packet types

   ROHC-TCP defines two different packet types: the Initialization and
   Refresh (IR) packet type, and the Compressed packet type (CO). Each
   type correspond to one of the possible states of the compressor.

   Each packet type also define a number of packet formats: [#TBD]
   packet formats are defined for compressed headers (CO), and three for
   initialization/refresh/replication (IR).

5.2.1.  Initialization and Refresh packets (IR)

   The ROHC-TCP IR packet follows the general format of the ROHC IR
   packet, as defined in [RFC-3095, section 5.2.3].

   Packet type: IR

     This packet type communicates the static part of the context. It
     can optionally also communicate the dynamic part of the context.

   Packet type: IR-DYN

     This packet type communicates the dynamic part of the context.

   Packet type: IR-REPLICATE

     This packet type communicates the static and dynamic parts of the
     replicated context.

5.2.2.  Compressed packets (CO)

   <# Editor's Note:                                             #>
   <# To be written once the ROHC-TCP packet formats are defined #>
   <# A decision must be taken by the ROHC WG regarding the      #>
   <# method to use when defining the packet formats, in         #>
   <# particular in relation to the proposed formal notation.    #>


5.3.  Compression logic

5.3.1.  Compressor states and logic

   For ROHC-TCP, the two compressor states are the Initialization and
   Refresh (IR) state, and the Compression (CO) state. The compressor
   always start in the lower compression state (IR). The compressor will
   normally operate in the higher compression state (CO), under the
   constraint that the compressor is sufficiently confident that the
   decompressor has the information necessary to reconstruct a header
   compressed according to this state.





Pelletier, et al.                                              [Page 11]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   The figure below shows the state machine for the compressor. The
   details of each state, state transitions, and compression logic are
   given in sub-sections following the figure.

                 Optimistic approach / ACK     ACK
               +------>------>------>------+  +->-+
               |                           |  |   |
               |                           v  |   v
           +----------+                  +----------+
           | IR State |                  | CO State |
           +----------+                  +----------+
               ^                                |
               |  Timeout / NACK / STATIC-NACK  |
               +-------<-------<-------<--------+

   The transition from IR state to CO state is based on the following
   principles: the need for update and the optimistic approach principle
   or, if a feedback channel is established, feedback received from the
   decompressor.

   In ROHC-TCP, the compressor will start in the IR state. The following
   sub-sections will describe further the logic for the compressor.

5.3.2.  Initialization and Refresh (IR) state

   <# Editor's Note: To be defined #>

5.3.3.  Compression (CO) state

   <# Editor's Note: To be defined #>

5.3.4.  Feedback logic

   ROHC-TCP makes use of feedback from decompressor to compressor for
   transitions in the backward direction, and optionally to improve the
   forward transition.

   The reception of either positive feedback (ACKs) or negative feedback
   (NACKs) establishes the feedback channel from the decompressor. Once
   there is an established feedback channel, the compressor makes use of
   this feedback for optionally improving the transitions among
   different states. This helps increasing the compression efficiency by
   providing the information necessary for the compressor to achieve the
   necessary confidence level. When the feedback channel is established,
   it becomes superfluous for the compressor to send periodic refreshes.

   In the IR state, the compressor can transit to the CO state once it
   receives a valid ACK for an IR/IR-REPLICATE packet sent (an ACK can
   only be valid if it refers to a packet sent earlier). If the packet
   referred by the feedback is in the context window, the compressor
   will remove packets older than the referred packet from the context



Pelletier, et al.                                              [Page 12]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   window.  Because ACK means that the packet referred by feedback has
   been the reference of the decompressor, the compressor doesn't need
   to keep older packets.

   If the compressor is in the CO state, it will remove the packets
   older than the referred packet by the feedback from the context
   window.

   Upon receiving an NACK, the compressor transits back to IR state.

5.3.5.  State transition logic

   Decisions about transitions between the IR and the CO states are
   taken by the compressor on the basis of:

      - variations in the packet headers
      - positive feedback from decompressor (Acknowledgements -- ACKs)
      - negative feedback from decompressor (Negative ACKS -- NACKs)
      - confidence level regarding error-free decompression of a packet

5.3.5.1.  Optimistic approach, upward transition

   Transition to the CO state is carried out according to the optimistic
   approach principle. This means that the compressor transits to the CO
   state when it is fairly confident that the decompressor has received
   enough information to correctly decompress packets sent according to
   the higher compression state.

   In general, there are many approaches where the compressor can obtain
   such information. A simple and general approach can be achieved by
   sending uncompressed or partial full headers periodically.

5.3.5.2.  Optional acknowledgements (ACKs), upward transition

   The compressor can also transit to the CO state based on feedback
   received by the decompressor. If a feedback channel is available,
   positive feedback (ACKs) MAY be used for acknowledging successful
   decompression of packets. Upon reception of an ACK for a context
   updating packet, the compressor knows that the decompressor has
   received the acknowledged packet and the transition to the CO state
   can be carried out immediately. This functionality is optional, so a
   compressor MUST NOT expect to get such ACKs initially or during
   normal operation, even if a feedback channel is available or
   established.

5.3.5.3.  Timeouts, downward transition

   When the optimistic approach is used, e.g. until a feedback channel
   is established, there will always be a possibility of failure since
   the decompressor may not have received sufficient information for
   correct decompression. Therefore, unless a feedback channel has been



Pelletier, et al.                                              [Page 13]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   established, the compressor MUST periodically transit to the IR
   state.

5.3.5.4.  Negative ACKs (NACKs), downward transition

   Negative acknowledgments (NACKs) are also called context requests.
   Upon reception of a NACK the compressor transits back to the IR state
   and sends updates (IR-DYN, or possibly IR) to the decompressor. NACKs
   carry the MSN of the latest packet successfully decompressed.

5.3.5.5.  Need for updates, downward transition

   When the header to be compressed does not conform to the established
   pattern or the compressor is not confident whether the decompressor
   has the synchronized context, the compressor will transit to the IR
   state.

5.4.  Decompression logic

5.4.1.  Decompressor states and logic

   The three states of the decompressor are No Context (NC), Static
   Context (SC) and Full Context (FC). The decompressor starts in its
   lowest compression state, the NC state. Successful decompression will
   always move the decompressor to the FC state. The decompressor state
   machine normally never leaves the FC state once it has entered this
   state; only repeated decompression failures will force the
   decompressor to transit downwards to a lower state. The decompressor
   does not attempt to decompress headers at all in the NC state and SC
   states unless sufficient information is included in the received
   packet itself.

   Below is the state machine for the decompressor. Details of the
   transitions between states and decompression logic are given in the
   sub-sections following the figure.

                                 Success
                +-->------>------>------>------>------>--+
                |                                        |
    No Static   |            No Dynamic        Success   |    Success
     +-->--+    |             +-->--+      +--->----->---+    +-->--+
     |     |    |             |     |      |             |    |     |
     |     v    |             |     v      |             v    |     v
   +-----------------+   +---------------------+   +-------------------+
   | No Context (NC) |   | Static Context (SC) |   | Full Context (FC) |
   +-----------------+   +---------------------+   +-------------------+
      ^                         |        ^                         |
      | k_2 out of n_2 failures |        | k_1 out of n_1 failures |
      +-----<------<------<-----+        +-----<------<------<-----+





Pelletier, et al.                                              [Page 14]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


5.4.2.  No Context (NC) state

   Initially, while working in the NC state, the decompressor has not
   yet successfully decompressed a packet. Upon receiving an IR-STATIC,
   IR-DYN or IR-REPLICATE packet, the decompressor will verify the
   correctness of this packet by validating its header using the CRC
   check.

   For an IR-REPLICATE packet, the decompressor builds a new context
   from the existing base context and make the necessary update. For an
   IR-STATIC or an IR-DYN packet, the decompressor simply updates the
   context. Finally, the decompressor uses the successfully decompressed
   packet as the reference packet.

   When an IR-REPLICATE packet passes the verification, the decompressor
   should send an ACK. When an IR, an IR-DYN or any other packet is
   correctly decompressed, the compressor may optionally send an ACK. In
   either cases, the feedback packet will carry the master sequence
   number (MSN) information corresponding to the latest correctly
   decompressed packet.

   In the NC state, when any packet fails the verification, the
   decompressor should send a NACK. The decompressor discards all
   packets until a static update (IR-STATIC) or replication (IR-
   REPLICATE) that passes the verification check is received.

   Once a packet has been decompressed correctly, the decompressor can
   transit to the FC state, and only upon repeated failures will it
   transit back to a lower state. Only IR, IR-DYN or IR-REPLICATE
   packets may be decompressed in the NC state.

5.4.3.  Full Context (FC) state

   Upon receiving an IR, IR-DYN or IR-REPLICATE packet, the decompressor
   should verify the correctness of its header by CRC check. If the
   verification succeeds, the decompressor will update the context and
   use this packet as the reference packet. Consequently, the
   decompressor will convert the packet into the original packet and
   pass it to the network layer of the system.

   Upon receiving other types of packet, the decompressor will
   decompress it. The decompressor MUST verify the correctness of the
   decompressed packet. If this verification succeeds, the decompressor
   passes the decompressed packet to the system's network layer. The
   decompressor will then use this packet as the reference value, if it
   is not older than the current reference packet (by checking the MSN
   of the compressed packet, or the sequence number and/or the
   acknowledgement number field of the TCP header).

   When the verification check of k_1 out of the last n_1 decompressed
   packets have failed, context damage SHOULD be assumed and a NACK



Pelletier, et al.                                              [Page 15]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   SHOULD be sent. The decompressor moves to the SC state and discards
   all packets until an update that successfully  passes the
   verification check is received.

5.4.4.  Static Context (SC) state

   In the SC state, when the verification check of k_2 out of the last
   n_2 decompressed packets have failed, context damage is assumed and a
   STATIC-NACK SHOULD be sent. The decompressor moves to the NC state
   and discards all packets until an IR, IR-DYN or IR-REPLICATE that
   successfully passes the verification check is received.

   Note that appropriate values for k and n, are related to the residual
   error rate of the link.  When the residual error rate is close to
   zero, k = n = 1 may be appropriate.

   <# Editor's Note: Parts if this logic may have to be refined #>
   ># based on the packet formats and types to be defined, and  #>
   <# when the context replication mechanism will be defined.   #>


5.4.5.  Allowing decompression

   In the No Context state, only IR packets (including IR-REPLICATE),
   which carry information on the static fields, may be decompressed.

   <# Editor's Note: the Static Context is dependant on the packet   #>
   <#                format and particularly if and what kind of CRC #>
   <#                will be used. This is still to be defined.      #>

   In the Full Context state, decompression may be attempted regardless
   of the type of packet received. If  decompression may not be
   performed, the packet is discarded.

5.4.6.  Reconstruction and verification

   <# Editor's Note: To be written - depends on the packet formats #>


5.4.7.  Actions upon CRC failure

   The actions to be taken when a CRC verification fails following the
   decompression of an IR-REPLICATE packet are specified in [ROHC-CR].
   For other IR packets, the actions to be taken are specified in [RFC-
   3095, section 5.3.2.2.3]. For other ROHC-TCP packet types carrying a
   CRC, the following actions MUST be taken when a CRC verification
   fails:

   <# Editor's Note: To be defined - depends on packet formats,    #>
   <#                and particularly if and what kind of CRC will #>
   <#                be used. This is still to be defined.         #>



Pelletier, et al.                                              [Page 16]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


5.4.8.  Feedback logic

   The decompressor may send positive feedback (ACKs) to initially
   establish the feedback channel. Either positive feedback (ACKs) or
   negative feedback (NACKs) will establish the feedback channel between
   decompressor and compressor. Once a feedback channel is established,
   it will be used by the decompressor to send error recovery requests
   and (optionally) acknowledgements of significant context updates.
   When the feedback channel is established, it becomes superfluous for
   the compressor to send periodic refreshes.

5.5.  Packet formats

   <# Editor's Note: To be defined #>


5.5.1.  Basic structure of the TCP IR and IR-DYN packets

   ROHC-TCP uses the same basic structure for the IR and IR-DYN packets
   as defined in [RFC-3095, section 5.7.7.1. and section 5.7.7.2].

5.5.1.2.  Initialization of IPv6 Header [RFC-2460]

   Same as [RFC-3095, section 5.7.7.3].

5.5.1.3.  Initialization of IPv4 Header [RFC-791]

   Same as [RFC-3095, section 5.7.7.4].


























Pelletier, et al.                                              [Page 17]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


5.5.1.4.  Initialization of TCP Header [RFC-793]

   Static part:

         +---+---+---+---+---+---+---+---+
         /          Source Port          /   2 octets
         +---+---+---+---+---+---+---+---+
         /       Destination Port        /   2 octets
         +---+---+---+---+---+---+---+---+

   Dynamic part:

         +---+---+---+---+---+---+---+---+
         /    Master Sequence Number     /   2 octets
         +---+---+---+---+---+---+---+---+
         /       Sequence Number         /   4 octets
         +---+---+---+---+---+---+---+---+
         /    Acknowledgement Number     /   4 octets
         +---+---+---+---+---+---+---+---+
         | Data Offset   |   Reserved    |   1 octet
         +---+---+---+---+---+---+---+---+
         |CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|   1 octet
         +---+---+---+---+---+---+---+---+
         /            Window             /   2 octets
         +---+---+---+---+---+---+---+---+
         /           Checksum            /   2 octets
         +---+---+---+---+---+---+---+---+
         /        Urgent Pointer         /   2 octets
         +---+---+---+---+---+---+---+---+
         /           Options             /   variable length
         +---+---+---+---+---+---+---+---+

   Eliminated:

     Nothing.

   Extra:

     Master Sequence Number           See section 4.1.2.

5.5.2.  IP-ID

   The IP-ID is handled as in [RFC-3095, section 4.5.5], but the offset
   is from the MSN (see also section 4.1.2).

5.5.3.  Basic structure of the TCP IR-REPLICATE packet

   ROHC-TCP supports the context replication mechanism defined in [ROHC-
   CR]. Context replication requires a dedicated IR packet format that
   uniquely identifies the IR-REPLICATE packet for this profile.




Pelletier, et al.                                              [Page 18]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   With consideration to the extensibility of the IR packet type defined
   in [RFC-3095], the ROHC-TCP profile supports context replication
   through the profile specific part of the IR packet. This is achieved
   using the bit (x) left in the IR packet header for "Profile specific
   information". For ROHC-TCP, this bit is defined as a flag indicating
   whether this packet is an IR packet or an IR-REPLICATE packet.

     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   |         Add-CID octet         |  if for small CIDs and CID != 0
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   1   0   1 |
   +---+---+---+---+---+---+---+---+
   |                               |
   /    0-2 octets of CID info     /  1-2 octets if for large CIDs
   |                               |
   +---+---+---+---+---+---+---+---+
   |            Profile            |  1 octet
   +---+---+---+---+---+---+---+---+
   |              CRC              |  1 octet
   +---+---+---+---+---+---+---+---+
   | B |          CRC*             |  1 octet
   +---+---+---+---+---+---+---+---+
   |                               |  present if B = 1,
   /           Base CID            /  1 octet if for small CIDs, or
   |                               |  1-2 octets if for large CIDs
   +---+---+---+---+---+---+---+---+
   |                               |
   |   Static replication chain    /  variable length
   |                               |
   +---+---+---+---+---+---+---+---+
   |                               |
   /  Dynamic replication chain    /  variable length
   |                               |
    - - - - - - - - - - - - - - - -
   |                               |
   /           Payload             /  variable length
   |                               |
    - - - - - - - - - - - - - - - -

   B:  B = 1 indicates that the Base CID field is present.

   Profile:  Profile identifier.

   CRC: 8-bit CRC computed using the polynomial of [ROHC-CR, section
       3.4.1.2]. The 8-bit CRC in the IR-REPLICATE packet is calculated
       over the initial part of the IR-REPLICATE packet ending with the
       Base CID (if present). The calculation of this CRC therefore
       excludes both replication chains as well as the payload but
       includes the B bit, CRC*, CID or any Add-CID octet.




Pelletier, et al.                                              [Page 19]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   CRC*: The CRC over the original, uncompressed, header. This 7-bit CRC
       is computed according to [ROHC-CR, section 3.4.1.1].

   Static replication chain:  A chain of static subheader information
       used for replication.

   Dynamic replication chain:  A chain of dynamic subheader information
       used for replication.  What dynamic information is present is
       inferred from the static replication chain.

   Payload:  The payload of the corresponding original packet, if any.
       The presence of a payload is inferred from the packet length.

5.5.4.  Feedback packets and formats

5.5.4.1.  Feedback formats for ROHC-TCP

   This section describes the feedback format for ROHC-TCP. ROHC-TCP
   uses the ROHC feedback format described in [ROHC, section 5.2.2].

   All feedback formats carry a field labeled SN. The SN field contains
   LSBs of the Master Sequence Number (MSN) described in section 4.1.3.
   The sequence number to use is the MSN corresponding to the header
   that caused the feedback information to be sent. If that MSN cannot
   be determined, for example when decompression fails, the MSN to use
   is that corresponding to the latest successfully decompressed header.

   FEEDBACK-1

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |              SN               |
   +---+---+---+---+---+---+---+---+

      A FEEDBACK-1 is an ACK.  In order to send a NACK or a STATIC-NACK,
      FEEDBACK-2 must be used.

   FEEDBACK-2

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |Acktype|  <# To Be Defined #>  |
   +---+---+---+---+---+---+---+---+
   |              SN               |
   +---+---+---+---+---+---+---+---+
   /       Feedback options        /
   +---+---+---+---+---+---+---+---+

      Acktype:  0 = ACK
                1 = NACK
                2 = STATIC-NACK



Pelletier, et al.                                              [Page 20]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


                3 is reserved (MUST NOT be used for parseability)

   <# Editor's Note: The exact format is to be defined #>

      Feedback options: A variable number of feedback options, see
                       section 5.5.4.2. Options may appear in any order.

5.5.4.2.  ROHC-TCP Feedback options

   ROHC-TCP uses the same feedback options as the options defined in
   [RFC-3095, section 5.7.6], with the following exceptions:

   1) The MSN replaces RTP SN in the feedback information.
   2) The CLOCK option [RFC-3095, section 5.7.6.6] is not used.
   3) The JITTER option [RFC-3095, section 5.7.6.7] is not used.


6. Security considerations

   Because encryption eliminates the redundancy that header compression
   schemes try to exploit, there is some inducement to forego encryption
   of headers in order to enable operation over low-bandwidth links.
   However, for those cases where encryption of data (and not headers)
   is sufficient, TCP does specify an alternative encryption method in
   which only the TCP payload is encrypted and the headers are left in
   the clear.  That would still allow header compression to be applied.

   A malfunctioning or malicious header compressor could cause the
   header decompressor to reconstitute packets that do not match the
   original packets but still have valid IP, and TCP headers and
   possibly also valid TCP checksums.  Such corruption may be detected
   with end-to-end authentication and integrity mechanisms which will
   not be affected by the compression.  Moreover, this header
   compression scheme uses an internal checksum for verification of
   reconstructed headers.  This reduces the probability of producing
   decompressed headers not matching the original ones without this
   being noticed.

   Denial-of-service attacks are possible if an intruder can introduce
   (for example) bogus IR, CO or FEEDBACK packets onto the link and
   thereby cause compression efficiency to be reduced.  However, an
   intruder having the ability to inject arbitrary packets at the link
   layer in this manner raises additional security issues that dwarf
   those related to the use of header compression.


7. IANA Considerations

   ROHC profile identifier 0x00XX <# Editor's Note: To be replaced
   before publication #> has been reserved by the IANA for the profile
   defined in this document.



Pelletier, et al.                                              [Page 21]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   <# Editor's Note: To be removed before publication #>

   A ROHC profile identifier must be reserved by the IANA for the
   profile defined in this document.  Profiles 0x0000-0x0005 have
   previously been reserved, which means this profile could be 0x0006.
   As for previous ROHC profiles, profile numbers 0xnnXX must also be
   reserved for future updates of this profile.  A suggested
   registration in the "RObust Header Compression (ROHC) Profile
   Identifiers" name space would then be:

     Profile             Usage            Document
     identifier

      0x0006            ROHC TCP       [RFCXXXX (this)]
      0xnn06            Reserved


8. Acknowledgements

   Header compression schemes from [RFC-1144, RFC-2507, RFC-3095] have
   been important sources of ideas and knowledge. The authors would like
   to thank [TBW] for valuable input.


9.  References

9.1.  Normative 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): Framework and four profiles:
               RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

   [ROHC-CR]   Pelletier, G., "Robust Header Compression (ROHC): Context
               replication for ROHC profiles", Internet Draft (work in
               progress), <draft-pelletier-rohc-context-replication-
               00.txt>, May 2003.

   [RFC-791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
               September 1981.

   [RFC-793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.

   [RFC-2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.






Pelletier, et al.                                              [Page 22]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


9.2.  Informative References

   [TCP-REQ]   Jonsson, L-E., "Requirements on ROHC IP/TCP header
               compression", Internet Draft (work in progress),<draft-
               ietf-rohc-tcp-requirements-05.txt>, October 2002.

   [TCP-BEH]   West, M. and S. McCann, "TCP/IP Field Behavior", Internet
               Draft (work in progress), <draft-ietf-rohc-tcp-field-
               behavior-02.txt>, March 2003.

   [IP-ONLY]   Jonsson, L., "RObust Header Compression (ROHC): A
               compression profile for IP", Internet draft (work in
               progress), January 2003, <draft-ietf-rohc-ip-only-01.txt>

   [RFC-768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC-1072]  Jacobson, V., and R. Braden, "TCP Extensions for Long-
               Delay Paths", LBL, ISI, October 1988.

   [RFC-1144]  Jacobson, V.,"Compressing TCP/IP Headers for Low-Speed
               Serial Links", RFC 1144, February 1990.

   [RFC-1323]  Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
               for High Performance", RFC 1323, May 1992.

   [RFC-1644]  Braden, R. "T/TCP -- TCP Extensions for Transactions
               Functional Specification", ISI, July 1994.

   [RFC-1693]  Connolly, T., et al, "An Extension to TCP : Partial Order
               Service", University of Delaware, November 1994.

   [RFC-1889]  Schulzrinne, H., Casner, S., Frederick, R. and V.
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", RFC 1889, January 1996.

   [RFC-2001]  Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
               Retransmit, and Fast Recovery Algorithms", NOAO, January
               1997.

   [RFC-2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
               Selective Acknowledgment Options", RFC 2018, October
               1996.

   [RFC-2026]  Bradner, S., "The Internet Standards Process û Revision
               3", BCP 9, RFC 2026, October 1996.

   [RFC-2119]  Bradner, S.,"Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC-2507]  Degermark, M., Nordgren, B. and S. Pink, "IP Header



Pelletier, et al.                                              [Page 23]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


               Compression", RFC 2507, February 1999.

   [RFC-2883]  Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
               Extension to the Selective Acknowledgement (SACK) Option
               for TCP", RFC 2883, July 2000.

   [E2E]       Jacobson, V., "Fast Retransmit", Message to the end2end-
               interest mailing list, April 1990.

   [Mobi96]    Degermark, M., Engan, M., Nordgren, B. and S. Pink, "Low-
               loss TCP/IP header compression for wireless networks", In
               the Proceedings of MobiCom, 1996.


10.  Authors' addresses

   Ghyslain Pelletier
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 24 32
   Fax: +46 920 20 20 99
   Email: ghyslain.pelletier@epl.ericsson.se


   Qian Zhang
   Microsoft Research Asia
   Beijing Sigma Center
   No.49, Zhichun Road, Haidian District
   Beijing 100080, P.R.C.

   Phone: +86 10 62617711-3135Email: qianz@microsoft.com


   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.com


   HongBin Liao
   Microsoft Research Asia
   Beijing Sigma Center
   No.49, Zhichun Road, Haidian District
   Beijing 100080, P.R.C.




Pelletier, et al.                                              [Page 24]

INTERNET-DRAFT            ROHC Profile for TCP              May 23, 2003


   Phone: +86 10 62617711-3156
   Email: i-hbliao@microsoft.com

   Mark A West
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   Phone: +44 1794 833311
   Email: mark.a.west@roke.co.uk


Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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 November 23, 2003.





Pelletier, et al.                                              [Page 25]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/