Network Working Group Amir Hermelin Internet Draft Charlotte's Web Networks Expiration Date: February 2002 Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit draft-hermelin-ext-lsp-frags-02.txt Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. A. Hermelin Expires February 2002 [Page 1] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 1. Introduction In the IS-IS protocol, a system floods its link-state information in Link State Protocol Data Units, or LSPs for short. These logical LSPs can become quite large, therefore the protocol specifies a means of fragmenting this information into multiple LSP fragments. The number of fragments a system can generate is limited by ISO 10589 [ISIS-ISO] to 256 fragments, where each fragment's size is also limited. Hence, there is a limit on the amount of link-state information a system can generate. A number of factors can contribute to exceeding this limit: - Introduction of new TLVs and sub-TLVs to be included in LSPs. - The use of LSPs to propagate various types of information (such as traffic-engineering information). - The growing size of route tables and AS topologies. - Finer granularity routing, and the ability to inject external routes into areas [DOMAIN-WIDE]. This document describes a mechanism to relax the limit on the number of LSP fragments. 1.1 Definitions of Commonly Used Terms This section provides definitions for terms that are used throughout the text. Originating System A router running the IS-IS protocol. Original system-id The system-id of an Originating System. Extended system-id An additional system-id that is assigned by the network administrator. Each extended system-id allows generation of 256 additional, or extended, LSP fragments. The extended system-id, like the original system-id, must be unique throughout the routing domain. Virtual System The system, identified by an extended system-id, advertised as originating the extended LSP fragments. These fragments specify the extended system-id in their LSP IDs. Original LSP A. Hermelin Expires February 2002 [Page 2] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 An LSP using the original system-id in its LSP ID. Extended LSP An LSP using an extended system-id in its LSP ID. LSP set A group of LSP fragments constituting a logical LSP. These share a specific system-id and pseudonode number, and differ only in their LSP (or fragment) number. Extended LSP set A group of LSP fragments using an extended system-id, and originated by the Originating System. These fragments appear to other routers as having been originated by the Virtual System identified by an extended system-id. Extension-capable IS An IS implementing this extension. 1.2 Operation Modes Two administrative operation modes are provided: - Operation Mode 1 provides behavior that allows previous implementations to correctly process the extended fragment information, without any modifications to the SPF algorithm. This mode has some restrictions on what may be advertised in the extended LSP fragments. Namely, only leaf information may be advertised in the extended LSPs. - Operation Mode 2 extends the previous mode and relaxes its advertisement restrictions. Any link-state information may be advertised in the extended LSPs. However, it mandates a change to the SPF algorithm, in a way that isn't compatible with previous implementations. An L1 area, or the L2 domain, cannot be switched over to work in Mode 2, until all routers in that domain have been upgraded. These modes may be configured per level. There is no restriction that an L1/L2 IS operates in the same mode, for both L1 and L2. 1.3 Overview Using additional system-ids assigned by the administrator, the Originating System can advertise the excess link-state information in A. Hermelin Expires February 2002 [Page 3] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 extended LSPs under these extended system-ids. It would do so as if other routers, or "Virtual Systems", were advertising this information. These extended LSPs will also have the specified limit on their LSP fragments; however, the Originating System may generate extended LSPs under numerous Virtual Systems. Two new TLVs are introduced: the Extended Capabilities (EC) TLV and the Short-Circuit IS Neighbor (SC-ISN) TLV. These TLVs are necessary to correctly operate in Operation Mode 2, but are advertised by all extension-capable ISs, regardless of the mode they operate. For Operation Mode 1, 0-cost adjacencies are advertised from the Originating System to its Virtual System(s). No adjacencies (other than back to the Originating System) are advertised in the extended LSPs. As a consequence, the Virtual Systems are 'stub', meaning they can only be reached through their Originating System. Therefore, older implementations do not need to modify their SPF computation in order to correctly process these extended LSPs. For both modes, short-circuit adjacencies are advertised between the Originating System and its Virtual System(s). Extension-capable ISs can then use this information during their SPF, and can combine the original and extended LSPs into one single logical LSP. Note, that in either mode, no connections are advertised between two Virtual Systems. 2.0 Extended Capabilities TLV The proposed Extended Capabilities TLV allows a router to advertise support for this extension, as well as other capabilities that might be provided in the future. This TLV MUST appear only in LSP Number 0; it SHOULD be ignored when encountered in other LSP fragments. The type of the Extended Capabilities TLV is 23. The body contains only sub-TLVs, in the form: 0-255 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length 0-253 octets of value This body can only appear once within a TLV; therefore, the total length of the sub-TLVs can be inferred from the length of the TLV itself. This TLV may be repeated multiple times, to describe more information than can fit in a single TLV. A. Hermelin Expires February 2002 [Page 4] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 In addition, a new sub-TLV for the Extended Capabilities TLV is proposed here. This is the Extended LSP Fragments Capability sub- TLV. Routers implementing this extension MUST include the Extended Capabilities TLV, along with the Extended LSP Fragments Capability sub-TLV, in both their original and extended LSPs. 2.1 Extended LSP Fragments Capability sub-TLV The sub-TLV type is 1. The length is 1 octet, consisting of flags. 0x01 Operation Mode 2 This flag is set if the IS is operating in Operation Mode 2, and unset otherwise. 0x02 Originating System This flag is set if this LSP is an original LSP (that is, the system-id is the Original system-id), and unset otherwise. 3.0 Short-Circuit IS Neighbor TLV The proposed Short-Circuit IS Neighbor allows extension-capable ISs to recognize all extended LSPs of an Originating System, and combine the original and extended LSPs for the purpose of SPF computation. The Short-Circuit IS Neighbor TLV is type 24, and contains a new data structure, consisting of: 7 octets of system Id and pseudonode number 1 octet of length of sub-TLVs 0-247 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length 0-245 octets of value Without sub-TLVs, this structure consumes 8 octets per short-circuit neighbor. To indicate multiple short-citcuits, this structure can be repeated within the Short-Circuit IS Neighbor TLV. A single TLV can describe up to 31 short-circuit neighbors. This TLV may be repeated multiple times to describe more SC-neighbors. 4.0 Generating LSPs A. Hermelin Expires February 2002 [Page 5] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 4.1 Both Operation Modes Under both modes, the Originating System MUST include connectivity information in its original LSPs to all Virtual Systems for which extended LSPs are generated by it, and vice versa. This is to ensure other routers correctly process the extra information in their SPF calculation. This connectivity is advertised via a new Short-Circuit IS Neighbor TLV. Furthermore, an Originating System must advertise which mode it is currently operating in. This is done using a new Extended Capabilities TLV. +---------------------------------------------+ | Originating System | | system-id = S | | ( extended system-ids = S', S'' ) | +---------------------------------------------+ | /\ | /\ SC-ISN | | SC-ISN SC-ISN | | SC-ISN | | | | \/ | \/ | +------------------+ +------------------+ | Virtual System | | Virtual System | | system-id = S' | | system-id = S'' | +------------------+ +------------------+ Figure 1. Advertising connections to Virtual Systems under both modes When new extended LSP fragments are generated, these fragments should be generated as specified in ISO 10589 [ISIS-ISO]. Furthermore, a system SHOULD treat its extended LSPs the same as it treats its original LSPs, with the exceptions noted in the following sections. Specifically, creating, flooding, renewing, purging and all other operations are similar for both original and extended LSPs, unless stated otherwise. The extended LSPs will use one of the extended system-ids configured for the router, in their LSP ID. Extended LSPs with number zero should be regarded in the same special manner as specified in 10589 for LSPs with number zero, and should include the same type of extra information as specified in 10589 and RFC 1195 [ISIS-IP]. So, for example, when a system reissues its LSP Number zero due to an area address change, it should reissue all extended LSPs with number zero as well. An extended LSP Number zero MUST be generated for every extended LSP set, to allow a router's SPF calculation to consider those fragments in that set. A. Hermelin Expires February 2002 [Page 6] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 4.1.3 The Attached Bits The Attached (ATT) bits SHOULD be set to zero for all four metric types, on all extended LSPs. This is due to the following: if a Virtual System is reachable, so is its Originating System. It is preferable, then, that an L1 IS chooses the Originating System and not the Virtual System as its nearest L2 exit point, as connectivity to the Virtual System has a higher probability of being lost (a result of the extended LSP no longer being advertised). This could cause unnecessary processing on some implementations. 4.1.4 The Partition Repair Bit The Partition Repair (P) bit SHOULD be set to zero on all extended LSPs. This is for the same reasons as for the Attached bits. 4.1.1 ES Neighbors TLV ISO 10589 [ISIS-ISO] section 7.3.7 specifies inserting an ES Neighbor TLV in L1 LSPs, with the system ID of the router. RFC 1195 [ISIS-IP] relieves IP-only routers of this requirement. However, for routers that do insert this ESN TLV in L1 LSPs (whether IP-only or OSI- capable), then in an extended LSP, the ESN TLV should include the relevant extended system-id. Furthermore, OSI-capable routers should accept packets destined for this extended system-id. 4.2 Operation Mode 1 Additions The following additions apply only to routers operating in Mode 1. Routers, which are configured to operate in Operation Mode 2, MUST NOT apply these additions to their advertisements. Under Operation Mode 1, the adjacencies must also be advertised using the standard neighbor TLVs. The metric for these connections MUST be zero, since the cost of reaching a Virtual System is the same as the cost of reaching its Originating System. To older implementations, Virtual Systems would appear reachable only through their Originating System, hence loss of connectivity to the Originating System means loss of connectivity to all of its information, including that advertised in its extended LSPs. Furthermore, the cost of reaching information advertised in non- extended LSPs is the same as the cost of reaching information advertised in the new extended LSPs, with an additional hop. A. Hermelin Expires February 2002 [Page 7] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 +---------------------------------------------+ | Originating System | | system-id = S | | ( extended system-ids = S', S'' ) | +---------------------------------------------+ | /\ | /\ cost=0 | |cost=max-1 cost=0 | |cost=max-1 | | | | \/ | \/ | +------------------+ +------------------+ | Virtual System | | Virtual System | | system-id = S' | | system-id = S'' | +------------------+ +------------------+ Figure 2. Advertising additional connections to Virtual Systems under Operation Mode 1 Under Operation Mode 1, only "leaf" information, i.e. information that serves only as leaves in a shortest path tree, can be advertised in extended LSPs. When an extended LSP belonging to extended system-id S' is first created, the original LSP MUST specify S' as a neighbor, with metric set to zero. This is to ensure other routers will consider the extended LSP in their SPF computations, as well as consider the cost of reaching the Virtual System S' the same as the cost of reaching its Originating System. Furthermore, the extended LSP MUST specify the original system-id as a neighbor, with metric set to (MaxLinkMetric - 1). Where relevant, this adjacency SHOULD be considered as point-to-point. Note, that the restriction specified in ISO 10589 section 7.2.5 holds: if an LSP Number zero of the Originating System is not present, none of that system's neighbor entries would be processed during SPF, hence none of its extended LSPs would be processed as well. 4.2.1 IS Neighbors TLV An Extended LSP must specify only the Originating System as a neighbor, with the metric set to (MaxLinkMetric - 1). Where relevant, this adjacency should be considered as point-to-point. Other neighbors MUST NOT be specified in an Extended LSP, as this would not satisfy the bi-directionality check in the SPF computation. A. Hermelin Expires February 2002 [Page 8] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 5. Purging Extended LSP Fragments ISO 10589 [ISIS-ISO] section 7.3.4.4 note 21 suggests that an implementation keeps the number of LSP fragments within a certain limit based on the optimal (minimal) number of fragments needed. Section 7.3.4.6 also recommends that an IS purge its empty LSPs to conserve resources. These recommendations hold for the extended LSP fragments as well. However, an extended LSP Number zero should not be purged until all of the fragments in its set (i.e. belonging to a particular extended system-id), are empty as well. This is to ensure implementations consider the fragments in their SPF computations, as specified in section 7.2.5. When all the extended LSP fragments of a particular extended system- id S' have been purged, the Originating System SHOULD remove the neighbor information to S' from its original LSPs (for both IS and Short-Circuit). 6. Modifications to the SPF This section describes modifications to the SPF running on routers implementing this extension. A router operating in Mode 1, and processing an LSP of another router operating in Mode 1, MAY ignore these modifications and run a normal SPF. This is consistent with other non-extension-capable routers in the network. A router operating in Mode 2, or processing an LSP of another router operating in Mode 2, MUST run the following modifications to the SPF. When considering LSPs of an extension-capable IS, the original and extended LSPs are combined to form one large logical LSP. If the LSP is Operational Mode 1, and there are adjacencies between the original and extended LSPs, these are ignored. This check could be easily done (as the LSPs are tied together), and doesn't complicate the SPF. If the LSP number 0 of the original LSP set is missing, all of the LSPs generated by that Originating System (extended as well) MUST NOT be considered in the SPF. This is easily determined from the Extended Capabilities TLV. If an LSP number 0 of an extended LSP set is missing, only that LSP set MUST NOT be considered in the SPF. Note, that the above behavior is consistent with how previous implementations will interpret Mode 1 LSPs. A. Hermelin Expires February 2002 [Page 9] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 7. Forming Adjacencies It should be noted, that an IS must use the system-id of the LSP that will include a neighbor, when forming an adjacency with that neighbor. That is, if a neighbor is to be included in extended LSP S', then S' should be used as the system-id in IS Hellos [3] and IS- IS Hellos when forming an adjacency with that neighbor. This is regardless of the Operational Mode. Of course, in Mode 1 this means that only the original system-id will be used when sending hellos. 8. Transitioning the Network As noted earlier, in order to correctly run in Operation Mode 2, all ISs in an area must be extension-capable. However, it is possible to transition a live network, using the following steps: - Upgrade the routers, one-by-one, to run this extension in Operation Mode 1. The other non-extension-capable routers will interoperate correctly. - When all routers are extension-capable, configure them one-by-one to run in Operation Mode 2. All extension-capable routers interoperate correctly, regardless of what mode they're run in. 9. Security Considerations This document raises no new security issues for IS-IS. 10. Acknowledgments The author would like to thank Tony Li, Radia Perlman, and Mike Shand for helpful comments and suggestions on the subject. 11. References [ISIS-ISO] ISO 10589, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [ISIS-IP] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [ES-IS] ISO 9542, "End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for A. Hermelin Expires February 2002 [Page 10] Internet Draft draft-hermelin-ext-lsp-frags-02.txt August 2001 Providing the Connectionless-Mode Network Service (ISO 8473)", March 1988 [DOMAIN-WIDE] RFC 2966, "Domain-wide Prefix Distribution with Two- Level IS-IS", T. Li, T. Przygienda, H. Smit, October 2000 [BCP14] RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997 12. Author's Address Amir Hermelin Charlotte's Web Networks, Inc. 2 Ha'mada St. POB 650 Yokneam, 20692 ISRAEL Email: amir@cwnt.com Phone: +972 4 9592203 Fax: +972 4 9593325 A. Hermelin Expires February 2002 [Page 11]