Subject: RE: IETF 55 PWE3 Agenda -- E2E VoMPLS Header Compression

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Wed, 6 Nov 2002 12:29:26 -0500

All,

In regard to this agenda item:

> 1430-1440 Header Compression Drafts
>   Jerry Ash <[email-masked]>
> http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt 
> http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt

Please review the documents and raise any issues/comments to the list and/or during the meeting.  

Below is a brief background and synopsis of issues (so far) I plan to discuss.

Thanks,
Jerry Ash

Background:

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 over MPLS ('VoMPLS') 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).
  
VoIP over MPLS header compression methods have been proposed earlier (March, 2000) in the MPLS working group, however the relevant drafts have expired.  In particular, 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.  The work was accepted into the MPLS WG pending an addition to the MPLS WG charter.

In the I-D's we propose 3 approaches to VoMPLS header compression: a) re-use the methods in cRTP to determine the context and MPLS to route packets, b) re-use the methods in Swallow's and Berger's 'simple' approach to determine the context and MPLS to route packets, and c) re-use the methods in cRTP to determine the context and the SCID (session context ID) to route packets.

Issues to discuss:

1. WG charter -- The VoMPLS header compression work is not within the current charter of the PWE3 WG (or MPLS WG), so a charter extension is needed.  In a discussion with the WG chairs, it was pointed out that a) header compression has historically been a transport item (PWE3 is in the transport area), and b) header compression is more a function of the application than of the "base MPLS technology".  So PWE3 seems the best fit.  However, PWE3 is not chartered to do work related to signaling the PE-PE tunnel underlying the PSN (although PW signaling/maintenance are in scope).  The proposals in the I-Ds require extensions to RSVP-TE to create the tunnels, so VoMPLS is not in the PWE3 charter as it stands.

2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed to [cRTP] and [cRTP-ENHANCE], 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 (MPLS, CCAMP, AVT, ROHC, PPVPN, etc.).

3. Resynchronization -- E2E VoMPLS using cRTP header compression might not perform well with frequent resynchronizations.  The applicability and performance need to be addressed (the 'simple' header compression approach would avoid the need for resynchronization, but achieves less efficiency than cRTP).

4. Scalability -- E2E VoMPLS 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 VoMPLS tunnels with LDP, since many RFC2547 VPN implementations use LDP as the underlying LSP signaling mechanism.  It appears, however, that this would require substantial extensions to LDP.

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 7 Nov 2002 18:03:35 +0200

As you stated "voice" (as in VoIP or VoMPLS) 
is not in the PWE3 charter, and I don't think it should be. 

TDM is in the charter, and VoMPLS 
(as defined in the ITU and the MPLS forum) 
has a "trunking mode" which COULD be considered
a method of TDM transport.

I emphasized the word COULD since the present drafts
do not cover issues that would make this a true TDM transport method,
e.g. timing and transparent signaling.

In TDM transport methods (and in "trunking" VoMPLS)
since multiple voice sessions are transfered,
the overhead percentage is much less,
and the compression needed less.

Also, if headers are taking up too much room,
I would suggest not using the RTP header, rather than
adding needless overhead and then inventing methods
to compress it. 

Y)J(S

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Sat, 16 Nov 2002 19:28:19 -0500

Yaakov,

Please see my responses below.

Thanks,
Jerry

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 11:04 AM
> To: Ash, Gerald R (Jerry), ALASO; [email-masked]
> Cc: George Swallow; GOODE, B (Bur), ALBAS; Hand, James C, ALBAS
> Subject: RE: [PWE3] IETF 55 PWE3 Agenda -- E2E VoMPLS Header 
> Compression
> 

'VoIP over MPLS header compression' has to be in the charter for the work to progress.
 
> a method of TDM transport.

The ITU and MPLS Forum approaches appear to be equivalent (MPLSF spec being proposed in ITU).  We're not pursuing this approach, only approaches compatible with RTP/UDP/IP.
 
> and the compression needed less.

These methods appear to be incompatible with RTP/UDP/IP.  Is there a way to mux multiple streams of voice flows with RTP/UDP/IP header compression, to further reduce the overhead?

> adding needless overhead and then inventing methods

As above, we're only pursuing approaches compatible with RTP/UDP/IP.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 20 Nov 2002 15:03:07 +0200

Jerry, 

I first will quote from your email

<snip>
 
<snip>

<snip>

My only question is WHY? .

Why rule out any and all methods to solve a problem
just because they do not use a technology which
has not been shown to have relevance to the problem?

Please note that although the PWE charter explicitly
requires RTP to be used whenever timing has to be carried,
only one draft submitted to the WG actually uses RTP
(although several others say that it is an option).

Until someone shows that RTP solves some problem
related to PWE, I think that you should not base all
your design decisions on it.

Y(J)S

---

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Nov 2002 07:16:51 -0700

Yaakov,
I'd suggest that you realign yourself with the goals 
of this WG -- until you show  that RTP does NOT solve 
some problem related to PWE.  I.e., if you hope to 
progress anything in this WG.
 
-danny

> The ITU and MPLS Forum approaches appear to be equivalent (MPLSF spec > being proposed in ITU).  We're not pursuing this approach, only > approaches compatible with RTP/UDP/IP.
>  
> <snip>
> These methods appear to be incompatible with RTP/UDP/IP.  Is there a way > to mux multiple streams of voice flows with RTP/UDP/IP header > compression, to further reduce the overhead?
> 
> <snip>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 20 Nov 2002 16:53:28 +0200

Danny, 

As far as I understood the goals of this WG
were to provide methods for tunneling various
services over PSNs.

RTP is in the charter as the prefered method
of handling timing.

If use of RTP at all costs, even if it doesn't
solve a problem, is a GOAL of the WG,
I think this should be stated explicitly
in the charter.

Of course, in this case practically none
of the drafts submitted to date would be
acceptable.

Y(J)S

-----Original Message-----
From:	Danny McPherson [mailto:[email-masked]]
Sent:	Wed 11/20/2002 4:16 PM
To:	Yaakov Stein
Cc:	[email-masked]; [email-masked]; [email-masked]
Subject:	Re: [PWE3] IETF 55 PWE3 Agenda -- E2E VoMPLS Header Compression 

Yaakov,
 
-danny

> Jerry,=20
> The ITU and MPLS Forum approaches appear to be equivalent (MPLSF spec =
> being proposed in ITU).  We're not pursuing this approach, only =
> approaches compatible with RTP/UDP/IP.
> =20
> <snip>
> These methods appear to be incompatible with RTP/UDP/IP.  Is there a way =
> to mux multiple streams of voice flows with RTP/UDP/IP header =
> compression, to further reduce the overhead?
> 
> <snip>

---

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Nov 2002 08:05:30 -0700

> I think this should be stated explicitly

I think the current text in the charter suffices:

"PWE3 will use RTP where necessary to perform clock 
recovery and other real-time signaling functions. This 
work will be coordinated with the AVT WG and payloads 
will follow RFC 2736."
 
> of the drafts submitted to date would be

Indeed.

-danny