One document matched: draft-ash-e2e-vompls-hdr-compress-01.txt
Differences from draft-ash-e2e-vompls-hdr-compress-00.txt
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.
| PAFTECH AB 2003-2026 | 2026-04-24 05:55:10 |