The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] E2E VoIP over MPLS ('VoMPLS') Header Compression
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.
|
|