Internet DRAFT - draft-ash-e2e-vompls-hdr-compress

draft-ash-e2e-vompls-hdr-compress



 


Network Working Group                                        Jerry Ash
Internet Draft                                               Bur Goode
<draft-ash-e2e-vompls-hdr-compress-01.txt>                    Jim Hand
Expiration Date:  October 2003                                    AT&T
                                                        George Swallow
                                                   Cisco Systems, Inc.

                                                           March, 2003


             End-to-End VoIP over MPLS Header Compression

              <draft-ash-e2e-vompls-hdr-compress-01.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 to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


ABSTRACT:

VoIP over MPLS typically uses the encapsulation voice/RTP/UDP/IP/MPLS.  
For an MPLS VPN, the packet header is at least 48 bytes, while the voice 
payload is typically no more than 30 bytes.  VoIP over MPLS header 
compression can significantly reduce the VoIP overhead through various 
compression mechanisms.  This is important on access links where 
bandwidth is scarce, and can be important on backbone facilities, 
especially where costs are high (e.g., some global cross-sections).  In 
this draft we propose to use RSVP extensions to signal the header 
compression context and other control messages between the ingress and 
egress LSR.  We provide two approaches to determining the header 
compression context: a) re-use the methods in cRTP to determine the 
context, and b) re-use the methods in Swallow's and Berger's 'simple' 
approach to determine the context.

Table of Contents

   1. Introduction             
   2. Requirements
   3. Protocol Extensions
      3.1 Call Flows
          3.1.1 cRTP Header Compression
          3.1.2 'Simple' Header Compression
      3.2 Header Compression Object Formats
          3.2.1 SCID_Request Object
          3.2.2 Header_Compression_Reply Object
          3.2.3 Simple_Header_Compression Object
      3.3 Control Plane Procedures
          3.3.1 VoMPLS Procedures
          3.3.2 Resource Reservation Procedures
      3.4 Data Plane Procedures
   4. Security Considerations                                            
   5. Acknowledgments                                         
   6. References  
   7. Authors' Addresses
   8. Full Copyright Statement                                     

1. Introduction

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP/. 
 When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS.  For an 
MPLS VPN, the packet header is at least 48 bytes, while the voice 
payload is typically no more than 30 bytes.  The interest in VoIP over 
MPLS header compression (here abbreviated VoMPLS) is the possibility of 
significantly reducing the VoIP overhead through various compression 
mechanisms.  The need may be important on access links where bandwidth 
is more scarce, but it could be important on backbone facilities, 
especially where costs are high (e.g., some global cross-sections).  
Typically, VoIP will use voice compression mechanisms (e.g., G.729) in 
order to conserve bandwidth.  With VoIP header compression, 
significantly more bandwidth could be saved.  For example, carrying VoIP 
headers for the entire voice load of a large domestic network with 300 
million or more calls per day could consume on the order of about 20-40 
gigabits-per-second on the backbone network for headers alone.  This 
overhead could translate into considerable bandwidth capacity.

In principle, we could use existing header compression techniques, such 
as those described in [cRTP], together with MPLS labels to make the 
transport of the RTP/UDP/IP headers more efficient over an MPLS network. 
 However, at this time, there are no standards for VoMPLS header 
compression, and vendors have not implemented a VoMPLS header 
compression technique.  [cRTP] header compression is often used on the 
access links from the CE router to the PE router.  However, cRTP header 
compression must be implemented on a hop-by-hop basis, and does not 
scale well for large voice traffic loads.  To implement 'end-to-end' 
VoMPLS header compression, the ingress LSR would have to apply the 
header compression to the IP packet before adding the MPLS label, and 
the compressed header would have to be decompressed at the egress LSR 
where the LSP terminates.  A method is needed to set up a correspondence 
between the header compression tables at the ingress and egress of the 
LSP.

VoMPLS header compression methods have been proposed earlier in the MPLS 
working group, however the relevant drafts have expired.  George Swallow 
and Lou Berger proposed a 'simple' end-to-end compression scheme in 
which all first-order differences in the RTP/UDP/IP headers were 
transmitted, and in which the header compression context was established 
through RSVP signaling [RSVP, RSVP-TE]. Swallow's and Berger's 'simple' 
approach achieved about a 50 percent reduction in the size of the 
RTP/UDP/IP header. Thomas Theimer proposed an end-to-end header 
compression approach that would provide MPLS extensions for tunneling 
compressed headers over PPP links [TCRTP].  Lou Berger proposed 
MPLS-based extensions to 'hop-by-hop' header compression methods (e.g., 
[cRTP]), which could achieve about 90 percent reduction in the 
RTP/UDP/IP header. The MPLS Forum has since finalized an 
implementation/protocol for VoMPLS header compression [MPLSF-HC], 
however the technique does not provide means to interwork with IP.

In this draft we propose to use RSVP extensions to signal the header 
compression context between the ingress and egress LSR.  Furthermore, we 
provide two approaches to determining the context:

a) re-use the methods in [cRTP] to determine the FULL_HEADER packets for 
the context identification, which contains the session context ID (SCID) 
identified using RSVP objects;
b) re-use the methods in Swallow's and Berger's 'simple' approach to 
determine the SIMPLE_HEADER_COMPRESSION object, which contains the SCID 
and the compressed header template, and transport the object over RSVP.

We recommend using enhancements to cRTP that would minimize feedback 
based error recovery using CONTEXT_STATE packets [cRTP-ENHANCE] to make 
cRTP more tolerant of packet loss, and minimize the need to use the cRTP 
error recovery mechanism.  The reason is that basic cRTP would perform 
best with very low packet error rates on all hops of the path. Tunneling 
a cRTP session through multiple IP hops will increase the round trip 
delay and the chance of packet loss.  cRTP contexts are invalidated due 
to packet loss.  The cRTP error recovery mechanism using CONTEXT_STATE 
packets can compound the problem when long round trip delays are 
involved.  When the cRTP decompressor context state gets out of synch 
with the compressor, it will drop packets associated with the context 
until the two states are resynchronized.  To resynchronize context state 
at the two ends, the decompressor transmits the CONTEXT_STATE packet to 
the compressor, and the compressor transmits a FULL_HEADER packet to the 
decompressor.  If the resynchronization were rare, then the basic cRTP 
approach would perform well for end-to-end header compression.  
Otherwise, enhanced cRTP is desirable.

The SIMPLE_HEADER compression approach is very tolerant to delay and 
packet loss, but achieves less header compression as a trade-off (about 
50% header reduction versus 90% for cRTP).

Compressing and decompressing headers at the CE routers (versus, say, 
the PE routers) in RFC2547 VPNs disperses the header compression 
computational load among many CE routers, and may achieve better 
scalability.  However, CEs need to establish many LSPs with RSVP, manage 
labels, etc. which would counterbalance the scalability gain.  Also, 
there is a need to limit calls to LSP bandwidth, hence application of 
aggregated bandwidth allocation is suggested through use of 
MPLS/DiffServ traffic engineering [MPLS-DS-TE], for better scalability.

Section 2 presents the requirements for end-to-end VoMPLS header 
compression, and Section 3 presents the proposed protocol extensions.

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 [KEY].

2. Requirements

A problem statement and requirements for end-to-end VoIP header 
compression are given in [VoIP-HC-RSMTS], where the following 
requirements are identified.  End-to-end VoIP header compression, 
possibly over MPLS, MUST:

a. avoid link-by-link compression/decompression cycles.  Compression 
should be performed end-to-end through the MPLS network, e.g., from CE1 
--> PE1 --> P --> PE2 --> CE2, where CE1 is the compressor and CE2 is 
the decompressor ([E2E-VoMPLS], [E2E-cRTP]).
b. provide for efficient voice transport.
c. support various voice encoding (G.729, G.723.1, etc.).
d. use standard compress/decompress algorithms (e.g., [cRTP], [SIMPLE]).
e. operate in RFC2547 VPN context [MPLS-VPN].
f. operate in MPLS [MPLS-ARCH] networks using either [LDP] or [RSVP] 
signaling.
g. be scalable to very large number of CE --> CE flows.
   - use standard protocols to aggregate RSVP-TE signaling (e.g., 
[RSVP-AGG]}.
   - minimize setups of tunnels & call sessions
h. use standard protocols to signal context identification and control 
information (e.g., [RSVP], [RSVP-TE]).
i. use standard protocols to prioritize packets (e.g., [DIFFSERV, 
DIFF-MPLS]).
j. use standard protocols to allocate LSP bandwidth (e.g., [MPLS-DS-TE]).
k. use standard protocols to make [cRTP] more tolerant of packet loss 
(e.g., [cRTP-ENHANCE]).
l. add minimal delay to the VoIP media flows.

3. Protocol Extensions

3.1 Call Flows

In the discussion here we assume an example VoIP flow set up from CE1 
--> PE1 --> P --> PE2 --> CE2, and in the reverse direction.  Each 
router functions as an LSR and supports RSVP signaling of LSPs.  A 
summary of the VoIP call setup is as follows:

1. CE1 sends an RSVP PATH message to CE2, which includes a SCID_Request 
object with a 2-byte VoIP-Call-ID and (for the SHC case) the 
Simple_Header_Compression object with the header compression template.
2. CE2 assigns a unique 2-byte SCID to the call and sends an RSVP RESV 
message to CE1 which includes a Header_Compression_Reply object with the 
VoIP-Call-ID and the assigned SCID.
3. CE1 sets the SCID in compressed packets and (for the cRTP case) 
FULL_HEADER packets.
4. Compressed packets and header compression control packets 
(FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP, 
set up by RSVP, from non-compressed packets; FULL-HEADER packets are 
routed on the same CE1 --> CE2 LSP as the CE1 to CE2 compressed packets 
for the VoIP call; CONTEXT-STATE packets are routed on the same CE2 --> 
CE1 LSP as the CE2 to CE1 compressed packets for the VoIP call.
5. compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets 
are routed with MPLS labels.
6. CE2 (decompressor) uses the incoming MPLS label and the SCID to 
locate the proper decompression context.
7. if needed to resync, CE2 sends a CONTEXT_STATE packet to CE1 with 
SCID set; CE1 resends FULL_HEADER packet with SCID set to CE2, etc.
8. CE2 frees up the SCID when the VoIP call disconnects (as indicated by 
SIP BYE message and RSVP/PATH-TEAR messages), or by refreshing the PATH 
state.

In [E2E-cRTP] we discuss the scenario for end-to-end header compression 
in which compressed VoIP flows use MPLS between PE1 and PE2, but use 
normal cRTP procedures between CE1-PE1 and PE2-CE2.  Again, the 
compression is done at CE1 and decompression at CE2, however 'SCID 
switching' is done at PE1 and PE2 in order to route compressed packets.  
SCID switching involves the formation of an 'SCID routing table' to 
determine the next-hop for compressed packets given the SCID.  
[E2E-cRTP] also contains proposals for cRTP enhancements and associated 
procedures.

3.1.1 cRTP Header Compression

The goal of cRTP header compression is to reduce the IP/UDP/RTP headers 
to two bytes for most packets in the case where no UDP checksums are 
being sent, or four bytes with checksums.  (Note that the UDP checksum 
is required for [cRTP-ENHANCE], and the compressed headers would be four 
bytes.) In cRTP header compression, the first factor-of-two reduction in 
header size comes from the observation that half of the bytes in the 
IP/UDP/RTP headers remain constant over the life of the connection. 
After sending the uncompressed header template once, these fields may be 
removed from the compressed headers that follow. The remaining 
compression comes from the observation that although several fields 
change in every packet, the difference from packet to packet is often 
constant and therefore the second-order difference is zero.

By maintaining both the uncompressed header and the first-order 
differences in the session state shared between the compressor and 
decompressor, all that must be communicated is an indication that the 
second-order difference was zero. In that case, the decompressor can 
reconstruct the original header without any loss of information simply 
by adding the first-order differences to the saved uncompressed header 
as each compressed packet is received. The compressed packet carries the 
SCID, to indicate in which session context that packet should be 
interpreted.  Since compressed packets are assumed to be routed on a 
separate LSP, set up by RSVP, the decompressor uses the incoming MPLS 
label and the SCID to locate the proper decompression context.

The encodings in cRTP use a different link layer packet type field for 
each of 9 cRTP packet types.  Since it is necessary to identify packet 
types for cRTP packets over MPLS (e.g., FH packets and compressed 
packets), it is proposed in [E2E-cRTP] to add a 4-bit packet type field 
in the cRTP header to encode the 9 different packet types.

3.1.2 'Simple' Header Compression

In order to avoid the need for resynchronization and to minimize 
processing, the proposed technique relies on transmitting all first 
order differences in packets.  Any byte which varies in any bit will be 
explicitly transmitted as part of the compressed header.

The compressor communicates the uncompressed header template via an RSVP 
PATH message.  Also included in the message are a set of operands for 
reconstructing the header from the transmitted compressed header and the 
stored header template.

The compressor removes the header from the packet, where the term 
'header' refers to the first n bytes of the packet where n is the length 
of the header template.  The compressor uses the operands to extract the 
variable fields from the header.  These are concatenated together as a 
compressed header.  The SCID is then prepended to the compressed header 
and the packet is sent.

Since compressed packets are assumed to be routed on a separate LSP, set 
up by RSVP, the decompressor uses the incoming MPLS label and the SCID 
to locate the proper decompression context.  The decompressor then uses 
the header template to reconstruct the original header.  It uses the 
operands to populate the variable fields of the header with the contents 
of the compressed header.

3.2 Header Compression Object Formats

3.2.1 SCID_Request Object

The Class for Header Compression Objects is of the form 10bbbbbb (need 
an official number from IANA).  The form 10bbbbbb allows intermediate 
nodes which do not understand header compression to silently drop the 
compression object.  This ensures that an LSP either exists between the 
source and the destination or that header compression is disabled.

      Class 3D Header Compression Object, Type 3D 1

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Num VoIP-Calls |                VoIP-Call-IDs                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           VoIP-Call-IDs Continued             |       PAD     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


3.2.2 Header_Compression_Reply Object

The presence of this object in a RESV message indicates that the 
receiver will act as a decompressor for packets sent on this LSP which 
contain one of the listed SCIDs.  Over the life of an RSVP session SCIDs 
may be added and deleted simply by refreshing the PATH state with the 
updated set of objects  This object provides synchronization between the 
sender and receiver as to which SCIDs may be used.

   Class 3D Header Compression Object, Type 3D 2

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Num SCIDs   |                   SCIDs                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              SCIDs Continued                  |       PAD     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         VoIP-Call-IDs                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           VoIP-Call-IDs Continued             |       PAD     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.3 Simple_Header_Compression Object

The header template and the set of operands is encoded in a    
SIMPLE_HEADER_COMPRESSION (SHC) object.  The compressor sends one or 
more SHC objects via an RSVP PATH message.  To allow multiplexing across 
an LSP, the SHC objects are sent along with SCID_Request object, and a 
corresponding number of two-byte SCIDs are assigned by the decompressor 
in the Header_Compression_Reply object. 

The template consists of the first n bytes of a packet.  All of the 
fixed fields are set to their appropriate values.  The variable fields 
SHOULD be set to zero.  Fields are always delimited on byte boundaries.  
Each operand is simply an offset and a length.  They serve to delimit 
the variable fields within the template.

Several additional operations are signaled via flags.  They concern the 
updating of TTL, the IP checksum, and the IP length field.  The 'T' flag 
allows the IP TTL to be updated using the MPLS TTL.  The 'L' flag 
indicates that the IP length field should be inferred from the received 
packet length.  The 'C' flag indicates that the checksum should be 
recomputed from the reconstructed header.

      Class 3D Header Compression Object, Type 3D 3

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Header Length         |   Compressed Header Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         RESVD           |T|L|C|      Number of Operands       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                      Header Operands                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                      Header Template                         //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Header Length

         The length of the header template in bytes

      Compressed Header Length

         The length of the compressed header in bytes

      SCID

         Session context ID (can optionally be set to 2 bytes)

      Flags

          T  Propagate MPLS TTL

             Indicates that the MPLS TTL field should be used to fill in
             the TTL field of the IPv4 header

          L  Reconstruct IP Length Field

             Indicates that the IP length field should be inferred from
             the received packet size.

          C  Reconstruct IP Header Checksum

             Indicates that the IP Header Checksum should be recomputed

      Number of Operands

         The number of operands which follow this field

      Header Operands

         A variable number of operands.  Each operand occupies 2  bytes.
         The operand format is shown below.

      Header Template

         The template for  reconstruction  of  the  header.   All  fixed
         fields  MUST  be  filled out with their respective values.  All
         variable fields SHOULD be set to zero.  The template is  padded
         with zeros to the next four byte boundary.
  
Each header operand consists of an offset and a length in bytes.  The 
format is as follows.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Offset    |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Header Offset

         The displacement from the  beginning  of  the  header  template
         where replacement begins.

      Replacement Length

         The number of compressed header bytes to  be  copied  into  the
         header template.

3.3 Control Plane Procedures

There are two logically separate functions in the control plane, call 
control and bearer control. 

Call control establishes, modifies, and releases telephone calls (e.g., 
using SIP).  In distributed VoIP architectures, call agents control 
media gateways (e.g., using Megaco/H.248) to obtain the IP address of 
the terminating GW and determine what processing functions the media GW 
must apply to the media stream (e.g., codec choice, echo cancellation, 
etc.).

Bearer control establishes, modifies, and releases the logical 
bearer-path connection between gateways (e.g., using RSVP), allowing a 
bandwidth reservation to be established before called party alerting, 
and giving the originating GW the capability to reject a call if quality 
would be unacceptable.  RSVP also needs to establish and control the 
VoMPLS header compression context, as described in the previous Section. 
 RSVP bearer control and SIP call control need to be coordinated in 
setting up a call.

The MPLS control-plane uses RSVP to a) establish LSPs and label bindings 
between each GW-GW pair, b) to establish and control VoMPLS header 
compression, and c) to provide resource reservation and bandwidth 
allocation for the varying number of calls on a GW-GW pair.  VoMPLS 
header compression control and resource reservation procedures are now 
further described.

3.3.1 VoMPLS Procedures

The following procedures apply only to unicast sessions (extension to 
multicast is for further study) and discuss processing at the source, 
intermediate and destination nodes.

VoMPLS header compression is always initiated by the originator of the 
PATH message, which we refer to as the source.  Note that the initiator 
of the RSVP session may or may not be the ultimate source of the 
compressed flow.  For instance a Cable Modem Termination System (CMTS) 
in a packet cable environment might serve as the compressor for a VoIP 
flow across an MPLS backbone.

The source requests SCID assignments from the decompressor and for 
'simple' header compression creates an SHC object.  The decompressor 
assigns the SCIDs.

For cRTP header compression, the compressor and decompressor follow the 
procedures in [cRTP], including the sending of FULL-HEADER packets, 
compressed packets, CONTEXT_STATE packets, etc. 

Compressed packets and header compression control packets (FULL_HEADER 
and CONTEXT_STATE packets) are routed on a separate LSP, set up by RSVP, 
from non-compressed packets.  FULL-HEADER packets are routed on the same 
CE1 --> CE2 LSP as the CE1 to CE2 compressed packets for the VoIP call.  
CONTEXT-STATE packets are routed on the same CE2 --> CE1 LSP as the CE2 
to CE1 compressed packets for the VoIP call.

For simple header compression, the TTL field is handled in one of two 
ways depending on the choice of the setting of the propagate MPLS TTL 
bit and the value sent in the header template.  If the bit is set, the 
TTL field is to be updated based upon the MPLS TTL.  If the bit is not 
set then the TTL is set to the lower of the TTL of the PATH message and 
the value contained in the header template.

The SCID-Request Object and SHC Object are included in an RSVP PATH 
message.  These objects MUST not be included if a LABEL_REQUEST object 
is not also included in the PATH message.

Multiple SHC Objects may be included in a PATH Message.  The set of 
objects may be updated over the life of the session.  If multiple SHC 
Objects are included then each SHC Object MUST correspond to a unique 
VoIP-Call-ID and SCID.

Intermediate nodes must act to ensure that an LSP exists from source to 
destination.  Thus if an intermediate node forwards a PATH message 
without a label request, the node MUST drop the HC Object from the PATH 
message.  The HC object class is set to a value which indicates to nodes 
in the PATH which do not understand the object that they are to silently 
drop the object.  This has the effect of allowing the RSVP session while 
disabling header compression.  This ensures that a HC unaware node will 
not inadvertently allow a discontinuity in the LSP.

If the destination node receives a PATH message with HC objects and is 
willing to act as a decompressor for this session and these 
VoIP-Call-IDs, it includes the SCIDs in a HC_REPLY object in the 
corresponding RESV message.  For simple header compression, if the 
propagate TTL bit is not set, the decompressor compares the TTL of the 
PATH message with the TTL of the header template and updates the 
template with the lower value.

3.3.2 Resource Reservation Procedures

There are several options for scaling the resource reservation and 
bandwidth allocation function.  One approach uses aggregated bandwidth 
allocation for each class type and priority level (e.g., high-priority 
voice and best-effort data) [MPLS-DS-TE].  When a high priority LSP has 
sufficient capacity for a new call, no additional bandwidth allocation 
may be necessary.  However, when additional bandwidth is required, then 
a bandwidth increment is added to the LSP, or similarly, bandwidth 
decremented.  RSVP could be used to determine whether sufficient 
resources were available at the network edges, including bandwidth on 
the access links, wherein VoIP gateways measure available resources 
locally.

As illustrated in Figure 1, each voice call requires two reservations, 
because the reservation and admission control mechanisms provided by 
RSVP are unidirectional.

     Originating Gateway/                         Terminating Gateway/   
              
     Ingress LSR                                  Egress LSR
                                                                   
          |                                            |                 
          |----------------(1) INVITE----------------->|                 
          |                                            |                 
          |<--------(2) 183_SESSION_PROGRESS ----------|                 
          |                                            |                 
          |<---------------(3) PATH -------------------|                 
          |                                            |                 
          |----------------(4) PATH ------------------>|                 
          |                                            |                 
          |<---------------(5) RESV -------------------|                 
          |                                            |                 
          |----------------(6) RESV ------------------>|                 
          |                                            |                 
          |----------(7) RESV_CONFIRMATION------------>|                 
          |                                            |                 
          |<------------(8) 180_RINGING----------------|                 
          |                                            |                 
          |<--------------(9) 200_OK-------------------|                 
          |                                            |                 
          |----------------(10) BYE------------------->|                 
          |                                            |                 
          |-------------(11) PATH_TEAR---------------->|                 
          |                                            |                 
          |<------------(12) RESV_TEAR-----------------|                 
          |                                            |                 
          |<------------(13) PATH_TEAR-----------------|                 
          |                                            |                 
          |-------------(14) RESV_TEAR---------------->|               

              Figure 1 - Call Setup with RSVP & SIP

To set up the call, for example using SIP [SIP, SIP-CALL] and RSVP, the 
originating GW sends a SIP INVITE message to the destination GW.  The 
destination GW responds to the INVITE message with a SIP 
183_SESSION_PROGRESS message, and also sends a RSVP PATH message along 
the reverse path back to the originating GW. The originating GW also 
sends a RSVP PATH message to the destination GW along the path that the 
voice packets will take.  The PATH messages include the HC objects for 
VoMPLS context identification and control, as described in Section 3.2.  
The destination GW holds the call setup process in abeyance waiting for 
the reservation results for both directions of proposed VoIP packet 
flow.  Upon receipt of the PATH messages, each GW sends a RESV message 
along the path in the reverse direction, with the HC objects described 
in Section 3.2.  Each RSVP-activated router along the path makes a 
decision whether there is enough bandwidth to admit the call.

When the originating GW receives a positive RESV message, it knows that 
there is enough capacity along the path to the destination GW, and it 
sends an RSVP RESV_CONFIRMATION message to the destination GW. When the 
destination GW receives a positive RESV message, it knows that there is 
enough capacity along the path to the originating GW.  When the 
destination GW has determined that there is enough capacity in both 
directions, it lets call setup continue and sends a SIP 180_RINGING 
message to the originating GW and then a 200_OK message after the call 
is answered.  If this process determines that there is insufficient 
capacity, the call is blocked.

The GW initiates a normal disconnect by sending a SIP BYE message.  The 
gateways tear down their reservations by sending RSVP PATH_TEAR and 
RESV_TEAR messages.  If a GW fails or a link failure leads to unilateral 
disconnection, the reservation will time out when the routers fail to 
receive reservation refresh messages.

3.4 Data Plane Procedures                          

The source node compresses the header by removing the header and forming 
the compressed header, which is prepended to the remainder of the 
packet.  The SCID and the MPLS header are then prepended and the packet 
is sent.  Note that the compressor MUST not use a SCID until it has 
received a RESV message which contains a HC_REPLY with the SCID listed.

The destination node removes the MPLS header and the compressed header.  
The node prepends the header template to the packet and then uses the 
operands to populate the variable fields of the header with the values 
sent in the compressed header.

For cRTP header compression, the compressor and decompressor follow the 
procedures in [cRTP], including the sending of FULL-HEADER packets, 
compressed packets, CONTEXT_STATE packets, etc.

For simple header compression, if the 'T' flag is set, the received MPLS 
TTL is copied into the IP TTL field in the decompressed header. The 
decompressed TTL is considered to be the incoming 
(yet-to-be-decremented) TTL.  If the 'L' flag is set the packet length 
is recomputed based on the received packet length.  If the 'C' bit is 
set the IP checksum is generated afresh.

4. Security Considerations

These procedures do not change the trust model of [RSVP] and [RSVP-TE].  
As such no additional security risks are posed.

5. Acknowledgements

George Swallow and Lou Berger are the originators of the concepts 
repeated here for the 'simple' header compression approach.

6. References

[cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for 
Low-Speed Serial Links", RFC 2508, February 1999.

[cRTP-ENHANCE] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on 
Links with High Delay, Packet Loss, and Reordering," work in progress.

[DIFF-MPLS] Le Faucheur, F., et. al., "MPLS Support of Diff-Serv", RFC 
3270, May 2002.

[DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated 
Services", RFC 2475, December 1998.

[E2E-cRTP] Ash, G., Goode, B., Hand, J., "End-to-End VoIP Header 
Compression Using cRTP", work in progress.

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

[LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January 
2001.

[LDP-PWE3] Rosen, E., "LDP-based Signaling for L2VPNs", work in 
progress.

[MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching 
Architecture," RFC 3031, January 2001.

[MPLS-DS-TE] Le Faucheur, F., et. al., "Requirements for support of 
Diff-Serv-aware MPLS Traffic Engineering," work in progress.

[MPLS-ENCAP] Rosen, E., Tappan, D., et al, "MPLS Label Stack Encoding", 
RFC 3032, January 2001.

[MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 
1999.

[MPLSF-HC] MPLS Forum Technical Committee, "Voice over MPLS - 
BearerTransport Implementation Agreement,"  March 2001.

[RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 
Version 1, Functional Specification", RFC 2205, September 1997.

[RSVP-AGG] Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6 
Reservations", RFC 3175, September 2001.

[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 
Tunnels", RFC 3209, December 2001.

[SIP} Rosenberg, J., et. al., "SIP: Session Initiation Protocol," RFC 
3261, June 2002.

[SIP-CALL] Camarillo, G., et. al., "Integration of Resource Management 
and SIP," work in progress.

[TCRTP] Thompson, B., et. al., "Tunneling Multiplexed Compressed RTP 
("TCRTP")", work in progress.

[VoIP-HC-RSMTS] Ash, G., Goode, B., Hand, J., "Requirements for 
End-to-End VoIP Header Compression", work in progress.

7. Authors' Addresses

Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-4578
Email: gash@att.com

Bur Goode
AT&T
Phone: + 1 203-341-8705
E-mail: bgoode@att.com

Jim Hand
AT&T
Room MT A2-4F36
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-6179
E-mail: jameshand@att.com

George Swallow
Cisco Systems, Inc.
250 Apollo Drive Chelmsford, MA 01824
Phone: +1 978 497 8143
Email: swallow@cisco.com

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