One document matched: draft-ash-avt-ecrtp-over-mpls-reqs-00.txt
Network Working Group Jerry Ash
Internet Draft Bur Goode
<draft-ash-avt-ecrtp-over-mpls-reqs-00.txt> Jim Hand
Expiration Date: July 2004 AT&T
Raymond Zhang
Infonet Services Corporation
January, 2004
Requirements for ECRTP over MPLS
<draft-ash-avt-ecrtp-over-mpls-reqs-00.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 typically uses the encapsulation voice/RTP/UDP/IP. When MPLS
labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an
MPLS VPN, the packet header is at least 48 bytes, while the voice
payload is often no more than 30 bytes, for example. VoIP header
compression can significantly reduce the VoIP overhead through various
compression mechanisms, such as enhanced compressed RTP (ECRTP). 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). We consider using MPLS to route ECRTP
compressed packets over multiple router hops without
compression/decompression cycles at each router. Such an ECRTP over
MPLS capability can increase the bandwidth efficiency as well as
processing scalability of the maximum number of simultaneous VoIP flows
which use header compression at each router. This draft gives a problem
statement, goals, requirements, and an example scenario for ECRTP over
MPLS.
Table of Contents
1. Introduction
2. Problem Statement
3. Goals & Requirements
4. Example Scenario
5. Security Considerations
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-labels.
For an MPLS VPN (e.g., [MPLS-VPN], the packet header is at least 48
bytes, while the voice payload is often no more than 30 bytes, for
example. The interest in VoIP header compression is to exploit the
possibility of significantly reducing the VoIP overhead through various
compression mechanisms, such as with enhanced compressed RTP [ECRTP],
and also to increase scalability of VoIP header compression. We consider
using MPLS to route ECRTP compressed packets over multiple router hops
without compression/decompression cycles at each router. Such an ECRTP
over MPLS capability can increase bandwidth efficiency as well as the
processing scalability of the maximum number of simultaneous VoIP flows
which use header compression at each router.
To implement ECRTP over MPLS, the ingress router/gateway would have to
apply the ECRTP algorithm to the IP packet, the compressed packet routed
over multiple hops on an MPLS label switched path (LSP) using MPLS
labels, and the compressed header would be decompressed at the egress
router/gateway where the ECRTP session terminates. Figure 1 illustrates
an ECRTP over MPLS session established on an LSP that crosses several
routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress
router where header compression (HC) is performed, and R4/HD is the
egress router where header decompression (HD) is done. ECRTP
compression of the RTP/UDP/IP header is performed at R1/HC, and the
compressed packets are routed using MPLS labels from R1/HC to R2, to R3,
and finally to R4/HD, without further decompression/recompression
cycles. The RTP/UDP/IP header is decompressed at R4/HD and can be
forwarded to other routers, as needed.
_____
| |
|R1/HC| ECRTP Header Compression (HC) Performed
|_____|
|
| voice/ECRTP/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| voice/ECRTP/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| voice/ECRTP/MPLS-labels
V
_____
| |
|R4/HD| ECRTP Header Decompression (HD) Performed
|_____|
Figure 1. Example of ECRTP over MPLS over Routers R1 --> R4
In the example scenario, ECRTP header compression therefore takes place
between R1 and R4, and the MPLS path transports voice/ECRTP/MPLS-labels
instead of voice/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet.
The MPLS label stack and link-layer headers are not compressed. A method
is needed to set up a correspondence between the header compression
tables at the ingress and egress routers of the ECRTP over MPLS session.
Therefore additional signaling is needed to map the context for the
compressed packets.
In Section 2 we give a problem statement, in Section 3 we give goals and
requirements, and in Section 4 we give an example scenario.
2. Problem Statement
As described in the introduction, ECRTP over MPLS can significantly
reduce the VoIP header overhead through compression mechanisms. The
need for compression may be important on access links where bandwidth is
more scarce, but it could also be important on backbone facilities,
especially where costs are high (e.g., some global cross-sections).
VoIP typically will use voice compression mechanisms (e.g., G.729) on
access and international routes, 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.
The claim is often made that once fiber is in place, increasing the
bandwidth capacity is inexpensive, nearly 'free'. This may be true in
some cases, however, on some international cross-sections, especially,
facility/transport costs are very high and saving bandwidth on such
backbone links is very worthwhile. Decreasing the backbone bandwidth is
needed in some areas of the world where bandwidth is very expensive. It
is also important in almost all locations to decrease the access
bandwidth. While ECRTP over MPLS clearly helps decrease bandwidth
requirements, it also avoids compression-decompression cycles at every
router hop. So although bandwidth is getting cheaper, the value of
compression does not go away. In addition, IPv6 will increase the size
of headers and therefore increase the importance of header compression
for VoIP flows.
In principle, we could use existing header compression techniques, such
as those described in [ECRTP, 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 ECRTP over
MPLS, and vendors have not implemented such techniques.
[cRTP] header compression is often used on access links to conserve
bandwidth. However, cRTP header compression must be implemented on a
hop-by-hop basis, and does not scale well for large voice traffic loads.
The maximum number of cRTP flows is about 30-50 for a typical customer
premise router, depending upon its uplink speed and processing power.
However, the need, for example, can exceed 300-500 for a high-end case.
By using ECRTP over MPLS, routers merely forward compressed packets
without doing a decompression/recompression cycle, thereby increasing
the maximum number of simultaneous VoIP compressed flows that routers
can handle.
3. Goals & Requirements
The goals of ECRTP over MPLS are as follows:
a. provide more efficient voice transport,
b. increase the scalability of VoIP header compression to a large number
of flows, and
c. not significantly degrade packet delay, delay variation, or loss
probability.
Therefore the requirements for ECRTP over MPLS are that it:
a. MUST allow ECRTP over MPLS, and thereby avoid hop-by-hop
compression/decompression cycles [e.g., VoMPLS].
b. SHOULD use [ECRTP] to compress RTP/UDP/IP headers, in order to
provide for efficient voice transport, tolerance to packet loss, and
resistance to loss of session context.
c. MUST minimize incremental performance degradation due to increased
delay, packet loss, and jitter.
d. SHOULD allow use of standard protocols to signal context
identification and control information (e.g., [RSVP], [RSVP-TE], [LDP]).
Protocol extensions may be required for [ECRTP] in that a packet type
field is needed to identify FULL_HEADER, CONTEXT_STATE, and compressed
packets. New objects need to be defined for [RSVP-TE]. It is also
desirable to signal ECRTP over MPLS tunnels with the label distribution
protocol [LDP], since many RFC2547 VPN [MPLS-VPN] implementations use
LDP as the underlying LSP signaling mechanism, and LDP is very scalable.
However, extensions to LDP may be needed to signal ECRTP over MPLS.
These protocol extensions need coordination with other working groups
(e.g., MPLS).
Resynchronization and performance of ECRTP over MPLS needs to be
considered. cRTP performs best with very low packet error rates on all
hops of the path. Tunneling a cRTP session through multiple hops will
increase the round trip delay and the chance of packet loss, and 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. [ECRTP] minimizes feedback
based error recovery using CONTEXT_STATE packets to make cRTP more
tolerant of packet loss, and minimize the need to use the cRTP error
recovery mechanism. [ECRTP] should be used to make cRTP more tolerant of
packet loss and to guard against frequent resynchronizations.
Scalability of ECRTP over MPLS needs to be considered. This may require
that LSPs be established with RSVP-TE between many router pairs, raising
possible scalability issues. RSVP-TE has advantages in that it allows
VoIP bandwidth assignment on LSPs and has QoS mechanisms. LDP is more
scalable, but lacks QoS mechanisms.
4. Example Scenario
As illustrated in Figure 2, many VoIP flows are originated from customer
sites such as R1, R2, and R3 to several large customer call centers
served by R4, which include R5, R6, and R7. It is essential that the
R4-R5, R4-R6, and R4-R7 access links all use header compression to allow
a maximum number of simultaneous VoIP flows. To allow processing at R4
to handle the volume of simultaneous VoIP flows, it is desired to use
ECRTP over MPLS for these flows. With ECRTP over MPLS, R4 does not need
to do header compression/decompression for the flows to the call
centers, enabling more scalability of the number of simultaneous VoIP
flows with header compression at R4.
voice/ECRTP/MPLS-labels ______ voice/ECRTP/MPLS-labels
R1/HC---------------------->| |-----------------------> R5/HD
| |
voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels
R2/HC---------------------->| R4 |-----------------------> R6/HD
| |
voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels
R3/HC---------------------->|______|-----------------------> R7/HD
Figure 2. Example Scenario for Application of ECRTP over MPLS
5. Security Considerations
No new requirements.
6. References
[cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS Header
Compression", work in progress.
[ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links
with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.
[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.
[MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
1999.
[RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205, September 1997.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
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
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: raymond_zhangr@info.net
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 06:05:09 |