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
Jim Hand
AT&T
Bur Goode
AT&T

2. Outline (draft-ash-e2e-vompls-hdr-compress-00
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 for End-to-End VoMPLS Header Compression
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 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 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

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

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

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

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
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
used in many RFC 2547 VPNs
scalable
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