1 / 16

Jerry Ash AT&T gash@att

End-to-End VoMPLS Header Compression (draft-ash-e2e-vompls-hdr-compress-00.txt) End-to-End VoIP Header Compression Using cRTP (draft-ash-e2e-crtp-hdr-compress-00.txt). Jerry Ash AT&T gash@att.com. Jim Hand AT&T jameshand@att.com. Bur Goode AT&T bgoode@att.com.

sai
Download Presentation

Jerry Ash AT&T gash@att

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. End-to-End VoMPLS Header Compression(draft-ash-e2e-vompls-hdr-compress-00.txt)End-to-End VoIP Header Compression Using cRTP (draft-ash-e2e-crtp-hdr-compress-00.txt) Jerry Ash AT&T gash@att.com Jim Hand AT&T jameshand@att.com Bur Goode AT&T bgoode@att.com

  2. Outline(draft-ash-e2e-vompls-hdr-compress-00.txt)(draft-ash-e2e-crtp-hdr-compress-00.txt)Outline(draft-ash-e2e-vompls-hdr-compress-00.txt)(draft-ash-e2e-crtp-hdr-compress-00.txt) • motivation/requirements for VoIP over MPLS (VoMPLS) • brief review of proposals • ‘you read the drafts’ • issues • PWE3 WG charter extension • protocol extensions for cRTP, RSVP-TE, RFC2547 VPNs • resynchronization, performance, & applicability of cRTP/'simple' mechanisms • scalability of E2E VoMPLS applied CE-CE • LDP application as the underlying LSP signaling mechanism

  3. Motivation/Requirements forEnd-to-End VoMPLS Header Compression • motivation • carriers evolving to converged MPLS/IP backbone with VoIP services • enterprise VPN services with VoIP • legacy voice migration to VoIP • requirements • need mechanism for end-to-end VoIP over MPLS CE --> CE header compression • e.g., from CE1 --> PE1 --> P --> PE2 --> CE2 • prior work in MPLS WG by Swallow/Berger on ‘simple’ mechanism (I-D expired) • for efficient voice transport • support encapsulation of voice/RTP/UDP/IP/MPLS • header (uncompressed) = typically 40-48 bytes • voice = typically < 30 bytes • ~60% overhead, 10s of gigabits-per-second for headers alone • support voice encoding (G.729, G.723.1, etc.) • compress/decompress header using cRTP (RFC 2508) and/or ‘simple’ algorithm • ~90% header compression with cRTP • ~50% header compression with ‘simple’ • operate in RFC2547 VPN context • scalable to very large number of CE --> CE flows

  4. Brief Review of ProposalsEnd-to-End VoMPLS Header Compression(draft-ash-e2e-vompls-hdr-compress-00.txt) • steps • use RSVP to establish LSPs between CE1-CE2 • use cRTP (or simple HC) to compress header at CE1, decompress at CE2 • CE1 requests SCIDs from CE2 • CE1 appends CE2 label to compressed header • header compression context routed from CE1 --> PE1 --> P --> PE2 --> CE2 • route compressed packets with MPLS labels CE1 --> CE2 • packet decompressed at CE2 using cRTP (or simple HC) algorithm • advantages • minimizes PE requirements (has to route HC context) • disadvantages • CE’s need to run RSVP, possible scalability issue

  5. Brief Review of ProposalsEnd-to-End VoIP Header Compression Using cRTP (draft-ash-e2e-crtp-hdr-compress-00.txt) • steps • use RSVP to establish LSPs between PE1-PE2 • use cRTP to compress header at CE1, decompress at CE2 • CE1 requests SCIDs from CE2 • header compression context routed from CE1 --> PE1 --> P --> PE2 --> CE2 • PE1 & PE2 create ‘SCID routing tables’ & perform ‘SCID switching’ for compressed packets (SCID --> MPLS labels’) • route compressed packets with MPLS labels PE1 --> PE2 • packet decompressed at CE2 using cRTP algorithm • advantages • minimizes CE requirements (has to route HC context) • disadvantages • additional PE requirements (need to create ‘SCID routing tables’)

  6. Issue 1 - PWE3 WG Charter Extension • VoMPLS header compression not within current charter of the PWE3 WG (or any WG) • why PWE3? • seems the best fit • header compression historically a transport item (PWE3 in transport area) • header compression more a function of application than "base MPLS technology” • current charter mentions work on header compression with RTP: “Specify methods with RTP(and possibly using header compression where needed) to ensure in-order final PDU delivery, perform clock recovery inband emulation and maintenance functions across the PSN, where required.” • what extension needed? • PWE3 not chartered to do work related to signaling PE-PE tunnel (PW signaling/maintenance in scope) • proposals in I-Ds require extensions to RSVP-TE to create tunnels • charter extension needed

  7. Issue 2 - Protocol Extensionsfor cRTP, RSVP-TE, RFC2547 VPNs • extensions proposed to [cRTP] and [cRTP-ENHANCE] • new packet type field to identify FULL_HEADER, CONTEXT_STATE, etc. packets • new objects defined for [RSVP-TE] • extensions proposed to RFC2547 VPNs • create 'SCID routing tables' to allow routing based on the session context ID (SCID) • extensions need coordination with other WGs (MPLS, CCAMP, AVT, ROHC, PPVPN, etc.)

  8. Issue 3 - Resynchronization, Performance, & Applicability of cRTP/’simple' Mechanisms • E2E VoMPLS using cRTP header compression might not perform well with frequent resynchronizations • applicability & performance need to be addressed • 'simple' header compression avoids need for resynchronization • cRTP header compression achieves greater efficiency than ‘simple’ (90% vs. 50% header compression)

  9. Issue 4 - Scalability of E2E VoMPLSApplied CE-CE • E2E VoMPLS applied CE-CE would require a large number of LSPs to be created • concern for CE/PE/P ability to do necessary processing & architecture scalability • processing & label binding at every MPLS node on path between each GW-GW pair • processing every time resource reservation is modified (e.g., to adjust to varying number of calls on a GW-GW pair) • core router load from thousands of LSPs, setup commands, refresh messages

  10. Issue 5 - LDP Application as Underlying LSP Signaling Mechanism • desirable to signal VoMPLS tunnels with LDP • many RFC2547 VPN implementations use LDP as underlying LSP signaling mechanism • may require substantial extensions to LDP • 2 I-D's propose ways for LDP to signal 'VC' (outer) labels for PWs • http://ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt • http://www.ietf.org/internet-drafts/draft-rosen-ppvpn-l2-signaling-02.txt • Rosen's I-D suggests ways to do auto-discovery • this together with LDP capability to distribute inner labels might support CE-CE VoMPLS LSPs (within the context of RFC 2547) • other LDP issues • no bandwidth associated with LSPs. • QoS mechanisms limited

  11. Issue 4/5 - LDP vs. RSVP-TE for MPLS LSPs • no solution perfect • LDP • lack of TE, no bandwidth associated with LSPs • QoS mechanisms limited • perhaps too many bytes for an ATM packet • RSVP-TE • lack of scalability • however • LDP • used in many RFC 2547 VPNs • scalable • RSVP-TE • TE allows bandwidth assignment to LSPs • QoS mechanisms

  12. Next Steps • propose Charter extension to PWE3 to include VoMPLS • propose I-D’s be accepted as PWE3 WG documents

  13. Backup Slides

  14. VoIP/VoMPLS Control Plane • call control • establishes, modifies, and releases telephone calls • e.g., SIP or H.323 • in distributed VoIP architecture, Call Agents control gateways using MGCP or MEGACO/H.248 • arranges for media gateway to obtain address of terminating GW • determines, through negotiation if necessary, what processing functions the media GW must apply to the media stream • e.g., codec choice, echo cancellation, etc. • connection/bearer control • establishes, modifies, & releases logical connections between gateways • provide fairness in sharing of LSPs • TE provides low-delay, low jitter routes for VoIP • QoS guarantees for existing connections should be unaffected by new voice calls • new calls should be rejected at network edge if insufficient resources are available • network should be resilient to mass calling events

  15. VoIP/VoMPLS Control Plane • interaction between call/connection control needed • BW reservation must occur before called party alerting • new sessions routed to use network efficiently • architecture to accommodate multimedia as well as VoIP

  16. Call Setup with RSVP

More Related