Internet DRAFT - draft-ash-avt-ecrtp-over-mpls-reqs

draft-ash-avt-ecrtp-over-mpls-reqs





Network Working Group                                        Jerry Ash
Internet Draft                                               Bur Goode
<draft-ash-avt-ecrtp-over-mpls-reqs-01.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-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 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). We 
consider using MPLS to route ECRTP compressed packets over an MPLS LSP 
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 
that use header compression at each router.

Table of Contents

   1. Introduction             
   2. Problem Statement
   3. Goals & Requirements
   4. Example Scenario
   5. Security Considerations
   6. IANA Considerations                                          
   7. References
   8. Intellectual Property Statement
   9. Authors' Addresses
   10. Full Copyright Statement                                     

Specification of Requirements

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 [RFC 2119].

1. Introduction

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP.  
When MPLS labels [MPLS-ARCH] 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 an MPLS LSP (label switched path) 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 
on an MPLS 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 low-speed 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 
low-speed 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 bandwidth 
consumption on low-speed links. So although bandwidth is getting 
cheaper, the value of compression does not go away.  It should be 
further noted that IPv6 will increase the size of headers, and therefore
increase the importance of header compression for VoIP flows.

While hop-by-hop header compression could be applied to decrease 
bandwidth requirements, that implies a processing requirement for 
compression-decompression cycles at every router hop, which 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, while the need may exceed 
300-500 for a high-end case. Therefore, ECRTP over MPLS seems to be a 
viable alternative to get the compression benefits without introducing 
costly processing demands on the intermediate nodes.   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.

Therefore the proposal is to use existing header compression techniques, 
such as those described in [ECRTP], 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.

3. Goals & Requirements

The goals of ECRTP over MPLS are as follows:

a. provide more efficient voice transport over MPLS networks,
b. increase the scalability of VoIP header compression to a large number 
of flows, and
c. not significantly increase packet delay, delay variation, or loss 
probability.

Therefore the requirements for ECRTP over MPLS are that it must:

a. Use existing protocols such as ECRTP and/or ROHC 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.
b. Allow ECRTP over an MPLS LSP, and thereby avoid hop-by-hop 
compression/decompression cycles [e.g., VoMPLS].
c. Minimize incremental performance degradation due to increased delay, 
packet loss, and jitter.
d. Use standard protocols to signal context identification and control 
information (e.g., [RSVP], [RSVP-TE], [LDP]).

[ECRTP] should be used to make ECRTP over MPLS more tolerant of packet 
loss, to guard against frequent resynchronizations, and to minimize the 
need for error recovery.  [ROHC] can also be considered, however [ROHC] 
does not accommodate packet reordering to protect against 
out-of-sequence packets, which can occur on MPLS LSPs.

Protocol extensions may be required for [ECRTP] in that a packet type 
field is needed to identify FULL_HEADER, CONTEXT_STATE, and compressed 
packets.  For example, [cRTP-ENCAP] specifies a separate link-layer 
packet type defined for header compression.  Using a separate link-layer 
packet type for every packet type used in header compression avoids the 
need to add extra bits to the compression header to identify the packet 
type.  However, this practice does not extend well to MPLS encapsulation 
conventions [MPLS-ENCAP], in which a separate link-layer packet type 
translates into a separate LSP for each packet type.  In order to extend 
ECRTP to ECRTP over MPLS, each packet type defined in [ECRTP] would need 
to be identified in an appended packet type field in the ECRTP header. 

Extensions to MPLS signaling are needed to signal the session context 
IDs (SCIDs) between the ingress and egress routers on the MPLS LSP.  For 
example, new objects need to be defined for [RSVP-TE] to signal the 
SCIDs between the ingress and egress routers, and [ECRTP] used to 
determine the FULL_HEADER packets for the context identification; these 
FULL HEADER packets then contain the SCID identified by using the 
RSVP-TE objects.  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 would 
be needed to signal SCIDs between ingress and egress routers on ECRTP 
over MPLS LSPs.  For example, 'targeted LDP sessions' might be 
established for signaling SCIDs, or perhaps methods described in 
[LDP-PWE3] and [GVPLS] to signal pseudo-wires and multipoint-to-point 
LSPs might be extended to support signaling of SCIDs for ECRTP over MPLS 
LSPs. 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 over an MPLS LSP with 
multiple routers in the path 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 
ECRTP over MPLS 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 low-speed 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

[Note: HC 3D header compression; HD 3D header decompression]

Figure 2. Example Scenario for Application of ECRTP over MPLS

5. Security Considerations

The high processing load of header compression makes header compression 
a target for denial-of-service attacks.  For example, an attacker could 
send a high bandwidth data stream through a network, with the headers in 
the data stream marked appropriately to cause header compression to be 
applied.  This would use large amounts of processing resources on the 
routers performing compression and decompression, and these processing 
resources might then be unavailable for other important functions on the 
router. This threat is not a new threat for cRTP/ECRTP header 
compression, but is addressed and mitigated by ECRTP over MPLS.  That 
is, by reducing the need for performing compression and decompression 
cycles, as proposed in this draft, the risk of this type of 
denial-of-service attack is reduced.

6. IANA Considerations

No IANA actions are required.

7. References

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

[cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., "IP Header Compression 
over PPP", RFC 2509, February 1999.

[ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links 
with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.

[GVPLS] Radoaca, V., et. al., "GVPLS/LPE - Generalized VPLS Solution 
based on LPE Framework," 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] Martini, L., et. al., "Pseudowire Setup and Maintenance using 
LDP", work in progress.

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

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

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

[ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)," RFC 
3091, July 2001.

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

[VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS Header 
Compression", work in progress.

8. Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights.  Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in RFC 2028.  Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
 
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard.  Please address the information to the IETF Executive
Director.

9. 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
E-mail: hand17@earthlink.net

Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: raymond_zhangr@info.net

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