Transcript PPT Version
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] 1 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 2 Motivation/Requirements for End-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 3 Brief Review of Proposals End-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 4 Brief Review of Proposals End-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’) 5 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 6 Issue 2 - Protocol Extensions for 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.) 7 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) 8 Issue 4 - Scalability of E2E VoMPLS Applied 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 9 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-protocol01.txt – http://www.ietf.org/internet-drafts/draft-rosen-ppvpn-l2signaling-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 10 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 11 Next Steps propose Charter extension to PWE3 to include VoMPLS propose I-D’s be accepted as PWE3 WG documents 12 Backup Slides 13 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 14 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 15 Call Setup with RSVP Originating Gateway/ Ingress LSR Terminating Gateway/ Egress LSR | | |----------------(1) INVITE----------------->| | | |<--------(2) 183_SESSION_PROGRESS ----------| | | |<---------------(3) PATH -------------------| | | |----------------(4) PATH ------------------>| | | |<---------------(5) RESV -------------------| | | |----------------(6) RESV ------------------>| | | |----------(7) RESV_CONFIRMATION------------>| | | |<------------(8) 180_RINGING----------------| | | |<--------------(9) 200_OK-------------------| | | |----------------(10) BYE------------------->| | | |-------------(11) PATH_TEAR---------------->| | | |<------------(12) RESV_TEAR-----------------| | | |<------------(13) PATH_TEAR-----------------| | | |-------------(14) RESV_TEAR---------------->| 16