CCAMP Working Group Katsuhiro Shimano (NTT) Internet Draft Kohei Shiomoto (NTT) Expiration Date: April 2003 Yoshihiko Suemura (NEC) October 2003 Extra class LSP service using protecting resources in GMPLS networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document proposes the extra class LSP, which uses the resource reserved but not allocated for the protecting LSPs in the pre-planned LSP re-routing without extra-traffic (including shared mesh) recovery method. Network utilization is improved because the resource reserved for the protecting LSPs are used for the extra class LSPs. The extra class LSP is preempted less frequently than the conventional priority mechanism using setup and holding priorities because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. This document addresses the issues on the extra class LSP: (1) advertisement of avail- able resource, (2) extra class LSP indication in signaling message (3) PIL [Page 1] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 extra class LSP preemption signaling, and (4) preventing unintended con- nections. The solution based on DSTE is presented. With DSTE, we define the TE-class in the following way: TE-Class[0] for Primary LSP : CT=CT1, setup priority = 0, holding priority = 0, TE-Class[1] for Secondary LSP: CT=CT0, setup priority = 0, holding priority = 0, TE-Class[2] for Extra LSP: CT=CT0, setup priority = 0, holding priority = 1. The above-mentioned TE-class implements the following mechanisms for the Extra class LSP: (1) resource advertisement, (2) preemption in response to failure, and (3) prevention of preemption in normal state. 1. Author information This document is the product of the following authors collaboration. Katsuhiro Shimano (NTT) NTT Network Innovation Laboratories Hikari-no-oka 1-1 Yokosuka, Kanagawa 239-0847, Japan Email: shimano@exa.onlab.ntt.co.jp Kohei Shiomoto (NTT) NTT Network Innovation Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Yoshihiko Suemura (NEC) 4-1-1, Miyazaki, Miyamae-ku, Kawasaki 216-8555, Japan E-mail: y-suemura@bp.jp.nec.com Itaru Nishioka (NEC) 4-1-1, Miyazaki, Miyamae-ku, Kawasaki 216-8555, Japan E-mail: i-nishioka@cb.jp.nec.com Eiichi Horiuchi (Mitsubishi Electric Corp.) 5-1-1 Ofuna, Kamakura Kanagawa, Japan 247-8501 E-mail: eiichi@isl.melco.co.jp PIL [Page 2] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 Shoichiro Seno (Mitsubishi Electric Corp.) 5-1-1 Ofuna, Kamakura Kanagawa, Japan 247-8501 Email: senos@isl.melco.co.jp Toshio Soumiya Fujitsu Laboratories Ltd. 1-1, Kamikodanaka 4-Chome Nakahara-ku, Kawasaki 211-8588, Japan Phone: +81-44-754-2765 Email: soumiya.toshio@jp.fujitsu.com Shinya Kanoh Fujitsu Laboratories Ltd. 1-1, Kamikodanaka 4-Chome Nakahara-ku, Kawasaki 211-8588, Japan Phone: +81-44-754-2765 Email: kanoh@jp.fujitsu.com Dai Muto (The Furukawa electric corporation) 5-1-9 Higashi-yawata, Hiratsuka 254-0016, Japan E-mail: dai@inf.furukawa.co.jp Kazumasa Morita (The Furukawa electric corporation) 5-1-9 Higashi-yawata, Hiratsuka 254-0016, Japan Email: k_morita@inf.furukawa.co.jp Kenji Kataoka (Hitachi Ltd.) 1099 Ohzenji, Asao, Kawasaki 215-0013, Japan E-mail: kataoka@sdl.hitachi.co.jp Yoshio Nogi (Hitachi Communication Technologies, Ltd.) 216 Totsuka-cho, Totsuka-ku, Yokohama-shi 244-8567, Japan E-mail: yoshio_nogi@hitachi-com.co.jp 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. PIL [Page 3] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 3. Introduction A functional description of GMPLS-based recovery is provided in [FUNCT] and end-to-end LSP recovery signaling is specified in [e2e]. In GMPLS- based recovery, the working LSP is protected by the protecting LSPs. There are several ways as to how to allocate and/or reserve the link resource for the protecting LSPs. [e2e] addresses four types of end-to- end LSP recovery: 1+1 unidirectional/1+1 bi-directional protection, LSP protection with extra-traffic (including 1:1 protection with extra-traf- fic), pre-planned LSP re-routing without extra-traffic (including shared mesh) and full LSP re-routing. In LSP protection with extra-traffic (including 1:1 protection with extra-traffic), the protecting LSP is instantiated at the provisioning phase but it is used to carry extra traffic on condition that the resource is preempted when the working LSP fails. In pre-planned LSP re-routing without extra-traffic (including shared mesh) method, the protecting LSP is not instantiated and the resource for the protecting LSP is reserved but not allocated at the provisioning phase. The unallocated protecting resource could be used to set up extra class LSP on condition that the resource is preempted when the working LSP fails. This document addresses the problem statement and the issue on a extra class LSP service and proposes the solution based on Diffserv-aware traffic engineering (DSTE). The extra class LSP service uses the resource reserved but not allocated for the protecting LSP at the provi- sioning phase. Network utilization is improved because the resource reserved for the protecting LSPs are used for the extra class LSPs. The extra class LSP is preempted less frequently than the conventional pri- ority mechanism using setup and holding priorities because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. This document addresses the issues on the extra class LSP: (1) advertisement of avail- able resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption signaling, and (4) preventing unintended con- nections. The solution based on DSTE is presented. With DSTE, we define the TE-class in the following way: TE-Class[0] for Primary LSP : CT=CT1, setup priority = 0, holding priority = 0, TE-Class[1] for Secondary LSP: CT=CT0, setup priority = 0, holding priority = 0, TE-Class[2] for Extra LSP: CT=CT0, setup priority = 0, holding priority = 1. The above-mentioned TE-class implements the following mechanisms for the Extra class LSP: (1) resource advertisement, (2) preemption in response to failure, and (3) prevention of preemption in normal state. PIL [Page 4] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 4. Problem statement [e2e] addresses LSP protection with extra-traffic (including 1:1 protec- tion with extra-traffic) and pre-planned LSP re-routing without extra- traffic (including shared mesh). These two LSP recovery methods make the resource of the protecting LSPs available to other extra traffic. [e2e] claims that the resource reserved for the protecting LSPs is used for extra traffic in case of the LSP protection with extra-traffic (including 1:1 protection with extra-traffic) recovery method. However it does not address how to use the resource reserved for the protecting LSPs for extra traffic in case of the pre-planned LSP re-routing without extra-traffic (including shared mesh) recovery method. The resource reserved for the protecting LSPs is used for extra traffic in case of the LSP protection with extra-traffic (including 1:1 protec- tion with extra-traffic) recovery method as claimed in [e2e]. Although the resources are pre-allocated for the protecting LSP , lower priority traffic may use these resources. The lower priority traffic will be preempted if the working fails. This method improves the network uti- lization by allowing the extra traffic to use the resource of the pro- tecting LSPs. However the resource sharing is limited to the LSPs between the same source-destination node pair. It is not addressed how to use the resource reserved for the protecting LSPs for extra traffic in case of the pre-planned LSP re-routing without extra-traffic (including shared mesh) recovery method in [e2e]. In 1:1 re-routing without Extra-Traffic, only the working LSP is fully instan- tiated during the provisioning phase and resources are reserved but not allocated for the protecting LSPs. The protecting LSP can not carry any extra-traffic because it is not instantiated. In the following example using network topology shown in in Fig.1, the working LSP0, which is routed along with the path [A,B,C,D], is pro- tected by the protecting LSP1, which is routed along with the path [A,E,F,G,D]. Bandwidth resources are allocated for only working LSP0. The protecting LSP1 is not instantiated (resources are not allocated for the protecting LSP1). Therefore, the protecting LSP1 can not carry any extra-traffic. However the resource reserved for LSP1 along with the path [A,E,F,G,D] could be used to instantiate extra class LSPs. PIL [Page 5] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 A---B---C---D \ / E---F---G / /\ \ H I J K Figure 1 For example the resource along with the path [A,E,F,G,D] could be used to instantiate the new extra class LSP along with the path [A,E,F,G,D]. In this case, resource sharing is allowed to the LSPs between the same source-destination node pair. Resource sharing between the different source-destination node pair is allowed as well. For example the resource along with the path [E,F] could be used to instantiate the LSP along with the path [H,E,F,J]. Similarly the resource along with the path [F,G] could be used to instantiate the LSP along with the path [I,F,G,K]. In this way, the resources reserved for the protecting LSPs could be allocated to extra class LSP with less constraint on the rout- ing in end-to-end 1:1 re-routing without extra-traffic (including shared mesh) recovery method. Here we mean by "less constraint on the routing" that the resource sharing is allowed between the different source-desti- nation node pair. 5. Extra class LSP service We define an extra class LSP. Extra class LSP makes use of the resources reserved but not allocated to the protecting LSPs in 1:1 re- routing without extra traffic (including shared mesh). By allowing resource sharing between the protecting LSPs and the extra class LSPs, the network utilization is improved with less routing constraint, i.e., the resource sharing is allowed for both between the different source- destination node pair and between the same source-destination node pair. Network utilization is therefore improved. We should note that resource reserved for the protecting LSP is used in this method while the conventional priority mechanism using setup and holding priorities uses the working resource. Lower priority traffic may be preempted if new higher priority traffic is set up. The proba- bility that the lower priority traffic is preempted depends on the traf- fic load of the higher priority traffic. On the other hand, the resource reserved for the protecting LSPs is preempted only if the work- ing LSP fails, which is usually expected to rarely happen. By using this resource, the extra class LSP is defined , which is less likely to PIL [Page 6] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 be preempted than the conventional priority mechanism when the higher priority traffic load is high. 6. Issues on extra class LSP 6.1. Advertisement of available resource The extra class LSP service uses the protecting resource. In order to route the extra class LSP, we need a mechanism to advertise the avail- able resource for the extra class LSP. The available resource for the extra class LSP is the resource , which is reserved but not allocated to the protecting LSPs. 6.2. Extra class LSP indication in signaling message The protecting resource is allocated to the extra class LSP. When the extra class LSP is set up, it should be indicated as extra class LSP in signaling message. We need a mechanism to indicate the extra class LSP in singaling message. 6.3. Extra class LSP preemption signaling When a working LSP fails, resources allocated to an extra class LSP may be preempted. Transit node detects the preemption of extra class LSP resource. The extra class LSP teardown procedure should be initiated by the transit node. We need to define the signaling method to tear down the extra class LSP , which is initiated by the transit node. In the conventional priority mechanism using setup and holding priori- ties, the packet oriented MPLS TE Soft Preemption mechanism could be used to re-route the preempted LSP [soft-preemption]. For packet ori- ented MPLS networks with Diffserv and TE capabilities, the MPLS TE Soft Preemption mechanism could be used to re-route the preempted LSP while avoiding disruption by allowing resource to be overbooked until the pre- empted LSP can be rerouted [soft-preemption]. So, the preempted LSP should not be torn down immediately and quickly in packet oriented net- work and we can choose a relatively slow procedure for the purpose form several options. Both packet oriented and circuit oriented switching technologies are used in GMPLS networks, the resource may not be shared between cross-connected LSPs (for example, the resource can not be PIL [Page 7] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 shared between cross-connected LSPs in TDM, LSC, and FSC networks). For circuit oriented in GMPLS network, overbooking mechanism cannot be applied because LSPs have strict association with network resources, such as lambdas or time slots. We need to define the signaling method to tear down the extra class LSP immediately and quickly, which is ini- tiated by the transit node. 6.4. Preventing Unintended Connections In 1:1 rerouting, switchover from a working LSP to a protecting LSP may cause an unintended connection to be established and traffic from the failed working path to be delivered to an extra class LSP instead of the protecting LSP. In Figure 2, for example, it is possible to have a working LSP, A-B-C-D, and a protecting LSP, A-E-F-D. Having an extra class LSP, G-E-F-H is also possible. This extra class LSP uses label X on link E-F. If the protecting LSP is established from node A to node F and label X is allocated to this LSP, the protecting LSP is unintention- ally connected to the extra class LSP for a short time until node F sets up a cross-connect for the protecting LSP. This can be prevented if the extra class LSP is released before the switchover occurs. B----C / \ A D \ / E----F / \ G H Figure 2 7. Solution using Diffserv-aware traffic engineering mechanism We describe the solution for Extra LSP service using Diffserv-aware traffic engineering mechanism as a "Tool-box". 7.1. Diffserv-aware traffic engieering Diffserv-aware traffic engineering (DSTE) MPLS is being developed [DSTE- REQ, DSTE-PROTO]. DSTE was originally developed for how to carry the Diffserv traffic over MPLS LSP traffic trunk. DSTE can be used for Extra LSP service. PIL [Page 8] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 DSTE introduced Class-Type (CT) as the set of traffic trunks crossing a link that is governed by a specific set of bandwidth constraints. CT is used for the purposes of link bandwidth allocation, constrain based routing and admission control. DSTE introduced TE-Class as a pair of Class-Type and a preemption priority allowed for that Class-Type. The preemption attributes defined in [TE-REQ] are retained with DS-TE and applicable within, and across, all Class Types. This means that if LSP1 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher set-up preemption priority than LSP2 holding preemption prior- ity regardless of LSP1 CT and LSP2 CT. Routing protocol (OSPF) is retained in DSTE. With DSTE, the existing "Unreserved Bandwidth" sub-TLV is retained as the only vehicle to adver- tise dynamic bandwidth information necessary for Constraint Based Rout- ing. The Unreserved Bandwidth sub-TLV carries eight bandwidth values but they now correspond to the unreserved bandwidth for each of the TE- Class (instead of for each preemption priority). Signaling protocol (RSVP) is extended to support Class Type (CT). CT and preemption carried in Session Attribute forms the TE-Class. Session (here session is LSP) admission control is based on comparison between unreserved resource for Class Type and resoure requested by the session. The unreserved bandwidth for the TE-class is advertised by OSPF and the head-end node therefore computes the route which is expected to have sufficient network resource. 7.2. Extra class LSP implementation We need the following mechanism implemented for the extra class LSP: (1) resource advertisement, (2) preemption in response to failure, and (3) prevention of preemption in normal state. In order to set up the Extra class LSP, the network resource must be sufficient along with the path. We need to find the appropriate route which supports the sufficient resource. When a failure occurs and the secondary LSP is accordingly activated, the resource for the Extra class LSP is preempted. However the resource for the Extra class LSP should not be preempted unless a failure occurs. It is possible that a new secondary LSP is established by sharing resources with Extra class LSPs. In this case, the existing Extra class LSPs must not be preempted by the secondary LSP. In order to implement the above mechanisms, we use the DSTE. We define the TE-class in the following way: PIL [Page 9] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 TE-Class[0] for Primary LSP : CT=CT1, setup priority = 0, holding priority = 0, TE-Class[1] for Secondary LSP: CT=CT0, setup priority = 0, holding priority = 0, TE-Class[2] for Extra LSP: CT=CT0, setup priority = 0, holding priority = 1. The unreserved bandwidth for each of TE-class is advertised by OSPF. The Extra class LSP is preempted in response to the activation of the secondary LSP because the setup priority of the secondary LSP is higher than the holding priority of the Extra class LSP. The Extra class LSP is not preempted when the primary LSP is set up because different Class- Types are used for the primary LSP and the Extra class LSP. The Extra class LSP is not preempted when the secondary LSP is provisioned. The Extra class LSP is preempted when the secondary LSP is instantiated because the setup priority of the secondary LSP is higher than the hold- ing priority of the Extra class LSP. We should note that the setup of the secondary LSP is defined to be the instant the secondary LSP is instantiated (not the instant the secondary LSP is provisioned for resource reservation). We should also note that the bandwidth con- straint model should be MAM [MAM]. That is the bandwdith constraint should be defined in the following manner: Reserved (CTc) <= BCc <= Max-Reservable-Bandwidth, for each value of c in the range 0 <= c <= (MaxCT - 1) SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth, where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1) "Unreserved TE-Class [i]" = MIN [ [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p , [ Max-Res-Bw - SUM (Reserved(CTb,q)) ] for q <= p and 0 <= b <= 7, ] where: TE-Class [i] <--> < CTc , preemption p> in the configured TE-Class mapping. 8. Conclusions This document proposes the extra class LSP service using the resource reserved but not allocated for the protecting LSP at the provisioning phase in case of the pre-planned LSP re-routing without extra-traffic PIL [Page 10] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 (including shared mesh) recovery method. Network utilization is improved because the resource reserved for the protecting LSPs are used for the extra class LSPs. The extra class LSP is preempted less fre- quently than the conventional priority mechanism using setup and holding priorities because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. This document addresses the issues on the extra class LSP: (1) adver- tisement of available resource, (2) extra class LSP indication in sig- naling message (3) extra class LSP preemption signaling, and (4) pre- venting unintended connections. The solution based on DSTE is pre- sented. With DSTE, we define the TE-class in the following way: TE-Class[0] for Primary LSP : CT=CT1, setup priority = 0, holding priority = 0, TE-Class[1] for Secondary LSP: CT=CT0, setup priority = 0, holding priority = 0, TE-Class[2] for Extra LSP: CT=CT0, setup priority = 0, holding priority = 1. The above-mentioned TE-class implements the following mechanisms for the Extra class LSP: (1) resource advertisement, (2) preemption in response to failure, and (3) prevention of preemption in normal state. 9. Security considerations Security issues are not discussed in this draft. 10. Reference [FUNCT] J. P. Lang and B. Rajagopalan (Editors), "Generalized MPLS recovery functional specification," Internet draft, Work in progress, draft-ietf-ccamp-gmpls-recovery-functional-00.txt, January 2002. [e2e] J. P. Lang and Y. Rekhter (Editors), "RSVP-TE extensions in sup- port of end-to-end GMPLS-based recovery," Internet draft, Work in progress, draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt, May 2003. [soft-preemption] M. R. Meyer, D. Maddux, and J.-P. Vasseur, "MPLS Traf- fic Engineering Soft preemption," Internet draft, Work in progress, draft-ietf-mpls-soft-preemption-00.txt, February, 2003. [DSTE-REQ] "Requirements for support of differentiated services-aware PIL [Page 11] PIL draft-pil-ccamp-extra-lsp-01.txt June 23 2003 MPLS traffic engineering," RFC 3564 [DSTE-PROTO] "Protocol extensions for support of diff-serv-aware MPLS traffic engineerin," Internet draft, Work in progress, draft-ietf-tewg- diff-te-proto-04.txt, [MAM] "Maximum allocation bandwidth constraints model for diff-serv- aware MPLS traffic engineering," Internet draft, Work in progress, draft-ietf-tewg-diff-te-mam-00.txt, PIL [Page 12]