Voice over IP over MPLS BOF (3/30/2000)
CHAIRS: Antti Kankkunen
Gerald R. Ash
SCRIBE: Jason Jeffords
BOF Objectives (Presented by Antti Kankkunen)
Gage interest in VoMPLS
Decide how to proceed with VoMPLS work
Find a home for VoMPLS work:
Bring to existing WGs?
Or form new WG?
Non-goal: Detailed technical discussions
1. BOF Objectives (chair, 5 minutes)
2. Agenda bashing (chair, 5 minutes)
3. Definition of Voice over MPLS (Antti Kankkunen, 5 minutes)
4. Goals of Voice over MPLS (includes non-goals)(Antti Kankkunen, 5 minutes)
5. VoMPLS Framework, draft-kankkunen-vompls-fw-00.txt (Antti Kankkunen, Brian Rosen, Dave Stacey 35 minutes)
6. Simple Header Compression, draft-swallow-mpls-simple-hdr-compress-00.txt, (George Swallow, 10 minutes)
7. MPLS/IP Header Compression, draft-berger-mpls-hdr-comp-00.txt & MPLS/IP Header Compression over PPP, draft-berger-mpls-hdr-comp-over-ppp-00.txt (Lou Berger, 10 minutes)
8. Bearer Control for VoIP and VoMPLS Control Plane, draft-lefaucheur-vompls-bearer-cont-00.txt, (Angela Chiu, 15 minutes)
9. The management of MPLS LSPs for scalable QoS Service Provision, draft-gibson-manage-mpls-qos-01.txt (Mark Gibson, 5 minutes)
10. Open discussion (20 minutes)
11. Agree on Next Steps (5 minutes)
No agenda bashing was done.
Definition of VoMPLS:
Use of MPLS as the efficient transport of VoIP services with predictable QoS/GoS in an IP/MPLS network.
No comments on definition.
What is VoMPLS?
- Voice over MPLS == VoIP
- Existing call/device control protocols (e.g. MEGACO, MGCP, H.323, SIP, Q.1901, ...)
- Existing voice encapsulation (RTP)
- IP over MPLS
- Existing signaling protocols (CR-LDP, RSVP-TE)
- Preference would be having standard mappings of Voice over IP and IP over MPLS
- In practice further work is necessary to combine call control and MPLS transport
- Includes the exact details of mapping voice service requirements to MPLS
Voice over MPLS Framework
- Kankkunen, Integral Access.
- G. Ash, AT&T
- J. Hopkins, Fujitsu
- Rosen, Marconi
- Stacey, Nortel Networks
- Yelundur, NEC
- L. Berger, LabN Consulting
VoMPLS is signaling protocol agnostic.
VoMPLS is short form of voice over IP over MPLS. The framework defines voice service requirements. Not defining new protocols, but will generate requirements.
Dave Oran - What is special about voice, i.e. a comparison was made to ftp over MPLS? In short, why do we need to specify this when we would not specify an interaction like this for ftp or other applications.
This question was deferred until after the following presentations. The hope is that they will answer this question.
VoMPLS Framework (Brian Rosen and Dave Stacy)
Vompls Reference Model (Brian Rosen)
- intelligent end points (SIP-phones, ...)
- decomposed gateways
- call agent
- media gateway
- MGCP/MEGACO between them
- Lots of different gateways
- Trunk gateway
- Access gateway
- Line side gateway
- Signaling gateway
The reference model diagram was presented.
Scott Bradner - Are signaling and data forwarding separate? What goes over IP/MPLS?
Brian Rosen - We are not concerned with the signaling part. It may go over MPLS but it would use normal IP over MPLS encapsulation. We are only interested in the transport.
- Trunk Gateway (TGW)
- MPLS - trunk side PSTN (IMT w/ss7)
- Integrated Access Device (IAD)
- single customer voice and data
- POTS/T1 w/POTs, CAS, ISDN signaling
- Access Gateways (AGWs)
- multiple customer voice (and data)
- POTS/T1/E1/T3/E3 TDM w/POTS, CAS or ISDN
Dave Oran - There are things you can do without a router?
Brian Rosen - Call control can affect which LSPs are used (static, not dynamic).
Scott Bradner - Are these trunks or per call?
Brian Rosen- Either one, but more interested in trunking.
Data Plane Requirements
- Provide a transparent path for VoIP bearers (RTP)
- Provide efficient transport (header compression)
- Provide an efficient method for multiplexed LSPs
- Provide an optional method to specify delay characteristics across the
- network on a specific LSP, specifically, a way to specify the maximum delay and a bound on delay variation for an LSP
- Provide an optional method to specify a "circuit emulation" LSP, which would
- provide a way to implement "private line" service
Brian Rosen - Evolving to a converged network, useful to define delay constraint on LSPs, and bound on delay variation, this avoids echo cancellation everywhere. Also want to do circuit emulation; T1 Private line like service; goes beyond basic MPLS.
Control Plane Requirements
- The VoMPLS control plane is identical to a VoIP control plan with respect to call control (call agent) operation
- The VoMPLS control plane for bearer control must provide the call control function the ability to:
- Create a new LSP for VoMPLS
- Use an existing multiplexed LSP and create a new subchannel
- Specify the QoS to be applied to a new LSP, or change the QoS on an existing LSP
- Specify the bandwidth to be allocated to a new LSP, or change the bandwidth on an existing LSP
Scott Brim - Where would we put the equivalent of SRTS?
Brian Rosen - Don't have an answer yet, have timing which involves SRTS, but no answer yet. The circuit emulation problem has not been solved.
- Trunking between gateways
- multiple streams per LSP = desire for efficient multiplexed trunk
- Circuit Emulation
- optional capability
- allows interconnect of legacy equipment
- Efficiency is important
- MPLS/IP/UDP/RTP is a lot of overhead
- compressing headers on top of an LSP
- link level compression for maximum efficiency on low speed links
- header compression of IP/UDP/RTP is desirable
- several techniques available to do this
Voice Traffic Engineering
- off-line voice traffic engineering
- traffic engineer LSPs for predicted voice traffic
- connection admission and/or connection routing
- possible multiple LSPs between points
- call admission control with bandwidth awareness of LSPs at edge of network
- dynamic traffic management
- buffer and queuing with possible delay control
- jitter buffering
- VoMPLS does not differ from other forms of Voice over data networks in its dynamic TM capabilities other than the fundamental properties MPLS provides
Voice Traffic Engineering - can you use the same techniques?
Yes and No. Off-line pre-establish, or in connection control, create new LSPs on the fly, around hotspots etc.
Why is circuit emulation in scope?
It really isn't, this is a big step. It was included to support converged networks.
Dave Oran - We have a header compression scheme, why do we need a new scheme?
Lou Berger - CRTP does not work over MPLS.
Getting into George's draft.
Jim Luciani - What doesn't EF plus MPLS get you there (last bullet)?
Brian Rosen - timing
Requirements for call control protocols and MPLS Signaling (Dave Stacy)
- Potential service types for VoMPLS include:
- MPLS core network - PSTN equivalent service
- MPLS within the core and access network - PSTN equivalent service
- Circuit emulation/leased line service
- Low cost economy service
- Service types will drive explicit quantitative (voice) requirements
- Objective is to map the service requirements onto LSP usage requirements
Voice Service Requirements
- Quality of Service Factors:
- voice encoding, transcoding, echo control, delay jitter, packet loss, and timing accuracy
- Grade of service
- Call blocking, mass call events, overload conditions
- Quality factors affecting session management
- misrouted sessions, dropped sessions, failure to maintain billing records, clipping, theft of service, etc.
Example deployment scenarios
- Annex provides some example reference connections
- Global reference connections considered
- multiple MPLS islands interworking with the PSTN
- Three key scenarios are considered
- core MPLS networks
- extending MPLS to access
- investigation of voice coding schemes
Work items identified in the draft
- Service requirements
- definition of service types
- definition of service requirements (delay, jitter, etc)
- Definition of framework for operation of VoMPLS
- Single MPLS domain
- Multiple MPLS domains
- Interworking with PSTN/ATM network domains
Work items identified in the draft (continued)
- definition of LSP usage
- requirements to achieve voice service requirements
- predictable resource usage and GoS
- call, bearer and device control protocol requirements
- MEGACO, MGCP and SDP
- LDP, CR-LDP, RSVP-TE
- Specification of encapsulation mechanisms
There seems to be two different beliefs about VoIP,
- build service on diffserv is adequate (benefits of ATM)
- must go to cbr
Why isn't it the former, isn't diffserv adequate?
Antti Kankkunen - engineering the MPLS network is the problem to be solved
This work hopes to determine requirements, it may be that diffserv is adequate.
Specify concrete requirements, and then the methods. MPLS may be one method.
Simple header compression (George Swallow)
MPLS voice tie lines
RSVP aggregation ties VoIP admission control to MPSL Traffic Engineering
- guaranteed bandwidth/loss characteristics
- TE/QOS routing
- protection switching
An MPLS tie line
An example diagram was presented.
- In VoIP, headers account for a significant portion of the overhead
- Trade-off, less compression for better processing efficiency
- Also could be done from access point to access point
- MPLS label serves as the context id
- All first order changes are sent
- Flags for
- MPLS TTL
- infer length from received MTU
- re-compute checksum
- allows multiplexing across an LSP (e.g. traffic engineered tunnel
- path message communicates the header template and decompression options
- RESV message acks sub
MPLS/IP Header Compression (Lou Berger)
Being worked on in MPLS working group
- enable header compression for MPLS encapsulated traffic
- optimize for maximum compression
- end-to-end (LSP ingress-to-egress) compression not a requirement
- targeted at "lower speed" links
- definition of "lower speed" is hardware specific
What has the MPLS working group taken on?
Header compression using MPLS.
Added to the charter of the MPLS working group.
It is MPLS related header compression. Adapting existing schemes to work with MPLS.
- different options considered to meet objectives
- key consideration
- are MPLS headers compressed
- With header compression over MPLS
- With compression of MPLS/IP headers
- Link-by-link is optimized for transport efficiency
Comparison of compression approaches
- Simple - 50% efficient
- Link-by-Link - 90% efficient
Dave Oran - There is one thing missing from this slide, the CPU costs.
Lou Berger - There is serious computation in link-by-link.
Bearer control for VoIP and VoMPLS control plane (Angela Chiu)
- Reference model
- Bearer control for VoIP
- Bearer control for VoMPLS
- Focuses on:
- intra-domain bearer control (inter-domain is more complex)
- environments that require guaranteed QoS and abilities to perform call admission control
- refinements to the VoMPLS Framework and Reference model
VoIP/VoMPLS Reference Model
- Propose model: current model in VoMPLS Framework + the separation:
- VoMPLS MG = (VoIP) MG + MIWF (Media Inter-Working Function)
- VoMPLS SG = (VoIP) SG + SIWF (Signal Inter--Working Function)
- MG & SG: PSTN to IP inter-working
- MIWF & SIWF: IP to MPLS inter-working
- Advantage: allow a VoMPLS endpoint to coexist and inter-operate with
- existing VoIP endpoints
- existing native IP transport networks
MIWF and SIWF
- implement functionality of an MPLS edge node
- perform inter-working between VoIP QoS Bearer Control and MPLS based QoS services
- SIWF: implement functionality of an MPLS edge node
Bearer Control for VoIP
- Bearer Control (BC): establish, modify, and release the logical connection between GWs
- With VoIP, default connectivity is permanently available, but may not always be appropriate
- IP QoS Bearer Control: resource reservation and QoS establishment in environments where service providers want to guarantee adequate quality voice calls
Requirements on call control protocol
- for the call control protocol, it's
- necessary to include provisions for specifying the codec type, packetization period, parameters to determine traffic parameters in QoS reservation => included in existing call control protocols
- useful to advertise and negotiate requirements for IP QoS Bearer Control
- Ongoing work in IETF: I-D "Integration of Resource Management and SIP for IP Telephony"
Signaling for IP QoS BC establishment
- Architecture: separate QoS from application level signaling--call control protocol
- Using a network level protocol designed for network resource reservation and QoS signaling => RSVP
Scaling IP QoS BC with RSVP
- Multiple options to scale per-call RSVP signaling:
- Simplest: carry the per-call RSVP messages through an IP core transparently => rely on pre-provisioned resource in the core
- Option 2: use Int-Serv over Diff-Serv
- scalability advantage in the user plane with aggregate Diff-Serv classification/scheduling
- Option 3: scale further in the control plane using RSVP reservation aggregation
Dynamically Resize Aggregate Rsv
- initial capacity established pair-wise between backbone routers
- bandwidth can be increased (or decreased) as tie lines fill (or under-utilized)
- resizing can be done based on local policy and algorithm
- new calls rejected only if tie line capacity can not be increased
Coordination with Call Control
- Goal: having the ability to reject a call due to a failure in network level admission control
- o Require coordination with call control
- Ongoing efforts:
- o I-D "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms"
- I-D "Integration of Resource Management and SIP for IP Telephony"
- ITU-T, SG16/Q13, "Enhancement for Synchronizing RSVP with Slow Start
Bearer Control for VoMPLS
- connectivity: user RSVP or CR-LDP and benefit from
- constraint based routing
- fast reroute
- QoS and resource reservation: identical to the solutions for VoIP
- With Diff-Serv in the core, use "MPLS Support for Diff-Serv" for interworking
- With RSVP as the bearer control protocol
- Without aggregation: map RSVP reservation to an LSP
- With RSVP aggregation: map multiple RSVP reservations to a shared LSP => scalable core
VoMPLS Bearer Control for Compression/Multiplexing
- Both RSVP and CR-LDP may be used to signal the corresponding information
- RSVP: I-D "Simple Header Compression"
- Take into account the compression gains locally on some hops
- I-D "Integrated Services in the Presence of Compressible Flows"
- Recommendation: define the corresponding compression identifiers for the compression scheme(s) that may be defined for VoMPLS
An MPLS tie line
A diagram was presented.
Recommendations for progress of the VoMPLS framework
- Reference model be modified to cover VoIP as well as VoMPLS to clarify that
- Interworking situations involving any mix of MPLS and non-MPLS transport are within the scope of the framework
- Many exising items of work in the IETF for VoIP are applicable to VoMPLS
- recognize and adopt the following existing IETF work on bearer control for VoIP:
- solutions for advertisement and negotiation of Traffic Parameters and
- QoS Bearer Control requirement in Call Control protocols;
- solutions for QoS Bearer Control signaling;
- solutions for coordination between call control and QoS Bearer Control.
- Recognize the proposed approach for achieving aggregated MPLS processing In the core.
This draft extends the document to describe how the framework works with non-MPLS end devices.
Dave Oran - Do VoIP vs. VoMPLS, lets go home it's all done.
?? - You are a carrier, why do you care about the mix of MPLS and non-MPLS on the same network?
Who is "we" here? Build an MPLS...Don't stretch too far.
Bruce Thompson - The important part is to place the gateway, call out the fact that this is VoIP over MPLS. The GW is both VoIP and VoIPoMPLS.
Dave Oran - Now he is confused. Are modifications to H.323, etc. in or out of the reference model? Would modifications to MEGACO, SIP, etc. be in or out of scope?
Brian Carpenter - Angela cleared things up. I had written in my trip report I don't know what this BOF is about". I can take that out now, i.e. use RSVP as the layer violation protocol. What is the need for IP in this thing?
Brian Rosen - The proposal was to create GWs on MPLS networks... Header compression is being done by some other working group, etc., this could be done by other groups.
The Management of MPLS LSPs for Scalable QoS Service Provision (Mark Gibson)
Managing QoS for MPLS Networks
- MPLS used to provide carrier class IP networks
- GoS, QoS, security
- nested ER-LSPs provide sessions and trunks
- overlay network is used to determine path
- based on QoS metrics
A diagram was presented.
- Enables dynamic route selection
- Provides a mechanism for guaranteed QoS
- Enables TE
- edge rejection and admission control
- potential for dynamic reconfiguration
- small level of session state
- MPLS operation unaltered
Description of working group (Antti Kankkunen)
The Voice over IP over MPLS (vompls) working group will define a framework for the operation of voice over MPLS and identify requirements for possible extensions to existing protocols to support this application. The working group will serve as a forum for discussing Voice over IP over MPLS technology integration issues.
- VOMPLS Framework, Informational RFC.
- Mapping voice service type definitions and packet transport performance requirements to MPLS, Informational RFC.
- VoMPLS call and device control protocol requirements, Informational RFC.
- VoMPLS QoS/GoS Parameter Usage/Requirements, BCP RFC.
- Other items as identified based on the framework document.
Antti Kankkunen - Back to the original question. If you were to do ftp over network using MPLS, would you need additional RFCs. How would you get a guaranteed 64 kbit/s ftp session with minimal loss, delay, and jitter?
Scott Bradner - We have heard a lot of stuff, varying views of what's needed. Compression being addressed elsewhere, some overlap. Different views on whether there is a full set of technology. Inclination is there is a need for another rev on the framework. Quite persuaded by use of RSVP to do aggregate tunnels. Heard in diffserv about virtual line like behavior. There is a need for another spin of the requirements doc. Not persuaded new work is needed. Who has other view?
Matt Holdrege - We are a long way from handling 100m phone calls over IP. There are a lot of discrete protocols and tools in the IETF. This is not discrete or concrete enough given the current framework. There is a need for focus. What are the exact issues?
On diffserv. They are trying to provide a BA for real time QoS.
There is a need to provide timing.
Why is circuit emulation in VoMPLS?
Antti Kankkunen - It came out of trying to provide all voice services over MPLS.
Are all pieces really covered in other wgs? Putting all the requirements together can provide some value.
Scott Bradner - Any other comments? Tendency to agree with last comment. Use the mailing list to bring this out. Develop the framework and requirements. If there are topics that need discussion, can have a BOF at the next IETF; maybe a working group; if missing pieces; but at this point don't seejustification for firing up a working group now.
Marty Borden - I am bothered by the creeping scope for this document. This is not only VoMPLS, it includes circuit emulation.
Scott Bradner - Leave it out. Put it in a separate doc.
Dave Oran - Is it ok for this document to talk about modifying application protocols (e.g. SIP, H.323, etc.) to talk to the MPLS layer?
Brian Rosen - Lets get the group consensus. Should call control be aware of the transport/MPLS layer?
This is a layer violation..
Serious concern.. The IETFs role is not to design a multi-purpose circuit emulation net, it is to define a packet forwarding net.
George Swallow - There is no MPLS control plane, only OSPF, BGP, etc. Control planes. Must talk about each one of the mappings. Mapping to RSVP is already done, don't know the status of CR-LDP mapping.
Brian Carpenter? - On the concern for layer violations. Layer violations are bad for many reasons. Higher layer protocols should not be modified. Applications layer not going to be modified (trying to make the layers do something they should not do).
A good internet should support voice.
Jim Luciani - re. Purpose of the framework document. Modify the doc to use the tools we have to solve the problem. If a tool is missing, then work on that problem. Is willing to work on the document.
Lou Berger - This was the intent of the document.
Scott Bradner - Agrees with Brian, keep level of abstraction in application layer (it should not know what technology it is running over). Any signaling should be asking for QoS, not specific implementations of QoS. This is too constraining for growth.
Sense of the room.
Continue to work on framework document. Only invent new tools when needed. Specify use of existing tools. Have another BOF.
Many humms for, no humms against.
Description of Working Group
MPLS/IP Header Compression
Bearer Control for VoIP and VoMPLS Control Plane
Managing QoS for MPLS Networks
VoMPLS Reference Model