INTERNET DRAFT (Informational) Shaoling Sun Xiaodong Duan Hong Liu China Mobile Corporation Bin Li Defeng Li Hejun Li Renhai Zhang Huawei Technologies Expires August, 2005 February 2005 A mini-FRR(Fast Rerouting) mechanism for IP/MPLS network Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document analyzes the weakness of current fast rerouting mechanisms in IP network[1] and MPLS enabled network [2]describes a simple fast rerouting mechanism for IP/MPLS network, and with these points in mind, proposes the simple fast reroute mechanisms based on the intrinsic characteristics of IP network and MPLS network, and illustrates the principles of these mechanisms in node protection and link/path protection. Shaoling Sun, et al. Expires Aug 2005 [Page 1] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 Contents 1. Authors ................................................ 2 2. Terminology ............................................ 3 3. IP mini-FRR(fast rerouting)............................. 3 3.1 Introduction ......................................... 3 3.2 IP mini-FRR mechanism ................................ 4 3.3 IP mini-FRR process .................................. 4 3.4 IP mini-FRR for node protection and path protection .. 5 4. MPLS Mini-FRR(fast rerouting) .......................... 5 4.1 Introduction ......................................... 5 4.2 MPLS mini-FRR mechanism .............................. 6 4.3 MPLS mini-FRR process ................................ 6 5. Application Statement ................................... 8 6. Security Considerations ................................. 8 7. IANA Consideration ...................................... 9 8. IPR Disclosure .......................................... 9 9. IPR Notice .............................................. 9 10. Copyright Notice and Disclaimer ........................ 9 11. Normative References ................................... 10 1 Authors This document was discussed by Shaoling Sun, Xiaodong Duan, Hong Sun, Bin Li, Defeng Li(editor),Hejun Li,Renhai Zhang, Shaoling Sun China Mobile Group Corporation E-mail:sunshaoling@chinamobile.com Xiaodong Duan China Mobile Group Corporation E-mail:duanxiaodong@chinamobile.com Hong Liu China Mobile Group Corporation E-mail:liujongyfw@chinamobile.com Bin Li HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : l.b@huawei.com Defeng Li HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : 77cronux.leed0621@huawei.com Shaoling Sun, et al. Expires Aug 2005 [Page 2] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 2 Terminology mini-FRR:A Fast Rerouting Mechanism Proposed in This Document LSDB: Link State Database LSDB-mini:Link State Database for IP mini-FRR SPF: Shortest Path First Algorithm OSPF: Open Shortest Path First Algorithm 3 IP mini-FRR 3.1 Introduction In IP network, more than one next hops for a destination are sometimes configured to achieve load balancing or to ensure the reliability for some specific traffic, such multi-next hops are derived by running routing protocol supporting ECMPú¿equal cost multi-pathú¨ or other policy such as static routes. In this case, when one of such multi-next hops is in failure, other next hop for the same destination can be utilized in forwarding the IP traffic, this mechanism is sometimes called IP Rerouting, however, the failure of a next hop is perceived after the convergence of routing protocol, when one port of a router is in failure, normally it will take the routes which take that port as the outgoing port for the next hop seconds to be deleted in FIB of the router after the convergence of IGP in the related area/level, and during this period, the traffic traversed this port can't be ransferred to entries with other next hops, so this failure will result in the long time for the backup routes to take effect and accordingly high packet loss rate. To address such problem, a mechanism called IP fast rerouting(IP FRR) is proposed, in IP FRR, a port state table of a router is maintained in the forwarding unit, this table records the status of every ports in the router, when a failure (defect in the physical or shutdown) in a port is detected, the port state table should be updated at once, at the same time, when backup/load balancing entries for the port in failure in FIB (i.e. multi-next hops for the destination) are found, one of such entry will be selected following some rules, then check the state of the outgoing port corresponding to the selected entry in the port state table. If the state of the outgoing port is in failure all the same, then select the still next outgoing port related to the other backup/load balancing next hop, this process continues until the all backup/load balancing next hops are gone through. The advantage of IP FRR over IP rerouting heretofore mentioned is that actions of checking and updating the port state is much faster than convergence process of routing protocol, so IP FRR according to port state table can make the reroute entry to take effect much faster and bring much more reliability to the traffic forwarding. The characteristics of IP FRR is that it performs the reroute according to the port state and the backup ports are configured manually, so the optimization can't be guaranteed in the case of complex network Shaoling Sun, et al. Expires Aug 2005 [Page 3] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 topology, what's more, when the configured backup port is in failure prior to the primary port, even there are other ports can function as backup port, they can't be used as rerouting. 3.2 IP mini-FRR mechanism To increase the resilience to the network, it is better to decide the backup port for a given port (which corresponding to a next hop for a given destination) following the SPF algorithm in advance. This is achieved by running SPF once more in the router alone where the port in that router needs backup with the condition that the protected port is simulated as in failure, take the case of OSPF as IGP running in a router, after OSPF routing protocol is convergent, and the route for a destination is derived, another LSDB(called LSDB-mini) is created in that router based on the synchronized LSDB for the area, the difference is that the LSDB-mini exclude the link state of links related to the protected port in LSDB, then perform SPF algorithm in that router based on LSDB-mini, then the backup port corresponding to the backup next hop for the routes take the protected port as the next hop to all the destinations can be derived, such port is the optimal backup port for the protected port. This mechanism is called IP mini-FRR, It should be noted that in IP mini-FRR such additional SPF computation is not needed for other neighbor routers. This method exempts the network administrator from manual configuration of the backup ports for the primary port, and the as the additional SPF computation based on LSDB-mini is only performed on the router which need to backup its ports, so no additional signaling or protocol interaction other than the normal link state routing protocol between neighbor routers. 3.3 IP mini-FRR process To realize IP mini-FRR, link state routing protocol should be run in the network so as to learn the synchronized LSDB of the topology, and all the devices in the network run SPF algorithm to obtain the routes to all the destinations. This step is a standard convergence process of link state routing protocol, then following steps should be performed. (1)In a given router running IP mini-FRR, the port need backup should be designated, this port can be called primary port. This can be configured be command line or network management system. (2)Create LSDB-mini in the given router based on the synchronized IGP LSDB following the method explained in section 3.2(i.e. delete the links related to the ports need), and additional SPF algorithm is run based on LSDB-mini, then all the alternative routes traversed this router (exclude the primary port) will come out, then the backup port for the primary port can be decided, and the alternative routes traverse backup port follows the shortest-path-first rule in case of the failure of primary port, the backup routes taking such backup port as the outgoing port to the next hop will be more optimal then otherwise configured backup port. Shaoling Sun, et al. Expires Aug 2005 [Page 4] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 (3) The given router add such backup port as an alternative entry to its FIB, if the primary port is in failure, this router can select the backup port as the outgoing port to the next hop and perform the traffic forwarding without blackout. (4) Router maintains the states for its ports, if it happens that the backup port decided by IP mini-FRR is in failure prior to the primary port, then LSDB for the IGP area will update and synchronize, after which this router will create another new LSDB-mini based on the new LSDB for the IGP area (exclude the link related to the primary port), then gets the new alternative backup port if it exists. After that update the entry in FIB. 3.4 IP mini-FRR for node protection and path protection In section 3.3, IP mini-FRR for port protection is explained, it can be achieved by running mini-FRR on one router, if mini-FRR runs on necessary several neighboring router, node protection and path protection can be realized. R1-----R2------R5 \ | | \ | | \ | | \ | | \-R3------R4 Figure 1 Node protection and path protection using IP mini-FRR Considering Figure 1, it assumes that routers R1, R3 perform IP mini-FRR, and the shortest path from R1 to R5 is R1-R2-R5, the primary port is R1-R2, the backup port for R1-R2 is R1-R3, the shortest path from R3 to R5 is R3-R2-R5, the primary port is R3-R2, the backup port for R3-R2 is R3-R4. When node R2 is in failure, R1 and R3 can both detect such failure and perform IP mini-FRR detailed in section 3.3, then primary ports R1-R2 and R3-R2 switched to backup ports R1-R3 and R3-R4 respectively, then the new shortest path R1-R3-R4-R5 will take the place of the R1-R2-R5 very fast, so FRR of node protection for R2 is realized. Similarly, if IP mini-FRR runs on the necessary routers along a traffic path, the protection for the whole path can be realized, the advantage of such path protection is that the routers only need to run IP mini-FRR independently, no new protocol or signaling is required, so its implementation is rather simple. 4 MPLS Mini-FRR(fast rerouting) 4.1 Introduction MPLS network need FRR to protect the traffic transported on MPLS LSP in the case of link or node failure, and in [2] Shaoling Sun, et al. Expires Aug 2005 [Page 5] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 draft-ietf-mpls-rsvp-lsp-fastreroute-07, the MPLS fast rerouting mechanism of extension to RSVP-TE is detailed, it requires that RSVP-TE is deployed as the label distribution protocol in the network, however, in some network, LDP rather than RSVP-TE is deployed as label distribution protocol, so FRR based on RSVP-TE can't be performed; another point is that the backup LSP in RSVP-TE FRR is manually configured, so the configuration job is such a burden in large scale network; moreover, to protect the link, node or path respectively, the different backup LSP are accordingly required, which will consume a large amount of resource in the network. In this section, a simple MPLS FRR mechanism based on LDP(called MPLS mini-FRR) is introduced. 4.2 MPLS mini-FRR mechanism In MPLS mini-FRR mechanism, LDP protocol runs in network as the MPLS label distribution protocol, a given port can be protected by selecting a backup port in advance through manual configuration or automatic algorithm, this given port is called primary port, when the primary port is in failure, the device can switch all the related LSPs traversing the primary port to the backup LSP traversing the backup port very quickly and forwarding the traffic to the same destination, and such backup LSP needn't manual configuration or off-line computation, it is setup automatically and implicitly by LDP protocol, it only requires that LDP works under Downstream Unsolicited Label Advertisement and Liberal Label Retention Mode (in most cases, LDP exactly works under such mode), MPLS mini-FRR works locally in LSR, it needs no additional signaling or protocol, if one LSR performs MPLS mini-FRR, the link protection can be achieved; if the neighboring LSRs both performs this mechanism, the node protection or even the path protection can be realized, and moreover, link protection, node protection or path protection can share the same backup port, it doesn't require the independent resources respectively. The backup port used for backup LSP can be manually configured or decided by additional SPF computation which detailed in section 3. 4.3 MPLS mini-FRR process In MPLS mini-FRR, LDP is the label distribution protocol in the MPLS network, and LDP works under Downstream Unsolicited Label Advertisement and Liberal Label Retention Mode, in this mode, label mapping advertisements for all routes may be received from all LDP peers, and every label mappings received from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping, however, LSR only create the entry ((LDP Identifier, label), PREFIX) in its LIB (Label information base) if the next hop for the prefix (normally corresponding to a FEC) is the advertiser of the related label mapping, in MPLS mini-FRR, this entry is called primary LIB entry for the FEC, and in MPLS mini-FRR mechanism, LSR will create LIB entries for other label mappings advertised from other LDP peers who isn't the next hop for the given FEC, these LIB entries are backup LIB entries for the primary LIB entry. LSR can use these entries to establish the implicit backup LSP with the neighboring LSR when the port corresponding to the Shaoling Sun, et al. Expires Aug 2005 [Page 6] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 primary LIB entry is in failure, so when the link on the primary LSP is in failure, MPLS traffic can be switched to the backup LSP very quickly, so the link protection FRR will be achieved. L21 l52 <--- <--- R1--------R2------R5 \ ^|| || \ L32|||l23 ||L54 \ ||V |V \-----R3-------R4 <--- <--- L31 L43 Figure 2 Node protection and path protection using MPLS mini-FRR Considering Figure 2 above, it assumes that Lxy is the label advertised from Rx to Ry, there are two paths from from R1 to R5, one traverse the link R1-R2(corresponding to port R1-R2), the other traverse the link R1-R3 (corresponding to port R1-R3), and assumes that port R1-R3 is the backup port for port R1-R2. In DU mode, R5 sends the corresponding label mappings to its upstream peer R2 and R4, and R2,R3,R4 continue such process, at last, R2 and R3 sends the label mapping to R1 respectively, R1 runs MPLS mini-FRR stated above, so R1 will maintain both labels and create LIB entries for both labels in its LIB, the labels assigned by R2 and R3 is the primary label and backup label respectively, which forms the primary LSP and backup LSP. The primary LSP and backup LSP is implicitly established by Ingress LER, Intermediate LSR and Egress LER through create the necessary LIB entry respectively. In Ingress LER, LIB is composed of FTN and NHLFE, the regular next hop of FTN is decided by IGP next hop corresponding to the FEC, and the label is carried in the label mapping advertised by the neighboring LDP peer, after the backup port and MPLS mini-FRR is configured to work , a new backup FTN entry will be created, where, the next hop the configured backup port, and the label is that carried in the label mapping advertised by the neighbor LDP peer of the backup port. In the case of Figure 2, R1 will create two NHLFEs for FEC for destinations corresponding to R5 (called FEC-5). (1) FEC-5-( R1-R2,L21, LDP Identifier of R2) (2) FEC-5-( R1-R3,L31, LDP Identifier of R3) In the immediate LSR and pen-ultimate hop LSR, LIB is composed of ILM and NHLFE, ILM is a table the mapping incoming label and outgoing label, if this LSR performs MPLS mini-FRR, it will add the backup NHLFE entries to its ILM, the backup NHLFE entry includes label advertised by its LDP peer and the related outgoing port. In case of PHP Shaoling Sun, et al. Expires Aug 2005 [Page 7] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 (pen-ultimate hop), as the Egress LER don't assign the explicit label for the pen-ultimate LSR, no backup NHLFE is needed, but pen-ultimate LSR will assign the labels for his upstream LSR as the other immediate LSR. Router maintains the states for its ports, if it happens that the backup port for MPLS mini-FRR is in failure prior to the primary port, LIB will updated, the new backup port can be created by some means (manual configuration or automatic computation detailed in section 3), correspondingly, new backup NHLFE entry will be added to the LIB. If the neighboring LSRs implements MPLS mini-FRR appropriately, the node protection and path protection can be achieved. Considering Figure 2 again, we need realize node protection for R2, and the shortest path is R1-R2-R5, it assumes that routers R1, R3 perform MPLS mini-FRR, and the shortest path from R1 to R5 is R1-R2-R5, the primary port is R1-R2,the primary label is L21, the backup port for R1-R2 is R1-R3, the backup label is L31, the shortest path from R3 to R5 is R3-R2-R5, the primary port is R3-R2, the primary label is L23, the backup port for R3-R2 is R3-R4, the backup label is L43. When node R2 is in failure, R1 and R3 can both detect such failure and perform MPLS mini-FRR, then their backup NHLFE entries corresponding to L31 and L43 are used to forward traffic from R1 to R5, so the implicit LSP R1-R3-R4-R5 is established for R1-R5 traffic and node protection for R2 is achieved. Similarly, if the necessary neighboring LSRs for LSRs on a given LSP performs MPLS mini-FRR, the path protection for the whole LSP can also be achieved. 5. Application Statement IP mini-FRR and MPLS mini-FRR introduced in this document exploit the inherent characteristic of the related protocols, it needs no complex additional signaling or signaling, and the backup port or NHLFE for some failure can be based on the optimum algorithm under the pre-designed possible topology in the case of such failures. In some sense, such mini-FRR is kind of self-healing mechanisms, which makes use of the resilience of the network itself. These mechanism is applicable for the network where FRR is preferable while Traffic Engineering is not deployed, so these mini-FRR is the effective complementary to Traffic Engineering, Some Service Providers expressed explicitly their preference to these mini-FRR mechanisms considering MPLS Traffic Engineering is so complex and not yet standardized. 6. Security Consideration As such mini-FRR mechanisms are based on the current prevalent protocols (such as SPF algorithm and LDP) which are deployed widely and endured security proof-test, so these mechanisms introduce no additional security problem. Shaoling Sun, et al. Expires Aug 2005 [Page 8] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 7. IANA Consideration This document needs no actions for IANA. 8. IPR Disclosure By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668." 9. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. Copyright Notice and Disclaimer Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shaoling Sun, et al. Expires Aug 2005 [Page 9] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005 11. Normative References [1] RFC 2328,Moy, J., "OSPF Version 2", April 1998. [2] IETF Draft:draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, Fast Reroute Extensions to RSVP-TE for LSP Tunnels. [3] RFC 2702: Requirements for Traffic Engineering Over MPLS. Shaoling Sun, et al. Expires Aug 2005 [Page 10] Internet Draft draft-defeng-mpls-mini-fast-rerouting-00 Feb 2005