QoS control by means of COPS to Support SIP-based applications

1. QoS control by means of COPS to SupportSIP-based applications S. Salsano, L. Veltri IEEE Networks, March/April 2002 R93944010賈　立 R93922011黃文彬 R93922053陳育成 R93922095陳奕安

2. Contents • Introduction • The COPS role for Dynamic DiffServ resource allocation • Definition of the COPS Interfaces • IP Telephony : A COPS Based QoS model • Implementation Testbed • conclusion

3. What is QoS • What is quality of service? • What does it take for the Internet to support QoS? • Existing Internet QoS architectures: • Integrated services, differentiated services, and MPLS overview.

4. What is QoS • User point of view: • Assurance of end-to-end service. • E.g. Guaranteed delay (VoIP), Guaranteed bandwidth (VPN) • Relaxed definition: • Service differentiation: different packets is treated differently. • end-to-end service guarantees may be achieved by provisioning. • e.g. only a small portion of high priority packets. • Existing IP networks only support best effort service. Adding service differentiation is non-trivial.

5. What is QoS(Cont.) • Applications that need QoS • VoIP: bounded delay • VPN: bounded bandwidth • Video conferencing: bounded delay and bounded loss rate • Common QoS parameters: • delay/delay variation (jitter) • Bandwidth • error rate

6. What is QoS(Cont.) • Per flow QoS guarantees and aggregate QoS guarantees • Statistical QoS guarantees .vs. deterministic QoS guarantees

7. What is needed to support QoS • Between the network and its clients: Traffic contract. Traffic specification/desired QoS/supported QoS • At network edge: • Signaling and admission control • Packet classification/marking • Traffic shaping • Packet classification/marking and traffic shaping is also called traffic conditioning. • Traffic policing

8. What is needed to support QoS • What is needed to support QoS: • At routers: • classification and scheduling: FCFS won't work, need more advanced packet scheduling scheme (Fair Queuing) • Routing algorithm need to improve: find a path that satisfies QoS constraints (QoS/policy/constraint based routing). • Buffer management. • Traffic monitoring: find problems as early as possible • Traffic reshaping (at merge and fork points)

9. QoS in the Internet: Do we really need it? • Alternative: buy excessive bandwidth • Everything is simple in the Internet without QoS, everything seems to be much harder in the Internet with QoS support. • What is the main problem? • Complexity and scalability of QoS mechanisms • Which is cheaper: higher network speed or network with QoS support. • Where is the balance? • A guess: Some form of QoS support will be there, per flow QoS guarantee may or may not ever be deployed.

10. Intergrated Services (IntServ) • Trying to match the user demand by providing per flow QoS guarantees. • Signaling protocol: RSVP • IntServ is a reservation based approach • Main problem: • Router complexity (scalability)

11. Differentiated Services (Diffserv) • Define per-hop behavior instead of end-to-end service model • Support a small number of forwarding classes at each router. • Forwarding class is encoded in the packet header. • Problems with DiffServ: • end-to-end service guaranteed is hard to maintain.

12. Multi-Protocol Label Switching (MPLS): • Originally designed for IP over ATM • A short (fixed length) label is encoded for the packet header for packet forwarding • Allow Label switched path (LSP) to be setup (explicit routing). • allow datagram and virtual circuit to be coexisted in an IP network. • MPLS can be combined with IntServ and DiffServ to support QoS.

13. Comparison of IntServ and DiffServ

14. COPS • Definition • Common Open Policy Service protocol • IETF RAP working group • To support policy control in an IP QoS environment • Policy servers v.s. policy clients

15. The COPS Role for Dynamic DiffServ Resource Allocation • COPS protocol • A simple query • Response protocol that allows policy servers (PDPs, Policy Decision Point ) to communicate policy decisions to network devices (PEPs, Policy Enforcement Point ) • To support multiple types of policy clients • Uses to TCP to provide reliable exchange of messages • Provides the means • To establish and maintain a dialogue between the client and the server • To identify the requests

16. The COPS Role for Dynamic DiffServ Resource Allocation(2) • Two main model Outsourcing model Provisioning model Events Bandwidth broker(policy decision point) Query (2) Notifications Bandwidth broker(policy decision point) Trigger Events (1) Response (3) Configuration commands Edge router(policy enforcement point) Edge router(policy enforcement point) Trigger events, notifications, and configuration commands are asynchronous Trigger events generate queries and responses Outsourcing and provisioning models in COPS

17. The COPS Role for Dynamic DiffServ Resource Allocation(3) • The dynamic scenario for DiffServ QoS • An admission control framework • To use server to control the admission of traffic within a DiffServ domain  Bandwidth Broker • The use of COPS for the communication between the edge device and the BB • COPS extensions for DiffServ resources allocation under outsourcing model

18. The COPS Role for Dynamic DiffServ Resource Allocation(4) • Signaling mechanism • The QoS client to make resource reservation requests to the network • RSVP • End-to-end protocol to support multicast sessions spanning the whole Internet with receiver-oriented reservations • More complex • The European IST project AQUILA • More systematic approach to address this problem

19. PDP PEP The COPS Role for Dynamic DiffServ Resource Allocation(5) Bandwidth broker QoS client(H323 gatekeeper,SIP server…) PDP PEP COPS QoS-enabled network COPS Edge router COPS support to dynamic DiffServ-based IP QoS

20. Definition of the COPS Interface • The extension of COPS • For dynamic DiffServ QoS scenario • COPS-DRA : DiffServ Resource Allocation • COPS-ODRA : Outsourcing DRA • Based only on the outsourcing model • For flexibility and efficiency • In combination with providing model

21. Definition of the COPS Interface • The PEP always explicitly asks the PDP/BB for a given amount of resources • For scalability • Per-flow state is not stored in PDP/BB • Resource allocation requests are properly aggregated • Aggregate state information is kept in PDP/BB • Provisioning model • More scalable • Inflexibility : difficult to handle modification of config. • Not explicitly customized to handle dynamic DiffServ QoS

22. Definition of the COPS Interface • Requirements for a combined model • The capability of provisioning resource to local nodes, in order to avoid high signaling burden • Easy for the local node to request the modification of the provisioned resource • Possible to handle specific requests under the outsourcing model

23. Definition of the COPS Interface • Three components of the reserv. Requests • The scope and amount of reservation • Where the reservation applies • How much bandwidth • The type of requested service • Possibly including a set of QoS parameters • The flow identification • To which IP flow or aggregate of flows the reservation applies • More complex scenarios may require more parameters • Ex : timing

24. PDP PEP PEP PDP Definition of the COPS Interface Bandwidth broker (1) PDP (4) (2) (3) (5) (6) QoS-enabled network An example information exchange using COPS-DRA

25. IP telephony : A COPS Based QoS model • SIP protocol • Defined within the IETF • Initiate voice, video, and multimedia sessions • Candidate for call setup signaling in IP telephony • IntServ-based approaches • Client iscustomized for specific QoS mechanism. • Terminal has to implement SIP and QoS reservation protocol.

26. IP telephony : A COPS Based QoS model • The main idea • To eliminate the need for a specific QoS protocol in the terminals • To use SIP as the sole call setup protocol • All the QoS-related functions can be moved from the terminal to local SIP proxy servers • To relieve the terminals of unneeded complexity and preserving backward compatibility

27. Q-SIP Architecture • No specific QoS protocol required. • Terminal implementation is simplified. QoS Access Point QoS Access Point COPS/Other Client network Client network COPS/Other SIP SIP Q-SIP SIP terminal Q-SIPproxy server Q-SIP proxy server SIPterminal QoS SIP architecture

28. Asymmetric Q-SIP Architecture • Variant scenarios QoS Access Point QoS Access Point COPS/Other Client network COPS/Other Client network SIP SIP Q-SIP Q-SIPproxy server SIP proxy server Q-SIP terminal SIP terminal QoS SIP architecture

29. PDP PEP PEP PDP A Q-SIP Architecture using COPS Based QoS model Bandwidth Broker(BB) PDP Qos signaling (COPS) COPS-DRA Qos-enablednetwork Client network Client network COPS-DRA COPS-DRA Access edge router Access edge router SIP SIP Q-SIP SIP terminal SIP terminal Q-SIP proxy server Q-SIP proxy server QoS SIP architecture Application signaling (SIP)

30. A COPS Based QoS model • QoS SIP architecture • The edge routers • Implement all mechanisms needed to perform admission control decision and policing function • COPS protocol • Used to make QoS reservation requests to the QoS access points

31. A COPS Based QoS model(Cont.) • SIP server • To exchange message between the clients • To add QoS related information in the SIP messages • To negotiate QoS parameters among them • Interact with the network QoS mechanisms • Q-SIP • Enhanced SIP ( QoS-enable SIP server )

32. Bandwidth broker Called user Q-SIP server Called user Q-SIP server DiffServ network SIP terminal Called user ER Called user ER SIP terminal Message Flow INVITE INVITE(With QoS-Info) INVITE 180 ringing 180 ringing 180 ringing 200 OK Cops REQ Cops REQ Cops DEC Cops DEC (With QoS-Info)200 OK Cops REQ Cops REQ Cops DEC Cops DEC 200 OK ACK ACK ACK <Traffic stream>

33. QoS Info recorded in Q-SIP • QoS info. is inserted into new INVITE messages or 200 OK response message: • QoS-Info: <qos-param> *(;<qos-param>) • Same info can also be carried by “Record-Route” header. • Example of QoS-Info: • QoS-Info: qos-domain=coritel.it;er-ingress=192.168.77.5; qos-mode=unidirectional

34. QoS Info recorded in Q-SIP(Cont.) • <qos-mode> • Either “unidirectional” or “bidirectional” • <er-ingress> & <er-egress> • The edge router on caller/callee side • <qos-domain> • Identify the domain where resource reservation is done • <caller-media-addr> & <caller-media-port> • Caller address • <other>

35. Implementation Testbed The overall testbed scenario

36. Implementation Testbed • the QoS and call setup aspects • two Ethernet based client networks • Based on Linux OS • COPS clients/servers • A DiffServ core network • Two ERs & one core router • PDP/BB • Access network • One SIP terminal & one Q-SIP server

37. Implementation Testbed Q-SIP server, ER, and BB internal architecture

38. Conclusions • Signaling mechanism • Resource admission control within DiffServ • Resource requests to a QoS provider • QoS-aware call setups for SIP-based applications

39. Conclusions (Cont.) • Resource admission control within DiffServ • PEP (Edge Router) • Handles resource & policy enforcement • PDP (Bandwidth Broker) • Handles resource allocation pecisions

40. Conclusions (Cont.) • Resource requests to a QoS provider • PEP (SIP proxy server) • Asks for QoS reservation • PDP (edge router) • Typically edge routers of the DiffServ network

41. Conclusions (Cont.) • QoS-aware call setups for SIP-based applications • Integrating the SIP signaling with DiffServ QoS mechanisms • Preserving backward compatability.

42. Reference • S. Salsano, L. Veltri, Qos Control by Means of COPS to Support SIP-Based Applications • X. Xiao, L. M. Ni, Internet QoS: A Big Picture • S. Mallenius, The COPS (Common Open Policy Service) Protocol • S. Salsano, L. Veltri, SIP Extensions for QoS support, <draft-veltri-sip-qsip-01.txt> • http://www.coritel.it/projects/cops-bb