Internet Draft Network Working Group Li Mo Internet Draft Fujitsu Network Multi-Protocol Label Switching Communications Expiration Date: December 2001 July 2000 General Considerations for Bandwidth Reservation in Protection draft-mo-mpls-protection-00.txt 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 docu- ments 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: Protection issues for MPLS LSP have been discussed in recent IETF meetings. Various drafts have different proposals on establishing the working and protection LSP ([1]-[5]). But how to reserve bandwidth for the protection LSP has not be discussed. If the bandwidth for the protection LSP is reserved in a similar fashion as that of the working LSP, the bandwidth utilization in the network would be very poor. In this draft, an algorithm for reserve bandwidth for protection LSP is presented which enables very efficient bandwidth reservation for single fault protection. Mo Expire December, 2000 1 1.0 Specification of Requirements 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. 2.0 Overview For all the protection schemes in the MPLS context, two LSPs are established, a working LSP and a protection LSP. Those two LSPs are normally disjoint in order to protect a single nodal failure along the path. How to establishing such paths has been discussed a number of contributions (e.g. [1],[3]). If the bandwidth for the protection LSP is reserved similar to that of the working LSP, the overall bandwidth efficiency of the network would be very low. In this case, it is akin to the bandwidth efficiency of the USPR in SONET environment, which would be very poor. In order to make efficient bandwidth reservation, the fact that the protection path is to protect single nodal failure has to be utilized. In this case, the following factors have to be considered when reservation for protection bandwidth is to be made: ò the bandwidth required for protecting the working LSP, which can be the same traffic descriptor (e.g. T-SPEC, R-SPEC, AD- SPEC in RSVP terms) for the working LSP. ò the set of nodes (or links if only single link failure is to be con- sidered) which the working LSP travois. This information will be used by the nodes on either the working or the protection LSP. The algorithm developed in this draft can be used when bandwidth reservation is required for the protection LSP Mo Expire December, 2000 2 3.0 Bandwidth Reservation Algorithm For any node, denoted as node 'X', it will be responsible for bandwidth reservation calculations on all its egress links. For any particular egress link 'L' on node 'X', if additional bandwidth reservation is required for working traffic, the new reservation will be added to the existing reservation, which will be used as input to the CAC (Connection Admission Control). For any particular egress link 'L' on node 'X', if additional bandwidth reservation is required for protection traffic, the node 'X' has the following factor to considered in order to derive a bandwidth requirement for link 'L' for CAC purposes: ò the total working bandwidth reserved on the egress link 'L' on node 'X' ò for any other node 'Y' inside the network, if 'Y' failed, the amount of bandwidth which will disappear on link 'L' of the node 'X' ò for any other node 'Y' inside the network, if 'Y' failed, the amount of bandwidth which will appear on link 'L' of node 'X' due to protection switch It is obvious that the total working bandwidth on link 'L' on node 'X' is required as CAC input and is denoted as W(L,X). In addition to the W(L,X), for each node 'Y' in side the network where link 'L' on node 'X' is providing either working traffic and protec- tion traffic, there will be a record on node 'X' for link 'L'. This record will have the following two kinds of information ò amount of traffic which will disappear if the node 'Y' failed, noted as D(Y|L,X) ò amount of traffic which will appear if the node 'Y' failed, noted as P(Y|L,X) Mo Expire December, 2000 3 The amount of the bandwidth required for protection, for single nodal failure inside the network, would be the 'max (0, max of P(Y|L,X)- D(Y|L,X))' for 'all the node Y' inside the network which link 'L' of node 'X' is providing either the working or the protection traffic. The required bandwidth would be denoted as P(L,X). The amount of bandwidth requirement for CAC purposes, for single node failure case, would be W(L,X) + P(L,X) Signaling protocol (either CR-LDP or RSVP-TE) needs to be improved to convey the following information in order to establish the D(Y|L,X) and P(Y|L,X). ò list of node IDs (router IDs) where the working LSP traverse ò nature of the setup signaling, either working LSP setup or the protection LSP setup The W(L,X) will be updated when bandwidth reservation is required for working LSP. This is performed during the processing of the working LSP setup if CAC approves such LSP. The D(Y|L,X) will be updated whenever bandwidth reservation is required for the working LSP if all the node 'Y' which is upstream to node 'X' regarding this LSP. This is also performed as part of the working LSP setup. The P(Y|L,X) will be updated when bandwidth reservation is required for establishing the protection LSP for all the node 'Y' in the working LSP. This is part of the protection LSP setup. The P(L,X) can be evaluated once P(Y|L,X) for all node 'Y' in the working LSP is updated by using the information inside the setup message. Mo Expire December, 2000 4 This algorithm does not require any node to have the complete bandwidth reservation picture inside the network. Any nodes will only store the information when it is part of the working or the protection LSP. This algorithm can also be extended to cover multiple faults inside the network for efficient bandwidth reservation and such extensions will not be pursued here. 4.0 Security Considerations Security consideration for this algorithm is similar to that of the CR- LDP. Extension to CR-LDP can be used to distribute the information required for the efficient bandwidth reservation. 5.0 Acknowledgments Thanks for Indra Widjaja, David Wynn, George Bucklin, Ed Sul- liven for their comments. 6.0 References [1] "Protection/Restoration of MPLS networks", S. Makam, et al, draft- makam-mpls-protection-00.txt, 10/1999 [2] "Framework for MPLS Based Recovery", S. Makam, et al, draft- makam-mpls-recovery-frmwrk-00.txt, 03/2000 [3] "A Path Protection/Restoration Mechanism for MPLS Networks", Changcheng Huang, et al, draft-chang-mpls-path-protection- 00.txt, 03/2000 [4] "Requirements for OAM Functionality in MPLS", T. Theimer, J. Klink, draft-theimer-mpls-oam-requ-00.txt, 10/1999 [5] "Extensions to RSVP-TE for MPLS Path Protection", Changcheng Huang, Vishal Sharma, Srinivas Makam, Ken Owens, draft- chang- mpls-rsvpte-path-protection-ext-00.txt, 06/2000 7.0 Author Information Li Mo Fujitsu Network Communications 2801 Telecom Parkway Richardson, TX 75024 email: li.mo@fnc.fujitsu.com Mo Expire December, 2000 5