Internet DRAFT - draft-defeng-mpls-mini-fast-rerouting
draft-defeng-mpls-mini-fast-rerouting
INTERNET DRAFT (Informational)
<draft-defeng-mpls-mini-fast-rerouting-00>
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
