CCAMP Working Group Katsuhiro Shimano (NTT) Internet Draft Kohei Shiomoto (NTT) Expiration Date: June 2004 Yoshihiko Suemura (NEC) February 2004 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 because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. The extra class LSP can be combined with the priority class service. This document addresses the issues on the extra class LSP: (1) advertisement of available resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption PIL [Page 1] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 signaling, and (4) preventing unintended connections. 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 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 PIL [Page 2] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 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. 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 PIL [Page 3] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 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. 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. PIL [Page 4] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 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. 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 PIL [Page 5] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 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 stress the difference between the extra class LSP and the pri- ority service. The priority service consists of different priority classes. For example Gold, Silver, and Bronze classes are defined (Gold class has the highest priority). We call hereafter it GSB service. In GSB service, lower priority classes (Silver or Bronze) may be preempted if the higher class (Gold) is set up. The preemption of the lower pri- ority class depends on the traffic volume of other higher priority classes. The priority service can be implemented using setup and hold- ing priority indication in signaling message [RFC2702, RFC3473]. On the other hand, the service preemption of the extra class LSP does not depend on the traffic volume of other classes. The Extra class LSP uses the resource reserved for the protecting LSPs. The resource for the extra class LSP is preempted only when the working LSP fails, which is expected to rarely occur. In GSB service, each priority class could have high availability sub- class, which is implemented by shared mesh restoration mechanism. Fig- ure shows the resource map in GSB service. The resource reserved by protecting LSPs in all priority classes could be used for the extra class LSP. The resource for the extra class LSP could be preempted if the either of following conditions happens: (1) Protecting LSP is instantiated. (2) Higher priority class working LSP is set up. PIL [Page 6] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 +-----------++-----------+-------------------+ | || Working | Protecting | +-----------++-----------+-------------------+ | Gold || | | +-----------++-----------| Resource | | Silver || | used for | +-----------++-----------| Extra class LSP | | Bronze || | | +-----------++-----------+-------------------+ Figure Resource map for GSB service. The above-mentioned resource used for the extra class LSP is not uniform characteristics. For example the resource reserved by Silver protecting LSPs may be preempted by Gold Working LSP while the resource reserved by Gold protecting LSPs may not be preempted by it. Resource for the Extra class LSP could be partitioned into three classes for differentiation. Figure shows the resource map in GSB service when the extra class LSP is further classified according to the corresponding priority class. +-----------++-----------+-------------------+ | || Working | Protecting | +-----------++-----------+-------------------+ | Gold || | Gold Extra | +-----------++-----------+-------------------+ | Silver || | Silver Extra | +-----------++-----------+-------------------+ | Bronze || | Bronze Extra | +-----------++-----------+-------------------+ Figure Resource map for GSB service. 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. PIL [Page 7] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 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 from 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 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 PIL [Page 8] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 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 A-B-C-D: Primary LSP A-E-F-D: Secondary LSP G-E-F-H: Extra (preemptable) LSP Figure 2 The unintended connection can be avoided by using a two-way activation scheme. The two-way activation scheme uses Path message to delete the cross-connection of the extra LSP while Resv message to activate the cross-connection of the protecting LSP. Node A sends Path message to node D to activate the protecting LSP. The Path message deletes the cross-connections of the extra LSP at nodes E and F. Once node D receives the Path message, it sends back Resv message to node A. The Resv message activates the cross-connections of the protecting LSP at nodes E and F. In this way the protecting LSP is established after the extra LSP is deleted and therefore the unintended connection can be avoided. Even though the above mentioned two-way scheme avoids the unintended connection in most case, it does not completely avoid the unintended connection when it mistakenly interprets a refresh Resv message as the one used in the two-way scheme. Consider the following case: (1) At node E, a cross-connection for the extra LSP is deleted when receiving the Path message for activation. (2) Then, if node E receives a refresh Resv message from F, it sets up a cross-connection for the protecting LSP because it cannot distinguish the refresh Resv message from the Resv message for activation. If this occurs before F deletes a cross-connection for the extra LSP, it causes unintended connection between the protecting LSP and the extra LSP. This problem may often occur when the number of hops increases or when PIL [Page 9] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 the interval of refresh message gets shorter. Unintended connection could violate confidentiality of user traffic and therefore is consid- ered to a serious problem. The above mentioned problem can be avoided by allowing the Resv message to carry Protection object because Resv message for activation is distinguished from a refresh Resv message by watching the S bit in the protection object. In the 1:1/Shared Mesh Restoration described in [e2e], protection object is carried only in a Path message (assuming that activation of a secondary LSP is done only by a Path message). As mentioned above, Protection object should be carried in Resv message so as to avoid unintended connection. 7. 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 (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. 8. Security considerations Security issues are not discussed in this draft. 9. 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. PIL [Page 10] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 [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-02.txt, Septem- ber 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 MPLS traffic engineering," RFC 3564 [DSTE-PROTO] "Protocol extensions for support of diff-serv-aware MPLS traffic engineering," 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, 10. Appendix: Solution using Diffserv-aware traffic engineering mecha- nism We describe the solution for Extra LSP service using Diffserv-aware traffic engineering mechanism as a "Tool-box". 10.1. Diffserv-aware traffic engineering 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. 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 PIL [Page 11] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 advertise dynamic bandwidth information necessary for Constraint Based Routing. The Unreserved Bandwidth sub-TLV carries eight bandwidth val- ues 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 resource requested by the ses- sion. 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. 10.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: 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 PIL [Page 12] PIL draft-pil-ccamp-extra-lsp-02.txt February 2004 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 bandwidth 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. PIL [Page 13] .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF PIL .ds RF [Page %] .ds CF .ds LH PIL .ds RH February 2004 .ds CH draft-pil-ccamp-extra-lsp-02.txt .hy 0 .ad l .in 0 .nf CCAMP Working Group Katsuhiro Shimano (NTT) Internet Draft Kohei Shiomoto (NTT) Expiration Date: June 2004 Yoshihiko Suemura (NEC) February 2004 .ce Extra class LSP service using protecting resources in GMPLS networks .ti 0 Status of this Memo .fi .in 3 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. .ti 0 Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. .SH Abstract .LP 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 because the resource reserved for the protecting LSPs is allocated only if the working LSP fails, which is usually expected to rarely occur. The extra class LSP can be combined with the priority class service. This document addresses the issues on the extra class LSP: (1) advertisement of available resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption signaling, and (4) preventing unintended connections. .NH Author information .LP This document is the product of the following authors collaboration. .nf 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 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 .NH 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. .NH Introduction .LP 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-traffic), 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. .LP 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 provisioning 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 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 available resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption signaling, and (4) preventing unintended connections. .NH Problem statement .LP [e2e] addresses LSP protection with extra-traffic (including 1:1 protection 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. .LP 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 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 utilization by allowing the extra traffic to use the resource of the protecting LSPs. However the resource sharing is limited to the LSPs between the same source-destination node pair. .LP 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 instantiated 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. .LP 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 protected 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. .KS A---B---C---D \\ / E---F---G / /\\ \\ H I J K Figure 1 .KE .LP 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 routing 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-destination node pair. .NH Extra class LSP service .LP 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. .LP We should stress the difference between the extra class LSP and the priority service. The priority service consists of different priority classes. For example Gold, Silver, and Bronze classes are defined (Gold class has the highest priority). We call hereafter it GSB service. In GSB service, lower priority classes (Silver or Bronze) may be preempted if the higher class (Gold) is set up. The preemption of the lower priority class depends on the traffic volume of other higher priority classes. The priority service can be implemented using setup and holding priority indication in signaling message [RFC2702, RFC3473]. On the other hand, the service preemption of the extra class LSP does not depend on the traffic volume of other classes. The Extra class LSP uses the resource reserved for the protecting LSPs. The resource for the extra class LSP is preempted only when the working LSP fails, which is expected to rarely occur. .LP In GSB service, each priority class could have high availability sub-class, which is implemented by shared mesh restoration mechanism. Figure shows the resource map in GSB service. The resource reserved by protecting LSPs in all priority classes could be used for the extra class LSP. The resource for the extra class LSP could be preempted if the either of following conditions happens: (1) Protecting LSP is instantiated. (2) Higher priority class working LSP is set up. .KS +-----------++-----------+-------------------+ | || Working | Protecting | +-----------++-----------+-------------------+ | Gold || | | +-----------++-----------| Resource | | Silver || | used for | +-----------++-----------| Extra class LSP | | Bronze || | | +-----------++-----------+-------------------+ Figure Resource map for GSB service. .KE The above-mentioned resource used for the extra class LSP is not uniform characteristics. For example the resource reserved by Silver protecting LSPs may be preempted by Gold Working LSP while the resource reserved by Gold protecting LSPs may not be preempted by it. Resource for the Extra class LSP could be partitioned into three classes for differentiation. Figure shows the resource map in GSB service when the extra class LSP is further classified according to the corresponding priority class. .KS +-----------++-----------+-------------------+ | || Working | Protecting | +-----------++-----------+-------------------+ | Gold || | Gold Extra | +-----------++-----------+-------------------+ | Silver || | Silver Extra | +-----------++-----------+-------------------+ | Bronze || | Bronze Extra | +-----------++-----------+-------------------+ Figure Resource map for GSB service. .KE .NH Issues on extra class LSP .NH 2 Advertisement of available resource .LP The extra class LSP service uses the protecting resource. In order to route the extra class LSP, we need a mechanism to advertise the available 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. .NH 2 Extra class LSP indication in signaling message .LP 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. .NH 2 Extra class LSP preemption signaling .LP 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. .LP In the conventional priority mechanism using setup and holding priorities, the packet oriented MPLS TE Soft Preemption mechanism could be used to re-route the preempted LSP [soft-preemption]. For packet oriented 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 preempted LSP can be rerouted [soft-preemption]. So, the preempted LSP should not be torn down immediately and quickly in packet oriented network and we can choose a relatively slow procedure for the purpose from 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 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 initiated by the transit node. .NH 2 Preventing Unintended Connections .LP 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 unintentionally 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. .KS B----C / \\ A D \\ / E----F / \\ G H A-B-C-D: Primary LSP A-E-F-D: Secondary LSP G-E-F-H: Extra (preemptable) LSP Figure 2 .KE The unintended connection can be avoided by using a two-way activation scheme. The two-way activation scheme uses Path message to delete the cross-connection of the extra LSP while Resv message to activate the cross-connection of the protecting LSP. Node A sends Path message to node D to activate the protecting LSP. The Path message deletes the cross-connections of the extra LSP at nodes E and F. Once node D receives the Path message, it sends back Resv message to node A. The Resv message activates the cross-connections of the protecting LSP at nodes E and F. In this way the protecting LSP is established after the extra LSP is deleted and therefore the unintended connection can be avoided. Even though the above mentioned two-way scheme avoids the unintended connection in most case, it does not completely avoid the unintended connection when it mistakenly interprets a refresh Resv message as the one used in the two-way scheme. Consider the following case: (1) At node E, a cross-connection for the extra LSP is deleted when receiving the Path message for activation. (2) Then, if node E receives a refresh Resv message from F, it sets up a cross-connection for the protecting LSP because it cannot distinguish the refresh Resv message from the Resv message for activation. If this occurs before F deletes a cross-connection for the extra LSP, it causes unintended connection between the protecting LSP and the extra LSP. This problem may often occur when the number of hops increases or when the interval of refresh message gets shorter. Unintended connection could violate confidentiality of user traffic and therefore is considered to a serious problem. The above mentioned problem can be avoided by allowing the Resv message to carry Protection object because Resv message for activation is distinguished from a refresh Resv message by watching the S bit in the protection object. In the 1:1/Shared Mesh Restoration described in [e2e], protection object is carried only in a Path message (assuming that activation of a secondary LSP is done only by a Path message). As mentioned above, Protection object should be carried in Resv message so as to avoid unintended connection. .NH Conclusions .LP 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 (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. .LP This document addresses the issues on the extra class LSP: (1) advertisement of available resource, (2) extra class LSP indication in signaling message (3) extra class LSP preemption signaling, and (4) preventing unintended connections. .NH Security considerations .LP Security issues are not discussed in this draft. .NH Reference .LP [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 support of end-to-end GMPLS-based recovery," Internet draft, Work in progress, draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt, September 2003. [soft-preemption] M. R. Meyer, D. Maddux, and J.-P. Vasseur, "MPLS Traffic 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 MPLS traffic engineering," RFC 3564 [DSTE-PROTO] "Protocol extensions for support of diff-serv-aware MPLS traffic engineering," 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, .NH Appendix: Solution using Diffserv-aware traffic engineering mechanism .LP We describe the solution for Extra LSP service using Diffserv-aware traffic engineering mechanism as a "Tool-box". .NH 2 Diffserv-aware traffic engineering .LP 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. .LP 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. .LP 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 priority regardless of LSP1 CT and LSP2 CT. .LP Routing protocol (OSPF) is retained in DSTE. With DSTE, the existing "Unreserved Bandwidth" sub-TLV is retained as the only vehicle to advertise dynamic bandwidth information necessary for Constraint Based Routing. 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). .LP 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 resource 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. .NH 2 Extra class LSP implementation .LP 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. .LP In order to implement the above mechanisms, we use the DSTE. We define the TE-class in the following way: .KS 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. .KE 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 holding 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 constraint model should be MAM [MAM]. That is the bandwidth constraint should be defined in the following manner: .KS 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. .KE