1 / 51

Resource ReSerVation Protocol (RSVP)

Resource ReSerVation Protocol (RSVP). Version 1. Functional Specification.(rfc 2205). 네트워크연구실 오 승 훈. Introduction. 경로상의 모든 router 에 자원 할당 , QoS Transport 계층에서 동작 ( ICMP, IGMP 와 같은 메시지 ) Route 정보를 얻기 위해 routing database 참조 . Multicast 인 경우

haamid
Download Presentation

Resource ReSerVation Protocol (RSVP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Resource ReSerVation Protocol(RSVP) Version 1. Functional Specification.(rfc 2205) 네트워크연구실 오 승 훈

  2. Introduction • 경로상의 모든 router에 자원 할당, QoS • Transport 계층에서 동작( ICMP, IGMP 와 같은 메시지) • Route 정보를 얻기 위해 routing database 참조 . • Multicast 인 경우 • Host에서 IGMP를 먼저 보냄(multicast group에 join) • RSVP 자원 할당.

  3. Introduction. • Receiver host의 응용이 RSVP데몬에 자원 할당 요청을 전달. • 경로상의 모든 host의 RSVP의 데몬과 통신하여 자원을 할당한다. • Receiver host의 응용이 데이타전송.

  4. Traffic control 을 위한 구성요소 • Classifier (분류자) • Admission control • Packet scheduler. • 자원 예약 과정에 수락제어와 정책 제어가 이루어진다. • Soft state. ( refresh )

  5. RSVP 의 특징 • For unicast, and many-to-many multicast applications • Simplex • Receiver-oriented • Soft state • Several reservation models or styles • Transparent operation through router that do not support it • IPv4/ IPv6

  6. Session ? • Dst address, Protocol ID, Dst port 로 식별되는 dataflow. • RSVP Reservation Request 구성 • Flow spec & Filter spec 데이터 패킷의 집합의 정의(flow) desired QoS node의 scheduler의 파라메터를 설정 Classifier의 파라메터를 설정

  7. Flow spec • 구성 • R-spec(Reservation) : desired QoS, • T-spec(Traffic) : data flow 를 정의 • Filter spec(depends on IPv4 / IPv6) • 세션속에서 Packet들의 집합 결정, (Sender의 정보를 이용, IP-addr , port#)

  8. RSVP Reservation request를 받은 중간 node 의 행동. • 1. Make reservation on a link. • RSVP 데몬이 이 request를 Policy control, admission control 를 통해 수용여부결정.? • NO,-- Error message 를 전송. • YES,-- filter spec에 의해 classifier 설정 flow spec에 의한 QoS를 설정( link layer or scheduler) • 2. Forwarding the request upstream. • Toward upstream. • Hop-hop 단위로, 각각의 node의 flow spec 변경 가능 ,

  9. Reservation styles • 자원 공유 방법에 따라 • Shared : 송신자들이 자원 공유 • Distinct : 자원을 배타적으로 할당. • 송신자(sender)지정 방법에 따라 • Explicit : 특정 송신자 지정 • Wildcard : 모든 송신자

  10. 예약방식 • WF(wildcard-Filter) • Pipe 같은 것 • WF-style reservation request • WF( * {Q} ) • * : Wildcard sender, Q : flow spec. • FF (Fixed-Filter style) • Distinct reservation , explicit sender • FF( S{q}) • 동시 다중지원 가능 : FF( S1{Q1}, S2{Q2}, … )

  11. 예약방식 • SE (Shared Explicit style) • A single reservation shared by selected upstream senders • SE( (s1,s2,…){Q} ) ** WF 와 SE 는 multicast 응용에 적합.

  12. Fixed Filter(FF) 예약방식

  13. Wildcard filter 예약방식

  14. Shared Explicit(SE) 예약방식

  15. RSVP protocol Mechanism- messages 메시지 종류와 방향. *Reservation state in each node along the path(s) *Resv 메시지를 받으면 적절한 traffic control parameter 가 설정된다.

  16. Path message. • downstream, unicast/multicast routers, • store “path state” in the each node along the path. • The contents. • Sender Template • Sender가 보낼 data format • Filter spec형식 • Specify only sender IP address , optionally UDP/TCP port. • Sender Tspec • Sender 가 만들 data flow 의 traffic 특성 • Adspec • (may) Carry a packet of OPWA advertising information • 수신  local traffic controler에 전달  updated one returned forwarding.

  17. Soft state • Refreshed by Path and Resv msg • State 가 제거 되는 경우 • Refresh timeout! • By explicit ‘teardown’ message • 저장된 state 가 갱신되어서 변했을 경우 • Refresh msg 를 만들어서 즉시 forwarding  modification propagated to endsystem immediately • Independent reservation in the two direction.

  18. Teardown • Remove path or reservation state immmediately • 종류 • PathTear : • towards all receiver downstream • Delete Path states • Granularity for teardown : single sender • ResvTear • Towards all sender upstream • Delete Reservation states • Granularity : individual filterspec

  19. Errors-ResvErr, PathErr • Path Err • Simple, 단지 upstream sender에게 error정보만 전달. • No change in Path state in the node • Few possible to occure.

  20. PathErr • Must be reported to all responsible receiver • Killer-reservation problem(1) • KR-II • Q0 가 이미 저장 • New Q1 예약 요청(Q1>Q0) • Q1으로 병합  previous hop 에게 요청 • Previous hop 에거 수락을 거절. •  이미 있던 Q1마저 해제 된다.

  21. Killer-reservation problem(2) • KR-II

  22. KR-II의 해결책 • Resv msg 는 각 노드에 Blockade state를 만든다. • Blockade state : 요구가 너무 커서 거절당한 flowspec 를 저장.  같은 flow spec이 병합 되는 것을 막아준다.

  23. Confirmation

  24. 정책 제어와 보안 • 특정 사용자에 의한 망 자원의 독점을 막고자 • 정책제어 & 수락제어를 사용 • 정책 데이터 • 사용자, 사용자 계층, 계정 번호, 제한 사항. • 이런 데이터는 보안을 위해 암호화 되어 전송.

  25. Non-RSVP clouds • Non-RSVP node 경유가능 , 그러나 Qos보장 안됨 • Non RSVP host가 바로 옆에 있는 경우. • Non RSVP flag bit를 설정해서 local traffic controller에 전달  local traffic controller는 Adspec를 이용해서 수신자에게 보낸다. • LIH(logical Interface handle) 사용 • Resv msg가 다른 RSVP-capable node에 도착할 가능성 • 맞은 node의 다른 interface에 도착할 가능성 • Path message 의 previous hop 정보에 IP address 와 LIH 정보를 넣는다. path state 정보로 저장.

  26. Host model • Session 생성 전 • Session ID(Dst Addr, Protocol ID, [Dst port])가 할당되고 모든 수신자와 송신자에게 전달되어야 한다. (by out-of-band) • RSVP session setup H1. 수신자가 IGMP를 사용하여 다중 전송그룹에 가입 H2. 송신자  수신자 : Path msg. H3. 수신자 응용이 Path msg 수신 H4. 수신자는 적당한 Resv msg를 보낸다. H5. 송신자는 Resv msg를 수신. H6, 송신자는 데이터 전송 시작.

  27. RSVP Functional Spec-message format • Common header • RSVP length : common header 포함 • (various-length object) • Msg Type • 1:path, 2:Resv, 3:PathErr, 4:ResvErr, • 5:Pathtear, 6:ResvTear, 7:ResvConf

  28. Packet form. • Message –Header -Body–objects - header - body. Type 정보로 구별 C-type 값을 새로 정의 해서 새로운 서비스 확장

  29. Object format • One word(32bits) header • Length : 전체 객체의 길이로써 항상 4의 배수이다. • Class-Num : 객체 계층을 구별하기 위한 번호이다. ① NULL : 이 부분은 무시된다. ② SESSION : 모든 RSVP메시지 안에 필요한 IP 주소, IP 프로토콜 ID 그리고 수신자 포트가 있고 IPv4 세션과 IPv6 세션으로 구별된다. ③ RSVP_HOP : RSVP를 지원하는 노드의 이전 또는 다음 홉의 주소

  30. ④ TIME_VALUES : 경로 또는 예약 재확인의 빈도수를 나타낸다. ⑤ STYLE : 예약 방식을 나타낸다. ⑥ FLOWSPEC : 예약 메시지 안에 요구된 서비스 품질을 나타낸다. ⑦ FILTER_SPEC : 플로우에 대한 설명으로 수신자 주소와 IP 플로우 레벨을 가진다. ⑧ SENDER_TEMPLATE : 송신자에 관한 정보를 가진다. ⑨ SENDER_TSpec : 송신자 데이터의 트래픽 특징을 나타낸다. ⑩ ADSPEC : OPWA정보 데이터를 전송하며 종단간의 통신 경로 특성 을 수신자에게 알린다. ⑪ ERROR_SPEC : PathErr와 ResvErr의 에러에 대해 설명한다. ⑫ POLICY_DATA : 플로우에 대한 정책 데이터를 가진다. ⑬ SCOPE : WF예약 방식의 예약 재확인 메시지가 적용되는 호스트의 목록을 나타낸다. ⑭ RESV_CONFIRM : 예약 메시지 확인을 요구한 IP 주소를 가진다.

  31. Path message

  32. Path message • SENDER_TEMPLATE • Data packet 형식 • SENDER_TSPEC • Flow 트래픽 특성 • [ADSPEC] • Advertising (OPWA)

  33. Path message • <Path Message> ::= <Common Header> [ <INTEGRITY> ] • <SESSION> <RSVP_HOP> • <TIME_VALUES> • [ <POLICY_DATA> ... ] • [ <sender descriptor> ] • <sender descriptor> ::= <SENDER_TEMPLATE> • <SENDER_TSpec> • [ <ADSPEC> ]

  34. Path message • PHOP(i.e.,RSVP_HOP) obj :previous hop address • 가장 최근에 path msg 가 보내 졌던 interface의 IP address • LIH 를 포함 • Path msg를 수신한 RSVP-capable node 의 행동. • Path msg 를 catch 해서 Path state를 만든다.(갱신) • By SEND_TEMPLATE, SESSION object • And POLICY_DATA , SENDER_TSPEC, ADSPEC obj 정장. • If error detected, PathErr을 sender에게 전송.

  35. Resv message

  36. Resv message • RSVP_HOP(Last Hop Address ) • 예약 요청을 조정한 최근의 시스템의 정보 • STYLE • 예약 방식 FF(10), WF(17), SE(18) • Hop 단위로 전달. • IP destination of Resv msg = previous-hop node 의 unicast address • IP source of Resv msg = message 를 보낸 node 의 주소.

  37. Resv messge-Format • <Resv Message> ::= <Common Header> [ <INTEGRITY> ] • <SESSION> <RSVP_HOP> • <TIME_VALUES> • [ <RESV_CONFIRM> ] [ <SCOPE> ] • [ <POLICY_DATA> ... ] • <STYLE> <flow descriptor list> • <flow descriptor list> ::= <empty> | • <flow descriptor list> <flow descriptor>

  38. Resv message-Format • WF(Wildcard-Filter) Style: • <flow descriptor list> ::= <WF flow descriptor> • <WF flow descriptor> ::= <FLOWSPEC> • FF(Fixed-Filter) style: • <flow descriptor list> ::= • <FLOWSPEC> <FILTER_SPEC> | • <flow descriptor list> <FF flow descriptor> • <FF flow descriptor> ::= • [ <FLOWSPEC> ] <FILTER_SPEC> • SE(Shared-Explicit) style: • <flow descriptor list> ::= <SE flow descriptor> • <SE flow descriptor> ::= • <FLOWSPEC> <filter spec list> • <filter spec list> ::= <FILTER_SPEC> • | <filter spec list> <FILTER_SPEC>

  39. Resv message • 예약 범위(reservation scope) • Merging 이후 특정 예약 요구가 도착될 sender들의 집합 • Explicit sender selection • Path state에 저장된 ‘SENDER_TEMPLATE”와 reservation의 FILTER_SPEC과 matching 된 것만 모든 sender에게 forwarding. • Wilder sender selection • Outgoing interface 쪽에 연결된 모든 sender들과 matching 된다. • 하나이상의 previous hop 으로 전달될 시 scope object 반드시 포함 .

  40. Path Teardown message(PathTear) • To delete matching path state • matching: SESSION, SENDER_TEMPLATE, PHOP obj. • If No matching path state, • PathTear discarded and not forwarded. • Initiated by senders or by path state timeout in any node. • Travel downstream • If path state for the same(session, sender)pair but a different PHOP -> unicast PathTear must not be forwarded.

  41. Path Teardown message(PathTear) • Format • <PathTear Message> ::= <Common Header> [ <INTEGRITY> ] • <SESSION> <RSVP_HOP> • [ <sender descriptor> ] • <sender descriptor> ::= (see earlier definition)

  42. Resv Teardown message (ResvTear) • To delete matching reservation states • Matching :SESSION, STYLE, FILTER_SPEC, LIH • If no matching -> then discarded! • (may) teardown any subset of filterspec(FF-style, SE-style) • Initiated explicitly by receiver or by any node(reservation has timed out) • Hop-by-hop (travel up stream)

  43. Resv Teardown message • Format • <ResvTear Message> ::= <Common Header> • [<INTEGRITY>] • <SESSION> <RSVP_HOP> • [ <SCOPE> ] <STYLE> • <flow descriptor list> • <flow descriptor list> ::= (see earlier definition) • Node 에서 state 변화 결과에 따라서 “ResvTear forwarding” ,modified Resv forwarding 또는 no message forwarding 를 결정된다.

  44. Path Error Message • Report errors in processing path msg to sender applic. • Upstream, and routed hop-by-hop using path state • No modification of state of any node. • format • <PathErr message> ::= <Common Header> [ <INTEGRITY> ] • <SESSION> <ERROR_SPEC> • [ <POLICY_DATA> ...] • [ <sender descriptor> ] • <sender descriptor> ::= (see earlier definition) ** ERROR_SPEC : 에러 정보 명시, 에러 발생한 node 주소 포함 .

  45. Resv Error Message • Report errors in processing Resv msg • Downsteam towards the appropriate receivers • Routed hop-by-hop using the reservation state • Format • <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] • <SESSION> <RSVP_HOP> • <ERROR_SPEC> [ <SCOPE> ] • [ <POLICY_DATA> ...] • <STYLE> [ <error flow descriptor> ] • <error flow descriptor> ::= • <WF flow descriptor> | • <FF flow descriptor> | <SE flow descriptor>

  46. Resv Error Message • 수락제어 시 에러 발생할 경우 • 현존하는 reservation은 보존하고, ResvErr 의 ERROR_SPEC의 InPlace flag가 on 이 돼야 한다. • ResvErr 가 receiver에 도착 시 STYLE, flow descriptor, ERROR_SPEC 등이 수신단 응용으로 전달 되어야 한다.

  47. Confirmation Messages • ResvConf msg = Reservation request의 ack. • Resv msg 의 RESV_CONFIRM obj 존재 시 ResvConf 발생 • Receiver host 으 unicast 주소로 전달(hop-by-hop) • Format • <ResvConf message> ::= <Common Header> [ <INTEGRITY> ] • <SESSION> <ERROR_SPEC> • <RESV_CONFIRM> • <STYLE> <flow descriptor list> • <flow descriptor list> ::= (see earlier definition)

  48. Sending RSVP message • Protocol 번호 : 46 • Raw-IP-datagram 으로 RSVP를 지원하는 router사이에 hop 단위로 전송. • 실제론 UDP를 사용 • Path , PathTear, ResvConf msg 는 IP header 에 Router Alert IP option 를 사용해야 함.

  49. Avoiding RSVP Message Loops • Refresh period 에 맞혀진 auto-refresh loop 가 발생할 가능성 있음. • keep state forever.(problem) • Forwarding on each node only once per refresh period. • ‘Resv’ and ‘ResvErr’ msg with wildcard sender selection  auto-refresh looping 가능성 있음. • 해결책 • Topology 자체에 loop 가 없다면 들어온 interface으로 다시 나가지 못하게 함. • Topology에 loop가 있는 경우.SCOPE에 sender address를 명시한다.

  50. Blockade State

More Related