diff options
Diffstat (limited to 'doc/rfc/rfc3847.txt')
| -rw-r--r-- | doc/rfc/rfc3847.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc3847.txt b/doc/rfc/rfc3847.txt new file mode 100644 index 0000000..b51fdc6 --- /dev/null +++ b/doc/rfc/rfc3847.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group M. Shand +Request for Comments: 3847 L. Ginsberg +Category: Informational Cisco Systems + July 2004 + + + Restart Signaling for + Intermediate System to Intermediate System (IS-IS) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes a mechanism for a restarting router to signal + to its neighbors that it is restarting, allowing them to reestablish + their adjacencies without cycling through the down state, while still + correctly initiating database synchronization. + + This document additionally describes a mechanism for a restarting + router to determine when it has achieved LSP database synchronization + with its neighbors and a mechanism to optimize LSP database + synchronization, while minimizing transient routing disruption when a + router starts. + + + + + + + + + + + + + + + + + + + + +Shand & Ginsberg Informational [Page 1] + +RFC 3847 Restart signaling for IS-IS July 2004 + + +Table of Contents + + 1. Conventions used in this Document. . . . . . . . . . . . . . . 2 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Restart TLV. . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2.1. Use of RR and RA Bits. . . . . . . . . . . . . . 6 + 3.2.2. Use of SA Bit. . . . . . . . . . . . . . . . . . 7 + 3.3. Adjacency (re)Acquisition. . . . . . . . . . . . . . . . 8 + 3.3.1. Adjacency Reacquisition During Restart . . . . . 8 + 3.3.2. Adjacency Acquisition During Start . . . . . . . 10 + 3.3.3. Multiple Levels. . . . . . . . . . . . . . . . . 12 + 3.4. Database Synchronization . . . . . . . . . . . . . . . . 12 + 3.4.1. LSP Generation and Flooding and SPF Computation. 13 + 3.4.1.1. Restarting. . . . . . . . . . . . . . . 13 + 3.4.1.2. Starting. . . . . . . . . . . . . . . . 15 + 4. State Tables . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 16 + 4.2. Restarting Router. . . . . . . . . . . . . . . . . . . . 17 + 4.3. Starting Router. . . . . . . . . . . . . . . . . . . . . 18 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 19 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 19 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 + 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 + +1. Conventions used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC-2119 [3]. + + If the control and forwarding functions in a router can be maintained + independently, it is possible for the forwarding function state to be + maintained across a resumption of control function operations. This + functionality is assumed when the terms "restart/restarting" are used + in this document. + + The terms "start/starting" are used to refer to a router in which the + control function has either commenced operations for the first time + or has resumed operations but the forwarding functions have not been + maintained in a prior state. + + The terms "(re)start/(re)starting" are used when the text is + applicable to both a "starting" and a "restarting" router. + + + + +Shand & Ginsberg Informational [Page 2] + +RFC 3847 Restart signaling for IS-IS July 2004 + + +2. Overview + + The Intermediate System to Intermediate System (IS-IS) routing + protocol [RFC 1195, ISO/IEC 10589] is a link state intra-domain + routing protocol. Normally, when an IS-IS router is restarted, + temporary disruption of routing occurs due to events in both the + restarting router and the neighbors of the restarting router. + + The router which has been restarted computes its own routes before + achieving database synchronization with its neighbors. The results + of this computation are likely to be non-convergent with the routes + computed by other routers in the area/domain. + + Neighbors of the restarting router detect the restart event and cycle + their adjacencies with the restarting router through the down state. + The cycling of the adjacency state causes the neighbors to regenerate + their LSPs describing the adjacency concerned. This in turn causes a + temporary disruption of routes passing through the restarting router. + + In certain scenarios, the temporary disruption of the routes is + highly undesirable. This document describes mechanisms to avoid or + minimize the disruption due to both of these causes. + + When an adjacency is reinitialized as a result of a neighbor + restarting, a router does three things: + + 1. It causes its own LSP(s) to be regenerated, thus triggering SPF + runs throughout the area (or in the case of Level 2, throughout + the domain). + + 2. It sets SRMflags on its own LSP database on the adjacency + concerned. + + 3. In the case of a Point-to-Point link, it transmits a (set of) + CSNP(s) over the adjacency. + + In the case of a restarting router process, the first of these is + highly undesirable, but the second is essential in order to ensure + synchronization of the LSP database. + + The third action above minimizes the number of LSPs which must be + exchanged and, if made reliable, provides a means of determining when + the LSP databases of the neighboring routers have been synchronized. + This is desirable whether the router is being restarted or not (so + that the overload bit can be cleared in the router's own LSP, for + example). + + + + + +Shand & Ginsberg Informational [Page 3] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + This document describes a mechanism for a restarting router to signal + that it is restarting to its neighbors, and allow them to reestablish + their adjacencies without cycling through the down state, while still + correctly initiating database synchronization. + + This document additionally describes a mechanism for a restarting + router to determine when it has achieved LSP database synchronization + with its neighbors and a mechanism to optimize LSP database + synchronization and minimize transient routing disruption when a + router starts. + + It is assumed that the three-way handshake [4] is being used on + Point-to-Point circuits. + +3. Approach + +3.1. Timers + + Three additional timers, T1, T2, and T3 are required to support the + functionality defined in this document. + + An instance of the timer T1 is maintained per interface, and + indicates the time after which an unacknowledged (re)start attempt + will be repeated. A typical value might be 3 seconds. + + An instance of the timer T2 is maintained for each LSP database + present in the system, i.e., for a Level1/2 system, there will be an + instance of the timer T2 for Level 1 and an instance for Level 2. + This is the maximum time that the system will wait for LSPDB + synchronization. A typical value might be 60 seconds. + + A single instance of the timer T3 is maintained for the entire + system. It indicates the time after which the router will declare + that it has failed to achieve database synchronization (by setting + the overload bit in its own LSP). This is initialized to 65535 + seconds, but is set to the minimum of the remaining times of received + IIHs containing a restart TLV with the RA set and an indication that + the neighbor has an adjacency in the "UP" state to the restarting + router. + + NOTE: The timer T3 is only used by a restarting router. + + + + + + + + + + +Shand & Ginsberg Informational [Page 4] + +RFC 3847 Restart signaling for IS-IS July 2004 + + +3.2. Restart TLV + + A new TLV is defined to be included in IIH PDUs. The presence of + this TLV indicates that the sender supports the functionality defined + in this document and it carries flags that are used to convey + information during a (re)start. All IIHs transmitted by a router + that supports this capability MUST include this TLV. + + Type 211 + Length # of octets in the value field (1 to (3 + ID Length)) + Value + + No. of octets + +-----------------------+ + | Flags | 1 + +-----------------------+ + | Remaining Time | 2 + +-----------------------+ + | Restarting Neighbor ID| ID Length + +-----------------------+ + + + Flags (1 octet) + + 0 1 2 3 4 5 6 7 + +--+--+--+--+--+--+--+--+ + | Reserved |SA|RA|RR| + +--+--+--+--+--+--+--+--+ + + + RR - Restart Request + RA - Restart Acknowledgement + SA - Suppress adjacency advertisement + + + (Note: Remaining fields are required when the RA bit is set) + + Remaining Time (2 octets) + + Remaining holding time (in seconds) + + Restarting Neighbor System ID (ID Length octets) + + The system ID of the neighbor to which an RA refers. Note: + Implementations based on earlier versions of this document may not + include this field in the TLV when the RA is set. In this case, a + router which is expecting an RA on a LAN circuit SHOULD assume that + the acknowledgement is directed at the local system. + + + +Shand & Ginsberg Informational [Page 5] + +RFC 3847 Restart signaling for IS-IS July 2004 + + +3.2.1. Use of RR and RA Bits + + The RR bit is used by a (re)starting router to signal to its + neighbors that a (re)start is in progress, that an existing adjacency + SHOULD be maintained even under circumstances when the normal + operation of the adjacency state machine would require the adjacency + to be reinitialized, to request a set of CSNPs, and to request + setting of the SRMflags. + + The RA bit is sent by the neighbor of a (re)starting router to + acknowledge the receipt of a restart TLV with the RR bit set. + + When the neighbor of a (re)starting router receives an IIH with the + restart TLV having the RR bit set, if there exists on this interface + an adjacency in state "UP" with the same System ID, and in the case + of a LAN circuit, with the same source LAN address, then, + irrespective of the other contents of the "Intermediate System + Neighbors" option (LAN circuits) or the "Point-to-Point Three-Way + Adjacency" option (Point-to-Point circuits): + + a) the state of the adjacency is not changed. If this is the first + IIH with the RR bit set that this system has received associated + with this adjacency, then the adjacency is marked as being in + "Restart mode" and the adjacency holding time is refreshed - + otherwise the holding time is not refreshed. The "remaining time" + transmitted according to (b) below MUST reflect the actual time + after which the adjacency will now expire. Receipt of a normal + IIH with the RR bit reset will clear the "Restart mode" state. + This procedure allows the restarting router to cause the neighbor + to maintain the adjacency long enough for restart to successfully + complete while also preventing repetitive restarts from + maintaining an adjacency indefinitely. Whether an adjacency is + marked as being in "Restart mode" or not has no effect on + adjacency state transitions. + + b) immediately (i.e., without waiting for any currently running timer + interval to expire, but with a small random delay of a few 10s of + milliseconds on LANs to avoid "storms") transmit over the + corresponding interface an IIH including the restart TLV with the + RR bit clear and the RA bit set, in the case of Point-to-Point + adjacencies having updated the "Point-to-Point Three-Way + Adjacency" option to reflect any new values received from the + (re)starting router. (This allows a restarting router to quickly + acquire the correct information to place in its hellos.) The + "Remaining Time" MUST be set to the current time (in seconds) + before the holding timer on this adjacency is due to expire. If + the corresponding interface is a LAN interface, then the + Restarting Neighbor System ID SHOULD be set to the System ID of + + + +Shand & Ginsberg Informational [Page 6] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + the router from whom the IIH with the RR bit set was received. + This is required to correctly associate the acknowledgement and + holding time in the case where multiple systems on a LAN restart + at approximately the same time. This IIH SHOULD be transmitted + before any LSPs or SNPs are transmitted as a result of the receipt + of the original IIH. + + c) if the corresponding interface is a Point-to-Point interface, or + if the receiving router has the highest LnRouterPriority (with + highest source MAC address breaking ties) among those routers to + which the receiving router has an adjacency in state "UP" on this + interface whose IIHs contain the restart TLV, excluding + adjacencies to all routers which are considered in "Restart mode" + (note the actual DIS is NOT changed by this process), initiate the + transmission over the corresponding interface of a complete set of + CSNPs, and set SRMflags on the corresponding interface for all + LSPs in the local LSP database. + + Otherwise (i.e., if there was no adjacency in the "UP" state to the + system ID in question), process the IIH as normal by reinitializing + the adjacency and setting the RA bit in the returned IIH. + +3.2.2. Use of the SA Bit + + The SA bit is used by a starting router to request that its neighbor + suppress advertisement of the adjacency to the starting router in the + neighbor's LSPs. + + A router which is starting has no maintained forwarding function + state. This may or may not be the first time the router has started. + If this is not the first time the router has started, copies of LSPs + generated by this router in its previous incarnation may exist in the + LSP databases of other routers in the network. These copies are + likely to appear "newer" than LSPs initially generated by the + starting router due to the reinitialization of LSP fragment sequence + numbers by the starting router. This may cause temporary blackholes + to occur until the normal operation of the update process causes the + starting router to regenerate and flood copies of its own LSPs with + higher sequence numbers. The temporary blackholes can be avoided if + the starting router's neighbors suppress advertising an adjacency to + the starting router until the starting router has been able to + propagate newer versions of LSPs generated by previous incarnations. + + When a router receives an IIH with the restart TLV having the SA bit + set, if there exists on this interface an adjacency in state "UP" + with the same System ID, and in the case of a LAN circuit, with the + same source LAN address, then the router MUST suppress advertisement + of the adjacency to the neighbor in its own LSPs. Until an IIH with + + + +Shand & Ginsberg Informational [Page 7] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + the SA bit clear has been received, the neighbor advertisement MUST + continue to be suppressed. If the adjacency transitions to the "UP" + state, the new adjacency MUST NOT be advertised until an IIH with the + SA bit clear has been received. + + Note that a router which suppresses advertisement of an adjacency + MUST NOT use this adjacency when performing its SPF calculation. In + particular, if an implementation follows the example guidelines + presented in [2] Annex C.2.5 Step 0:b) "pre-load TENT with the local + adjacency database", the suppressed adjacency MUST NOT be loaded into + TENT. + +3.3. Adjacency (Re)Acquisition + + Adjacency (re)acquisition is the first step in (re)initialization. + Restarting and starting routers will make use of the RR bit in the + restart TLV, though each will use it at different stages of the + (re)start procedure. + +3.3.1. Adjacency Reacquisition During Restart + + The restarting router explicitly notifies its neighbor that the + adjacency is being reacquired, and hence that it SHOULD NOT + reinitialize the adjacency. This is achieved by setting the RR bit + in the restart TLV. When the neighbor of a restarting router + receives an IIH with the restart TLV having the RR bit set, if there + exists on this interface an adjacency in state "UP" with the same + System ID, and in the case of a LAN circuit, with the same source LAN + address, then the procedures described in 3.2.1 are followed. + + A router that does not support the restart capability will ignore the + restart TLV and reinitialize the adjacency as normal, returning an + IIH without the restart TLV. + + On restarting, a router initializes the timer T3, starts the timer T2 + for each LSPDB, and for each interface (and in the case of a LAN + circuit, for each level) starts the timer T1 and transmits an IIH + containing the restart TLV with the RR bit set. + + On a Point-to-Point circuit the restarting router SHOULD set the + "Adjacency Three-Way State" to "Init", because the receipt of the + acknowledging IIH (with RA set) MUST cause the adjacency to enter the + "UP" state immediately. + + On a LAN circuit the LAN-ID assigned to the circuit SHOULD be the + same as that used prior to the restart. In particular, for any + circuits for which the restarting router was previously DIS, the use + of a different LAN-ID would necessitate the generation of a new set + + + +Shand & Ginsberg Informational [Page 8] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + of pseudonode LSPs, and corresponding changes in all the LSPs + referencing them from other routers on the LAN. By preserving the + LAN-ID across the restart, this churn can be prevented. To enable a + restarting router to learn the LAN-ID used prior to restart, the + LAN-ID specified in an IIH with RR set MUST be ignored. + + Transmission of "normal" IIHs is inhibited until the conditions + described below are met (in order to avoid causing an unnecessary + adjacency initialization). Upon expiry of the timer T1, it is + restarted and the IIH is retransmitted as above. + + When a restarting router receives an IIH a local adjacency is + established as usual, and if the IIH contains a restart TLV with the + RA bit set (and on LAN circuits with a Restart Neighbor System ID + which matches that of the local system), the receipt of the + acknowledgement over that interface is noted. When the RA bit is set + and the state of the remote adjacency is "UP", then the timer T3 is + set to the minimum of its current value and the value of the + "Remaining Time" field in the received IIH. + + On a Point-to-Point link, receipt of an IIH not containing the + restart TLV is also treated as an acknowledgement, since it indicates + that the neighbor is not restart capable. However, since no CSNP is + guaranteed to be received over this interface, the timer T1 is + cancelled immediately without waiting for a complete set of CSNP(s). + Synchronization may therefore be deemed complete even though there + are some LSPs which are held (only) by this neighbor (see section + 3.4). In this case we also want to be certain that the neighbor will + reinitialize the adjacency in order to guarantee that the SRMflags + have been set on its database, thus ensuring eventual LSPDB + synchronization. This is guaranteed to happen except in the case + where the Adjacency Three-Way State in the received IIH is "UP" and + the Neighbor Extended Local Circuit ID matches the extended local + circuit ID assigned by the restarting router. In this case the + restarting router MUST force the adjacency to reinitialize by setting + the local Adjacency Three-Way State to "DOWN" and sending a normal + IIH. + + In the case of a LAN interface, receipt of an IIH not containing the + restart TLV is unremarkable since synchronization can still occur so + long as at least one of the non-restarting neighboring routers on the + LAN supports restart. Therefore T1 continues to run in this case. + If none of the neighbors on the LAN are restart capable, T1 will + eventually expire after the locally defined number of retries. + + In the case of a Point-to-Point circuit, the "LocalCircuitID" and + "Extended Local Circuit ID" information contained in the IIH can be + used immediately to generate an IIH containing the correct 3-way + + + +Shand & Ginsberg Informational [Page 9] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + handshake information. The presence of "Neighbor Extended Local + Circuit ID" information which does not match the value currently in + use by the local system is ignored (since the IIH may have been + transmitted before the neighbor had received the new value from the + restarting router), but the adjacency remains in the initializing + state until the correct information is received. + + In the case of a LAN circuit, the source neighbor information (e.g., + SNPAAddress) is recorded and used for adjacency establishment and + maintenance as normal. + + When BOTH a complete set of CSNP(s) (for each active level, in the + case of a point-to-point circuit) and an acknowledgement have been + received over the interface, the timer T1 is cancelled. + + Once the timer T1 has been cancelled, subsequent IIHs are transmitted + according to the normal algorithms, but including the restart TLV + with both RR and RA clear. + + If a LAN contains a mixture of systems, only some of which support + the new algorithm, database synchronization is still guaranteed, but + the "old" systems will have reinitialized their adjacencies. + + If an interface is active, but does not have any neighboring router + reachable over that interface, the timer T1 would never be cancelled, + and according to clause 3.4.1.1, the SPF would never be run. + Therefore timer T1 is cancelled after some pre-determined number of + expirations (which MAY be 1). + +3.3.2. Adjacency Acquisition During Start + + The starting router wants to ensure that in the event that a + neighboring router has an adjacency to the starting router in the + "UP" state (from a previous incarnation of the starting router), this + adjacency is reinitialized. The starting router also wants + neighboring routers to suppress advertisement of an adjacency to the + starting router until LSP database synchronization is achieved. This + is achieved by sending IIHs with the RR bit clear and the SA bit set + in the restart TLV. The RR bit remains clear and the SA bit remains + set in subsequent transmissions of IIHs until the adjacency has + reached the "UP" state and the initial T1 timer interval (see below) + has expired. + + Receipt of an IIH with the RR bit clear will result in the + neighboring router utilizing normal operation of the adjacency state + machine. This will ensure that any old adjacency on the neighboring + router will be reinitialized. + + + + +Shand & Ginsberg Informational [Page 10] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + Upon receipt of an IIH with the SA bit set, the behavior described in + 3.2.2 is followed. + + Upon starting, a router starts timer T2 for each LSPDB. + + For each interface (and in the case of a LAN circuit, for each + level), when an adjacency reaches the "UP" state, the starting router + starts a timer T1 and transmits an IIH containing the restart TLV + with the RR bit clear and SA bit set. Upon expiry of the timer T1, + it is restarted and the IIH is retransmitted with both RR and SA bits + set (only the RR bit has changed state from earlier IIHs). + + Upon receipt of an IIH with the RR bit set (regardless of whether the + SA is set or not), the behavior described in 3.2.1 is followed. + + When an IIH is received by the starting router and the IIH contains a + restart TLV with the RA bit set (and on LAN circuits with a Restart + Neighbor System ID which matches that of the local system), the + receipt of the acknowledgement over that interface is noted. + + On a Point-to-Point link, receipt of an IIH not containing the + restart TLV is also treated as an acknowledgement, since it indicates + that the neighbor is not restart capable. Since the neighbor will + have reinitialized the adjacency, this guarantees that SRMflags have + been set on its database, thus ensuring eventual LSPDB + synchronization. However, since no CSNP is guaranteed to be received + over this interface, the timer T1 is cancelled immediately without + waiting for a complete set of CSNP(s). Synchronization may therefore + be deemed complete even though there are some LSPs which are held + (only) by this neighbor (see section 3.4). + + In the case of a LAN interface, receipt of an IIH not containing the + restart TLV is unremarkable since synchronization can still occur so + long as at least one of the non-restarting neighboring routers on the + LAN supports restart. Therefore T1 continues to run in this case. + If none of the neighbors on the LAN are restart capable, T1 will + eventually expire after the locally defined number of retries. The + usual operation of the update process will ensure that + synchronization is eventually achieved. + + When BOTH a complete set of CSNP(s) (for each active level, in the + case of a point-to-point circuit) and an acknowledgement have been + received over the interface, the timer T1 is cancelled. Subsequent + IIHs sent by the starting router have the RR and RA bits clear and + the SA bit set in the restart TLV. + + Timer T1 is cancelled after some pre-determined number of expirations + (which MAY be 1). + + + +Shand & Ginsberg Informational [Page 11] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + When the T2 timer(s) are cancelled or expire, transmission of + "normal" IIHs (with RR, RA, and SA bits clear) will begin. + +3.3.3. Multiple Levels + + A router which is operating as both a Level 1 and a Level 2 router on + a particular interface MUST perform the above operations for each + level. + + On a LAN interface, it MUST send and receive both Level 1 and Level 2 + IIHs and perform the CSNP synchronizations independently for each + level. + + On a point-to-point interface, only a single IIH (indicating support + for both levels) is required, but it MUST perform the CSNP + synchronizations independently for each level. + +3.4. Database Synchronization + + When a router is started or restarted it can expect to receive a (set + of) CSNP(s) over each interface. The arrival of the CSNP(s) is now + guaranteed, since an IIH with the RR bit set will be retransmitted + until the CSNP(s) are correctly received. + + The CSNPs describe the set of LSPs that are currently held by each + neighbor. Synchronization will be complete when all these LSPs have + been received. + + When (re)starting, a router starts an instance of timer T2 for each + LSPDB as described in 3.3.1 or 3.3.2. In addition to normal + processing of the CSNPs, the set of LSPIDs contained in the first + complete set of CSNP(s) received over each interface is recorded, + together with their remaining lifetime. In the case of a LAN + interface, a complete set of CSNPs MUST consist of CSNPs received + from neighbor(s) which are not restarting. If there are multiple + interfaces on the (re)starting router, the recorded set of LSPIDs is + the union of those received over each interface. LSPs with a + remaining lifetime of zero are NOT so recorded. + + As LSPs are received (by the normal operation of the update process) + over any interface, the corresponding LSPID entry is removed (it is + also removed if an LSP arrives before the CSNP containing the + reference). When an LSPID has been held in the list for its + indicated remaining lifetime, it is removed from the list. When the + list of LSPIDs is empty and the timer T1 has been cancelled for all + the interfaces that have an adjacency at this level, the timer T2 is + cancelled. + + + + +Shand & Ginsberg Informational [Page 12] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + At this point, the local database is guaranteed to contain all the + LSP(s) (either the same sequence number, or a more recent sequence + number) that were present in the neighbors' databases at the time of + (re)starting. LSPs that arrived in a neighbor's database after the + time of (re)starting may or may not be present, but the normal + operation of the update process will guarantee that they will + eventually be received. At this point, the local database is deemed + to be "synchronized". + + Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime + are not recorded, and those with a short remaining lifetime are + deleted from the list when the lifetime expires, cancellation of the + timer T2 will not be prevented by waiting for an LSP that will never + arrive. + +3.4.1. LSP Generation and Flooding and SPF Computation + + The operation of a router starting, as opposed to restarting, is + somewhat different. These two cases are dealt with separately below. + +3.4.1.1. Restarting + + In order to avoid causing unnecessary routing churn in other routers, + it is highly desirable that the router's own LSPs generated by the + restarting system are the same as those previously present in the + network (assuming no other changes have taken place). It is + important therefore not to regenerate and flood the LSPs until all + the adjacencies have been re-established and any information required + for propagation into the local LSPs is fully available. Ideally, the + information is loaded into the LSPs in a deterministic way, such that + the same information occurs in the same place in the same LSP (and + hence the LSPs are identical to their previous versions). If this + can be achieved, the new versions may not even cause SPF to be run in + other systems. However, provided the same information is included in + the set of LSPs (albeit in a different order, and possibly different + LSPs), the result of running the SPF will be the same and will not + cause churn to the forwarding tables. + + In the case of a restarting router, none of the router's own LSPs are + transmitted, nor are the router's own forwarding tables updated while + the timer T3 is running. + + Redistribution of inter-level information MUST be regenerated before + this router's LSP is flooded to other nodes. Therefore, the Level-n + non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 + timer has expired and its SPF has been run. This ensures that any + inter-level information which is to be propagated can be included in + the Level-n LSP(s). + + + +Shand & Ginsberg Informational [Page 13] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + During this period, if one of the router's own (including + pseudonodes) LSPs is received, which the local router does not + currently have in its own database, it is NOT purged. Under normal + operation, such an LSP would be purged, since the LSP clearly should + not be present in the global LSP database. However, in the present + circumstances, this would be highly undesirable, because it could + cause premature removal of a router's own LSP - and hence churn in + remote routers. Even if the local system has one or more of the + router's own LSPs (which it has generated, but not yet transmitted), + it is still not valid to compare the received LSP against this set, + since it may be that as a result of propagation between Level 1 and + Level 2 (or vice versa), a further router's own LSP will need to be + generated when the LSP databases have synchronized. + + During this period a restarting router SHOULD send CSNPs as it + normally would. Information about the router's own LSPs MAY be + included, but if it is included it MUST be based on LSPs which have + been received, not on versions which have been generated (but not yet + transmitted). This restriction is necessary to prevent premature + removal of an LSP from the global LSP database. + + When the timer T2 expires or is cancelled indicating that + synchronization for that level is complete, the SPF for that level is + run in order to derive any information which is required to be + propagated to another level, but the forwarding tables are not yet + updated. + + Once the other level's SPF has run and any inter-level propagation + has been resolved, the router's own LSPs can be generated and + flooded. Any own LSPs which were previously ignored, but which are + not part of the current set of own LSPs (including pseudonodes) MUST + then be purged. Note that it is possible that a Designated Router + change may have taken place, and consequently the router SHOULD purge + those pseudonode LSPs which it previously owned, but which are now no + longer part of its set of pseudonode LSPs. + + When all the T2 timers have expired or been cancelled, the timer T3 + is cancelled and the local forwarding tables are updated. + + If the timer T3 expires before all the T2 timers have expired or been + cancelled, this indicates that the synchronization process is taking + longer than the minimum holding time of the neighbors. The router's + own LSP(s) for levels which have not yet completed their first SPF + computation are then flooded with the overload bit set to indicate + that the router's LSPDB is not yet synchronized (and therefore other + routers MUST NOT compute routes through this router). Normal + operation of the update process resumes and the local forwarding + tables are updated. In order to prevent the neighbor's adjacencies + + + +Shand & Ginsberg Informational [Page 14] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + from expiring, IIHs with the normal interface value for the holding + time are transmitted over all interfaces with neither RR nor RA set + in the restart TLV. This will cause the neighbors to refresh their + adjacencies. The router's own LSP(s) will continue to have the + overload bit set until timer T2 has expired or been cancelled. + +3.4.1.2. Starting + + In the case of a starting router, as soon as each adjacency is + established, and before any CSNP exchanges, the router's own zeroth + LSP is transmitted with the overload bit set. This prevents other + routers from computing routes through the router until it has + reliably acquired the complete set of LSPs. The overload bit remains + set in subsequent transmissions of the zeroth LSP (such as will occur + if a previous copy of the router's own zeroth LSP is still present in + the network) while any timer T2 is running. + + When all the T2 timers have been cancelled, the router's own LSP(s) + MAY be regenerated with the overload bit clear (assuming the router + is not in fact overloaded, and there is no other reason, such as + incomplete BGP convergence, to keep the overload bit set) and flooded + as normal. + + Other LSPs owned by this router (including pseudonodes) are generated + and flooded as normal, irrespective of the timer T2. The SPF is also + run as normal and the RIB and FIB updated as routes become available. + + To avoid the possible formation of temporary blackholes, the starting + router sets the SA bit in the restart TLV (as described in 3.3.2) in + all IIHs that it sends. + + When all T2 timers have been cancelled, the starting router MUST + transmit IIHs with the SA bit clear. + +4. State Tables + + This section presents state tables which summarize the behaviors + described in this document. Other behaviors, in particular adjacency + state transitions and LSP database update operation, are NOT included + in the state tables except where this document modifies the behaviors + described in [2] and [4]. + + The states named in the columns of the tables below are a mixture of + states that are specific to a single adjacency (ADJ suppressed, ADJ + Seen RA, ADJ Seen CSNP) and states which are indicative of the state + of the protocol instance (Running, Restarting, Starting, SPF Wait). + + + + + +Shand & Ginsberg Informational [Page 15] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + Three state tables are presented from the point of view of a running + router, a restarting router, and a starting router. + +4.1. Running Router + + Event | Running | ADJ suppressed +============================================================== + RX RR | Maintain ADJ State | + | Send RA | + | Set SRM,send CSNP | + | (Note 1) | + | Update Hold Time, | + | set Restart Mode | + | (Note 2) | +-------------+----------------------+------------------------- + RX RR clr | Clr Restart mode | +-------------+----------------------+------------------------- + RX SA | Suppress IS neighbor | + | TLV in LSP(s) | + | Goto ADJ Suppressed | +-------------+----------------------+------------------------- + RX SA clr | |Unsuppress IS neighbor + | | TLV in LSP(s) + | |Goto Running +============================================================== + + Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c + Note 2: If Restart Mode clear + + + + + + + + + + + + + + + + + + + + + + + +Shand & Ginsberg Informational [Page 16] + +RFC 3847 Restart signaling for IS-IS July 2004 + + +4.2. Restarting Router + + Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait + | | RA | CSNP | +=================================================================== + Router | Send IIH/RR | | | + restarts | ADJ Init | | | + | Start T1,T2,T3 | | | +------------+--------------------+-----------+-----------+------------ + RX RR | Send RA | | | +------------+--------------------+-----------+-----------+------------ + RX RA | Adjust T3 | | Cancel T1 | + | Goto ADJ Seen RA | | Adjust T3 | +----------- +--------------------+-----------+-----------+------------ + RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | +------------+--------------------+-----------+-----------+------------ + RX IIH w/o | Cancel T1 (Point- | | | + Restart TLV| to-point only) | | | +------------+--------------------+-----------+-----------+------------ + T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| + | Restart T1 | Restart T1| Restart T1| +------------+--------------------+-----------+-----------+------------ + T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | + nth time | normal | normal | normal | +------------+--------------------+-----------+-----------+------------ + T2 expires | Trigger SPF | | | + | Goto SPF Wait | | | +------------+--------------------+-----------+-----------+------------ + T3 expires | Set OL | | | + | Flood local LSPs | | | + | Update fwd plane | | | +------------+--------------------+-----------+-----------+------------ + LSP DB Sync| Cancel T2, and T3 | | | + | Trigger SPF | | | + | Goto SPF wait | | | +------------+--------------------+-----------+-----------+------------ +All SPF | | | | Clear OL + done | | | | Update fwd + | | | | plane + | | | | Flood local + | | | | LSPs + | | | | Goto Running +====================================================================== + + + + + + + + +Shand & Ginsberg Informational [Page 17] + +RFC 3847 Restart signaling for IS-IS July 2004 + + +4.3. Starting Router + + Event | Starting | ADJ Seen RA| ADJ Seen CSNP +============================================================= +Router | Send IIH/SA | | + starts | Start T1,T2 | | +-------------+-------------------+------------+--------------- +RX RR | Send RA | | +-------------+-------------------+------------+--------------- +RX RA | Goto ADJ Seen RA | | Cancel T1 +-------------+-------------------+------------+--------------- +RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | +-------------+-------------------+------------+--------------- +RX IIH w | Cancel T1 | | + no Restart | (Point-to-Point | | + TLV | only) | | +-------------+-------------------+------------+--------------- +ADJ UP | Start T1 | | + | Send local LSPs | | + | w OL | | +-------------+-------------------+------------+--------------- +T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR + | and SA | and SA | and SA + | Restart T1 |Restart T1 | Restart T1 +-------------+-------------------+------------+--------------- +T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA + nth time | | | +-------------+-------------------+------------+--------------- +T2 expires | Clear OL | | + | Send IIH normal | | + | Goto Running | | +-------------+-------------------+------------+--------------- +LSP DB Sync | Cancel T2 | | + | Clear OL | | + | Send IIH normal | | +============================================================== + +5. Security Considerations + + Any new security issues raised by the procedures in this document + depend upon the ability of an attacker to inject a false but + apparently valid IIH, the ease/difficulty of which has not been + altered. + + + + + + + + +Shand & Ginsberg Informational [Page 18] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + If the RR bit is set in a false IIH, neighbors who receive such an + IIH will continue to maintain an existing adjacency in the "UP" state + and may (re)send a complete set of CSNPs. While the latter action is + wasteful, neither action causes any disruption in correct protocol + operation. + + If the RA bit is set in a false IIH, a (re)starting router which + receives such an IIH may falsely believe that there is a neighbor on + the corresponding interface which supports the procedures described + in this document. In the absence of receipt of a complete set of + CSNPs on that interface, this could delay the completion of (re)start + procedures by requiring the timer T1 to time out the locally defined + maximum number of retries. This behavior is the same as would occur + on a LAN where none of the (re)starting router's neighbors support + the procedures in this document and is covered in Sections 3.3.1 and + 3.3.2. + + If an SA bit is set in a false IIH, this could cause suppression of + the advertisement of an IS neighbor which could either continue for + an indefinite period, or occur intermittently with the result being a + possible loss of reachability to some destinations in the network + and/or increased frequency of LSP flooding and SPF calculation. + + The possibility of IS-IS PDU spoofing can be reduced by the use of + authentication as described in [1] and [2], and especially the use of + cryptographic authentication as described in [5]. + +6. IANA Considerations + + This document defines the following IS-IS TLV that is listed in the + IS-IS TLV code-point registry: + + Type Description IIH LSP SNP + ---- ----------------------------------- --- --- --- + 211 Restart TLV y n n + +7. Normative References + + [1] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, + December 1990. + + [2] ISO, "Intermediate system to Intermediate system routeing + information exchange protocol for use in conjunction with the + Protocol for providing the Connectionless-mode Network Service + (ISO 8473)," ISO/IEC 10589:2002, Second Edition. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + +Shand & Ginsberg Informational [Page 19] + +RFC 3847 Restart signaling for IS-IS July 2004 + + + [4] Katz, D. and R. Saluja, "Three-Way Handshake for IS-IS Point- + to-Point Adjacencies", RFC 3373, September 2002. + + [5] Li, T. and R. Atkinson, "Intermediate System to Intermediate + System (IS-IS) Cryptographic Authentication", RFC 3567, July + 2003. + +8. Acknowledgements + + The authors would like to acknowledge contributions made by Jeff + Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, + Russ White, and Rena Yang. + +9. Authors' Addresses + + Mike Shand + Cisco Systems + 250 Longwater Avenue, + Reading, + Berkshire, + RG2 6GB + UK + Phone: +44 208 824 8690 + + EMail: mshand@cisco.com + + + Les Ginsberg + Cisco Systems + 510 McCarthy Blvd. + Milpitas, Ca. 95035 USA + + EMail: ginsberg@cisco.com + + + + + + + + + + + + + + + + + + +Shand & Ginsberg Informational [Page 20] + +RFC 3847 Restart signaling for IS-IS July 2004 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Shand & Ginsberg Informational [Page 21] + |