Network Working Group D. Ward Internet-Draft Cisco Systems Expires: January 2, 2006 R. Perlman Sun Microsystems R. White D. Farinacci Cisco Systems July 2005 Carrying Attached Addresses in IS-IS draft-ward-l2isis-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft specifies the IS-IS extensions necessary to support multi- link IPv4 and IPv6 networks, as well as to provide true link state routing to any protocols running directly over layer 2. While supporing this concept involves several pieces, this document only Ward, et al. Expires January 2, 2006 [Page 1] Internet-Draft Carrying Attached Addresses in IS-IS July 2005 describes extensions to IS-IS. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. 1. Overview There are a number of systems which have proposed using layer 2 addresses carried in a link state routing protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing in specific environments. This draft proposes a set of TLVs added to [IS-IS] level 1 PDUs, and a new PDU type, to support these proposed systems. This draft does not propose new forwarding mechanisms using this additional information carried within IS-IS. There is a short section included on two possible ways to build a shortest path first tree including this information, to illustrate how this information might be used. 2. Proposed Enhancements to IS-IS This draft proposes a single TLV, the ADDR TLV, with two sub-TLVs, for carrying a list of attaced addresses and pairs of related addresses within IS-IS. This draft also proposes a new IS-IS PDU, the Multicast Group (MGROUP) PDU, for carrying a list of attached or joined multicast groups. 2.1. The ADDR TLV The ADDR TLV is IS-IS TLV type [TBD], and has the following format: 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 | Length | Reserved | +---------------+---------------+-------------------------------+ | Address Sub-TLVs.... +---- o Type: TLV Type, set to [TBD]. o Length: Total number of octets contained in the TLV, including the length of each Sub-TLV within the ADDR TLV. o Reserved: Set to 0. The ADDR TLV MUST be carried in a level-1 psuedo-node LSP generated by the originating IS. An ADDR TLV may carry two types of sub-TLVs, addresses and Ward, et al. Expires January 2, 2006 [Page 2] Internet-Draft Carrying Attached Addresses in IS-IS July 2005 attribtutes. This document defines two address sub-TLVs, and a single attribute sub-TLV. All attribute sub-TLVs carried within a single ADDR TLV apply to all of the address TLVs carried within the same ADDR TLV. If an ADDR TLV is carried within a standard Level 1 link state PDU, it SHOULD contain only unicast addresses. If an ADDR TLV is carried in an MGROUP PDU, described later in this document, it SHOULD contain only multicast group addresses. 2.1.1. The Single AFI Type A Single AFI TLV is used to carry a list of addresses of a single AFI for devices attached to, or reachable from, the IS. One or more of these sub-TLVs may be carried in the ADDR TLV. 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 | Length | AFI Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | addresses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... +---------------- o Type: Set to 1. o Length: Set to the length of the sub-TLV in octets. o AFI Type: The IANA defined AFI type of the included addresses [IANA]. o Addresses: Addresses of the type and length indicated by the AFI type. 2.1.2. The Address Pair Type The Address Pair Sub-TLV carries a pair of related addresses, with each address type defined using an IANA assigned AFI type. The first address of the pair is the reachable through address, and the second is the destination address. Zero or more Address Pair Type sub-TLVs MAY be included in a single ADDR TLV. Ward, et al. Expires January 2, 2006 [Page 3] Internet-Draft Carrying Attached Addresses in IS-IS July 2005 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 | Length | IS AFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IS Address (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AN AFI | AN Address (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... +------------- o Type: Set to 2. o Length: Set to the total number of octects in the sub-TLV. o IS AFI: The IANA defined AFI type of address contained in the RT Address [IANA]. o IS Address: The reachable through, or IS, address. The length of this field is defined by the IANA defined AFI address type. o AN AFI: The IANA defined AFI type of address contained in the AN Address [IANA]. o AN Address: The attached node, or reachable, address. The length of this field is defined by the IANA defined AFI address type. This sub-TLV may be used in several ways, including (but not limited to): o The first address may be an IS address, with the second address being an attached node. o The first address may be an attached node layer 2 address, with the second address being the same attached node's layer 3 address. 2.1.3. The VLAN Type The VLAN sub-TLV carries a 32 bit VLAN identifier. All address sub- TLVs carried within the same ADDR TLV as the VLAN sub-TLV are considered part of the VLAN indicated in this sub-TLV. 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 | Length | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN ID | +---------------------------------------------------------------+ o Type: Set to 3. o Length: Set to 4. Ward, et al. Expires January 2, 2006 [Page 4] Internet-Draft Carrying Attached Addresses in IS-IS July 2005 o Options: Optional Flags o VLAN ID: Set to the VLAN identifier. The Options field is treated as 16 flags indicating additional information about this VLAN or the status of the advertising IS on this VLAN: o Bit 0: If set, indicates this IS has directly connected end nodes (or end nodes learned through some other mechanism than through IS-IS). o Bits 1-15: Reserved 2.2. The Multicast Group PDU The Multicast Group (MGROUP) PDU can be used to advertise a set of attached, or joined, multicast groups. The MGROUP PDU is formatted identical to a Level 1 Link State PDU, as described in Section 9.3 of [IS-IS]. One field, PDU Type, is changed to [TBD], to signify this PDU is carrying multicast group information, rather than unicast reachability information. ADDR TLVs, described in the previous sections of this document, are used to carry attached or joined multicast groups. 3. Considerations for Using L2 Information in IS-IS While this document does not specify the way in which addresses carried in these TLVs is used in IS-IS, two general areas of concern are considered in this section: building the SPF tree when using this information, and the election of designated intermediate systems (DIS) in an environment using this information. 3.1. Building SPF Trees with Layer 2 Information Each IS which is part of a single broadcast domain from a layer 2 perspective will build a single SPF tree (SPT) for every IS indicating connected layer 2 end nodes or advertising direct connections to layer 2 end nodes. An optimal unicast forwarding path and an optimal flooding path to any given layer 2 address or set of layer 2 addresses can be developed using these trees. We assume some mechanism for forwarding traffic to these attached addresses added to the SPT is provided for in the mechanism proposing the use of these extension TLVs. Ward, et al. Expires January 2, 2006 [Page 5] Internet-Draft Carrying Attached Addresses in IS-IS July 2005 3.2. Designated Intermediate Routers A single DIS SHOULD be elected as described in [IS-IS] for each layer 2 broadcast domain (VLAN) for which information is being carried in IS-IS. This reduces the amount of work required to flood and maintain synchronized databases over the underlying media on which IS-IS is running and providing layer 2 forwarding information for. 4. Acknowledgements 5. Security Considerations This document adds no additional security risks to IS-IS, nor does it provide any additional security for IS-IS. 6. IANA Considerations This document creates a new TLV type within IS-IS, the ADDR TLV. IANA SHOULD assign a TLV descriptor code (type) to this TLV. This document creates a new sub-TLV numbering space for ADDR TLVs. Within this space, this document defines three types. IANA SHOULD manage the remaining space using the consensus method. 7. References 7.1. Normative References [IS-IS] Heffernan, A., "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)", OSI Standard ISO 10589, 1992. 7.2. Informative References [RBRIDGES] Perlman, R., Touch, J., and A. Yegin, "RBridges: Transparent Routing", RFC draft draft-perlman-rbridge-02.txt, February 2005. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. Ward, et al. Expires January 2, 2006 [Page 6] Internet-Draft Carrying Attached Addresses in IS-IS July 2005 Authors' Addresses David Ward Cisco Systems Email: wardd@cisco.com Radia Perlman Sun Microsystems Email: Radia.Perlman@Sun.com Russ White Cisco Systems Email: riw@cisco.com Dino Farinacci Cisco Systems Email: dino@cisco.com Ward, et al. Expires January 2, 2006 [Page 7] Internet-Draft Carrying Attached Addresses in IS-IS July 2005 Intellectual Property Statement 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-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ward, et al. Expires January 2, 2006 [Page 8]