Internet Engineering Task Force (IETF) J. Harrison Request for Comments: 6119 J. Berger Category: Standards Track M. Bartlett ISSN: 2070-1721 Metaswitch Networks February 2011 IPv6 Traffic Engineering in IS-IS
AbstractThis document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic- engineered routes using IPv6 addresses. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6119. Copyright Notice Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. IS-IS]. Each router generates a Link State PDU (LSP) that contains information describing the router and the links from the router. The information in the LSP is encoded in a variable length data structure consisting of a Type, Length, and Value. Such a data structure is referred to as a TLV. [TE] and [GMPLS] define a number of TLVs and sub-TLVs that allow Traffic Engineering (TE) 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 Shortest Path First (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. Multiprotocol Label Switching (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 information (including Generalized-MPLS (GMPLS) TE information) to be carried in IPv6 IS-IS networks. KEYWORDS].
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, and 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. TE] and [GMPLS] and gives an overview of the required IPv6 equivalents.
Section 4.1. Section 4.2. Section 4.3. A router constructs the IPv4 Neighbor Address sub-TLV using one of the IPv4 addresses received in the IS-IS Hello (IIH) PDU from the neighbor on the link. The IPv6 Neighbor Address sub-TLV contains a globally unique IPv6 address for the interface from the peer (which can be either a global or unique-local IPv6 address). The IPv6 Interface Address TLV defined in [IPv6] only contains link-local addresses when used in the IIH PDU. Hence, a neighbor's IP address from the IPv6 Interface Address TLV cannot be used when constructing the IPv6 Neighbor Address sub-TLV. Instead, we define an additional TLV, the IPv6 Global Interface Address TLV in Section 4.5. The IPv6 Global Interface Address TLV is included in IIH PDUs to provide the globally unique IPv6 address that a neighbor router needs in order to construct the IPv6 Neighbor Address sub-TLV. GMPLS] contains the set of SRLGs associated with a link. The SRLG TLV identifies the link using either local/remote IPv4 addresses or, for point-to-point unnumbered links, link-local/remote identifiers. The SRLG TLV includes a flags field to indicate which type of identifier is used.
When only IPv6 is used, IPv4 addresses and link-local/remote identifiers are not available to identify the link, but IPv6 addresses can be used instead. There is no backward-compatible way to modify the SRLG TLV (type 138) to identify the link by IPv6 addresses; therefore, we need a new TLV. The IPv6 SRLG TLV is defined in Section 4.4. 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.
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. "Shared Risk Link Group Information" section of [GMPLS-ROUTING]). It contains a data structure consisting of the following: - 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 the 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. The 1-octet flags field is interpreted as follows. Flags (1 octet) 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved |NA| +--+--+--+--+--+--+--+--+ NA - Neighbor Address included. The flags field currently contains one flag to indicate whether the IPv6 neighbor address is included (the NA bit is set to 1) or not included (the NA bit is set to 0).
Other bits in the flags field are reserved for future use. Any bits not understood by an implementation MUST be set to zero by the sender. If a router receives an IPv6 SRLG TLV with non-zero values for any bit that it does not understand, it MUST ignore the TLV (in other words, it does not use the TLV locally but floods the TLV unchanged to neighbors as normal). 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 ignore the TLV rather than attempt 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 causing confusion of interpretation, 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). - If both an SRLG TLV and an IPv6 SRLG are received describing the SRLGs for the same link, the receiver MUST apply the SRLG TLV and ignore the IPv6 SRLG TLV. 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). 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 unique-local IPv6 addresses assigned to the interface that is sending the Hello.
The IPv6 Global Interface Address TLV is not used in LSPs. ISIS-AUTH]. [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] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[TE] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ISIS-AUTH] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008. [GMPLS] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [GMPLS-ROUTING] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.