One document matched: draft-ash-e2e-voip-hdr-comp-rqmts-00.txt

 


Network Working Group                                        Jerry Ash
Internet Draft                                               Bur Goode
<draft-ash-e2e-voip-hdr-comp-rqmts-00.txt>                    Jim Hand
Expiration Date:  August 2003                                     AT&T
  			   			         Raymond Zhang
					  Infonet Services Corporation

                                                        February, 2003


        Requirements for End-to-End VoIP Header Compression

            <draft-ash-e2e-voip-hdr-comp-rqmts-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.  For an MPLS VPN, 
the packet header is at least 48 bytes, while the voice payload is 
typically no more than 30 bytes.  VoIP 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).  This draft gives a 
problem statement and requirements for end-to-end VoIP header 
compression, possibly over MPLS.

Table of Contents

   1. Introduction             
   2. Problem Statement
   3. Requirements
   4. Security Considerations                                            
   5. References  
   6. Authors' Addresses
   7. 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 header 
compression is the possibility of significantly reducing the VoIP 
overhead through various compression mechanisms.  This draft gives a 
problem statement and requirements for end-to-end VoIP header 
compression, possibly over MPLS.

2. Problem Statement

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP/. 
When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS.  
Typically, VoIP will use voice compression mechanisms (e.g., G.729) in 
order to conserve bandwidth.  For an MPLS VPN, the packet header is at 
least 48 bytes, while the compressed voice payload is typically no more 
than 30 bytes.  With VoIP header compression, significantly more 
bandwidth could be saved.  Therefore, end-to-end VoIP header 
compression, possibly over MPLS, is required in order to significantly 
reduce the VoIP overhead through 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).  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.

3. Requirements

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 a 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., [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.

4. Security Considerations

No new requirements.

5. 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-VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS 
Header Compression", work in progress.

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

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

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

[SIMPLE] Swallow, G., Berger, L., "Simple Header Compression", work in 
progress.

6. 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_zhang@infonet.com

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