인터넷 QoS 기술

1. 인터넷 QoS 기술 1999. 7. 숭실대학교 김 영 한 yhkim@dcn.soongsil.ac.kr

2. Content • Introduction • Integrated Service • Differentiated Service • Scheduling algorithm • Buffer Management

3. Existing Internet Model • 인터넷의 급속한 성장 • 사용자 증가 • 다양한 응용 프로그램의 출현 • both data and real-time applications • Weaknesses • Unable to support Quality of Service • Does not allow variable grade service • charging • 망 운용이 어려워지고 있음 • ( Gateway based on old packet switching techmology)

4. Existing Internet Model(cont’d) • Current Internet Approach • 복잡함 • 많은 파라미터들과 복잡한 traffic management 방식 • 사용자의 의식 부족과 망 운용자의 어려움

5. Challenges High speed networks that can provide QoS support • Hardware architecture • Need a lot of computing cycles • Need high bandwidth data paths among CPUs, memory, devices, and network • Operating system and protocols • Handle continuous flows of data • Provide (soft) real time performance • Provide inter-stream synchronization • Support for multipoint communication • Efficient implementations within the constraints of OS and hardware • Applications development environment

6. What are Quality of Service ? • QOS is a concept for specifying how “good” offered (networking) services are [ISO] • QoS characterized by specific parameters • Parameters vary for different layers

7. What are QoS gurantees ? Ensure that negotiated QOS parameters will be enforce in spatial (layer) and temporal (duration of session) dimensions Types of guarantees • Guaranteed services enforce parameters negotiated with QoS specification Guarantees could be deterministic or statistical • Predictive services enforce QoS parameters estimated from past behavior

8. Integrated services(IntServ) • Service model • Guaranteed service • controlled load service • best-effort service • Protocol support • RSVP(Resource reservation protocol) • Algorithms • scheduling • admission control

9. Limitations of Resource Management Architecture Today • IP provides only best effort service • IP does not participate in resource management • IP cannot provide service quarantees on a per flow basis • IP cannot provide service differentiation among traffic aggregates • IETF and research community efforts • integrated service initiative • differentiated services initiative

10. Integrated Services Internet • Enhance IP’s service model • old model : single best-effort service class • new model : multiple service classes, including best-effort and QoS classes • Create protocols and algorithms to support new service models • old model : no resource management at IP level • new model : explicit resource management at IP level • Key architecture difference • old model : stateless • new model : per flow state maintained at routers • used for admission control and scheduling • set up by signaling protocol

11. Components of IntServ Network • RSVP • signaling protocol to set-up • tear-down per flow reservation state • Packet classifier • determine the route and the QoS class for each packet • Packet scheduler • make forward decisions every packet, to achieve the promised QoS on the particular link-layer medium • Admission control • determines whether the node has sufficient available resources • Policy control • determine whether the user has administrative permission to make the reservation

12. Architecture of Integrated Services

13. Service Classes • Guaranteed service : hard real-time • guarantee a deterministic upper bound on delay for each packet in a session provided that the session does not send more than it specifies • admission control based on worst-case analysis • per flow queueing support at routers • Controlled load service : soft real-time • provide a flow with a QoS closely approximating the QoS that the same flow would receive from an unloaded network • measurement based admission control possible • scheduling for aggregate possible

14. Role of RSVP in the Architecture • Signaling protocol for establishing per flow state • Carry resource request from hosts to routers • Collect needed information from routers to hosts • At each hop • consults admission control and policy module • sets up admission state or informs the requester of the failure

15. RSVP Design Feature • IP Multicast centric design • Receiver initiated reservation • Different reservation styles • Soft state inside network • Decouple routing from reservation

16. RSVP Reservation Model • Performs signaling to set up reservation state for a session • A session is a simplex data flow sent to a unicast or a multicast address, characterized by

17. RSVP Basic Operations • Sender sends PATH message via the data delivery path • set up the path state each router including the address of previous hop • Receiver sends RESV message on the reverse path • specifies the reservation style, QoS desired • set up the reservation state at each router • Things to notice • receiver initiated reservation • decouple the routing from reservation • two types of state : path and reservation

18. Example of RSVP Basic Operation Example 1. Path_msg S1 2. forwarding Path_msg R1 R2 D1 S2 R3 3-1.Resv_msg 4. forwarding Resv_msg D2 3-2. Resv_msg

19. PATH Message • Sender Template : a filter spec identifying the sender • whether to forward a RESV message to this sender • shared explicit, fixed filter styles • Sender Tspec • Describes data traffic generated by a sender • Never modified in the network • Adspec object • Describes services and parameters of the path • May be updated by network elements

20. SENDER_TSPEC Usage • Delivered to both intermediate network elements and receiving applications • Each intermediate network element uses SENDER_TSPECs and information arriving in the RESV messages to make an appropriate resource reservation from the desired service • Receiver uses SENDER_TSPEC and ADSPEC to pick a service

21. SENDER_TSPEC Format 0 (version) reserved 7 (overall length) 1 (general) 0 reserved 6 (service data length) 127 (tb tspec) 0 (flags) 5 (parameter length) token bucket rate token bucket size peak data rate minimum policed unit maximum packet size (MTU)

22. RESV Message • FLOWSPEC object • Tspec • Describes the traffic flow desired • Rspec • Parameters required to invoke the desired service • Transmitted upstream to intermediate network nodes and senders • May be merged at intermediate network nodes

23. Specification of Reservation with RESV Message • A reservation request or flow descriptor has two parts • flow spec and filter spec • Flow spec specifies desired QoS parameters • used by admission control module during set up time • used by traffic control module or packet scheduler • Filter spec specifies the set of data packets that can use the reservation • list of <IP source addr, port number> • empty list means wildcard or any source can use the resource

24. Flow Spec • Tspec :traffic specification • p : peak rate of flow • b : bucket depth of maximum burst size • r : token bucket rate or long term average rate • m : minimum policed unit • M : maximum datagram size • Rspec : resource specification • R : required service rate, must be no less than r • S : Slack term

25. FLOWSPEC Usage • Intermediate network nodes • Merge multiple FLOWSPECs • Make appropriate service reservation • FLOWSPECs arrive at senders • Sender use new minimum MTU value for sending

26. FLOWSPEC Format 0 (version) reserved overall length service id 0 reserved service data length 127 (tb tspec) 0 (flags) 5 (parameter length) token bucket rate token bucket size peak data rate minimum policed unit maximum packet size (MTU) Rspec for invoking QoS control (parameter header, parameter) pair

27. Performance Guarantee • Delay has two components • fixed component : sum of propagation and switching delays along the path, a function of the path • variable component : sum of queueing delays along the path, a function of the service • Guaranteed service provides a bound on queueing delay • a function of Tspec and Rspec • calculated based on the fluid model

28. Reservation Style • Motivation : achieve more efficient resource utilization in multicast (M*N) • Observation: in a video conferencing when there are M senders, only a few can be active simultaneously • multiple senders can share the same reservation • Various reservation style specify different rules for sharing among senders

29. Reservation Styles and Filter Spec • Reservation style • use filter to specify which senders can use the reservation • Three styles • fixed filter : no sharing among senders, sender explicitly identified for the reservation < IP source addr, port number > • wildcard filter : sharing among senders, sender explicitly identified for the reservation empty list or * • shared explicit filter : resource shared by senders that are explicitly specified < IP source addr, port number >

30. Fixed Filter Example FF(S1{4B}, S2{5B}) S1 R1 FF(S1{4B}) S1{4B} S2{5B} S1{3B} S3{B} FF(S1{3B}, S3{B}) R2 FF(S1{B}) S2 FF(S2{5B}, S3{B}) R3 S3 Router Host

31. Wildcard Filter Example WF(*{4B}) S1 R1 WF(*{4B}) *{4B} *{3B} WF(*{3B}) R2 WF(*{4B}) S2 WF(*{4B}) R3 S3 Router Host

32. Reservation Merging • Multiple receivers of same session may request reservation for the same sender • Intermediate router merge requests and pass one message to upper link • Reserve message forwarded according to the path state that was set up by the path message • What if different receivers request different QoS? • conflicting styles not permitted • merging reservations means computing maximum of the reservation requested • may have to reject the larger request

33. One Pass With Advertising (OPWA) • Improvement over basic model • Motivation • collect information along the path so that receivers can make better reservation request • Optional Adspec object in PATH message • Default General Parameters fragment • Service specific fragment such as Guaranteed service or Controlled load service fragment

34. ADSPEC Usage • Sender initialized • At each network element • Each service updates its section of ADSPEC • Break bit is set if the service is absent • General parameters break bit is set if a non-RSVP hop is on the path • Services may override general parameters • Receiver discovers whether RSVP is fully supported and what services are available

35. ADSPEC Usage (cont.) • Receiver discovers the path maximum transfer unit (MTU) • QoS control may place an upper bound on packet size • Use default MTU unless overridden • Receiver uses SENDER_TSPEC and ADSPEC to pick the right service

36. ADSPEC Format 0 (version) reserved service data length default general parameters fragment (service 1) service i specific fragment service j specific fragment more services specific fragments……..

37. Soft State • Per session state has a timer associated with it • path state, reservation state • State lost when timer expires • Sender/Receiver periodically refreshes the state, resends PATH/RESV messages, resets timer • Claimed advantages • no need to clean up dangling state after failure • can tolerate lost signaling packets • signaling message need not be reliably transmitted • easy to adapt to route changes • State can be explicitly deleted by a Teardown message

38. RSVP and Routing • RSVP designed to work with variety of routing protocols • Minimal routing service • RSVP asks routing how to route a PATH message • Route pinning • addresses QoS changes due to “avoidable” route changes while session in progress • QoS routing • RSVP route selection based on QoS prarmeters • granularity of reservation and routing may differ • Explicit routing • Use RSVP to set up routes for reserved traffic

39. Recap of RSVP • PATH message • sender template and traffic spec • advertisement • mark route for RESV message • follow data path • RESV message • reservation request, including flow and filter spec • reservation style and merging rules • follow reverse data path • Other messages • PathTear, ResvTear, PathErr, ResvErr

40. WHY DiffServ • Service Providers 요구 • Scalability • 간단한 implementation과 관리 • 서비스에 따른 차등화된 pricing • Users 요구 • Better than best effort service • Bandwidth guarantee • Low Delay & Jitter & Loss • Predictable service

41. Definition (cont.) • Scalable Service differentiation • Using DSCP(DiffServ Code Point) of IP Header • Traffic classification state를 줄일 수 있음. • 적절한 PHB선택을 위해 marking • Traffic aggregation • Micro-flow state를 유지할 필요가 없음 • 복잡한 작업을 망의 edge 노드에서 수행 • 내부 라우터의 기능을 간소화

42. Architecture • DS Domain • DS node들의 연속적인 집합 • 같은 관리를 받는 여러 network들 • DS Edge Node • DS domain의 경계 • DS Ingress Node & Egress Node • Traffic conditioning 기능 수행

43. Architecture (cont.) • Interior Node • DS domain 내에서 다른 interior node 나 edge node와 연결 • Domain에서 지원하는 PHB group의 정의에 따라 DS codepoint에 의한 패킷 전달이 가능 • 제한된 Traffic conditioning 기능이 가능하다.

44. DSCP (DiffServ Code Point) IPv4 Header (first 32bits) 4-bit header length 8-bit type of service (TOS) 4-bit version 16-bit total length (in byte) 6-bit DSCP for Per-Hop Behavior 2-bit CU Currently Unused 8-bit TrafficClass 4-bit version 20-bit Flow Label IPv6 Header (first 32bits)

45. SLA & TCA • Service • quantitative service • qualitative service • SLA (Service level agreement) • dynamic : 망의 변화에 맟춰서 변동가능 • static : 관리자가 manual에 따라 set • TCA (Traffic conditioning agreement)

46. PHB (Per Hop Behavior) • Hop by Hop의 행동방침 • Small set (building-block) of aggregation flow • 서비스의 품질 종류 • Default PHB • AF (Assured Forwarding) PHB • EF (Expedited Forwarding) PHB

47. PHB (cont.) • Default PHB • 최소한의 resource할당 되어져야한다. • For non-ds traffic. • DSCP ; 000000 • Class Selector Code Point : xxx000 • backward compatibility • 상대적인 우선순위 • routing signalling traffic등에 사용

48. AF PHB • Key Idea • Traffic 특성으로 다수의 class로 구분. • congestion상황에서도 drop level을 차별화 해서 minimum rate을 보장. • 3개의 Drop precedence 갖는 4개의 class로 구성 • 각 class는 독립적이고, class간의 관계는 아직 불명확하다.

49. AF PHB (cont.) • 각 class에게는 최소한의 forwarding resource가 보장되어야 한다. • Reordering 방지 • 각 class는 각각의 queue 가짐 • Forwarding assurance level 결정요인 • 패킷이 속한 AF class에 할당된 resource양 • Class에 존재하는 active load수 • Congestion상황 : Drop precedence level

50. EF PHB • Key Idea • Low loss, delay & jitter 실현 • 각 Node의 queueing 방법이 해결과제 • 각 node에서 Max arrival rate을 min departure rate보다 작게 해주는 것으로 극복 • Top-priority traffic • 다른 PHB group나 traffic을 가로채기 할 수 있다. • premium service, virtual leased line service