draft-ietf-rtgwg-ordered-fib-09.txt   draft-ietf-rtgwg-ordered-fib-10.txt 
Network Working Group M. Shand Network Working Group M. Shand
Internet-Draft Individual Contributor Internet-Draft Individual Contributor
Intended status: Informational S. Bryant Intended status: Informational S. Bryant
Expires: August 4, 2013 S. Previdi Expires: November 25, 2013 S. Previdi
C. Filsfils C. Filsfils
Cisco Systems Cisco Systems
P. Francois P. Francois
Institute IMDEA Networks Institute IMDEA Networks
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
January 31, 2013 May 24, 2013
Framework for Loop-free convergence using oFIB Framework for Loop-free convergence using oFIB
draft-ietf-rtgwg-ordered-fib-09 draft-ietf-rtgwg-ordered-fib-10
Abstract Abstract
This document describes the framework of a mechanism for use in This document describes an illustrative framework of a mechanism for
conjunction with link state routing protocols which prevents the use in conjunction with link state routing protocols which prevents
transient loops which would otherwise occur during topology changes. the transient loops which would otherwise occur during topology
It does this by correctly sequencing the forwarding information base changes. It does this by correctly sequencing the forwarding
(FIB) updates on the routers. information base (FIB) updates on the routers.
This mechanism can be used in the case of non-urgent (management This mechanism can be used in the case of non-urgent (management
action) link or node shutdowns and restarts or link metric changes. action) link or node shutdowns and restarts or link metric changes.
It can also be used in conjunction with a fast re-route mechanism It can also be used in conjunction with a fast re-route mechanism
which converts a sudden link or node failure into a non-urgent which converts a sudden link or node failure into a non-urgent
topology change. This is possible where a complete repair path is topology change. This is possible where a complete repair path is
provided for all affected destinations. provided for all affected destinations.
After a non-urgent topology change, each router computes a rank that After a non-urgent topology change, each router computes a rank that
defines the time at which it can safely update its FIB. A method for defines the time at which it can safely update its FIB. A method for
skipping to change at page 1, line 47 skipping to change at page 1, line 47
The technology described in this document has been subject to The technology described in this document has been subject to
extensive simulation using real network topologies and costs, and extensive simulation using real network topologies and costs, and
pathological convergence behaviour. However the mechanism described pathological convergence behaviour. However the mechanism described
in this document are purely illustrative of the general approach and in this document are purely illustrative of the general approach and
do not constitute a protocol specification. The document represents do not constitute a protocol specification. The document represents
a snapshot of the work of the Routing Area Working Group at the time a snapshot of the work of the Routing Area Working Group at the time
of publication and is published as a document of record. Further of publication and is published as a document of record. Further
work is needed before implementation or deployment. work is needed before implementation or deployment.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2013. This Internet-Draft will expire on November 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. The Purpose of this Document . . . . . . . . . . . . . . . . . 4 1. The Purpose of this Document . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The required FIB update order . . . . . . . . . . . . . . . . 6 3. The required FIB update order . . . . . . . . . . . . . . . . 5
3.1. Single Link Events . . . . . . . . . . . . . . . . . . . . 6 3.1. Single Link Events . . . . . . . . . . . . . . . . . . . 5
3.1.1. Link Down / Metric Increase . . . . . . . . . . . . . 6 3.1.1. Link Down / Metric Increase . . . . . . . . . . . . . 5
3.1.2. Link Up / Metric Decrease . . . . . . . . . . . . . . 7 3.1.2. Link Up / Metric Decrease . . . . . . . . . . . . . . 7
3.2. Multi-link events . . . . . . . . . . . . . . . . . . . . 7 3.2. Multi-link events . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Router Down events . . . . . . . . . . . . . . . . . . 8 3.2.1. Router Down events . . . . . . . . . . . . . . . . . 7
3.2.2. Router Up events . . . . . . . . . . . . . . . . . . . 8 3.2.2. Router Up events . . . . . . . . . . . . . . . . . . 7
3.2.3. Linecard Failure/Restoration Events . . . . . . . . . 8 3.2.3. Linecard Failure/Restoration Events . . . . . . . . . 7
4. Applying ordered FIB updates . . . . . . . . . . . . . . . . . 8 4. Applying ordered FIB updates . . . . . . . . . . . . . . . . 8
4.1. Deducing the topology change . . . . . . . . . . . . . . . 8 4.1. Deducing the topology change . . . . . . . . . . . . . . 8
4.2. Deciding if ordered FIB updates applies . . . . . . . . . 9 4.2. Deciding if ordered FIB updates applies . . . . . . . . . 8
5. Computation of the ordering . . . . . . . . . . . . . . . . . 10 5. Computation of the ordering . . . . . . . . . . . . . . . . . 9
5.1. Link or Router Down or Metric Increase . . . . . . . . . . 10 5.1. Link or Router Down or Metric Increase . . . . . . . . . 9
5.2. Link or Router Up or Metric Decrease . . . . . . . . . . . 11 5.2. Link or Router Up or Metric Decrease . . . . . . . . . . 10
6. Acceleration of Ordered Convergence . . . . . . . . . . . . . 11
6.1. Construction of the waiting list and notification list . . 12 6. Acceleration of Ordered Convergence . . . . . . . . . . . . . 10
6.1.1. Down events . . . . . . . . . . . . . . . . . . . . . 12 6.1. Construction of the waiting list and notification list . 11
6.1.2. Up Events . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Down events . . . . . . . . . . . . . . . . . . . . . 11
6.2. Format of Completion Messages . . . . . . . . . . . . . . 12 6.1.2. Up Events . . . . . . . . . . . . . . . . . . . . . . 11
7. Fall back to Conventional Convergence . . . . . . . . . . . . 13 6.2. Format of Completion Messages . . . . . . . . . . . . . . 12
8. oFIB state machine . . . . . . . . . . . . . . . . . . . . . . 13 7. Fall back to Conventional Convergence . . . . . . . . . . . . 12
8.1. OFIB_STABLE . . . . . . . . . . . . . . . . . . . . . . . 13 8. oFIB state machine . . . . . . . . . . . . . . . . . . . . . 12
8.2. OFIB_HOLDING_DOWN . . . . . . . . . . . . . . . . . . . . 14 8.1. OFIB_STABLE . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. OFIB_HOLDING_UP . . . . . . . . . . . . . . . . . . . . . 15 8.2. OFIB_HOLDING_DOWN . . . . . . . . . . . . . . . . . . . . 13
8.4. OFIB_ONGOING . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. OFIB_HOLDING_UP . . . . . . . . . . . . . . . . . . . . . 14
8.5. OFIB_ABANDONED . . . . . . . . . . . . . . . . . . . . . . 17 8.4. OFIB_ONGOING . . . . . . . . . . . . . . . . . . . . . . 16
9. Management Considerations . . . . . . . . . . . . . . . . . . 17 8.5. OFIB_ABANDONED . . . . . . . . . . . . . . . . . . . . . 16
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Management Considerations . . . . . . . . . . . . . . . . . . 17
11. Security considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security considerations . . . . . . . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Candidate Methods of Safely Abandoning Loop-Free Appendix A. Candidate Methods of Safely Abandoning Loop-Free
Convergence (AAH) . . . . . . . . . . . . . . . . . . 18 Convergence (AAH) . . . . . . . . . . . . . . . . . 18
A.1. Possible Solutions . . . . . . . . . . . . . . . . . . . . 19 A.1. Possible Solutions . . . . . . . . . . . . . . . . . . . 18
A.2. Hold-down timer only . . . . . . . . . . . . . . . . . . . 19 A.2. Hold-down timer only . . . . . . . . . . . . . . . . . . 18
A.3. AAH messages . . . . . . . . . . . . . . . . . . . . . . . 20 A.3. AAH messages . . . . . . . . . . . . . . . . . . . . . . 20
A.3.1. Per Router State Machine . . . . . . . . . . . . . . . 20 A.3.1. Per Router State Machine . . . . . . . . . . . . . . 20
A.3.2. Per Neighbor State Machine . . . . . . . . . . . . . . 22 A.3.2. Per Neighbor State Machine . . . . . . . . . . . . . 22
Appendix B. Synchronisation of Loop Free Timer Values . . . . . . 24 Appendix B. Synchronisation of Loop Free Timer Values . . . . . 23
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 23
B.2. Required Properties . . . . . . . . . . . . . . . . . . . 24 B.2. Required Properties . . . . . . . . . . . . . . . . . . . 24
B.3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 25 B.3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 24
B.4. Security Considerations . . . . . . . . . . . . . . . . . 26 B.4. Security Considerations . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. The Purpose of this Document 1. The Purpose of this Document
This document describes the framework of a mechanism for use in This document describes an illustrative framework of a mechanism for
conjunction with link state routing protocols which prevents the use in conjunction with link state routing protocols which prevents
transient loops which would otherwise occur during topology changes. the transient loops which would otherwise occur during topology
It does this by correctly sequencing the forwarding information base changes. It does this by correctly sequencing the forwarding
(FIB) updates on the routers. information base (FIB) updates on the routers.
At the time of publication there is no demand to deploy this At the time of publication there is no demand to deploy this
technology, however in view of the subtleties involved in the design technology, however in view of the subtleties involved in the design
of loop-free convergence routing protocol extensions the Routing Area of loop-free convergence routing protocol extensions the Routing Area
Working Group considered it desirable to publish this document to Working Group considered it desirable to publish this document to
place on record the design consideration of the ordered FIB place on record the design consideration of the ordered FIB
(oFIB)approach. (oFIB)approach.
The mechanisms presented in this document are purely illustrative of The mechanisms presented in this document are purely illustrative of
the general approach and do not constitute a protocol specification. the general approach and do not constitute a protocol specification.
skipping to change at page 5, line 5 skipping to change at page 4, line 35
packet loops and loss can still occur. packet loops and loss can still occur.
For example, in Figure 1, if the link between X and Y is shut down by For example, in Figure 1, if the link between X and Y is shut down by
an operator, packets destined to X can loop between R and Y when Y an operator, packets destined to X can loop between R and Y when Y
has updated its FIB while R has not yet updated its FIB, and packets has updated its FIB while R has not yet updated its FIB, and packets
destined to Y can loop between X and S if X updates its FIB before S. destined to Y can loop between X and S if X updates its FIB before S.
According to the current behaviour of ISIS and OSPF, this scenario According to the current behaviour of ISIS and OSPF, this scenario
will happen most of the time because X and Y are the first routers to will happen most of the time because X and Y are the first routers to
be aware of the failure, so that they will update their FIBs first. be aware of the failure, so that they will update their FIBs first.
1 1
X-------------/-------------Y X-------------/-------------Y
| | | |
| | | |
| | | |
| | | |
1 | | 1 1 | | 1
| | | |
| | | |
| | | |
| | | |
S---------------------------R S---------------------------R
2 2
Figure 1: A simple topology Figure 1: A simple topology
It should be noted that the loops can occur remotely from the It should be noted that the loops can occur remotely from the
failure, not just adjacent to it. failure, not just adjacent to it.
[RFC5715] provides an introduction to a number of loop-free [RFC5715] provides an introduction to a number of loop-free
convergence methods and readers unfamiliar with this technology are convergence methods and readers unfamiliar with this technology are
recommended to read before studying this document in detail. Note recommended to read before studying this document in detail. Note
that in common with other loop-free convergence methods, oFIB is only that in common with other loop-free convergence methods, oFIB is only
capable of providing loop free convergence in the presence of a capable of providing loop free convergence in the presence of a
single failure. single failure.
The goal of this document is to describe a mechanism which sequences The goal of this document is to describe a mechanism which sequences
the router FIB updates to maintain consistency throughout the the router FIB updates to maintain consistency throughout the
network. By correctly setting the FIB change order, no looping or network. By correctly setting the FIB change order, no looping or
packet loss can occur. This mechanism may be applied to the case of packet loss can occur. This mechanism may be applied to the case of
managed link-state changes, i.e. link metric change, manual link managed link-state changes, i.e. link metric change, manual link
down/up, manual router down/up, and managed state changes of a set of down/up, manual router down/up, and managed state changes of a set of
links attached to one router. It may also be applied to the case links attached to one router. It may also be applied to the case
where one or more network elements are protected by a fast re-route where one or more network elements are protected by a fast re-route
mechanism (FRR) [RFC5714] [RFC4090]. The mechanisms that are used in mechanism (FRR) [RFC5714] [RFC4090]. The mechanisms that are used in
the failure case are exactly the same as those used for managed the failure case are exactly the same as those used for managed
changes. For simplicity this document makes no further distinction changes. For simplicity this document makes no further distinction
between managed and unplanned changes. between managed and unplanned changes.
It is assumed in the description that follows that all routers in the It is assumed in the description that follows that all routers in the
routing domain are oFIB capable. This can be verified in an routing domain are oFIB capable. This can be verified in an
operation network by the routers reporting oFIB capability using the operation network by the routers reporting oFIB capability using the
IGP in use. Where non-oFIB capable routers exist in the network, IGP in use. Where non-oFIB capable routers exist in the network,
normal convergence would be used. The operation of mixed-mode normal convergence would be used by all routers. The operation of
networks is for further study. mixed-mode networks is for further study.
The technology described in this document has been subject to The technology described in this document has been subject to
extensive simulation using real network topologies and costs and extensive simulation using real network topologies and costs and
pathological convergence behaviour. A variant of the technology pathological convergence behaviour. A variant of the technology
described here has been experimentally deployed in a production described here has been experimentally deployed in a production
network. network.
3. The required FIB update order 3. The required FIB update order
This section provides an overview of the required ordering of the FIB This section provides an overview of the required ordering of the FIB
skipping to change at page 6, line 22 skipping to change at page 6, line 4
correctness proofs of the mechanism can be found in [refs.PFOB07]. correctness proofs of the mechanism can be found in [refs.PFOB07].
3.1. Single Link Events 3.1. Single Link Events
For simplicity the correct ordering for single link changes are For simplicity the correct ordering for single link changes are
described first. The document then builds on this to demonstrate described first. The document then builds on this to demonstrate
that the same principles can be applied to more complex scenarios that the same principles can be applied to more complex scenarios
such as line card or node changes. such as line card or node changes.
3.1.1. Link Down / Metric Increase 3.1.1. Link Down / Metric Increase
First consider the non-urgent failure of a link (i.e. where an
First consider the non-urgent failure of a link (i.e. where an
operator or a network management system (NMS) shuts down a link operator or a network management system (NMS) shuts down a link
thereby removing it from the currently active topology) or the thereby removing it from the currently active topology) or the
increase of a link metric by the operator or NMS . In this case, a increase of a link metric by the operator or NMS . In this case, a
router R must not update its FIB until all other routers that send router R must not update its FIB until all other routers that send
traffic via R and the affected link have first updated their FIBs. traffic via R and the affected link have first updated their FIBs.
The following argument shows that this rule ensures the correct order The following argument shows that this rule ensures the correct order
of FIB change when the link X->Y is shut down or its metric is of FIB change when the link X->Y is shut down or its metric is
increased. increased.
An "outdated" FIB entry for a destination is defined as being a FIB An "outdated" FIB entry for a destination is defined as being a FIB
entry that still reflects the shortest path(s) in use before the entry that still reflects the shortest path(s) in use before the
topology change. Once a packet reaches a router R that has an topology change. Once a packet reaches a router R that has an
skipping to change at page 7, line 21 skipping to change at page 6, line 49
event. If it does not reach an outdated router, it will only be event. If it does not reach an outdated router, it will only be
forwarded on the loop free path that will be used after the forwarded on the loop free path that will be used after the
convergence. convergence.
According to the proposed ordering, X will be the last router to According to the proposed ordering, X will be the last router to
update its FIB. Once it has updated its FIB, the link X->Y can update its FIB. Once it has updated its FIB, the link X->Y can
actually be shut down (or the repair removed). actually be shut down (or the repair removed).
If the link X-Y is bidirectional a similar process must be run to If the link X-Y is bidirectional a similar process must be run to
order the FIB update for destinations using the link in the direction order the FIB update for destinations using the link in the direction
Y->X. As has already been shown, no packet ever traverses the X-Y Y->X. As has already been shown, no packet ever traverses the X-Y
link in both directions, and hence the operation of the two ordering link in both directions, and hence the operation of the two ordering
processes is orthogonal. processes is orthogonal.
3.1.2. Link Up / Metric Decrease 3.1.2. Link Up / Metric Decrease
In the case of link up events or metric decreases, a router R must In the case of link up events or metric decreases, a router R must
update its FIB before all other routers that will use R to reach the update its FIB before all other routers that will use R to reach the
affected link. affected link.
The following argument shows that this rule ensures the correct order The following argument shows that this rule ensures the correct order
skipping to change at page 8, line 24 skipping to change at page 8, line 4
3.2.2. Router Up events 3.2.2. Router Up events
In the case of a router being brought into service, a router R must In the case of a router being brought into service, a router R must
update its FIB BEFORE all other routers that WILL use R to reach the update its FIB BEFORE all other routers that WILL use R to reach the
affected router. affected router.
A proof similar to that for link up, shows that no loops will occur A proof similar to that for link up, shows that no loops will occur
if this ordering is respected [refs.PFOB07]. if this ordering is respected [refs.PFOB07].
3.2.3. Linecard Failure/Restoration Events 3.2.3. Linecard Failure/Restoration Events
The failure of a line card involves the failure of a set of links all The failure of a line card involves the failure of a set of links all
of which have a single node in common, i.e. the parent router. The of which have a single node in common, i.e. the parent router. The
ordering to be applied is the same as if it were the failure of the ordering to be applied is the same as if it were the failure of the
parent router. parent router.
In a similar way, the restoration of an entire linecard to service as In a similar way, the restoration of an entire linecard to service as
a single event can be treated as if the parent router were returning a single event can be treated as if the parent router were returning
to service. to service.
4. Applying ordered FIB updates 4. Applying ordered FIB updates
4.1. Deducing the topology change 4.1. Deducing the topology change
skipping to change at page 10, line 25 skipping to change at page 9, line 52
reverse Shortest Path Tree (rSPT). The rSPT uses the cost towards reverse Shortest Path Tree (rSPT). The rSPT uses the cost towards
the root rather than from it and yields the best paths towards the the root rather than from it and yields the best paths towards the
root from other nodes in the network[I-D.bryant-ipfrr-tunnels]. root from other nodes in the network[I-D.bryant-ipfrr-tunnels].
5.1. Link or Router Down or Metric Increase 5.1. Link or Router Down or Metric Increase
To respect the proposed ordering, routers compute a rank that will be To respect the proposed ordering, routers compute a rank that will be
used to determine the time at which they are permitted to perform used to determine the time at which they are permitted to perform
their FIB update. In the case of a failure event rooted at router Y their FIB update. In the case of a failure event rooted at router Y
or an increase of the metric of link X->Y, router R computes the rSPT or an increase of the metric of link X->Y, router R computes the rSPT
in the topology before the failure (rSPT_OLD) rooted at Y. This rSPT in the topology before the failure (rSPT_OLD) rooted at Y. This rSPT
gives the shortest paths to reach Y before the failure. The branch gives the shortest paths to reach Y before the failure. The branch
of the reverse SPT that is below R corresponds to the set of shortest of the reverse SPT that is below R corresponds to the set of shortest
paths to R that are used by the routers that reach Y via R. paths to R that are used by the routers that reach Y via R.
The rank of router R is defined as the depth (in number of hops) of The rank of router R is defined as the depth (in number of hops) of
this branch. In the case of Equal Cost Multi-path (ECMP), the this branch. In the case of Equal Cost Multi-path (ECMP), the
maximum depth of the ECMP path set is used. maximum depth of the ECMP path set is used.
Router R is required to update its FIB at time Router R is required to update its FIB at time
skipping to change at page 11, line 20 skipping to change at page 10, line 45
according to the rule described in Section 3. The rank of R is thus according to the rule described in Section 3. The rank of R is thus
the number of hops between R and Y in its renewed Shortest Path Tree. the number of hops between R and Y in its renewed Shortest Path Tree.
When R has multiple equal cost paths to Y, the rank is the length in When R has multiple equal cost paths to Y, the rank is the length in
hops of the longest ECMP path to Y. hops of the longest ECMP path to Y.
Router R is required to update its FIB at time Router R is required to update its FIB at time
T0 + H + (rank * MAX_FIB) T0 + H + (rank * MAX_FIB)
It should be noted that only the routers that use Y after the event It should be noted that only the routers that use Y after the event
have to compute a rank, i.e. only the routers that have Y in their have to compute a rank, i.e. only the routers that have Y in their
SPT after the link-state change. SPT after the link-state change.
6. Acceleration of Ordered Convergence 6. Acceleration of Ordered Convergence
The mechanism described above is conservative, and hence may be The mechanism described above is conservative, and hence may be
relatively slow. The purpose of this section is to describe a method relatively slow. The purpose of this section is to describe a method
of accelerating the controlled convergence in such a way that ordered of accelerating the controlled convergence in such a way that ordered
loop-free convergence is still guaranteed. loop-free convergence is still guaranteed.
In many cases a router will complete its required FIB changes in a In many cases a router will complete its required FIB changes in a
skipping to change at page 12, line 14 skipping to change at page 11, line 39
Note that, since this is only an optimization, any loss of completion Note that, since this is only an optimization, any loss of completion
messages will result in the routers waiting their defined ranking messages will result in the routers waiting their defined ranking
time and hence the loop-free properties will be preserved. time and hence the loop-free properties will be preserved.
6.1. Construction of the waiting list and notification list 6.1. Construction of the waiting list and notification list
6.1.1. Down events 6.1.1. Down events
Consider a link or node down event rooted at router Y or the cost Consider a link or node down event rooted at router Y or the cost
increase of the link X->Y. A router R will compute rSPT_OLD(Y) to increase of the link X->Y. A router R will compute rSPT_OLD(Y) to
determine its rank. When doing this, R also computes the set of determine its rank. When doing this, R also computes the set of
neighbours that R uses to reach the failing node or link, and the set neighbours that R uses to reach the failing node or link, and the set
of neighbours that are using R to reach the failing node or link. of neighbours that are using R to reach the failing node or link.
The Notification list of R is equal to the former set and the Waiting The Notification list of R is equal to the former set and the Waiting
list of R is equal to the latter. list of R is equal to the latter.
Note that R could include all its neighbours except those in the Note that R could include all its neighbours except those in the
Waiting list in the Notification list, this has no impact on the Waiting list in the Notification list, this has no impact on the
correctness of the protocol, but would be unnecessarily inefficient. correctness of the protocol, but would be unnecessarily inefficient.
skipping to change at page 12, line 26 skipping to change at page 12, line 4
neighbours that R uses to reach the failing node or link, and the set neighbours that R uses to reach the failing node or link, and the set
of neighbours that are using R to reach the failing node or link. of neighbours that are using R to reach the failing node or link.
The Notification list of R is equal to the former set and the Waiting The Notification list of R is equal to the former set and the Waiting
list of R is equal to the latter. list of R is equal to the latter.
Note that R could include all its neighbours except those in the Note that R could include all its neighbours except those in the
Waiting list in the Notification list, this has no impact on the Waiting list in the Notification list, this has no impact on the
correctness of the protocol, but would be unnecessarily inefficient. correctness of the protocol, but would be unnecessarily inefficient.
6.1.2. Up Events 6.1.2. Up Events
Consider a link or node up event rooted at router Y or the cost Consider a link or node up event rooted at router Y or the cost
decrease of the link Y->X. A router R will compute its new SPT decrease of the link Y->X. A router R will compute its new SPT
(SPT_new(R)). The Waiting list is the set of next hop routers that R (SPT_new(R)). The Waiting list is the set of next hop routers that R
uses to reach Y in SPT_new(R). uses to reach Y in SPT_new(R).
In a simple implementation the notification list of R is all the In a simple implementation the notification list of R is all the
neighbours of R excluding those in the Waiting list. This may be neighbours of R excluding those in the Waiting list. This may be
further optimized by computing rSPT_new(Y) to determine those routers further optimized by computing rSPT_new(Y) to determine those routers
that are waiting for R to complete. that are waiting for R to complete.
6.2. Format of Completion Messages 6.2. Format of Completion Messages
skipping to change at page 13, line 14 skipping to change at page 12, line 44
New Metric New Metric
7. Fall back to Conventional Convergence 7. Fall back to Conventional Convergence
In circumstances where a router detects that it is dealing with In circumstances where a router detects that it is dealing with
incomplete or inconsistent link state information, or when a further incomplete or inconsistent link state information, or when a further
topology event is received before completion of the current ordered topology event is received before completion of the current ordered
FIB update process, it may be expedient to abandon the controlled FIB update process, it may be expedient to abandon the controlled
convergence process. A number of possible fall back mechanisms are convergence process. A number of possible fall back mechanisms are
described in Appendix A. This mechanism is referred to as described in Appendix A. This mechanism is referred to as
"Abandoning All Hope (AAH). The state machine defined in the body of "Abandoning All Hope" (AAH). The state machine defined in the body
this document does not make any assumption about which fall back of this document does not make any assumption about which fall back
mechanism will be used. mechanism will be used.
8. oFIB state machine 8. oFIB state machine
This section describes a model of an oFIB state machine which an This section describes a model of an oFIB state machine which an
implementation must be capable of interworking with. implementation must be capable of interworking with.
An oFIB capable router maintains an oFIB state value which can be one An oFIB capable router maintains an oFIB state value which can be one
of : OFIB_STABLE, OFIB_HOLDING_DOWN, OFIB_HOLDING_UP, OFIB_ABANDONED, of : OFIB_STABLE, OFIB_HOLDING_DOWN, OFIB_HOLDING_UP, OFIB_ABANDONED,
OFIB_ONGOING. OFIB_ONGOING.
skipping to change at page 13, line 44 skipping to change at page 13, line 26
8.1. OFIB_STABLE 8.1. OFIB_STABLE
OFIB_STABLE is the state of a router which is not currently involved OFIB_STABLE is the state of a router which is not currently involved
in any convergence process. This router is ready to process an event in any convergence process. This router is ready to process an event
by applying oFIB. by applying oFIB.
EVENT : Reception of a link-state packet describing an event of the EVENT : Reception of a link-state packet describing an event of the
type link X--Y down or metric increase to be processed using oFIB. type link X--Y down or metric increase to be processed using oFIB.
ACTION : ACTION :
Set state to OFIB_HOLDING_DOWN. Set state to OFIB_HOLDING_DOWN.
Start Hold_down_timer. Start Hold_down_timer.
ofib_current_common_set = {X,Y}. ofib_current_common_set = {X,Y}.
Compute rank with respect to the event, as defined in Section 5. Compute rank with respect to the event, as defined in Section 5.
Store Waiting List and Notification List for X--Y obtained from Store Waiting List and Notification List for X--Y obtained from
the rank computation. the rank computation.
EVENT : Reception of a link-state packet describing an event of the EVENT : Reception of a link-state packet describing an event of the
type link X--Y up or metric decrease which to be processed using type link X--Y up or metric decrease which to be processed using
oFIB. oFIB.
ACTION :
Set state to OFIB_HOLDING_UP.
Start Hold_down_timer.
ofib_current_common_set = {X,Y}
Compute rank with respect to the event, as defined in section
Section 5 .
Store Waiting List and Notification List for X--Y obtained from
the rank computation.
8.2. OFIB_HOLDING_DOWN 8.2. OFIB_HOLDING_DOWN
OFIB_HOLDING_DOWN is the state of a router that is collecting a set OFIB_HOLDING_DOWN is the state of a router that is collecting a set
of link down or metric increase link-state packets to be processed of link down or metric increase link-state packets to be processed
together using controlled convergence. together using controlled convergence.
EVENT : Reception of a link-state packet describing an event of the EVENT : Reception of a link-state packet describing an event of the
type link up or metric decrease which in itself can be processed type link up or metric decrease which in itself can be processed
using oFIB. using oFIB.
ACTION : ACTION :
Set state to OFIB_ABANDONED. Set state to OFIB_ABANDONED.
Reset Hold_down_timer.
Trigger AAH mechanism Reset Hold_down_timer.
Trigger AAH mechanism
EVENT : Reception of a link-state packet describing an event of the EVENT : Reception of a link-state packet describing an event of the
type link A--B down or metric increase which in itself can be type link A--B down or metric increase which in itself can be
processed using oFIB. processed using oFIB.
ACTION : ACTION :
ofib_current_common_set = ofib_current_common_set =
intersection(ofib_current_common_set,{A,B}). intersection(ofib_current_common_set,{A,B}).
If ofib_current_common_set is empty, then there is no longer a
node in common in all the pending link-state changes.
Set state to OFIB_ABANDONED
Reset Hold_down_timer
Trigger AAH mechanism.
If ofib_current_common set is not empty, update waiting list and If ofib_current_common_set is empty, then there is no longer a
notification list as defined in Section 5. Note that in the node in common in all the pending link-state changes.
case of a single link event, the link-state packet received when
the router is in this state describes the state change of the Set state to OFIB_ABANDONED
other direction of the link, hence no changes will be made to
the waiting and notification lists. Reset Hold_down_timer
Trigger AAH mechanism.
If ofib_current_common set is not empty, update waiting list and
notification list as defined in Section 5. Note that in the case
of a single link event, the link-state packet received when the
router is in this state describes the state change of the other
direction of the link, hence no changes will be made to the
waiting and notification lists.
EVENT : Hold_down_timer expires. EVENT : Hold_down_timer expires.
ACTION : ACTION :
Set state to OFIB_ONGOING. Set state to OFIB_ONGOING.
Start rank_timer with computed rank.
Start rank_timer with computed rank.
EVENT : Reception of a completion message EVENT : Reception of a completion message
ACTION : Remove the sender from waiting list associated with the ACTION : Remove the sender from waiting list associated with the
event identified in the completion message. event identified in the completion message.
8.3. OFIB_HOLDING_UP 8.3. OFIB_HOLDING_UP
OFIB_HOLDING_UP is the state of a router that is collecting a set of OFIB_HOLDING_UP is the state of a router that is collecting a set of
link up or metric decrease link-state packets to be processed link up or metric decrease link-state packets to be processed
together using controlled convergence. together using controlled convergence.
EVENT : Reception of a link-state packet describing an event of the EVENT : Reception of a link-state packet describing an event of the
type link down or metric increase to be processed using oFIB. type link down or metric increase to be processed using oFIB.
ACTION : ACTION :
Set state to OFIB_ABANDONED. Set state to OFIB_ABANDONED.
Reset Hold_down_timer.
Trigger AAH mechanism. Reset Hold_down_timer.
Trigger AAH mechanism.
EVENT : Reception of a link-state packet describing an event of the EVENT : Reception of a link-state packet describing an event of the
type link A--B up or metric decrease to be processed using oFIB. type link A--B up or metric decrease to be processed using oFIB.
ACTION : ACTION :
ofib_current_common_set = ofib_current_common_set =
intersection(ofib_current_common_set,{A,B}). intersection(ofib_current_common_set,{A,B}).
If ofib_current_common_set is empty, then there is no longer a
common node in the set of pending link-state changes.
Set state to OFIB_ABANDONED.
Reset Hold_down_timer.
Trigger AAH mechanism.
If ofib_current_common set is not empty, update waiting list and If ofib_current_common_set is empty, then there is no longer a
notification list as defined in Section 5. Note that in the common node in the set of pending link-state changes.
case of a single link event, the link-state packet received when
the router is in this state describes the state change of the Set state to OFIB_ABANDONED.
other direction of the link, hence no changes will be made to
the waiting and notification lists. Reset Hold_down_timer.
Trigger AAH mechanism.
If ofib_current_common set is not empty, update waiting list and
notification list as defined in Section 5. Note that in the case
of a single link event, the link-state packet received when the
router is in this state describes the state change of the other
direction of the link, hence no changes will be made to the
waiting and notification lists.
EVENT : Reception of a completion message EVENT : Reception of a completion message
ACTION : Remove the sender from the waiting list associated with the ACTION : Remove the sender from the waiting list associated with the
event identified in the completion message. event identified in the completion message.
EVENT : Hold_down_timer expires. EVENT : Hold_down_timer expires.
ACTION : ACTION :
Set state to OFIB_ONGOING. Set state to OFIB_ONGOING.
Start rank_timer with computed rank.
Start rank_timer with computed rank.
8.4. OFIB_ONGOING 8.4. OFIB_ONGOING
OFIB_ONGOING is the state of a router that is applying the ordering OFIB_ONGOING is the state of a router that is applying the ordering
mechanism w.r.t. the set of Link State Packets (LSP) collected when mechanism w.r.t. the set of Link State Packets (LSP) collected when
in OFIB_HOLDING_DOWN or OFIB_HOLDING_UP state. in OFIB_HOLDING_DOWN or OFIB_HOLDING_UP state.
EVENT : rank_timer expires or waiting list becomes empty. EVENT : rank_timer expires or waiting list becomes empty.
ACTION : ACTION :
Perform FIB updates according to the change. Perform FIB updates according to the change.
Send completion message to each member of the notification list.
Set State to OFIB_STABLE. Send completion message to each member of the notification list.
Set State to OFIB_STABLE.
EVENT : Reception of a completion message EVENT : Reception of a completion message
ACTION : Remove the sender from the waiting list. ACTION : Remove the sender from the waiting list.
EVENT : Reception of a link-state packet describing a link state EVENT : Reception of a link-state packet describing a link state
change event. change event.
ACTION : ACTION :
Set state to OFIB_ABANDONED. Set state to OFIB_ABANDONED.
Trigger AAH.
Start Hold_down_timer. Trigger AAH.
Start Hold_down_timer.
8.5. OFIB_ABANDONED 8.5. OFIB_ABANDONED
OFIB_ABANDONED is the state of a router that has fallen back to fast OFIB_ABANDONED is the state of a router that has fallen back to fast
convergence due to the reception of link-state packets that cannot be convergence due to the reception of link-state packets that cannot be
dealt together using oFIB. dealt together using oFIB.
EVENT : Reception of a link-state packet describing a link-state EVENT : Reception of a link-state packet describing a link-state
change event. change event.
skipping to change at page 18, line 12 skipping to change at page 17, line 44
We would like to thank Jean-Philippe Vasseur and Les Ginsberg for We would like to thank Jean-Philippe Vasseur and Les Ginsberg for
their useful suggestions and comments. their useful suggestions and comments.
13. Informative References 13. Informative References
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routing information exchange protocol for use in routing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/ connectionless-mode Network Service (ISO 8473)", ISO/IEC
IEC 10589:2002, Second Edition, Nov 2002. 10589:2002, Second Edition, Nov 2002.
[refs.PFOB07] [refs.PFOB07]
P. Francois and O. Bonaventure, "Avoiding transient loops P. Francois, and O. Bonaventure, "Avoiding transient loops
during IGP convergence in IP Networks", in IEEE/ACM during IGP convergence in IP Networks", in IEEE/ACM
Transactions on Networking, http://inl.info.ucl.ac.be/ Transactions on Networking, http://inl.info.ucl.ac.be/
system/files/pfr-obo-ofib-ton.pdf, December 2007. system/files/pfr-obo-ofib-ton.pdf, December 2007.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
May 2005. 2005.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
RFC 5714, January 2010. 5714, January 2010.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010. Convergence", RFC 5715, January 2010.
[I-D.atlas-bryant-shand-lf-timers] [I-D.atlas-bryant-shand-lf-timers]
K, A. and S. Bryant, "Synchronisation of Loop Free Timer K, A. and S. Bryant, "Synchronisation of Loop Free Timer
Values", draft-atlas-bryant-shand-lf-timers-04 (work in Values", draft-atlas-bryant-shand-lf-timers-04 (work in
progress), February 2008. progress), February 2008.
[I-D.bryant-ipfrr-tunnels] [I-D.bryant-ipfrr-tunnels]
skipping to change at page 19, line 47 skipping to change at page 19, line 30
delay it may reach some routers before the timer expires and others delay it may reach some routers before the timer expires and others
after it has expired. In the former case this LSP will be included after it has expired. In the former case this LSP will be included
in the set of changes to be considered, while in the latter it will in the set of changes to be considered, while in the latter it will
be excluded leasing to serious routing inconsistency. In such cases be excluded leasing to serious routing inconsistency. In such cases
continuing to operate the loop-free convergence protocol may continuing to operate the loop-free convergence protocol may
exacerbate the situation. exacerbate the situation.
The simple approach to this would be to revert to normal convergence The simple approach to this would be to revert to normal convergence
(AAH) whenever an LSP is received after the timer has expired. (AAH) whenever an LSP is received after the timer has expired.
However this also has problems for the reasons above and therefore However this also has problems for the reasons above and therefore
AAH must be a synchronous operation, i.e. it is necessary to arrange AAH must be a synchronous operation, i.e. it is necessary to arrange
that an AAH invoked anywhere in the network causes ALL routers to that an AAH invoked anywhere in the network causes ALL routers to
AAH. AAH.
It is also necessary to consider the means of exiting the AAH state. It is also necessary to consider the means of exiting the AAH state.
Again the simplest method is to use a timer. However while in AAH Again the simplest method is to use a timer. However while in AAH
state any topology changes previously received, or which are state any topology changes previously received, or which are
subsequently received, should be processed immediately using the subsequently received, should be processed immediately using the
traditional convergence algorithms, i.e. without invoking controlled traditional convergence algorithms, i.e. without invoking controlled
convergence. If the exit from the AAH state is not correctly convergence. If the exit from the AAH state is not correctly
synchronized, a new event may be processed by some routers synchronized, a new event may be processed by some routers
immediately (as AAH), while those which have already left AAH state immediately (as AAH), while those which have already left AAH state
will treat it as the first of a new batch of changes and attempt will treat it as the first of a new batch of changes and attempt
controlled convergence. Thus both entry and exit from the AAH state controlled convergence. Thus both entry and exit from the AAH state
needs to be synchronised. A method of achieving this is described in needs to be synchronised. A method of achieving this is described in
Appendix A.3. Appendix A.3.
A.3. AAH messages A.3. AAH messages
Like the simple timer AAH method, the "AAH messages" AAH method uses Like the simple timer AAH method, the "AAH messages" AAH method uses
a hold-down to acquire a set of LSPs which should be processed a hold-down to acquire a set of LSPs which should be processed
together. On expiry of the local hold-down timer, the router begins together. On expiry of the local hold-down timer, the router begins
processing the batch of LSPs according to the loop free prevention processing the batch of LSPs according to the loop free prevention
algorithm. This is the same behaviour as the hold-down timer only algorithm. This is the same behaviour as the hold-down timer only
method. However, if any router, having started the loop-free method. However, if any router, having started the loop-free
convergence process receives an LSP which would trigger a topology convergence process receives an LSP which would trigger a topology
change, it locally abandons the controlled convergence process, and change, it locally abandons the controlled convergence process, and
sends an AAH message to all its neighbours. This eventually triggers sends an AAH message to all its neighbours. This eventually triggers
all routers to abandon the controlled convergence. The routers all routers to abandon the controlled convergence. The routers
remain in AAH state (i.e. processing topology changes using normal remain in AAH state (i.e. processing topology changes using normal
"fast" convergence), until a period of quiescence has elapsed. The "fast" convergence), until a period of quiescence has elapsed. The
exit from AAH state is synchronized by using a two step process. To exit from AAH state is synchronized by using a two step process. To
achieve the required synchronization, two additional messages are achieve the required synchronization, two additional messages are
required, AAH and AAH ACK. The AAH message is reliably exchanged required, AAH and AAH ACK. The AAH message is reliably exchanged
between neighbours using the AAH ACK message. These could be between neighbours using the AAH ACK message. These could be
implemented as a new message within the routing protocol or carried implemented as a new message within the routing protocol or carried
in existing routing hello messages. Two types of state machines are in existing routing hello messages. Two types of state machines are
needed. A per-router AAH state machine and a per neighbour AAH state needed. A per-router AAH state machine and a per neighbour AAH state
machine(PNSM). These are described below. machine(PNSM). These are described below.
A.3.1. Per Router State Machine A.3.1. Per Router State Machine
Per Router State Table Per Router State Table
+-------------+-----------+---------+--------+------------+----------+ +-------------+----------+---------+--------+------------+----------+
| EVENT | Q | Hold | CC | AAH | AAH-hold | | EVENT | Q | Hold | CC | AAH | AAH-hold |
+=============+===========+=========+========+============+==========+ +=============+==========+=========+========+============+==========+
| RX LSP | Start | - | TX-AAH | Re-start | TX-AAH | | RX LSP | Start | - | TX-AAH | Re-start | TX-AAH |
| triggering | hold-down | | Start | AAH timer. | Start | | triggering |hold-down | | Start | AAH timer. | Start |
| change | timer | | AAH | [AAH] | AAH | | change | timer | | AAH | [AAH] | AAH |
| | [Hold] | | timer. | | timer. | | | [Hold] | | timer. | | timer. |
| | | | [AAH] | | [AAH] | | | | | [AAH] | | [AAH] |
+-------------+-----------+---------+--------+------------+----------+ +-------------+----------+---------+--------+------------+----------+
| RX AAH | TX-AAH | TX-AAH | TX-AAH | [AAH] | TX-AAH | | RX AAH | TX-AAH | TX-AAH | TX-AAH | [AAH] | TX-AAH |
|(Neighbour's | Start AAH | Start | Start | | Start | |(Neighbour's |Start AAH | Start | Start | | Start |
| PNSM | timer. | AAH | AAH | | AAH | | PNSM | timer. | AAH | AAH | | AAH |
| processes | [AAH] | timer | timer. | | timer. | | processes | [AAH] | timer | timer. | | timer. |
| RX AAH.) | | [AAH] | [AAH] | | [AAH] | | RX AAH.) | | [AAH] | [AAH] | | [AAH] |
+-------------+-----------+---------+--------+------------+----------+ +-------------+----------+---------+--------+------------+----------+
| Timer | - | Trigger | - | Start | [Q] | | Timer | - | Trigger | - | Start | [Q] |
| expiry | | CC. | | AAH-hold | | | expiry | | CC. | | AAH-hold | |
| | | [CC] | | timer. | | | | | [CC] | | timer. | |
| | | | | [AAH-hold] | | | | | | | [AAH-hold] | |
+-------------+-----------+---------+--------+------------+----------+ +-------------+----------+---------+--------+------------+----------+
| Controlled | - | - | [Q] | - | - | | Controlled | - | - | [Q] | - | - |
| convergence | | | | | | | convergence | | | | | |
| completed | | | | | | | completed | | | | | |
+-------------+-----------+---------+--------+------------+----------+ +-------------+----------+---------+--------+------------+----------+
TX-AAH = Send "goto TX-AAH" to all other PNSMs. TX-AAH = Send "goto TX-AAH" to all other PNSMs.
Operation of the per-router state machine is as follows: Operation of the per-router state machine is as follows:
Operation of this state machine under normal topology change involves Operation of this state machine under normal topology change involves
only states: Quiescent (Q), Hold-down (Hold) and Controlled only states: Quiescent (Q), Hold-down (Hold) and Controlled
Convergence (CC). The remaining states are associated with an AAH Convergence (CC). The remaining states are associated with an AAH
event. event.
The resting state is Quiescent. When the router in the Quiescent The resting state is Quiescent. When the router in the Quiescent
state receives an LSP indicating a topology change, which would state receives an LSP indicating a topology change, which would
skipping to change at page 23, line 5 skipping to change at page 22, line 25
state, and it is necessary to rendezvous the entire network back to state, and it is necessary to rendezvous the entire network back to
AAH state. AAH state.
When the AAH Hold timer expires the router changes to state Quiescent When the AAH Hold timer expires the router changes to state Quiescent
and is ready for loop free convergence. and is ready for loop free convergence.
A.3.2. Per Neighbor State Machine A.3.2. Per Neighbor State Machine
Per Neighbour State Table Per Neighbour State Table
+----------------------------+--------------+------------------------+ +----------------------------+--------------+-----------------------+
| EVENT | Idle | TX-AAH | | EVENT | Idle | TX-AAH |
+============================+==============+========================+ +============================+==============+=======================+
| RX AAH | Send ACK. | Send ACK. | | RX AAH | Send ACK. | Send ACK. |
| | | Cancel timer. | | | | Cancel timer. |
| | [IDLE] | [IDLE] | | | [IDLE] | [IDLE] |
+----------------------------+--------------+------------------------+ +----------------------------+--------------+-----------------------+
| RX ACK | ignore | Cancel timer. | | RX ACK | ignore | Cancel timer. |
| | | [IDLE] | | | | [IDLE] |
+----------------------------+--------------+------------------------+ +----------------------------+--------------+-----------------------+
| RX "goto TX-AAH" from | Send AAH | ignore | | RX "goto TX-AAH" from | Send AAH | ignore |
| Router State Machine | [TX-AAH] | | | Router State Machine | [TX-AAH] | |
+----------------------------+--------------+------------------------+ +----------------------------+--------------+-----------------------+
| Timer expires | impossible | Send AAH | | Timer expires | impossible | Send AAH |
| | | Restart timer. | | | | Restart timer. |
| | | [TX-AAH] | | | | [TX-AAH] |
+----------------------------+--------------+------------------------+ +----------------------------+--------------+-----------------------+
There is one instance of the per-neighbour state machine(PNSM) for There is one instance of the per-neighbour state machine(PNSM) for
each neighbour within the convergence control domain. each neighbour within the convergence control domain.
The normal state is IDLE. The normal state is IDLE.
On command ("goto TX-AAH") from the router state machine, the state On command ("goto TX-AAH") from the router state machine, the state
machine enters TX-AAH state, transmits an AAH message to its machine enters TX-AAH state, transmits an AAH message to its
neighbour and starts a timer. neighbour and starts a timer.
skipping to change at page 27, line 4 skipping to change at page 26, line 19
Email: stbryant@cisco.com Email: stbryant@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Via Del Serafico 200 Via Del Serafico 200
00142 Roma 00142 Roma
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Brussels, Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Pierre Francois Pierre Francois
Institute IMDEA Networks Institute IMDEA Networks
Avda. del Mar Mediterraneo, 22 Avda. del Mar Mediterraneo, 22
Leganese 28918 Leganese 28918
ES ES
 End of changes. 51 change blocks. 
197 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/