End-to-End VoMPLS Header Compression
1 / 16

Jerry Ash AT&T [email protected] - PowerPoint PPT Presentation

  • Uploaded on

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 [email protected] Jim Hand AT&T [email protected] Bur Goode AT&T [email protected]

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Jerry Ash AT&T [email protected]' - dyllis

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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


[email protected]

Jim Hand


[email protected]

Bur Goode


[email protected]

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

Motivation requirements for end to end vompls header compression
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

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

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’)

Issue 1 pwe3 wg charter extension
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

Issue 2 protocol extensions for crtp rsvp te rfc2547 vpns
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.)

Issue 3 resynchronization performance applicability of crtp simple mechanisms
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)

Issue 4 scalability of e2e vompls applied ce ce
Issue 4 - Scalability of E2E VoMPLS cRTP/’simple' MechanismsApplied 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

Issue 5 ldp application as underlying lsp signaling mechanism
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

Issue 4 5 ldp vs rsvp te for mpls lsps
Issue 4/5 - LDP vs. RSVP-TE for MPLS LSPs Mechanism

  • 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

Next steps
Next Steps Mechanism

  • propose Charter extension to PWE3 to include VoMPLS

  • propose I-D’s be accepted as PWE3 WG documents

Backup slides
Backup Slides Mechanism

Voip vompls control plane
VoIP/VoMPLS Control Plane Mechanism

  • 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

Voip vompls control plane1
VoIP/VoMPLS Control Plane Mechanism

  • 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