Network Working Group K. Noguchi Internet Draft IP Infusion Inc. Expiration Date: August 2003 T. Takada IP Infusion Inc. March 2003 Protocol Topology Support for IS-IS Status of this Memo 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. Abstract RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. [2] adds functionality to Integrated IS-IS so that it supports IPv6. RFC 1195 [1] places topological restrictions on networks that are routed using Integrated IS-IS, specifically, that every router in a level-1 area must be capable of all network layer protocols that are present in that area, and every routers in a level-2 area must be capable of all network layer protocols that are present in the whole IS-IS routing domain. The mechanism described in this document enables a single IS-IS Noguchi, Takada Expires July 2003 [Page 1] Internet Draft draft-noguchi-isis-protocol-topology-01.txt February 2003 routing domain to support different network layer protocol topologies by maintaining separate SPF trees for each network layer protocol. Furthermore, it no longer requires a router's protocol support capability to be identical for all interfaces on the router. 1 Specification of Requirements 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]. 2 Introduction RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. [2] adds functionality to Integrated IS-IS so that it supports IPv6. RFC 1195 [1] places topological restrictions on networks that are routed using Integrated IS-IS, specifically, that every router in a level-1 area must be capable of all network layer protocols that are present in that area, and every routers in a level-2 area must be capable of all network layer protocols that are present in the whole IS-IS routing domain. The extension discribed in this document takes away this restriction by maintaining separate SPF topologies for each network layer protocol. The major benefit of this mechanism is that IPv4-only routers, IPv6-only routers and IPv4/IPv6-dual routers can co-exist in a single IS-IS routing domain. Furthermore, it no longer requires a router's protocol support capability to be identical for all interfaces on the router. The changes this document discribes include the design of new TLV and Sub-TLV to replace the existing Protocols Supported TLV and the migration mechanism from the current node oriented protocol support routing to the new interface oriented protocol support routing. 3 Maintaining Router Adjacency All routers MUST announce the interface oriented protocol support capability in IS-IS Hello packet to build the concrete view of the Noguchi, Takada Expires July 2003 [Page 2] Internet Draft draft-noguchi-isis-protocol-topology-01.txt February 2003 network layer protocol topology in the IS-IS routing domain. The "Interface Protocols Supported TLV" is introduced into the IS-IS Hello packet for this purpose. It replaces the existing Protocols Supported TLV that is prohibited from having different protocol support capability for each interface as specified in RFC 1195 [1] section 4.4. The rules for adjacency formation are different for broadcast and point-to-point interfaces. 3.1 Maintaining Adjacencies on Point-to-Point interfaces On point-to-point interfaces, routers MUST NOT form an adjacency if the neighboring router doesn't support at least one of the same interface oriented protocol support capability reported by "Interface Protocols Supported TLV" in IS-IS Hello packet. 3.2 Maintaining Adjacencies on Broadcast interfaces On broadcast interfaces, routers MUST attempt to form an adjacency regardless of the neighbor's interface oriented protocol support capability reported by "Interface Protocols Supported TLV" in IS-IS Hello packet. To avoid routing loops, routers MUST NOT attempt to form an adjacency if the neighboring router doesn't contain "Interface Protocols Supported TLV" in IS-IS Hello packet. There is no change regarding Designated IS selection, CSNP and PSNP with ISO 10589 [3]. 4 Advertising Protocols Supported Sub-TLV in Extended IS Reachability TLV The routing capability of network layer protocols between two neighboring routers MUST be encoded by "Protocols Supported Sub-TLV" in the Extended IS Reachability TLV [4]. This sub-TLV replaces the existing Protocols Supported TLV in LSP that contains only the node oriented routing capability of the network layer protocols. The rules for encoding this Sub-TLV depend on the type of interface. 4.1 Protocols Supported Sub-TLV for Point-to-Point Interface Neighbors Noguchi, Takada Expires July 2003 [Page 3] Internet Draft draft-noguchi-isis-protocol-topology-01.txt February 2003 On point-to-point interfaces, "Protocols Supported Sub-TLV" MUST be encoded by ANDing the local side of interface oriented protocol support capability with the remote side of interface oriented protocol support capability, which is reported by the "Interface Protocols Supported TLV" in the neighboring router's IS-IS Hello packet. 4.2 Protocols Supported Sub-TLV for Broadcast Interface Neighbors On broadcast interfaces, the routing capability between two neighboring routers is encoded by two "Protocols Supported Sub-TLVs". One is in a regular LSP and the other one is in a pseudo-node LSP. In the regular LSP, "Protocols Supported Sub-TLV" in Extended IS Reachability TLV to pseudo-node IS, MUST contain interface oriented protocol suppport capability of originating router. In the pseudo-node LSP, the "Protocols Supported Sub-TLV" in the Extended IS Reachability TLV to each neighboring router MUST contain each router's interface oriented protocol support capability, which DIS received in the "Interface Protocols Supported TLV" in each neighboring router's IS-IS Hello packet. Then the SPF calculation acquires routing capability of network layer protocols between two neighboring routers by combining those two "Protocols Supported Sub-TLVs". Detail is specified in section 5. 5 SPF calculation To build separate topologies of each network layer protocol, the SPF caluculation MUST be done for each network layer protocol. "Protocols Supported Sub-TLV" in Extended IS Reachability TLV MUST be used to check the routing capability of each network layer protocols. This replaces the use of the existing Protocols Supported TLV which contains only the node oriented routing capability of network layer protocols. On point-to-point networks, the "Protocols Supported Sub-TLV" in the Extended IS Reachability TLV to the neighboring router MUST contain the specified network layer protocols identifier to use the neighboring router for the specified SPF calculation. On broadcast networks, both the "Protocols Supported Sub-TLV" in Extended IS Reachability TLV to pseudo-node IS in regular LSP and the "Protocols Supported Sub-TLV" in Extended IS Reachability TLV to the Noguchi, Takada Expires July 2003 [Page 4] Internet Draft draft-noguchi-isis-protocol-topology-01.txt February 2003 neighboring router in pseudo-node LSP MUST contain the specified network layer protocols identifier to use the neighboring router for the specified protocol SPF calculation. The reverse protocol support capability check within SPF SHOULD be made to acquire the bi-directinal protocol support capability. 6 LSP Flooding There is no change in the LSP flooding mechanism with ISO 11589 [3]. 7 Packet Encoding One TLV and one Sub-TLV are introduced for the protocol topology support. 7.1 Interface Protocols Supported TLV Interface Protocols Supported TLV MUST be encoded in all IS-IS Hello packets to replace the existing Protocols Supported TLV. This TLV contains the set of Network Layer Protocol Identifiers for Network Layer protocols that this interface is capable of sending and receiving. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 139 | Length | NLPID #1 | NLPID #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | +-+-+-+-+-+-+-+-+ 7.2 Protocols Supported Sub-TLV in Extended IS Reachability TLV Protocols Supported Sub-TLV MUST be encoded in all Extended IS Reach- ability TLV as specified section 4 to replace the existing Protocols Supported TLV. This TLV contains the set of Network Layer Protocol Identifiers for Network Layer protocols that two neighboring routers are capable of. Noguchi, Takada Expires July 2003 [Page 5] Internet Draft draft-noguchi-isis-protocol-topology-01.txt February 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 129 | Length | NLPID #1 | NLPID #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | +-+-+-+-+-+-+-+-+ 8 Migration from Node Oriented to Interface Oriented Protocol Support Protocols Supported TLV (TLV 129) in IS-IS Hello packets and LSPs with LSP number 0 identifies the protocols which are supported by each router as defined in RFC 1195 [1]. This TLV MUST be identical for all IS-IS Hello packets and all LSPs with LSP number 0 as stated in RFC 1195 [1] section 4.4. This is called the node oriented proto- col support routing. The Interface Protocols Supported TLV (TLV 139) and the Protocols Supported Sub-TLV (Sub-TLV 129) in the Extended IS-Reachability TLV (TLV 22) are defined in this draft. The Interface Protocols Supported TLV identifies the protocols capability which are supported by the interface on which IS-IS Hello packet is transmitted. The Protocols Supported Sub-TLV in the Extended IS-Reachability TLV is flooded those interface oriented protocol support capability in the IS-IS routing domain. This is called the interface oriented protocol sup- port routing. If not all routers in the IS-IS routing domain support the interface oriented protocol support routing, the node oriented protocol support routing MUST continue to be used. Once all routers in the network are able to support the new TLV and Sub-TLV containing interface oriented protocol support capability, then network can be migrated to the new interface oriented protocol support routing, though care must be taken to avoid routing loops. 8.1 Transition Algorithm To facilitate a smooth transition between the use of the node ori- ented protocol support routing exclusively to the use of the inter- face oriented protocol support routing exclusively, the following steps must be taken, in the order below. Noguchi, Takada Expires July 2003 [Page 6] Internet Draft draft-noguchi-isis-protocol-topology-01.txt February 2003 (1) All routers advertise the Protocols Supported TLV in IS-IS Hello packets and LSPs with LSP number 0 as defined in RFC 1195 [1], and consider only the Protocols Supported TLV in LSPs in their SPF calculation. (2) Each router is configured in turn to send the Interface Protocols Suppported TLV as well as the Protocols Supported TLV in IS-IS Hello packet and the Protocols Supported Sub-TLV in the Extended IS-Reachability TLV as well as the Protocols Supported TLV in the LSPs. The all protocol support capability identifiers SHOULD be same. (3) When all routers are advertising the Interface Protocols Supported TLV in IS-IS Hello packets and the Protocols Supported Sub-TLV in Extended IS-Reachability TLV, make any changes necessary on each system to consider Interface Protocols Supported TLV in IS-IS Hello packet for the adjacency formation and the Protocols Supported Sub-TLV in Extended IS-Reachability TLV for the SPF calculation. (4) Each router is configured in turn to stop advertising the Protocols Supported TLV in IS-IS Hello packet and LSPs with LSP number 0. (5) When the area is only using interface oriented protocol support routing, the protocol support capability on individual interface may be reconfigured to take advantage of the interface oriented protocol support routing. 9 Security Consideration This document raises no new security issues for IS-IS. 10 Acknowledgments We would like to thank Jeff Learman for constructive and valuable comments. 11 Reference [1] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. RFC 1195, December 1990. [2] C. Hopps. Routing IPv6 with IS-IS. Noguchi, Takada Expires July 2003 [Page 7] Internet Draft draft-noguchi-isis-protocol-topology-01.txt February 2003 draft-ietf-isis-ipv6-05.txt, January 2003 (work in progress) [3] ISO. Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO 10589, 1992. [4] T. Li and H. Smit. IS-IS Extensions for Traffic Engineering. draft-ietf-isis-traffic-04.txt, August 2001 (work in progress) 12 Author's Address Kay Noguchi IP Infusion Inc. 111 W. St. John Street, Suite 910 San Jose CA 95113 Email: kay@ipinfusion.com Toshiaki Takada IP Infusion Inc. 111 W. St. John Street, Suite 910 San Jose CA 95113 Email: toshiaki@ipinfusion.com Noguchi, Takada Expires July 2003 [Page 8]