Internet Engineering Task Force J. Harrison INTERNET-DRAFT J. Berger Expires July 2009 M. Bartlett Intended status: Proposed Standard Data Connection Ltd (DCL) January 2009 IPv6 Traffic Engineering in IS-IS Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 7, 2009. Abstract This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with two new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. Expires July 2009 [Page 1] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 1. Terms 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. Overview [TE] and [GMPLS] define a number of TLVs and sub-TLVs that allow Traffic Engineering information to be disseminated by the IS-IS protocol [IS-IS]. The addressing information passed in these TLVs is IPv4 specific. [IPv6] describes how the IS-IS protocol can be used to carry out SPF routing for IPv6. It does this by defining IPv6 specific TLVs that are analogous to the TLVs used by IS-IS for carrying IPv4 addressing information. MPLS Traffic Engineering is very successful and, as the use of IPv6 grows, there is a need to be able to support Traffic Engineering in IPv6 networks. This document defines the TLVs that allow Traffic Engineering (including GMPLS TE) information to be carried in IPv6 IS-IS networks. 3. Summary of operation 3.1 Identifying IS-IS links using IPv6 addresses Each IS-IS link has certain properties - bandwidth, shared risk link groups (SRLGs), switching capabilities and so on. The IS-IS extensions defined in [TE] and [GMPLS] describe how to associate these traffic engineering parameters with IS-IS links. These TLVs use IPv4 addresses to identify the link (or local/remote link identifiers on unnumbered links). When IPv6 is used, a numbered link may be identified by IPv4 and/or IPv6 interface addresses. The type of identifier used does not affect the properties of the link - it still has the same bandwidth, SRLGs, switching capabilities. This document describes an approach for supporting IPv6 traffic engineering, by defining TLV extensions that allow TE links and nodes to be identified by IPv6 addresses. Expires July 2009 [Page 2] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 3.1.1 IPv6 address types An IPv6 address can have global, site-local or link-local scope. - A link-local IPv6 address is valid only within the scope of a single link, and may only be referenced on that link. - A site-local IPv6 address is valid in the scope of a single Autonomous System (AS). - A global IPv6 address is valid within the scope of the Internet. Because the IPv6 traffic engineering TLVs present in LSPs are propagated across networks, they MUST NOT use link-local addresses. As IS-IS only operates within the scope of a single AS, IS-IS does not need to differentiate between global and site-local addresses. 3.2 IP addresses used in Traffic Engineering TLVs This section lists the IP addresses used in the TLVs defined in [TE] and [GMPLS], and gives an overview of the required IPv6 equivalents. 3.2.1 TE Router ID TLV The TE Router ID TLV contains a stable IPv4 address that is routable, regardless of the state of each interface. Similarly, for IPv6, it is useful to have a stable IPv6 address identifying a TE node. The IPv6 TE Router ID TLV is defined in section 4.1. 3.2.2 IPv4 Interface Address sub-TLV This sub-TLV of the Extended IS Reachability TLV contains an IPv4 address for the local end of a link. The equivalent IPv6 Interface Address sub-TLV is defined in section 4.2. 3.2.3 IPv4 Neighbor Address sub-TLV This sub-TLV of the Extended IS Reachability TLV is used for point-to-point links, and contains an IPv4 address for the neighbor's end of a link. The equivalent IPv6 Neighbor Address sub-TLV is defined in section 4.3. Expires July 2009 [Page 3] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 In order to build the IPv6 Neighbor Address sub-TLV, an IS needs to be able to get hold of a global (or site-local) IPv6 address for the interface from the peer. To achieve this, the IPv6 Global Interface Address TLV is defined in section 4.5. This TLV is included in the IIH PDU and contains global or site-local IPv6 interface address information. The TLV is used in addition to the IPv6 Interface Address TLV defined in [IPv6], which, when used in the IIH PDU, carries only link-local addresses. 3.2.4 IPv4 SRLG TLV The SRLG TLV (type 138) defined in [GMPLS] identifies the corresponding link using either local/remote IPv4 addresses or link local/remote identifiers, and includes a flags field to indicate which type of identifier is used. When only IPv6 is used, we may not have either of these means of identifying the corresponding Extended IS Reachability TLV or link. There is no back-compatible way to modify the SRLG TLV (type 138) to identify the link by IPv6 addresses, and therefore we need a new TLV. The IPv6 SRLG TLV is defined in section 4.4. 4. IPv6 TE TLVs 4.1 IPv6 TE Router ID TLV The IPv6 Traffic Engineering Router ID TLV is TLV type 140. The IPv6 TE Router ID TLV contains a 16-octet IPv6 address. A stable, global or site-local IPv6 address SHOULD be used, so that the router ID provides a routable address, regardless of the state of a node's interfaces. If a router does not implement traffic engineering, it MAY include or omit the IPv6 Traffic Engineering Router ID TLV. If a router implements traffic engineering for IPv6, it MUST include this TLV in its LSP. This TLV MUST NOT be included more than once in an LSP. If the TLV occurs more than once in an LSP, all except the first instance is ignored. Implementations MUST NOT inject a /128 prefix for the IPv6 TE router ID into their forwarding table because this can lead to forwarding loops when interacting with systems that do not support this TLV. Expires July 2009 [Page 4] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 4.2 IPv6 Interface Address sub-TLV The IPv6 Interface Address sub-TLV of the Extended IS Reachability TLV has sub-TLV type 12. It contains a 16-octet IPv6 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times. Implementations MUST NOT inject a /128 prefix for the interface address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions described in [TE], it MAY include or omit this sub-TLV. If a router implements IPv6 traffic engineering, it MUST include this sub-TLV (except on an unnumbered point-to-point link, in which case the Link Local Interface Identifiers sub-TLV is used instead). This sub-TLV MUST NOT contain an IPv6 link-local address. 4.3 IPv6 Neighbor Address sub-TLV The IPv6 Neighbor Address sub-TLV of the Extended IS Reachability TLV has sub-TLV type 13. It contains a 16-octet IPv6 address for a neighboring router on the link described by the (main) TLV. This sub-TLV can occur multiple times. Implementations MUST NOT inject a /128 prefix for the interface address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions described in [TE], it MAY include or omit this sub-TLV. If a router implements IPv6 traffic engineering, it MUST include this sub-TLV for point-to-point links (except on an unnumbered point-to-point link, in which case the Link Local Interface Identifiers sub-TLV is used instead). This sub-TLV MUST NOT contain an IPv6 link-local address. 4.4 IPv6 SRLG TLV The IPv6 SRLG TLV has type 139. The TLV carries the Shared Risk Link Group information (see Section "Shared Risk Link Group Information" of [GMPLS-ROUTING]). Expires July 2009 [Page 5] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 It contains a data structure consisting of: - 6 octets of System ID - 1 octet of Pseudonode Number - 1 octet flags - 16 octets of IPv6 interface address - (optional) 16 octets of IPv6 neighbor address - (variable) list of SRLG values, where each element in the list has 4 octets. The following illustrates encoding of the Value field of the IPv6 SRLG 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System ID (cont.) | Pseudonode num| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 interface address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 interface address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 interface address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 interface address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) IPv6 neighbor address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 neighbor address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 neighbor address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 neighbor address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The neighbor is identified by its System Id (6-octets), plus one octet to indicate the pseudonode number if the neighbor is on a LAN interface. Expires July 2009 [Page 6] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 The flag octet indicates whether the IPv6 neighbor address is included (set to 1), or not included (set to 0). Other values for the flags field are reserved - an implementation receiving a value for the flags field other than 0 or 1 SHOULD discard the TLV. Note that this rule for processing the flags octet allows for future extensibility of the IPv6 SRLG TLV. In particular, it allows alternative means of identifying the corresponding link to be added in the future. An implementation that does not understand such an extension will simply discard the TLV, rather than attempting to interpret the TLV incorrectly. The length of this TLV is 24 + 4 * (number of SRLG values) + 16 (if the IPv6 neighbor address is included). To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP from contradicting each other, the following rules are applied. - The IPv6 SRLG TLV MAY occur more than once within the IS-IS logical LSP. - There MUST NOT be more than one IPv6 SRLG TLV for a given link. - The IPv6 SRLG TLV (type 139) MUST NOT be used to describe the SRLGs for a given link if it is possible to use the SRLG TLV (type 138). In other words, if SRLGs are to be advertised for a link, and if the Extended IS Reachability TLV describing a link contains IPv4 interface/neighbor address sub-TLVs or the link local identifiers sub-TLV, then the SRLGs MUST be advertised in the SRLG TLV (type 138). 4.5 IPv6 Global Interface Address TLV The IPv6 Global Interface Address TLV is TLV type 233. The TLV structure is identical to that of the IPv6 Interface Address TLV defined in [IPv6], but the semantics are different. In particular, the TLV is included in IIH PDUs for those interfaces using IPv6 TE extensions. The TLV contains global or site-local IPv6 addresses assigned to the interface that is sending the Hello. The IPv6 Global Interface Address TLV is not used in LSPs. 5. Security Considerations This document raises no new security considerations. Expires July 2009 [Page 7] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 6. IANA Considerations This document defines the following new IS-IS TLV types that need to be reflected in the IS-IS TLV code-point registry: Type Description IIH LSP SNP ---- ---------------------- --- --- --- 139 IPv6 SRLG TLV n y n 140 IPv6 TE Router ID n y n 233 IPv6 Global Interface y n n Address TLV This document also defines the following new sub-TLV types of top-level TLV 22 that need to be reflected in the IS-IS sub-TLV registry for TLV 22: Type Description Length ---- ------------------------------ -------- 12 IPv6 Interface Address 16 13 IPv6 Neighbor Address 16 7. References 7.1 Normative References [IS-IS] ISO, "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)", International Standard 10589: 2002, Second Edition, 2002. [IPv6] C. Hopps, "Routing IPv6 with IS-IS", RFC 5308, October 2008. [TE] H. Smit and T. Li, "IS-IS extensions for Traffic Engineering", RFC 5305, October 2008. Expires July 2009 [Page 8] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 7.2 Informative References [GMPLS] K.Kompella and Y.Rekhter, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching", RFC 5307, October 2008. [GMPLS-ROUTING] K.Kompella and Y.Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. 8. Authors' Addresses Jon Harrison Data Connection Ltd 100 Church Street Enfield EN2 6BQ U.K. Phone: +44 20 8366 1177 Email: jon.harrison@dataconnection.com Jon Berger Data Connection Ltd 100 Church Street Enfield EN2 6BQ U.K. Phone: +44 20 8366 1177 Email: jon.berger@dataconnection.com Mike Bartlett Data Connection Ltd 100 Church Street Enfield EN2 6BQ U.K. Phone: +44 20 8366 1177 Email: mike.bartlett@dataconnection.com Expires July 2009 [Page 9] Internet Draft IPv6 Traffic Engineering in IS-IS January 2009 9. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. ALL IETF Documents 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, THE IETF TRUST 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 definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Expires July 2009 [Page 10]