The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <28F05913385EAC43AF019413F674A01704A1770F@OCCLUST04EVS1.ugd.att.com>
, "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).
> 
> 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 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.
>