190 likes | 314 Views
How can QoS be guaranteed/managed in a multi-provider IP environment. Michael Smirnov GMD FOKUS COST 263. COST 263: "Quality of Internet Services". IETF: > 100 short-lived WGs in 5 areas COST: WGs within a long-lived Action. IETF: lacks inter-group coordination
E N D
How can QoS be guaranteed/managed in a multi-provider IP environment Michael Smirnov GMD FOKUS COST 263
COST 263: "Quality of Internet Services" IETF: > 100 short-lived WGs in 5 areas COST: WGs within a long-lived Action IETF: lacks inter-group coordination COST: committed to co-ordination IETF: hard to join with new work items COST: easy to join with new work items
QoS Engineering for the Internet Liaisons QoS Enhancements for the Internet protocol stack QoS in Multicast QoS in NG protocols QoS in Applications Charging for Premium IP Services COST 263 MoU: R&D
About Guarantee ... • Assurance - n, confidence ..., • belief and trust ..., • promise ... • Guarantee - n, promise or undertaking ... that certain conditions • agreed to in a transaction will be fulfilled • A.S.Hornby, Ed., Oxford Dictionary, 1986
What are the promises? • Business usage: Virtual Enterprise? • Real-time communication over the Internet? • IETF promises: IntServ, DiffServ, MPLS, ... • How in the multi-provider environment? • What’s coming next?
NSF Internet: each hop is a provider Commercial Internet: Peering ISP Certification Roaming Shared trouble ticketing Charging and accounting collaboration Multi-provider issues
Add BW on demand Add BW on demand No congestion here No congestion here Peering Point Peering Rules Network Access Point
Connection oriented vs Connectionlessfrom the QoS assurance viewpoint The only QoS guaranteed communication so far was always connection-oriented: - always only one hop; - QoS set-up at root. QoS assurance in a connectionless world has to repeat the QoS set-up step at each hop: IntServ ~ characterisation point DiffServ ~ PHBs mapping
ISP IntServ QoS routing QoS set-up Policy Capacity L3/L2 Classif. Sched. DiffServ The Big Picture ?
End-to-end QoS request Achieved QoS Needed QoS Dst Src IntServ’s Characterisation Point
What is wrong with IntServ and DiffServ? • The IntServ characterisation point is important in a multi-provider environment: • IntServ is not only RSVP • RSVP is complex (or too generic?). • The DiffServ reflects the backbone´s needs only • the end-to-end QoS is questionable.
IntServ + DiffServ ? • DiffServ is simple but has no end-to-end guarantees: need for the top level control; • IntServ guarantees end-to-end but is complex and needs admission controls; • The combination (IIS+DS) seems to be OK, however it needs QoS routingsupport, and qosr has no progress
VAIP GW QoS Interworking More than 1 provider Best Effort Internet VAIP GW VAIP IP/FEC Tunnel (Shortcut) VAIP QOSR
switch Dst IP, TOS, ... 1 800 345... codepoint behaviour Service DBase router codepoints behaviours Routing DBase TOS DBase IN and Internet
MG MG MG R R R Sw Sw MC MC SCP SCP SG IN and Internet Interworking Sw SCP SG
What is coming next: Active Networks? • The AN paradigm: networks programmable by applications: • are networks ready for this? (see e.g. IPv6 transition plan for an example); • The needed advances in SW development are missing (component software), however ... • attempts are numerous (...)
What is coming next: Shortcuts ! • We should go back to a CO world: • ATM is there with the QoS guarantees; • AAL5´s overhead is minimal. • Then the qosr is simply a shortcut management? (we do have solutions for IP and IP multicast over ATM with QoS!) • IETF: ION, ISSLL - no integration,MPLS is a solution?
R R R R MPLS is a solution? MPLS Trunk RSVP signalling
Conclusions • “The Internet has met its enemy and its name is QoS “ (B. Carpenter, J. Crowcroft) • Integrational approach is needed • protocol co-design, • better integration of L3/L2 issues • The issue: who pays, what for and how much?