EndtoEnd VoMPLS Header Compression draftashe2evomplshdrcompress00'txt EndtoEnd VoIP Header Compressi

1
End-to-End VoMPLS Header Compression(draft-ash-e2
e-vompls-hdr-compress-00.txt)End-to-End VoIP
Header Compression Using cRTP (draft-ash-e2e-crtp
-hdr-compress-00.txt)
Jerry Ash ATT gash_at_att.com
Jim Hand ATT jameshand_at_att.com
Bur Goode ATT bgoode_at_att.com
2
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
  --gt CE header compression
• e.g., from CE1 --gt PE1 --gt P --gt PE2 --gt 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 lt 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 --gt CE flows

4
Brief Review of ProposalsEnd-to-End VoMPLS
Header Compression(draft-ash-e2e-vompls-hdr-compr
ess-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 --gt
  PE1 --gt P --gt PE2 --gt CE2
• route compressed packets with MPLS labels CE1 --gt
  CE2
• packet decompressed at CE2 using cRTP (or simple
  HC) algorithm
• advantages
• minimizes PE requirements (has to route HC
  context)
• disadvantages
• CEs need to run RSVP, possible scalability issue

5
Brief Review of ProposalsEnd-to-End VoIP Header
Compression Using cRTP (draft-ash-e2e-crtp-hdr-com
press-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 --gt
  PE1 --gt P --gt PE2 --gt CE2
• PE1 PE2 create SCID routing tables perform
  SCID switching for compressed packets (SCID --gt
  MPLS labels)
• route compressed packets with MPLS labels PE1 --gt
  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-co
  ntrol-protocol-01.txt
• http//www.ietf.org/internet-drafts/draft-rosen-pp
  vpn-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-Ds 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