Skip this Video
Download Presentation
Jerry Ash AT&T [email protected]

Loading in 2 Seconds...

play fullscreen
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 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
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
    • 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
  • 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
  • propose Charter extension to PWE3 to include VoMPLS
  • propose I-D’s be accepted as PWE3 WG documents
voip vompls control plane
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
voip vompls control plane1
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