Network Working Group K. Noguchi Internet Draft IP Infusion Inc. Expiration Date: June 2003 T. Takada IP Infusion Inc. January 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 router 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 June 2003 [Page 1] Internet Draft draft-noguchi-isis-protocol-topology-00.txt January 2003 routing domain to support different network layer protocol topologies by maintaining separate SPF trees for each network layer protocol. 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 router 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 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. The changes this document discribes include the design of new TLV and Sub-TLV to replace the existing Protocols Supported TLV. Mechanisms and procedures to migrate to the new TLV and Sub-TLV are not discussed in this document. 3 Maintaining Router Adjacency All routers MUST announce the interface-specific protocols-supported capability in IS-IS Hello packet to build the concrete view of the 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 protocols- capability for each interface as specified in RFC 1195 [1] section Noguchi, Takada Expires June 2003 [Page 2] Internet Draft draft-noguchi-isis-protocol-topology-00.txt January 2003 4.4. Adjacency is made depending on with which interface the IS-IS Hello packet is exchanged. 3.1 Maintaining Adjacencies on Point-to-Point interfaces On point-to-point interfaces, all routers MUST be adjacent if the neighboring router supports at least one of the same interface- specific protocols-supported capabilities reported by "Interface Protocols Supported TLV" in IS-IS Hello packet. 3.2 Maintaining Adjacencies on Broadcast interfaces On broadcast interfaces, all routers MUST be adjacent regardless of the neighbor's interface-specific protocols-supported capability reported by "Interface Protocols Supported TLV" in IS-IS Hello packet. There is no change regarding Designated IS selection, CSNP and CSNP 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- specific routing capability of the network layer protocols. Encoding is made differently depending on which network the neighboring router exists on. 4.1 Protocols Supported Sub-TLV for Point-to-Point Interface Neighbors On point-to-point interfaces, "Protocols Supported Sub-TLV" MUST be encoded by ORing the local side of interface-specific protocols- supported capability with the remote side of interface-specific protocols-supported capability, which is reported by the "Interface Protocols Supported TLV" in the neighboring router's IS-IS Hello packet. Noguchi, Takada Expires June 2003 [Page 3] Internet Draft draft-noguchi-isis-protocol-topology-00.txt January 2003 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-specific protocols-suppported 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-specific protocols-supported 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-specific 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 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 protocols-supported check within SPF SHOULD be made to acquire the bi-directinal protocols routing capability. 6 LSP Flooding Noguchi, Takada Expires June 2003 [Page 4] Internet Draft draft-noguchi-isis-protocol-topology-00.txt January 2003 There is no change in the LSP flooding mechanism with ISO 11589 [0]. 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | +-+-+-+-+-+-+-+-+ Noguchi, Takada Expires June 2003 [Page 5] Internet Draft draft-noguchi-isis-protocol-topology-00.txt January 2003 8 Security Consideration This document raises no new security issues for IS-IS. 9 Acknowledgments TBD. 10 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. 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) 11 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: takada@ipinfusion.com Noguchi, Takada Expires June 2003 [Page 6]