RSVP-TE Extensions to RSVP for LSP Tunnels

1. RSVP-TEExtensions to RSVP for LSP Tunnels 초고속통신 연구실 임 범 진 Draft-ietf-mpls-rsvp-lsp-tunnel-07.txt August 2000

2. Upstream Downstream Resv Receiver 1 messages Path Receiver 2 Source messages Receiver 3 Directions of RSVP messages. Abstract • use of RSVP to establish label-switched paths (LSPs) in MPLS • several additional objects to extend RSVP • signaling protocol로 RSVP를 사용함으로써 network failures, congestion, bottleneck시에 자동적으로 LSP를 reroute하게 한다.

3. Introduction • Extended RSVP protocol supports • explicitly routed LSPs • smooth rerouting of LSPs, preemption, and loop detection • unicast label switched paths • Background • label & RSVP flows • packet의 label value를 바탕으로 router는 packet에 적당한 reservation state를 부여 • 같은 label 동일 forwarding equivalence class(FEC)

4. Introduction (con’t) • RSVP Path message • ingress node가 label binding 요청 • LABEL_REQUEST object • RSVP Resv message • egress node에서부터 label을 할당하여 ingress node로 전파 • Resource reservation없는 LSP • resource reservation이 유용하기는 하지만 mandatory는 아니다. ex) best effort traffic • 오류상황에서의 fall-back이나 recovery policy등의 구현

5. Overview • LSP tunnel 생성 • RSVP Path message : sender  receiver • session type = LSP_TUNNEL_IPv4 / IPv6 (in SESSION object) • LABEL_REQUEST object • EXPLICIT_ROUTE object / RECORD_ROUTE object / SESSION_ATTRIBUTE object • RSVP Resv message : receiver  sender • Path message에 의해 생성된 path state를 따라 • LABEL object • outgoing label / incoming label • Resv message가 sender node로 전달되어야 LSP가 실질적으로 맺어짐 것임

6. Overview – Reservation Styles • receiver node에서 각 RSVP session에 대해 reservation style을 선택 • 다른 LSP에게 다른 reservation styles • RSVP session – one or more LSPs • 선택된 reservation style에 따라 – WF, SE • Fixed Filter (FF) Styles • sender : reservation = 1: 1 • 즉, sender와 receiver사이에 point-to-point LSP • sender마다 label 할당 • Wildcard Filter (WF) Style • 어떤 session에 대해, sender : reservation = n :1 • multipoint-to-point LSP • session에 하나의 label value만이 할당 • WF의 merging rule에 의해 ERO는 WF와 같이 사용되어질 수 없다.

7. Overview – Reservation Styles (con’t) • Shared Explicit (SE) Style • receiver가 reservation에 포함될 sender를 명확하게 지정 • 열거된 sender들에 대해서 하나의 reservation이 존재 • 다른 sender들에게 다른 label이 할당 • separate LSPs • multipoint-to-point LSP • non EXPLICIT_ROUTE object in Path messages • identical EXPLICIT_ROUTE object in Path messages • LSP per sender • different EXPLICIT_ROUTE object in Path messages

8. Overview - Rerouting • Rerouting LSP Tunnels • When? • 더 나은 route가 이용 가능하게 된 경우 • resource failure인 경우 • 원래 path로 LSP tunnel이 return하는 경우 • adaptive and smooth rerouting • make-before-break • old LSP tunnel을 끊기전에 새로운 LSP tunnel을 생성하여 traffic을 old LSP tunnel에서 new LSP tunnel로 transfer • 문제점 • 두 LSP tunnel이 resource를 두고 경쟁하는 경우 • Admission Control은 새로운 LSP tunnel의 생성을 막음

9. Overview – Rerouting (con’t) • Rerouting procedure • 새로운 Path message를 보낸다. – ingress node • 기존의 SESSION object • 새로운 LSP ID를 갖는 새로운 SENDER_TEMPLATE • 새로운 path를 정의하는 새로운 ERO • 두 LSP가 공존하지 않는 link에서는, 이 새로운 Path message는 기존의 LSP tunnel setup처럼 다루어진다. • 두 LSP가 공존하는 link에서는, LSP_TUNNEL_SESSION object와 SE style을 이용 - old LSP 와 resource를 공유 • ingress node에서 새로운 LSP에 대한 Resv message를 받으면 새로운 LSP로 traffic을 전송하고 old LSP는 끊는다.

10. LSP Tunnel related Message Formats • new objects • 이 새로운 object들은 RSVP에서는 OPTION. • 그러나, 이 spec.에 대해서 LABEL_REQUEST, LABEL object는 mandatory

11. LSP Tunnel related Message Formats (con’t) • Path Message • <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<EXPLICIT_ROUTE>] <LABEL_REQUEST> [<SESSION_ATTRIBUTE>] [<POLICY_DATA>…] [<sender descriptor>] • <sender descriptor> ::= <SENDER_TEMPLATE><SENDER_TSPEC>[<ADSPEC>] [<RECORE_ROUTE>]

12. LSP Tunnel related Message Formats (con’t) • Resv Message • <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<RESV_CONFIRM>] [<SCOPE>] [<POLICY_DATA>…] <STYLE> [<flow descriptor list>] • <flow descriptor list> ::= <FF flow descriptor list> | <SE flow descriptor> • <FF flow descriptor list> ::= <FLOWSPEC><FILTER_SPEC><LABEL>[<RECORD_ROUTE>] |<FF flow descriptor list><FF flow descriptor> • <FF flow descriptor> ::= [<FLOWSPEC>] <FILTER_SPEC> <LABEL> [<RECORE_ROUTE>] • <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> • <SE flow spec list> ::= <SE filter spec> | <SE filter spec list> <SE filter spec> • <SE filter spec> ::= <FILTER_SPEC> <LABEL> [<RECORE_ROUTE>]

13. LSP Tunnel related Objects - LABEL • Label Object in Resv message • class = 16, C_Type = 1 • 각 label은 4 octets (0-1048575) • FR Right aligned 4 octets • ATM 0-15 VPI, 16-31 VCI • router는 LABEL object의 label을 sender에게 연결된 outgoing label로 이용하고 새로운 label을 할당하여 incoming interface에 binding. • Reservation State Block – LABEL object를 저장 • next Resv refresh event

14. LSP Tunnel related Objects - LABEL REQUEST • LABEL REQUEST object in Path message • Class = 19 • C_Type • Type 1 : Label Request without label range (generic range) • Type 2 : Label Request with an ATM label range • Type 3 : Label Request with a Frame Relay label range • Label Request without Label Range • Reserved : 0으로 set하며 수신측에서는 무시 • L3PID : layer 3 protocol identifier • Standard Ethertype values

15. LSP Tunnel related Objects - LABEL REQUEST • Label Request with ATM Label Range • M : data plane에서의 merging 가능 여부 • Minimum VPI (12 bit) • Virtual Path Identifiers block의 lower bound • Minimum VCI (16bit) • Virtual Connection Identifiers block의 lower bound

16. LSP Tunnel related Objects - LABEL REQUEST • Label Request with Frame Relay Label Range • DLI : DLCI Length Indicator • Minimum DLCI : original switch가 지원해주는 DLCI block의 lower bound (23-bit field) • Maximum DLCI : upper bound (23-bit field)

17. LSP Tunnel related Objects - LABEL REQUEST • LABEL_REQUEST • Path 메시지에 label binding을 요청하고 이 path로 지나갈 트래픽의 layer 3 프로토콜을 알린다. • LABEL_REQUEST를 송신한 sender는 LABEL을 수신할 준비를 하고 있다. • LABEL_REQUEST를 인식하지만 지원하지 않는 node(Label할당이 불가능할 경우 등)는 PathErr를 sender에게 전송하고 PathErr를 수신한 sender는 그 후로는 LABEL_REQUEST를 해당 node에는 전송하지 않는다. • P3ID를 지원하지 않는 node는 PathErr를 sender에게 전송 • RSVP는 non-RSVP라우터를 통과할 수 있지만 non-RSVP라우터가 LABEL을 할당할 수 없으므로 non-RSVP node로는 LABEL_REQUEST를 보낼 수 없고 sender에게 PathErr를 전송한다.

18. LSP Tunnel related Objects - ERO • Explicit Route Object in Path message • class = 20, C_Type = 1 • subobjects – variable-length data items : address • 이 object는 단지 unicast 상황에서만 이용 • explicit route에 속하는 모든 router들이 RSVP 및 ERO를 지원하는 경우에만 이용 가능 • 이 object를 지원하지 않는 RSVP router들은 “Unknown Object Class” error로 응답 • path setup fail • ERO 없는 reservation 수행 • 다른 explicit route통한 reservation 시도 • 그 path에 속하는 node들을 specify • 또는 그 path를 거치면서 수행해야 할 operation을 지정

19. LSP Tunnel related Objects - ERO • Subobjects • L (1 bit) - 이 bit이 set 되어 있으면 loose hop, 아니면 strict hop • Type • 0 – Reserved • 1 - IPv4 prefix • 2 – IPv6 prefix • 32 – Autonomous system number • Length • subobject의 전체 길이 – L, Type, Length field까지 포함 • 적어도 4 byte, 그리고 4의 배수여야 • Subobject 1 : IPv4 prefix • Type : 0x01 IPv4 address • Length : 8 bytes • Prefix length : IPv4 address를 여기에 주어진 길이만큼만 prefix로 처리 • 나머지 부분은 무시되고, 전송시에 0으로 set됨

20. LSP Tunnel related Objects - ERO

21. LSP Tunnel related Objects - ERO • ERO의 처리 • next hop의 선택 • 첫 번째 subobject를 체크 • 자신이 그 subobject가 지정한 abstract node에 속하지 않으면 “Bad initial subobject”를 return • 그 subobject가 operation subobject라면, “Bad EXPLICIT_ROUTE object”를 return • subobject가 없으면, “Bad EXPLICIT_ROUTE object”를 return • 두 번째 subobject를 체크 • 없다면 이는 path의 끝을 의미 - Path message에서 ERO를 제거하고 새로운 ERO를 Path message에 추가 • 있다면 • operation subobject인 경우- 그 subobject를 ERO에서 빼내어 기록하고 자기 다음의 subobject를 체크 그리고 해당 operation을 수행 • 이 node가 두 번째 subobject가 지정한 abstract node에도 속한다면, 첫 번째 subobject를 제거하고 자신 아래의 subobject를 검사. 그 path의 다음 abstract node를 알 수 있다.

22. LSP Tunnel related Objects - ERO • Abstract Node Border Case • 두 번째 subobject가 지정한 abstract node에 topological하게 인접해 있는 경우 • 그 abstract node들 중에서 하나를 next hop으로 선택 • 이제 첫 번째 subobject를 제거하고 ERO에 새로운 subobject를 추가 • Interior of the Abstract node Case • 다음 abstract node를 향하는 path를 따라 첫 번째 subobject의 abstract node중에서 next hop을 선택, 없으면 error • 그런 path가 없는 경우 • loose인 경우는 다음 abstract node로 가는 임의의 node를 선택 • strict인 경우는 error • 마지막으로 그 node는 첫 번째 subobject를 next hop을 포함하는 abstract node를 나타내는 다른 어떤 subobject로 대체

23. LSP Tunnel related Objects - ERO • ERO에 subobject 추가하기 • next hop을 선택한 후 explicit route를 변경할 수도 있다. • ERO가 제거되는 경우 • 또는, 첫 번째 subobject의 abstract node의 member라면 • 첫 번째 subobject앞에 일련의 subobject를 추가하던지, 첫 번째 subobject를 되돌려 놓는다. • 새로 추가되는 subobject들은 현재 abstract node의 subset인 abstract node이다. • 첫 번째 subobject가 loose subobject라면 임의의 subobject가 첫 번째 subobject의 앞에 삽입될 수 있다. • Loops • ERO는 finite length  loop 가능 • RECORD_ROUTE object 이용 • 세세한 path 정보를 수집, loop detection, diagnostics에 유용

24. LSP Tunnel related Objects – RRO • Record Route Object in Path/Resv message • class = 21, C_Type = 1 • only in unicast sessions • subobjects • last-in-first-out stack • first subobject – top • 추가는 top에 • last subobject – bottom • Subobject 1 : IPv4 address • Flags • 0x01 Local protection available • link downstream is protected via a local repair mechanism • 대응되는 Path message의 SESSION_ATTRIBUTE object내의 Local protection flag가 set되어 있는 경우만 set

25. LSP Tunnel related Objects – RRO • 0x02 Local protection in use • 현재 tunnel을 유지하기 위해 local repair mechanism이 이용중 • Subobject 2 : IPv6 address • RRO의 format은 ERO의 format과 동일 • Resvd  Flags (loop detection mechanism) • up-to-date detailed path information 수집 (hop-by-hop) • path change report • EXPLICIT_ROUTE object의 input • node가 RRO를 갖고 있는 Resv message를 받으면, node는 이를 다음 Path message의 EXPLICIT_ROUTE object로 이용한다. session path를 명확하게 하기 위해

26. LSP Tunnel related Objects – RRO • RRO의 처리 • RRO를 포함한 Path message로 RSVP session을 초기화 • 초기 RRO는 단지 sender의 IP address만을 포함 • 중간 router에서의 처리 • Path message안에 RRO가 있으면 이 RRO를 Path State Block에 copy하고 다음 Path refresh에 이용 • 새 Path message를 전송하기 전, RRO에 새로운 subobject를 추가 • 그 router의 IP address • Outgoing Path message의 interface address • Path(Resv) message에 넣기에 너무 큰 RRO는 버린다. 그리고 normal로 message processing을 계속한다. • sender (receiver)에게 제거된 RRO를 포함하는 ParhErr(ResvErr)보냄 - receiver가 ResvErr을 받은 경우는 다시 RRO를 포함한 PathErr를 sender에게 보낸다. • 이런 message를 받은 sender는 Path message에서 RRO를 제거한다

27. LSP Tunnel related Objects – RRO • RSVP session의 receiver에서의 처리 • RRO를 갖는 Path message를 받으면 Resv message에 RRO추가 • Loop detection • 중간 노드에서 RRO의 subobject들을 살펴봤을 때 그 list내에 자신이 이미 포함되어 있다면 loop로 판단 • forwarding loop • transient loop • L3 routing의 operation으로 인해 • permanent loop • network misconfiguration • loop가 발견되면, PathErr을 보내고 그 Path message는drop

28. LSP Tunnel related Objects – RRO • Error Codes for ERO and RRO • Error Code(24) - Routing Problem • Error value

29. LSP Tunnel related Objects – Session • Session Object • LSP_TUNNEL_IPv4 Session Object • class = SESSION, LSP_TUNNEL_IPv4 C_Type = 7 • IPv4 tunnel end point address • tunnel egress node의 IP address • Tunnel ID • SESSION에서 이용되는 16-bit identifier • tunnel을 거치는 동안 constant • Extended Tunnel ID • tunnel 내에서 constant –일반적으로 0으로 set • SESSION을 ingress-egress pair로 좁히고자 하는 경우 ingress node의 IP address

30. LSP Tunnel related Objects – Session • LSP_TUNNEL_IPv6 Session Object • class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8

31. LSP Tunnel related Objects – Sender Template • Sender Template Object • LSP_TUNNEL_IPv4 Sender Template Object • class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C_Type = 7 • IPv4 tunnel sender address • sender node의 IP address • LSP ID • SENDER_TEMPLATE과 FILTER_SPEC에서 이용되는 identifier • sender가 자신과 자원을 공유할 수 있도록 하기 위해 바뀔 수도 있다. • LSP_TUNNEL_IPv6 Sender Template Object • class = SENDER_TEMPLATE, LSP_TUNEL_IPv6 C_Type = 8

32. LSP Tunnel related Objects – Sender Template

33. LSP Tunnel related Objects – Filter Spec • Filter Specification Object • LSP_TUNNEL_IPv4 Filter Specification Object • class = FILTER SPECIFICATION • LSP_TUNNEL_IPv4 C-Type = 7 • LSP_TUNNEL_IPv6 Filter Specification Object • class = FILTER SPECIFICATION • LSP_TUNNEL_IPv6 C-Type = 8 • SENDER_TEMPLATE과 동일 format • Reroute Procedure • STYLE Shared Explicit로 session이 설정된 상태 • 이미 존재하는 SESSION object를 사용 • Tunnel_ID, Extended_Tunnel ID는 불변 • new LSP_ID를 선택하여 새로운 SENDER_TEMPLATE 생성 • 새 EXPLICIT_ROUTE object 생성 • ingress node는 old/new Path message를 refresh • ingress node가 Resv message를 받으면 새로운 route를 이용하기 시작 • old route에 대한 PathTear message를 보낸다.

34. LSP Tunnel related Objects – Session attribute • Session Attribute Object • class = 207, LSP_TUNNEL C_Type = 7 • session identification / diagnostics를 위한 부가적인 control 정보 • flag • 0x01 Local protection – OPTIONAL support • local repair mechanism • 0x02 merging permitted – OPTIONAL support • resource overhead를 줄이기 위해  better network scalability • 0x04 Ingress node may reroute • 이 tunnel을 tear down하지 않고 reroute • 이때 tunnel의 egress node는 반드시 SE Style을 이용해야 • Setup Priority (OPTIONA support) • 0 ~ 7 • 0 : highest priority • 이 session이 다른 session을 preempt할 수 있는지 결정

35. LSP Tunnel related Objects – Session attribute • Holding Priority (OPTIONAL support) • 0 ~ 7 • 이 session이 다른 session에 의해 preempt될 수 있는지 • 주어진 session에 대해서 setup priority가 holding priority보다 높아서는 안 된다. • Setup priority  Holding priority • 이 object를 지원하지 못하는 RSVP router의 경우에는 수정하지 않고 전달

36. LSP Tunnel related Objects – Tspec & Flowspec • Tspec and Flowspec Object for COS service • LSP에 자원이 할당될 필요가 없는 경우, Class-of-Service service를 이용 • best-effort traffic 전송 • SENDER_TSPEC object그리고 FLOWSPEC object에 대해 동일한 format이 이용됨 • Class-of-Service SENDER_TSPEC object • class = 12, C_Type = 3 • Class-of-Service FLOWSPEC object • class = 9, C_Type = 3

37. LSP Tunnel related Objects – Tspec & Flowspec • COS • 0 – best effort • network이 IP TOS field를 지원하도록 하려는 의도 • local significance – local administrative decision • M • RSVP SENDER_TSPEC object내의 정보를 기초로 receiver가 Resv message에 set • shared reservation인 경우 • 각 sender로부터 온 값들 중 가장 작은 값 • Path message내에 이 object가 있으면 이 parameter는 각 hop에서 수신된 값과 outgoing interface MTU를 비교 작은 값으로 update된다.

38. Hello Extension • node-to-node failure detection • 이웃 노드와의 연결성 확인하기 위해 • Hello message, HELLO REQUEST object, HELLO ACK object • Neighbor failure detection • neighbor’s “instance” value들을 수집, 저장 • 이 값에 변화가 있는 경우 이웃 노드가 reset되었다고 가정

39. Hello Extension (con’t) • Hello Message Format • 두 RSVP neighbor사이에서 주고 받는 message • <Hello Message> :: <Common Header> [<INTEGRITY>] <HELLO> • HELLO Object • HELLO REQUEST object • class = HELLO class (22), C_Type = 1 • HELLO ACK object • class = HELLO class (22), C_Type = 2 • Src_Instance • sender instance를 나타내는 값 • sender가 reset, node가 reboot, communication이 lost되는 경우 이 값은 바뀌어야만 한다. • Dst_Instance : 가장 최근에 수신된 Src_Instance value

40. Hello Extension (con’t) • Hello Message Usage • Hello message는 완전한 OPTION • 이 Hello message processing에 참여하지 않은 node들은 이 message를 무시하면 된다. • 주기적으로 HELLO REQUEST object를 담은 Hello message를 발생 • HELLO REQUEST를 받으면 receiver는 반드시 ACK • 이때 이전 message의 Src_Instance값과 이번 message의 값을 비교하여 sender의 reset 유무를 판단. • 이 값이 다르면 communication이 lost된 것처럼 neighbor를 처리

41. Hello Extension (con’t) • 이번 message의 Dst_Instance값으로 neighbor가 receiver의 instance value를 reflect한 것이 아닌지를 판단 • ACK의 경우도 마찬가지 • communication이 lost된 경우나 또는 그렇게 가정하는 경우에는 다시 HELLO를 re-initiate한다.