Subject: E2E VoIP over MPLS ('VoMPLS') Header Compression

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 12 Feb 2003 16:05:50 -0500

All,

I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS header compression.  This work was earlier accepted for consideration by the MPLS WG (see the background summary below).

Two I-D's related to this work are at:
http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt (George is added as co-author in the next rev)

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.

The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings notes at http://ietf.org/proceedings/02nov/index.html).  It was generally agreed that the work did not fit well in PWE3, and that MPLS might be the best overall fit. 

I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly review the above proposals and issues, and get a sense of the room.

Comments welcome

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 MPLS WG, so a charter extension is needed.  George said he 'would have no objection to the work being done in MPLS'... but suggested that the 'work fits more closely in the Transport Area/PWE3 WG' (which is why it was brought there first).

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Feb 2003 17:16:49 -0500

In message <[email-masked]>
, "Ash, Gerald R (Jerry), ALABS" writes:
> All,
> 
> I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS he
> ader compression.  This work was earlier accepted for consideration by the MP
> LS WG (see the background summary below).
> 
> http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt 
> (George is added as co-author in the next rev)
> 
> The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings no
> tes at http://ietf.org/proceedings/02nov/index.html).  It was generally agree
> d that the work did not fit well in PWE3, and that MPLS might be the best ove
> rall fit. 
> 
> I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly re
> view the above proposals and issues, and get a sense of the room.
> 
> Comments welcome
> 
> Thanks,
> Jerry Ash

Jerry,

A fix more appropriately belongs in the VoIP implementations that are
putting 30 byte payloads into a lot of tiny packets for a continuous
stream of relatively low bandwidth traffic rather than buffer a tiny
amount of the stream and produce more reasonable payload sizes.

A mere 5-10 milliseconds of buffering is imperceptible, would allow
very large payloads, and would make the framing overhead quite
negligible rather than just reduce it somewhat.  Putting an
application protocol directly over MPLS to solve an overhead problem
that results from an oversight in specific implementations of that
applications protocol is very poor engineering.

The problem is certainly not inherent to RTP, UDP, or IP.  The choice
of payload formats (media encodings) may be at fault but more likely
the implementation itself.  Note the following in rfc1890 (page 7):

   All frame-oriented audio codecs should be able to encode and decode
   several consecutive frames within a single packet. Since the frame
   size for the frame-oriented codecs is given, there is no need to use
   a separate designation for the same encoding, but with different
   number of frames per packet.

If VoIP equipment follows the advice in rfc1890, one of the base RFCs
for RTP, then there won't be an overhead problem.  If you are having
problems with specific equipment you should forward the above
paragraph to the suppier and ask for a bug fix.  If this is just a
hypothetical problem, then all the better - problem solved.

Curtis

ps - There is a big difference between one WG asking an author to take
their work to another WG and that other WG accepting a WG item.  The
PWE3 WG cannot accept a WG item for the MPLS WG and I'm sure that was
not their intent.

> 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 VoI
> P.  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 comp
> ression can significantly reduce the VoIP overhead through various compressio
> n mechanisms.  This is important on access links where bandwidth is scarce, a
> nd 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.  I
> n particular, George Swallow and Lou Berger proposed a 'simple' end-to-end co
> mpression scheme in which all first-order differences in the RTP/UDP/IP heade
> rs were transmitted, and in which the header compression context was establis
> hed through RSVP signaling.  The work was accepted into the MPLS WG pending a
> n 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 dete
> rmine 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 MPLS WG, so a charter extension is needed.  George said he 'w
> ould have no objection to the work being done in MPLS'... but suggested that 
> the 'work fits more closely in the Transport Area/PWE3 WG' (which is why it w
> as brought there first).
> 
> 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 routi
> ng tables' to allow routing based on the session context ID (SCID).  These ex
> tensions need coordination with other WGs (MPLS, CCAMP, AVT, ROHC, PPVPN, etc
> .).
> 
> 3. Resynchronization -- E2E VoMPLS using cRTP header compression might not pe
> rform well with frequent resynchronizations.  The applicability and performan
> ce 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 la
> rge 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 si
> gnaling mechanism.
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 13 Feb 2003 00:14:43 +0100

Jerry,

(with the wg chair hat on)

your proposal is received. I've not made up my mind on this yet. However 
I've one question
and one suggestion for the time being.

Question:
   Are there any requirements doc on this - there is  a small section in 
the documents sent
   out, but it is hardly enough to take a decission.

Suggestion:
   It is my take that for the time being what should be discussed on the 
list is
   whether we want to take this up as a working group task, and whether 
we should
   ask ADs and IESG to extend our charter to cover this.
   This is to say that we don't want to take the discussion on the 
solution before
   (or even in parallel) with the discussion if we want to do it or not.

/Loa