Subject: [AVT] RE: Agenda for Minneapolis

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 4 Nov 2003 19:39:48 -0600

All,

Here is a brief summary regarding the following agenda item:

> RTP Header Compression over Multi-Hop Paths		(Ash)		30
>	draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
http://ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt

Some service providers (such as AT&T) have plans to migrate large amounts of legacy voice traffic to VoIP, as well as to provide VPN services enabling VoIP.  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.  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).  Providing VoIP header compression over multiple hop paths avoids multiple compression/decompression cycles at each router, and thereby increases the processing scalability of the maximum number of simultaneous VoIP flows which use header compression at each router.  
  
I will summarize the problem statement, goals, example scenarios, requirements, and work items as described in http://ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt.  

I'll also discuss the following issues:

1. Protocol extensions -- Extensions are proposed to [cRTP] and [ECRTP], which involve a new packet type field to identify FULL_HEADER, CONTEXT_STATE, etc. packets.  New objects are defined for [RSVP-TE].  Extensions are also proposed to RFC2547 VPNs, which create 'SCID routing tables' to allow routing based on the session context ID (SCID).  These extensions need coordination with other WGs (e.g., MPLS).

2. Resynchronization -- VoIP header compression over multiple-hop paths using cRTP header compression might not perform well with frequent resynchronizations.  [ECRTP] seems appropriate in this context.  The 'simple' header compression approach would avoid the need for resynchronization, but achieves less efficiency than cRTP.

3. Scalability -- VoIP header compression over multiple-hop paths applied between CE-CE would perhaps require a large number of LSPs to be created.  There is concern for CE ability to do the necessary processing and the scalability of the architecture.

4. LDP application -- It would be desirable to signal the MPLS LSPs with LDP, since many RFC2547 VPN implementations use LDP as the underlying LSP signaling mechanism.

Please review the document and raise any issues/comments to the list.

Thanks,
Jerry Ash

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt