INTERNET-DRAFT T. Yagyu Y. Suemura Expires in November 2002 A. Kolarov NEC Corporation May 2002 Extensions to OSPF-TE for supporting shared mesh restoration 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. Abstract Shared mesh restoration technique efficiently uses network resources since restoration capacity is shared across multiple independent failures. In this scheme, when a new working LSP is established, its corresponding backup LSP is pre-calculated and resources along the restoration route are reserved. The resources reserved on each link along the restoration path may be shared across different working LSPs that are not expected to fail simultaneously. To make the method for selection of backup LSPs more efficient in terms of utilization of network resources, each link should provide the route calculator with information about its restoration capacity and SRLGs of working LSPs whose backup LSPs share the link restoration capacity. In this document we propose extensions to OSPF-TE in support of carrying link "Sharable Bandwidth" information. T. Yagyu et al. [Page 1] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 1. Summary for Sub-IP Area 1.1. Summary This document specifies extensions to the OSPF-TE routing protocol with GMPLS extensions [2] for supporting shared mesh restoration. 1.2. Where does it fit in the picture of the Sub-IP Work This work fits in the CCAMP. 1.3. Why is it targeted at this WG This draft is targeted at the CCAMP WG, because this draft specifies the extensions to the OSPF-TE to support shared mesh restoration in the GMPLS network. Protection and restoration in the GMPLS network is within the scope of the CCAMP WG. 1.4. Justification The WG should consider this document as it specifies the extensions to the OSPF routing protocols in support of shared mesh restoration in the GMPLS network. 2. Introduction Shared mesh restoration is the efficient technique in transport networks for rapid restoration and resource optimization [1], since resources reserved for restoration of failure disjoint working paths can be shared on the common links of their restoration paths. The GMPLS routing extensions document [2] defines several attributes for a TE-Link. One of them is the available link bandwidth, which is advertised as Unreserved Bandwidth. However, no attribute is used to advertise the link bandwidth that is reserved for backup LSPs protecting working LSPs that support shared mesh restoration. In order to efficiently use restoration capacity in transport networks, an additional link attribute should be defined to carry information about link restoration capacity used for shared mesh restoration. Each link in the network should provide the route calculator with information about available link bandwidth per SRLG that can be used for shared mesh restoration of other working LSPs. We call this bandwidth "Sharable Bandwidth". This document proposes an extension to OSPF-TE specified in [3][4] enabling advertisement of the "Sharable Bandwidth". 3. Route Calculation for Shared Mesh Restoration T. Yagyu et al. [Page 2] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 Since the main goal of shared mesh restoration is the resource optimization, the performance of a route calculation scheme is measured by the degree of sharing of link restoration capacity across backup LSPs. From this point of view, the more backup LSPs share the same restoration bandwidth the better a route calculation scheme is. In order to calculate the best route for a backup LSP, the route calculator must have information for each link about sharable bandwidth per SRLG that can be shared across backup LSPs. The details of the sharable bandwidth are described in Section 4. The concept of sharable bandwidth can be simply illustrated using the topology depicted in Figure 1. We consider an LSP established between node A and node B and its restoration (backup) LSP along the route A- C-D-B. The working LSP traverses SRLG #1, and thus, the links along the backup LSP (A-C, C-D and D-B) have sharable bandwidth for all SRLGs except SRLG #1. We also consider another working LSP established between node E and node F, which traverses SRLG #2. In the given topology, a backup LSP for the working LSP E-F can be established along either route E-C-D-F or route E-G-H-F. The links along the working paths do not share any common failure (LSP A-B traverses SRLG #1 and LSP E-F traverses SRLG #2), and therefore, if a service provider wishes to guarantee recovery from any single failure event, the backup paths can share the same restoration bandwidth on link C-D. In terms of efficient resource optimization, reserving the backup LSP along the route E-C-D-F is better choice than along the route E-G-H-F, in which case restoration capacity is not shared across the backup LSPs. In order to select the backup LSP along the route E-C-D-F instead of route E-G-H-F, the route calculator should have information about the sharable bandwidth on link C-D. +---+ SRLG #1 +---+ | A |----------------------| B | +---+ +---+ | | +---+ +---+ | C |----------------------| D | +---+ +---+ | | +---+ SRLG #2 +---+ | E |----------------------| F | +---+ +---+ | | +---+ +---+ | G |----------------------| H | +---+ +---+ Figure 1 T. Yagyu et al. [Page 3] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 4. Sharable Bandwidth Sharable bandwidth on a TE link is the available bandwidth that can be reserved for shared mesh restoration of working LSPs. In general, reserved link bandwidth can be divided as follows: bandwidth reserved for working LSPs, bandwidth reserved for backup LSPs supporting 1+1 protection scheme, bandwidth reserved for backup LSPs supporting 1:1 restoration scheme and bandwidth reserved for backup LSPs supporting shared mesh restoration. Figure 2 shows how total link bandwidth that is available for reservation can be divided across working and backup LSPs supporting different restoration mechanisms. Sharable bandwidth is defined per SRLG. For a given SRLG, the sharable bandwidth represents the available link restoration capacity that can be used for shared mesh restoration of working LSPs traversing the given SRLG. When a backup LSP for the working LSP traversing one or more SRLGs is reserved on a given link, the sharable bandwidth for all corresponding SRLGs is reduced by the amount of the reserved bandwidth. Maximum sharable bandwidth is defined as the maximum value of the sharable bandwidth among all SRLGs. Total BW available for reservation |----------------------------------------------------------------| |<---------->|<---------->|<--------->|<----------->|<---------->| | reserved | reserved | reserved | reserved | unreserved | for for 1+1 for 1:1 | for shared | working LSPs protection restoration| restoration | | | |<----------->| Maximum Sharable Bandwidth Figure 2 In Figure 3, we consider a 100 Mbps LSP established from node A to node C (PATH #1) and protected by shared mesh restoration. The working LSP is established along the route A-B-C, and the backup LSP is established along the route A-D-E-F-C. The working path traverses link A-B that belongs to SRLG #1 and link B-C that belongs to SRLG #2. During the signaling procedure when the backup LSP is established, the restoration capacity for the backup LSP is reserved on each link of the route (A-D, D-E, E-F and F-C). Since the working path traverses SRLG #1 and SRLG #2, the sharable bandwidth for both SRLGs is reduced by the amount of the reserved bandwidth (100 Mbps). Note that this restoration capacity is used to protect the working path A-B-C in case of any single SRLG failure. Figure 4 shows the bandwidth reserved for the shared mesh restoration on link D-E. Since T. Yagyu et al. [Page 4] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 in Figure 4 the reserved bandwidth for the backup LSP is equal to the maximum sharable bandwidth (100 Mbps), it follows that no more backup LSPs whose working LSPs traverse either SRLG #1 or SRLG #2 can be reserved on links A-D, D-E, E-F and F-C. But, the restoration capacity on these links can be used for working paths traversing all other SRLGs. Next, we consider a 50 Mbps path established from node G to node I (PATH #2). The working LSP is established along the route G-H-I, and it traverses SRLG #3 and SRLG #4. The backup LSP is established along the route G-D-E-F-I. Figure 5 shows the bandwidth reserved for shared mesh restoration on link D-E after PATH #2 is established. Last, we consider a 10 Mbps path established from node G to node H (PATH #3). The working LSP is established along the route G-H, and it traverses only SRLG #3. The backup LSP is established along the route G-D-E-H. Figure 6 shows the bandwidth reserved for shared mesh restoration on link D-E after PATH #3 is established. +---+ SRLG #1 +---+ SRLG #2 +---+ | A |-----------| B |-----------| C | +-+-+ +---+ +-+-+ | | +-+-+ +---+ +-+-+ | D |-----------| E |-----------| F | +-+-+ +-+-+ +-+-+ | | | +-+-+ SRLG #3 +-+-+ SRLG #4 +-+-+ | G |-----------| H |-----------| I | +---+ +---+ +---+ Figure 3 BW reserved for shared mesh restoration Max Sharable BW |<----------------- 100M ------------------>| for SRLG #1 |<-reserved 100M--------------------------->| for SRLG #2 |<-reserved 100M--------------------------->| Figure 4 BW reserved for shared mesh restoration Max Sharable BW |<----------------- 100M ------------------>| for SRLG #1 |<-reserved 100M--------------------------->| for SRLG #2 |<-reserved 100M--------------------------->| for SRLG #3 |<-reserved 50M----->|<--sharable 50M------>| for SRLG #4 |<-reserved 50M----->|<--sharable 50M------>| Figure 5 T. Yagyu et al. [Page 5] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 BW reserved for shared mesh restoration Max Sharable BW |<----------------- 100M ------------------>| for SRLG #1 |<-reserved 100M--------------------------->| for SRLG #2 |<-reserved 100M--------------------------->| for SRLG #3 |<-reserved 60M---------->|<-sharable 40M-->| for SRLG #4 |<-reserved 50M----->|<--sharable 50M------>| Figure 6 5. Extensions to OSPF-TE Kompella et al. proposed the GMPLS routing protocol extensions in [2] and [4]. In this draft, we propose a new TLV, called Sharable Bandwidth TLV, which is used to advertise the Sharable Bandwidth. The Sharable Bandwidth TLV is a sub-TLV of the Link TLV. The format of the Sharable Bandwidth TLV is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| 0 | SRLG # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sharable bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG 1 (Optional, if M is set) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG n (Optional, if M is set) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T. Yagyu et al. [Page 6] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 Type The type of this sub-TLV is TBD. Length The length is variable. M bit If the M bit is set (M = 1), each field in an ordered list of 32 bit numbers represents the maximum sharable bandwidth per priority. If the M bit is not set (M = 0), each field represents the sharable bandwidth per priority for the SRLGs that are specified in the optional list of 32 bit numbers. The SRLG fields are mandatory in case of M = 0, SRLG # This is the number of SRLGs for which the sharable bandwidth is specified. If no information about SRLGs is included, this field must be set to 0. Sharable bandwidth at priority 0-7 This field contains the sharable bandwidth per priority given in the IEEE floating-point format. If the M bit is not set, it includes the sharable bandwidth per priority that can be reserved for the SRLGs in the optional list. If the M bit is set, this field represents the maximum sharable bandwidth per priority. SRLG 1-n If the M bit is not set, these fields contain SRLGs for which information about the sharable bandwidth per priority is available. If the M bit is set, these fields are optional. If fields exist, they include SRLGs whose sharable bandwidth is equal to zero or is less than max sharable bandwidth (see Section 6). Note that these fields have different meanings based on the value of the M bit. 6. Scalability To simultaneously advertise the maximum sharable bandwidth and sharable bandwidth for each SRLG, a Link TLV should have multiple sharable bandwidth sub-TLVs. However, to keep size of the appropriate TE-LSA small, only the maximum sharable bandwidth may be advertised. Advertising maximum sharable bandwidth only may cause the route calculator to select a route on which bandwidth for a backup path cannot be reserved. This scenario is possible because the maximum sharable bandwidth in most cases does not represent the actual amount of bandwidth that can be shared per SRLG. As a result, signaling will fail or crank back. T. Yagyu et al. [Page 7] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 If signaling failures are not acceptable, all SRLGs whose sharable bandwidth is less than the maximum sharable bandwidth should be included in the optional list of the Sharable Bandwidth TLV. This prevents the route calculator to use links that do not have enough bandwidth for a backup LSP. The network administrator can decide this according to policy. 7. Example of Sharable Bandwidth TLV We consider the example in Figure 6, and scenario in which the maximum sharable link bandwidth is advertised only. Thus, the Link- TLV has one Sharable Bandwidth sub-TLV with the following parameters: -------------------------------------- M bit = 1 SRLG # = 2 Sharable Bandwidth at priority 0 = 100M . . . Sharable Bandwidth at priority 7 = 100M SRLG #1 SRLG #2 ------------------------------------ Note that both SRLG #1 and SRLG #2 are optionally advertised since their corresponding sharable bandwidth is equal to zero. In case when sharable bandwidth for each SRLG is advertised, the Link-TLV has two separate Sharable Bandwidth sub-TLVs with the following parameters: ----------------------------- M bit = 0 SRLG # = 1 Sharable Bandwidth at priority 0 = 40M . . . Sharable Bandwidth at priority 7 = 40M SRLG #3 ----------------------------- M bit = 0 SRLG # = 1 Sharable Bandwidth at priority 0 = 50M . . . Sharable Bandwidth at priority 7 = 50M SRLG #4 ----------------------------- Note that it is necessary to advertise two separate Sharable Bandwidth sub-TLVs since the values for the corresponding sharable T. Yagyu et al. [Page 8] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 bandwidth are different (40 Mbps and 50 Mbps). In contrast, in the example in Figure 5 the sharable bandwidth for both SRLG #3 and SRLG #4 is 50 Mbps, and thus, only one Sharable Bandwidth sub-TLV is needed: -------------------------------- M bit = 0 SRLG # = 2 Sharable Bandwidth at priority 0 = 50M . . . Sharable Bandwidth at priority 7 = 50M SRLG #3 SRLG #4 ----------------------------- 8. Related work The extensions to RSVP-TE for supporting multiple protection and restoration types are described in [5]. These protocol extensions include signaling for shared mesh restoration. 9. Security Considerations No security issues are considered in this document. References [1] G. Li et al., "RSVP-TE Extensions For Shared-Mesh Restoration in Transport Networks", draft-li-shared-mesh-restoration-01.txt, work in progress. [2] K. Kompella et al, "Routing Extensions in Support of Generalized MPLS", draft-ietf-ccamp-gmpls-routing-03.txt, work in progress. [3] D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-06.txt, work in progress. [4] K. Kompella et al, "OSPF Extensions in Support of Generalized MPLS", draft-ccmp-ospf-gmpls-extensions-03.txt, work in progress. [5] Y. Suemura et al, "Extensions to RSVP-TE for Supporting Multiple Protection and Restoration Types", draft-suemura-gmpls-restoration- signaling-00.txt, work in progress. Authors' Addresses Tomohiko Yagyu NEC Corporation T. Yagyu et al. [Page 9] draft-yagyu-gmpls-shared-restoration-routing-00 Expires November 2002 11-5, Shibaura 2-chome, Minato-ku, Tokyo, 108-6557, Japan Phone: +81-3-5476-1071 Email: yagyu@cp.jp.nec.com Yoshihiko Suemura NEC Corporation 4-1-1, Miyazaki, Miyamae-ku, Kawasaki, 216-8555, Japan Phone: +81-44-856-8109 Email: y-suemura@bp.jp.nec.com Aleksandar Kolarov NEC USA, Inc. 4 Independence Way, Princeton, NJ 08540, USA Phone: +1-609-951-2985 Email: kolarov@nec-lab.com T. Yagyu et al. [Page 10]