Internet Engineering Task Force Jonathan Sadler Internet Draft Tellabs Document: draft-sadler-isis-ml-bcp-00.txt Category: Informational Expiration Date: August 2003 February 2003 Multi-Level IS-IS Without Protocol Extensions draft-sadler-isis-ml-bcp-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Work has started in the ITU, the IETF IP over Optical Working Group, and in the OIF to specify the requirements for ASON NNI routing. One of the requirements identified is support for multi-level hierarchies. IS-IS is one of the candidate protocols to provide this functionality. Therefore, methods for multi-level IS-IS routing need to be developed. This draft documents one that provides multi-level routing through the "stacking" of Level 2 IS-IS instances. The method is possible using existing extensions to IS-IS. It also provides insight into some of the resulting operational issues. Sadler ISIS WG - February 2003 1 draft-sadler-isis-ml-bcp-00.txt August 2003 Changes No changes -- New Document. 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 RFC-2119 [1]. Table of Contents 1. Overview...................................................2 2. Acronyms and Definitions...................................3 3. Requirements...............................................4 3.1. Communication between levels...............................5 3.1.1Type of information exchanged..............................5 3.1.2Method of communication...................................10 3.2. Communication within a level..............................11 3.2.1Type of information exchanged.............................11 3.2.2Methods for exchanging information........................12 4. Method for Implementation.................................14 5. Known Issues..............................................17 6. Security Considerations...................................18 7. Acknowledgements..........................................18 8. References................................................18 9. Author's Addresses........................................19 1. Overview Work has started in the ITU [2], the IETF IP over Optical Working Group [3], and the OIF [4] to specify the requirements for ASON NNI routing. One of the requirements identified is the need to support routing hierarchies of more than two levels. The requirement for more than two levels of hierarchy is driven by the way service providers hierarchically organize their networks. Many times the hierarchy is defined at points where a network is partitioned into separate regions of control or control domains. The partitioning of a carrier's network into control domains constrained for a variety of reasons such as: o Administrative boundaries o Political boundaries o Scalability of routing or signaling protocols o Isolation of partitions for security or reliability o Technology differences and interoperability concerns. The ITU [5] and OIF [6] have both identified IS-IS [7] as a candidate protocol to provide NNI routing functionality. Therefore, methods for multi-level IS-IS routing need to be developed. This Sadler ISIS WG - February 2003 2 draft-sadler-isis-ml-bcp-00.txt August 2003 draft documents one method that does not require further extensions to IS-IS. It should be noted that while the method for multi-level routing using IS-IS described in this document satisfies the requirements stated for ASON networks, the method is independent of the type of signal being routed. Thus, it may be applied to packet and cell switched networks in addition to optical networks. The document closes with some of the operational issues that this method suffers from, which result from IS-IS's original two-level design. 2. Acronyms and Definitions Area A logical grouping of nodes that operate together to form an abstract topology which can be used to generate routes. Aggregation Area An area that contains Intermediate Systems, Endpoints and other (leaf or aggregation) areas. All areas except those that are the lowest in a particular branch of the network hierarchy will be aggregation areas. Area ID Identifier that uniquely specifies an area in the network ASON Automatically Switched Optical Network CPU Central Processing Unit ES End System IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 IS Intermediate System IS-IS Intermediate System to Intermediate System routing protocol ISO International Standards Organization ITU International Telecommunications Union L1 IS An IS participating in Level 1 IS-IS only L1+L2 IS An IS participating in Level 1 and Level 2 IS-IS Leaf Area An area that contains only Intermediate Systems and Endpoints. Only the lowest area for particular branch of the network hierarchy will be a leaf area. Level The depth in a hierarchy that an area exists LSP Link State PDU MPLS Multi-Protocol Label Switching MPLS LSP MPLS Label Switched Path NNI Network to Network Interface NSAP Address Network Service Access Point Address OIF Optical Internetworking Forum OSI Open Systems Interconnect PCS Path Computation Server RFC Request For Comments UNI User to Network Interface Sadler ISIS WG - February 2003 3 draft-sadler-isis-ml-bcp-00.txt August 2003 3. Requirements In order to implement multi-level hierarchical routing, two issues must be resolved: o How do routing functions within a level communicate and what information should be exchanged? o How do routing functions at different levels communicate and what information should be exchanged? In the process of answering these questions, the following model will be used: ---------------- //// \\\\ /// 1 2 \\\ // ---- ---- \\ | // \\ // \\ | | / 1 2 \ 3 / 1 2 \ | | | Area A | | Area B | | | 5 | 3 5 | | 3 5 | 6 | | \ 4 / \ 4 / | | \\ // 4 \\ // | \\ ---- ---- // \\\ Area C /// \\\\ //// ---------------- Figure 1: Area Containment Hierarchy For this model, Levels are relative, and numbered from bottom up. So, Area A and Area B are at Level n while Area C is at Level n+1. The numbers shown in the model represent different ISes located within the various areas, and will be referenced in the following sections. Traffic links exist within the area that contains both link endpoints. For example links between: - nodes A.1 and A.2 will be contained within Area A. - nodes C.1 and C.5 will be contained within Area C. - nodes A.1 and C.5 will be contained within Area C. - nodes A.2 and B.1 will be contained within Area C. The last two links are in Area C since only the aggregation area contains the two endpoints of these links. While IS-IS doesn't specifically define "links", it does discuss neighbor relationships. A neighbor relationship really serves two separate purposes -- the identification of a traffic link that can carry user traffic, and the identification of a flooding relationship between two IS-IS processes. The term link is used Sadler ISIS WG - February 2003 4 draft-sadler-isis-ml-bcp-00.txt August 2003 throughout this draft to describe just the traffic link, not the flooding relationship, although the link may be also supporting a flooding relationship. This distinction is further developed in section 3.2. 3.1. Communication between levels 3.1.1 Type of information exchanged The communication between levels describes the interface between a routing function in an aggregation area, and the routing function(s) operating in a contained area. The information that flows over this interface is defined in ISO 10589 for OSI, and in RFC 1195 [8] for IP. The information flowing upward (i.e. Level n to Level n+1) and the information flowing downward (i.e. Level n+1 to Level n) are used for similar purposes -- namely, the exchange of reachability information and summarized topology for endpoints outside of an area. However, different methods may be used. The next two sections describe this further. 3.1.1.1 Upward communication from Level n to Level n+1 Overview of Approaches Three different approaches exist for upward communications. In the first approach the Level n+1 routing function is statically configured with the endpoints located in Level n. This information may be represented by a address prefix to facilitate scalability, or it may be an actual list of the endpoints in the area. In the second approach, the Level n+1 routing function listens to the routing protocol exchange occurring in each contained Level n area and retrieves the endpoints being announced by the Level n routing instance(s). This information may be aggregated or summarized into smaller quantities (i.e. one or more prefixes) to facilitate scalability. The third approach is an extension to the second approach, with the Level n+1 routing function listening to the routing protocol exchange occurring in each contained Level n area. However, instead of just redistributing reachability information from the Level n areas into the Level n+1 area, an abstract topology is also advertised. This abstract topology consists of two or more identified border nodes on which the actual Level n+1 links terminate, and pseudo-links between the borders that representing the potential connectivity that exists within the Level n area. This approach has a notable benefit over the second approach -- it allows path computation functions located in Level n+1 to better understand the blocking characteristics of the Level n area. Without the pseudo-links, the connectivity between the physical Sadler ISIS WG - February 2003 5 draft-sadler-isis-ml-bcp-00.txt August 2003 borders is totally unknown. By adding the pseudo-links, higher quality routes can be developed. Both the second and third approaches can have multiple instances responsible for redistribution of information from a Level n area into the Level n+1 area. However, the third approach is extremely sensitive to the self-consistency of the information being advertised. If one instance is announcing a link with different attributes than another instance (including existence), then the quality of the route will suffer. IS-IS Implementation of Approaches In an ISO 10589 [6] compliant IS-IS for OSI implementation, addresses used within a Level 1 area all use the Area's ID as a common address prefix. This strongly-associated ID provides a natural summary of the endpoints in the Level 1 area and can be advertised by a L1+L2 Border IS into the Level 2. In an IS-IS implementation extended to support IPv4 per RFC 1195 [8], the network layer addresses do not use the Area ID, and, therefore, cannot be implicitly learned by the L1+L2 Border IS. Instead, the L1+L2 border will need to be statically configured with a list of the IPv4 address prefixes reachable. This weaker association means that more configuration actions are necessary, but it also allows address prefixes to be independent of Routing Area identities. Some IS-IS implementations that support IPv4 have extended the weakly associated address approach. Instead of using a static table of prefixes, they listen to the endpoint announcements in the L1 area and dynamically export the endpoints reachable (either individually or as part of a prefix summary) into the L2 protocol. This approach is mandatory for IS-IS implementations that support RFC 2966 [9]. Some of the benefits that result from the second approach are: oIt allows address formats to be independent of the area ID semantics used by the routing protocol. This allows a Service Provider to choose one of the common addressing schemes in use today (IPv4, IPv6, NSAP address, etc.), and allows new address formats to be easily introduced in the future. oIt allows for an endpoint to be attached to multiple switches located in different areas in the service provider's network and use the same address. At this time, the third approach has not been implemented for IS-IS. If an implementation of the third approach were to be undertaken, protocol extensions for synchronizing the information being advertised into the Level n+1 area will need to be defined. One approach would be to have only a single instance responsible for Sadler ISIS WG - February 2003 6 draft-sadler-isis-ml-bcp-00.txt August 2003 advertising information into the Level n+1 area active at one time. This is for further study. Multi-level IS-IS Requirements For Multi-level IS-IS, the lower area routing function needs to provide the upper level routing function with information on the endpoints contained within the lower area. Any of these approaches may be used. However, the second approach is preferable for the reasons mentioned above. 3.1.1.2 Downward communication from Level n+1 to Level n Overview of Approaches Four different approaches exist for downward communications. In the first approach, Intermediate Systems in an area at Level n that are attached to Level n+1 will announce that they are a border Intermediate System, and know how to get to endpoints outside of the area. When another Intermediate System within the area is presented with the need to develop a route to endpoints outside of the area, it can simply find a route to the closest border Intermediate System. The second approach has the Level n+1 routing function determine the endpoints reachable from the different Level n border Intermediate Systems, and provide that information to the Level n routing function so it can be advertised into the Level n area. These advertisements are then used by non-border Intermediate Systems at Level n to determine which border Intermediate System would be preferable for reaching a destination. When compared to the first approach the second approach increases the amount of information that needs to be shared within the Level n area. However, being able to determine which border Intermediate System is closer to the destination causes the route thus generated to be of "higher quality". The third approach has the Level n+1 routing function provide the Level n routing function with all reachability and topology information visible at Level n+1. Since the information visible at Level n+1 includes the information visible at Levels n+2, n+3, and so on to the root of the hierarchy tree, the amount of information introduced into Level n is significant. However, as with the second approach, this further increases the quality of the route generated. Unfortunately, the lower levels will never have the need for most of the information propagated. This approach has the highest "overhead cost". A forth approach is to not communicate downward from Level n+1 to Level n any routing information. Instead, the border Intermediate Systems provides other Intermediate Systems in the area with the Sadler ISIS WG - February 2003 7 draft-sadler-isis-ml-bcp-00.txt August 2003 address of a Path Computation Server (PCS) that can develop routes at Level n+1. When an Intermediate System operating in an area at Level n needs to develop a route to a destination located outside that area, the PCS at Level n+1 is consulted. The PCS can then determine the route to the destination at Level n+1. If this PCS also is unable to determine the route as the endpoint is located outside of the PCS's area, then it can consult the PCS operating at Level n+2. This recursion will continue until the PCS responsible for area at the lowest level that contains both the source and destination endpoints is reached. IS-IS Implementation of Approaches In an ISO 10589 compliant IS-IS for OSI implementation [6], the first approach is used. Border Intermediate Systems will announce into the Level 1 area the fact that they are "attached" to the Level 2. In an IS-IS implementation extended to support IPv4 per RFC 1195 [8], no change was made in determining how to route to endpoints outside of the area. One "attached" bit is for all network layers protocols supported by the node. An IS-IS for IPv4 implementation that has been further extended by RFC 2966 [9] uses the second approach. Multi-level IS-IS Requirements For Multi-level IS-IS, any of these approaches may be used. The second and forth approaches are preferable as they provide high- quality routes with the least amount of overhead. However, only the first and second approaches are possible at this time without further extensions to IS-IS. 3.1.1.3 Interactions between upward and downward communication Overview of Approaches Almost all combinations of upward (Level n to Level n+1) and downward (Level n+1 to Level n) communications approaches described in this document will work without any problems. However, when both the upward and downward communication interfaces contain endpoint reachability information, a feedback loop is created. Consequently, this combination must include a method to prevent re-introduction of information propagated into the Level n area from the Level n+1 area back into the Level n+1 area, and vise-versa. Two methods exist to deal with this problem. The first method requires a static list of endpoint addresses or endpoint summaries to be defined in all machines participating in Level n to Level n+1 communications. This list is then used to validate if that piece of endpoint reachability information should be propagated into the Level n+1 area. Sadler ISIS WG - February 2003 8 draft-sadler-isis-ml-bcp-00.txt August 2003 The second approach attaches an attribute to the information propagated from the Level n+1 area to the Level n area. Since endpoint information that was originated by the Level n area (or a contained area) will not have this attribute, the routing function can break the feedback loop by only propagating upward information where this attribute is appropriately set. For the second approach, it is necessary to make certain the ISes in the Level n area do not utilize the information received from Level n+1 when the endpoint is actually located within the Level n area, or a contained area. This can be accomplished by establishing the following preference order for endpoints based on how an endpoint is reached. Specifically, the following preference order would be used: 1) Endpoint is reached through a node at Level n or below (i.e. up/down bit cleared) 2) Endpoint is reached through a node above Level n (i.e. up/down bit set) IS-IS Implementation of Approaches The first method is required by ISO 10589 compliant implementations for OSI [6] as well as implementations extended to support IPv4 per RFC 1195 [8]. In the case of an ISO 10589, the Area ID being used by the node implicitly defines the prefix to be passed. However, since a strong association does not exist between Area ID and IPv4 prefix, the table must be manually populated by the network administrator with the IPv4 endpoints located in the local area. In a network that doesn't have any multi-homed endpoints this will work fine, although keeping the lists in sync introduces administrative overhead. Only IS-IS for IPv4 as extended by RFC 2966 [9] propagates endpoint reachability both upward and downward, and therefore is the only form of IS-IS today that has to deal with this issue. It uses the second approach, with a single bit attribute (called the up/down bit) providing the marker used by the upward filtering action. Specifically, RFC 2966 states that endpoint reachability information in the L1 area MUST only be passed to the L2 if the Up/Down bit is cleared (0). If the bit is set (1), the information MUST not be propagated upward. It further states that as information is passed from an area at L2 to an area at L1, the Up/Down bit MUST be set (1). There is no restriction on the information that may flow downward. Multi-level IS-IS Requirements While RFC 2966 defines this mechanism specifically for a hierarchy limited to two levels, the method can be used for more than two levels. By changing the absolute references to L1 and L2 into Sadler ISIS WG - February 2003 9 draft-sadler-isis-ml-bcp-00.txt August 2003 relative references Level n and Level n+1, the method can be applied to hierarchies with depths greater than 2. 3.1.2 Method of communication Overview of Approaches Two approaches exist for handling Level n to Level n+1 communications. The first approach places an instance of a Level n routing function and an instance of a Level n+1 routing function in the same system. The communications interface is now under control of a single vendor, meaning its implementation does not need to be an open protocol. However, there are downsides to this approach. Since both routing functions are competing for the same system resources (memory, and CPU), it is possible for one routing function to be starved, causing it to not perform effectively. Therefore, each system will need to be analyzed to identify the load it can support without affecting operations of the routing protocol. Furthermore, different parties may be responsible for the administration of the Level n and Level n+1 areas. Locating the area instances on the same node may lead to configuration maintenance and potentially security problems. The second approach places the Level n routing function on a separate system from the Level n+1 routing function. For this approach, two different methods exist to determine that a Level n to Level n+1 adjacency exists: static configuration, and automatic discovery. Static configuration relies on the network administrator configuring the two systems with their peer, and their specific role as parent (i.e. Level n+1 routing function) or child (i.e. Level n routing function). For automatic discovery, the system will need to be configured with the Routing Area ID(s) for its area, as well as the Routing Area ID(s) of the "containing" area. The Routing Area IDs will then be conveyed by the system in its neighbor discovery (i.e. Hello) messages. This in turn allows the system in the parent routing area to identify its neighbor as a system participating in child routing area, and vise versa. IS-IS Implementation of Approaches In standard IS-IS [6], communication between the routing functions operating in an aggregation area (L2) and in a contained leaf area (L1) is done within an L1+L2 IS. Multi-level IS-IS Requirements Since the goal of this document is to show how to do multi-level IS- IS without further extensions to the IS-IS protocol, the existing Intra-IS approach MUST be used. Sadler ISIS WG - February 2003 10 draft-sadler-isis-ml-bcp-00.txt August 2003 3.2. Communication within a level 3.2.1 Type of information exchanged Overview of Approaches Multi-level IS-IS requires a mechanism for nodes in an area to share the location of the endpoints within the area as well as endpoints outside of the area. To accomplish this, each node within the area will announce the endpoints that it can reach. For a "leaf" area, this means that the location of all End Systems and Intermediate Systems in that area needs to be shared. In the model provided in Section 3 figure 1, Area A and Area B will be leaf areas if they do not contain any further Areas. Area C cannot be a leaf area, as it contains Area A and Area B. The location of endpoints A.1-A.5 will be exchanged by the Intermediate Systems within Area A, while the location of endpoints B.1-B.5 will be exchanged by the Intermediate Systems within Area B. For areas that aggregate other areas, the End System and Intermediate System locations need to be shared, as well as a summary of the endpoints reachable through each Intermediate System participating in a lower level area. In the model shown in Section 3, location information for endpoints C.1-C.5 as well as the borders for Areas A and B will be exchanged by the Intermediate Systems in Area C. The borders active in areas A and B will announce the addresses reachable within these areas. IS-IS Implementation of Approaches As defined in ISO 10589 [6], IS-IS for OSI meets most, but not all, of these requirements. Leaf areas (Level 1 areas) propagate End System and Intermediate System location when distributing link state components of the topology graph. Aggregation areas (an IS-IS Level 2) propagate Intermediate System location, and include a summary of the endpoints reachable through the Intermediate System. Where standard IS-IS for OSI falls short is the lack of support for End Systems in aggregation areas - End Systems are restricted to leaf areas only. IS-IS extended for IPv4 per RFC 1195 [8] meets all of the requirements for multi-level IS-IS as end system reachability is not specifically advertised. Instead, an Intermediate System advertises the prefix common to all devices on the subnet it is connected to, implicitly including any end system that that is attached to that subnet. Since Intermediate Systems at Level 1 as well as in Level 2 have this ability, End Systems may exist in the Level 2. Multi-level IS-IS Requirements IS-IS extended for IPv4 per RFC 1195 can support Multiple Levels for IPv4 without modification. Sadler ISIS WG - February 2003 11 draft-sadler-isis-ml-bcp-00.txt August 2003 Since IS-IS currently needs to handle 2 levels of hierarchy, the differentiation of "leaf" and "aggregation" areas in the protocol is not problematic. However, in Multi-Level IS-IS, it may be necessary for a leaf area to become an aggregation area so that a new leaf area can be added below. Consequently, the use of Level 1 behavior is discouraged in Multi-Level IS-IS. 3.2.2 Methods for exchanging information Overview of Approaches Communications between Intermediate Systems located within an area is implemented using one of two methods: oIn-band communication oOut-of-band communication In-band communication refers to the case where routing protocol PDUs sent to neighboring equipment use a link that is also used for user data. This permits easy establishment of routing protocol adjacencies when a user data link already exists. It also allows the routing protocol to use a heartbeat mechanism to determine if a link has failed. However, it is not always possible or desirable for a link to be used for both user data as well as routing protocol traffic. As an example, a service provider may wish to isolate routing traffic from user data. Since the separation of traffic means that a user cannot overrun the links causing routing protocol PDUs to be discarded, the service provided will have a higher availability than if the user and routing protocol traffic were co-mingled. Out-of-band communication refers to the case where routing protocol PDUs sent to equipment uses a link that is not used for user data. In this environment, the routing protocol will announce links that it is not exchanging routing protocol traffic (including hellos) over. Instead, the routing protocol traffic is carried on a links in a separate network. IS-IS Implementation of Approaches Standard IS-IS [6] uses In-band for intra-area communications. This approach continues with IS-IS extended to support IPv4 using RFC 1195. IS-IS extended to support MPLS-TE [10] and MPLS LSP hierarchies [11] starts to remove the assumption that traffic-bearing links will always contain a flooding adjacency. Likewise, it isn't hard to realize that a flooding adjacency does not always have to have an announced traffic link. Sadler ISIS WG - February 2003 12 draft-sadler-isis-ml-bcp-00.txt August 2003 Multi-Level IS-IS Requirements Multi-level IS-IS can utilize either In-band or out-of-band communications. However, there is one major benefit to out-of-band not mentioned above: Border ISes that are not physical neighbors are able to maintain a neighbor relationship. Such a scenario is shown in figure 2. ------------ /----- -----\ //// A \\\\ // \ \\ // \ \\ // ------B----------------- \\ | // / \ \\ | | // / \ \\ | | || / \ || | | | / \ | | | |Level 1 1---------2---------3 | | | | \ / | | | || \ / || | | \\ \ / // | | \\ \ / // | \\ ----------------C------- // \\ \ // \\ Level 2 \ // \\\\ D //// \----- -----/ ------------ Figure 2: Discontinuous Level 2 Scenario In this scenario, Nodes A, B, C, and D are L1+L2 ISes, and Nodes 1, 2, and 3 are L1-only ISes. Control and Transport plane links exist for the following Node pairs: A-B, B-1, B-2, 1-2, 2-3, 2-C, 3-C, and C-D. Nodes B, C, 1, 2, and 3 are in the same L1 area, allowing for easy exchange of L1 IS-IS PDUs. Since nodes A and D connect to nodes B and C, connectivity exists between A and D by using the Level 1 area for transit. However, since nodes B and C are not immediate neighbors, the L2 is partitioned. Consequently, nodes A and D will not be able to communicate. By placing an out-of-band communication path between nodes B and C, the flooding partition is removed allowing nodes B and C to exchange L2 routing information. Furthermore, by announcing a link between nodes B and C in the Level 2 area, paths between A and D can be computed allowing A and D to communicate. It should be noted that this link is purely to support the exchange of routing information at Level 2, and therefore should not be announced into the Level 1 protocol. Nodes B and C should not Sadler ISIS WG - February 2003 13 draft-sadler-isis-ml-bcp-00.txt August 2003 install into the forwarding table any routes that use this link. Instead, B should use the route to D being leaked by C into the Level 1. As a result, B will send traffic for D through node 2 to node C. The out-of-band communication link can be provided either through an OSI-in-IP tunnel, or by a separate path that is carried on different Layer 2 (or lower) facilities such as an MPLS LSP. Regardless of whether an adjacency is carried by in band or out of band means, the neighboring systems need to validate that they are in the same area. Two different methods exist to determine that a Level n adjacency exists: static configuration, and automatic discovery. Static configuration relies on the network administrator configuring the two peer systems, and their role as peers. For automatic discovery, the system will need to be configured with the Routing Area ID(s) for its area. The Routing Area IDs will then be conveyed by the system in its neighbor discovery (i.e. Hello) messages. This in turn allows two systems to determine that they are in the same area. Since this document is looking at methods to support multi-level without further protocol extensions, the static method MUST be used for identifying peers. 4. Method for Implementation Given the requirements of section 3, this is a method proposed for implementing a Multi-Level IS-IS environment without any additional protocol modifications. 1. All aggregation areas MUST behave as defined for IS-IS L2. 2. Each IS-IS L2 instance on a node MUST maintain separate LSDBs for each area. 3. In order to provide propagation of reachability information between levels, the lower area MUST have at least one system that is participating in that area as well as the containing area. This system MAY participate in more than two areas operating at different (though consecutive) levels, but is not required to do so. 4. Endpoint reachability information with the up/down bit described in RFC 2966 cleared MUST be propagated from the lower level area to the containing area operating at the next higher level. This information MAY be summarized to reduce the amount of reachability information propagated between levels. Sadler ISIS WG - February 2003 14 draft-sadler-isis-ml-bcp-00.txt August 2003 5. Endpoint reachability information MUST be propagated from an area operating at a higher level to the areas it contains with the up/down bit described in RFC 2966 set. This information MAY be summarized to reduce the amount of reachability information propagated between levels. 6. Out-of-band communication methods MAY be used to establish adjacencies between non-adjacent nodes operating in the same area. 7. The endpoints of a link MUST terminate on ISes that operate in the area which contains the link. The result allows for topologies such as the following: .----------------------------------------------------------. |Area 1 | | | | .------------------. .-----------------------------. | | | | | .--------. Area 1.2 | | | | Area 1.1 -+--1--+-+- | | | | | / | | | \ | .--------. | | | | / | | | \ --+-------+-\ | | | | | / | | | \ / | | \ | | | | | 3-----------5 | | | 6---+-\ | 9 | | | | | \ /| | | | /|\ | \ | /|\ | | | | | \ / | | | | 8 | | | \ | | | 11 | | | | | \ / / | | | \|/ | \ | \|/ | | | | | \ / / | | | 7 | \-+---10 | | | | | \ / / | | | \ | | /| | | | | | 4-- | | | --+-------+-- | | | | | | \ | | | | | / | | | | | \ | | | | | / | | | | | \ | | |A=1.2.1 | |/ | | | | | \ | | '--------' / | | | | | ------+--2--+-----------------/|A=1.2.2 | | | | | | | '--------' | | | '------------------' '-----------------------------' | | | '----------------------------------------------------------' Figure 3: Example Multi-Level IS-IS Network Please note the area numbering (i.e. 1, 1.1, 1.2, etc.) used here is for illustration purposes only. The Area IDs for these areas would continue to be consistent with IS-IS area ID formats (i.e. NSAP prefixes). It should also be noted the area IDs do not necessarily need to be summarizeable, as they are not shared with any other nodes. This allows areas contained within the same aggregation area to have unrelated prefixes. Sadler ISIS WG - February 2003 15 draft-sadler-isis-ml-bcp-00.txt August 2003 In this diagram, nodes 1, 2, 4, 5, 6, and 10 are ISes in area 1 at the top level (level 3). Links within this area are 1-5, 5-4, 4-2, 2-10, 10-6, and 6-1. At Level 2 is area 1.1, which contains ISes 3, 4, 5. Links within this area are between ISes 4-3, 3-4, and 5-4. Since ISes 5 and 4 are adjacent in two different levels, the 5-4 link in use here is different from the 5-4 link that is part of the top level. The area 1.1 link is associated through configuration with a different L2 IS- IS instance than used for the area 1 link. Also at Level 2 is area 1.2, which contains ISes 6, 7, 9 and 10. Links within this area are between ISes 7-6, 6-9, 9-10, and 7-10, but does not include 10-6. This is because 6-10 is in use at the top level. At Level 1 is area 1.2.1 which contains ISes 6, 7 and 8. The links within this area are between 6-7, 7-8, and 8-6. Again, since ISes 6 and 7 are adjacent in two areas at the same time, there are two separate links associated with different L2 IS-IS instances. Also at Level 1 is area 1.2.2 which contains ISes 9, 10, and 11. The links within this area are between 9-10, 10-11, and 11-9. Again, since ISes 9 and 10 are adjacent in two different areas at the same time, there are two separate links, each associated with a different L2 IS-IS. Endpoint redistribution is done between area 1.1 and area 1 in ISes 4 and 5. It is also done between area 1.2 and Area 1 in ISes 6 and 10. Redistribution is further done between area 1.2.1 and area 1.2 in ISes 6 and 7 as well as between area 1.2.2 and area 1.2 in ISes 9 and 10. Route Computation is performed as described in ISO 10589, RFC 1995 and RFC 2996, with route preferences modified as follows: 1) Level n intra-area routes with internal metric Level n external routes with internal metric 2) Level n+1 intra-area routes with internal metric Level n+1 external routes with internal metric Level n ->Level n+1 inter-area routes with internal metric Level n ->Level n+1 inter-area external routes w/ internal metric 3) Level n+1 ->Level n inter-area routes with internal metric Level n+1 ->Level n inter-area external routes w/ internal metric 4) Level n external routes with external metric 5) Level n+1 external routes with external metric Level n ->Level n+1 inter-area external routes w/ external metric 6) Level n+1 ->Level n inter-area external routes w/ external metric where Level n routes include the endpoints located at Level n and the endpoints located in contained areas. Sadler ISIS WG - February 2003 16 draft-sadler-isis-ml-bcp-00.txt August 2003 5. Known Issues While this method works, it is cumbersome. It is presented here to validate that IS-IS can be used in a Multi-Level hierarchy without extensions. However, extensions to solve the following issues may be beneficial: - Support for multiple Multi-level IS-IS areas on LAN interfaces. It is not possible for L2 IS-IS instances on a LAN to participate in Multi-Level IS-IS areas since normal IS-IS expects only one L2 instance to exist within an IS-IS operational domain. Since the Multi-level IS-IS method described in this document requires all areas to implement L2 IS-IS behavior, only one Multi-level IS-IS area may be active on a LAN. - Automation of peer-wise adjacency establishment. Since the routing functions should be implemented consistent with L2 IS-IS behavior, there is no mechanism to prevent accidental associations between two ISes that are not operating in the same area. Consequently, the existing method requires use of links dedicated to an area (provided by either separate Layer 1 links, or through use of a Layer 2 switching function). Adding a TLV to L2 IIH PDUs similar to the Area Address TLV (Type=1) contained in L1 IIH PDUs would accomplish this. - External method for upward/downward communication between Level n and Level n+1. This would allow the IS-IS instance responsible for a contained area to be located on a different system than the IS-IS instance responsible for a containing area. The resulting protocol would likely look alot like the existing IS-IS L2 protocol. - Automatic Parent-Child adjacency establishment. This allows containing and contained IS-IS instances located on different platforms to automatically establish the adjacency used for upward/downward communcation. The same TLV added to L2 IIHes for peer-wise adjacency establishment could also be used to automate Parent-Child adjacency establishment. - Automatic Identification of the Area to which a Traffic-bearing Link belongs. Since links must be announced in the area that contains both endpoints of the link, the node that the link terminates on may not be the node that the link is to be advertised by. Consequently, the links existence will need to be propagated by that node to the routing function operating at the next higher (and potentially subsequently higher still) area, until the area that contains both endpoints of the link is reached. This can be accomplished by adding an additional TLV that lists the area IDs for all contained areas. This information would be propagated from the lower area to the upper area only. Sadler ISIS WG - February 2003 17 draft-sadler-isis-ml-bcp-00.txt August 2003 - Identification of what area an IS-IS LSP pertains. This would allow one adjacency to be shared by multiple areas when the peers participate in more than one common area. As a result, the requirement for separate Layer 1 or Layer 2 links to support each area peering would be removed. - Mechanism to identify that an IS-IS adjacency should only be used for flooding purposes, and that a traffic link should not be announced. - More efficient mechanisms to carry IS-IS PDUs between non- adjacent ISes. - Use of PCSes to compute routes. Work to realize these extensions should be initiated within the IS- IS Working Group. 6. Security Considerations This draft does not introduce any new security issues for IS-IS. 7. Acknowledgements The author would like to thank Radia Perlman for listening and validating this idea. The author would also like to thank the participants in the IETF IS-IS WG mailing list circa 1998 that discussed this topic, providing guidance to the development of this contribution. 8. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2 Draft G.7715.1, "Hierarchical Link State NNI routing", ITU SG15 Jan 2003 meeting 3 draft-ietf-ipo-carrier-requirements-05.txt, "Optical Network Service Requirements" 4 OIF-2002.378.02, "Hierarchical Link State NNI routing" 5 Q14/15 WD33, "Liaison Statement To ISO/IEC JTC1/SCO6/WG7 From WP3/15 Regarding ASON Routing", ITU-T SG15, January 2003. Available at http://www.ietf.org/IESG/LIAISON/ITU-tsg15opt.html 6 OIF-2002.426.00, "Sig. WG Closing Plenary Report, July, 2002, Copenhagen" 7 ISO 10589:1992, "Information technology -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)" 8 RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments" 9 RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS" Sadler ISIS WG - February 2003 18 draft-sadler-isis-ml-bcp-00.txt August 2003 10 draft-ietf-isis-traffic-04.txt, "IS-IS extensions for Traffic Engineering" 11 draft-ietf-mpls-lsp-hierarchy-07.txt, "LSP Hierarchy with Generalized MPLS TE" 9. Author's Address Jonathan Sadler Tellabs Operations, Inc. 1415 West Diehl Road Naperville, IL 60563 Phone: +1 630-798-6182 Email: Jonathan.Sadler@tellabs.com Full Copyright Statement "Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Sadler ISIS WG - February 2003 19