Network Working Group A. Hermelin Request for Comments: 3786 Montilio Inc. Category: Informational S. Previdi M. Shand Cisco Systems May 2004 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit 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.
AbstractThis document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. 1. Introduction ................................................. 2 1.1. Keywords ............................................... 2 1.2. Definitions of Commonly Used Terms ..................... 2 1.3. Operation Modes ........................................ 3 1.4. Overview ............................................... 4 2. IS Alias ID TLV (IS-A) ....................................... 5 3. Generating LSPs .............................................. 6 3.1. Both Operation Modes ................................... 6 3.2. Operation Mode 1 Additives ............................. 8 4. Purging Extended LSP Fragments ............................... 10 5. Modifications to LSP handling in SPF ......................... 10 6. Forming Adjacencies .......................................... 11 7. Interoperating between extension-capable and non-capable ISs . 11 8. Security Considerations ...................................... 12 9. Acknowledgements ............................................. 12
10. References ................................................... 12 11. Authors' Addresses ........................................... 13 12. Full Copyright Statement ..................................... 14 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 increasing number of destinations and AS topologies. - Finer granularity routing, and the ability to inject external routes into areas [DOMAIN-WIDE]. - Other emerging technologies, such as optical, IPv6, etc. This document describes mechanisms to relax the limit on the number of LSP fragments. RFC 2119 [BCP14].
Normal system-id The system-id of an Originating System. Additional system-id An Additional system-id that is assigned by the network administrator. Each Additional system-id allows generation of 256 additional, or extended, LSP fragments. The Additional system-id, like the Normal system-id, must be unique throughout the routing domain. Virtual System The system, identified by an Additional system-id, advertised as originating the extended LSP fragments. These fragments specify the Additional system-id in their LSP IDs. Original LSP An LSP using the Normal system-id in its LSP ID. Extended LSP An LSP using an Additional system-id in its LSP ID. LSP set Logical LSP. This term is used only to resolve the ambiguity between a logical LSP and an LSP fragment, both of which are sometimes termed "LSP". Extended LSP set A group of LSP fragments using an Additional system-id, and originated by the Originating System. Extension-capable IS An IS implementing the mechanisms described in this document.
- 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 way LSPs are considered during the SPF algorithm, in a way that is not compatible with previous implementations. These modes are configured on a per-level and area basis. That is, all LSPs considered in the same SPF instance MUST use the same Mode. There is no restriction that an L1/L2 IS operates in the same mode, for both its L1 and L2 instances. It can use Mode 1 for its L1 LSPs, and Mode 2 for its L2 LSPs, or vice versa. Mode 1 has the only advantage of being backwards compatible with older implementations. It does have restrictions which are considered drawbacks. Therefore, routers should operate in Mode 1 only if backwards compatibility is desired. Otherwise, it is recommended to run in Mode 2. Routers MAY implement Operational Mode 2 without supporting running in Operational Mode 1. They will still interoperate correctly with routers that support both modes.
Sub-TLVs A series of tuples with the following format: No. of Octets +-------------------+ | Sub-type | 1 +-------------------+ | Length | 1 +-------------------+ | | 0-245 : Value : : : | | +-------------------+ Sub-type Type of the sub-TLV Length Total length of the value field Value Type-specific TLV payload. For an explanation on sub-TLV handling, see [ISIS-TE]. Without sub-TLVs, this structure consumes 8 octets per LSP set. This TLV MUST be included in fragment 0 of every LSP set belonging to an Originating System running in either Mode 1 or Mode 2. Currently, there are no sub-TLVs defined. For a complete list of used IS-IS TLV numbers, see [ISIS-CODES].
+---------------------------------------------+ | Originating System | | system-id = S | | is-alias-id = S | +---------------------------------------------+ +-------------------+ +-------------------+ | Virtual System | | Virtual System | | system-id = S' | | system-id = S''| | is-alias-id = S | | is-alias-id = S | +-------------------+ +-------------------+ Figure 1. Advertising binding between all of a system's LSPs (both modes). S' and S'' are configured as Additional system-ids. When new extended LSP fragments are generated, these fragments should be generated as specified in ISO/IEC 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 Additional system-ids configured for the router, in their LSP ID. Extended LSPs fragment zero should be regarded in the same special manner as specified in ISO/IEC 10589 for LSPs with number zero, and should include the same type of extra information as specified in ISO/IEC 10589 and RFC 1195 [ISIS-IP]. So, for example, when a system reissues its LSP fragment zero due to an area address change, it should reissue all extended LSPs fragment zero as well. An extended LSP fragment zero MUST be generated for every extended LSP set, to allow a router's SPF calculation to consider those fragments in that set. See section 5 for details.
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 Additional system-id. Furthermore, OSI-capable routers should accept packets destined for this Additional system-id.
+---------------------------------------------+ | Originating System | | system-id = S | | is-alias-id = S | +---------------------------------------------+ | /\ | /\ cost=0 | |cost=max-1 cost=0 | |cost=max-1 | | | | \/ | \/ | +-------------------+ +-------------------+ | Virtual System | | Virtual System | | system-id = S' | | system-id = S''| | is-alias-id = S | | is-alias-id = S | +-------------------+ +-------------------+ Figure 2. Advertising connections to Virtual Systems under Operation Mode 1. S' and S'' are configured as Additional system-ids. 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 Additional system-id S' is first created, the Original LSP MUST specify S' as a neighbor, with metric set to zero. This is in order to 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 Normal system-id as a neighbor. The metric SHOULD be set to MaxLinkMetric - 1 (this is only for uniformity purpose, any metric greater than zero is acceptable). This in order to satisfy the two-way connectivity check on other routers. Where relevant, this adjacency SHOULD be considered as point-to-point. Note, that the restriction specified in ISO/IEC 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.
those other neighbors would only specify the Originating System and not the Virtual System, and hence would not satisfy the bi- directionality check in the SPF computation. ISIS-ISO] section 18.104.22.168 note 25 suggests that an implementation keeps the number of LSP fragments within a certain limit based on the optimal (minimal) number of fragments needed. Section 22.214.171.124 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 fragment zero should not be purged until all of the fragments in its set (i.e., belonging to a particular Additional 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. In Operational Mode 1, when all the extended LSP fragments of a particular Additional system-id S' have been purged, the Originating System SHOULD remove the neighbor information to S' from its original LSPs.
If LSP fragment 0 of the Original LSP set is missing or its RemainingLifetime is zero, all of the LSPs generated by that Originating System (Extended as well) MUST NOT be considered in the SPF. That is, the large logical LSP is not considered in the SPF. The original LSP fragments are identified when the is-alias-id value is the same as the system-id of those LSPs. If an LSP fragment 0 of an extended LSP set is missing or its RemainingLifetime is zero, only that LSP set MUST NOT be considered in the SPF. These rules are present to ensure consistent SPF results on Mode 1 and Mode 2 LSPs. Note, that the above behavior is consistent with how previous implementations will interpret Mode 1 LSPs.
Implementations SHOULD support a configuration parameter controlling the LSP origination behavior. The default value of this parameter SHOULD correspond to the behavior described in [ISIS-ISO], i.e., neither of the two modes described in this document should be enabled without explicit configuration when the router software is upgraded with this extension. [ISIS-ISO] "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)", ISO/IEC 10589:2002, Second Edition. [ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, May 2004. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DOMAIN-WIDE] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000. [ISIS-CODES] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.
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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.