GENWiki

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

Abstract

 This 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.

Harrison, et al. Standards Track [Page 1] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

 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.

1. Overview

 The IS-IS routing protocol is defined in [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.

2. Requirements Language

 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 [KEYWORDS].

Harrison, et al. Standards Track [Page 2] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

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, 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.

3.1.1. IPv6 Address Types

 An IPv6 address can have global, unique-local, or link-local scope.

A global IPv6 address is valid within the scope of the Internet.

A unique-local IPv6 address is globally unique but is intended for

local communication.

A link-local IPv6 address is valid only within the scope of a

single link and may only be referenced on that link.

 Because the IPv6 traffic engineering TLVs present in LSPs are
 propagated across networks, they MUST NOT use link-local addresses.

 IS-IS does not need to differentiate between global and unique-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.

Harrison, et al. Standards Track [Page 3] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

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.

 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.

3.2.4. IPv4 SRLG TLV

 The SRLG TLV (type 138) defined in [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.

Harrison, et al. Standards Track [Page 4] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

 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.

4. IPv6 TE TLVs

4.1. IPv6 TE Router ID TLV

 The IPv6 TE Router ID TLV is TLV type 140.

 The IPv6 TE Router ID TLV contains a 16-octet IPv6 address.  A stable
 global IPv6 address MUST 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 TE 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.

 An implementation receiving an IPv6 TE Router ID TLV MUST NOT
 consider the router ID as a /128 reachable prefix in the standard SPF
 calculation because this can lead to forwarding loops when
 interacting with systems that do not support this TLV.

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 containing Extended IS Reachability 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.

Harrison, et al. Standards Track [Page 5] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

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 the "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.

Harrison, et al. Standards Track [Page 6] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

  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).

Harrison, et al. Standards Track [Page 7] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

 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).

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 unique-local IPv6 addresses
 assigned to the interface that is sending the Hello.

Harrison, et al. Standards Track [Page 8] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

 The IPv6 Global Interface Address TLV is not used in LSPs.

5. Security Considerations

 This document raises no new security issues for IS-IS; for general
 security considerations for IS-IS, see [ISIS-AUTH].

6. IPv4/IPv6 Migration

 The IS-IS extensions described in this document allow the routing of
 GMPLS Label Switched Paths using IPv6 addressing through an IS-IS
 network.  There are no migration issues introduced by the addition of
 this IPv6 TE routing information into an existing IPv4 GMPLS network.
 Migration of Label Switched Paths from IPv4 to IPv6 is an issue for
 GMPLS signaling and is outside the scope of this document.

7. IANA Considerations

 This document defines the following new IS-IS TLV types that IANA has
 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 IANA has reflected in the Sub-TLVs for TLV 22, 141,
 and 222 registry:

        Type        Description            22  141  222  Length
        ----        -----------            --  ---  ---  ------
          12        IPv6 Interface Address  y   y    y       16
          13        IPv6 Neighbor Address   y   y    y       16

8. 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]      Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
             2008.

Harrison, et al. Standards Track [Page 9] RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011

 [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.

Authors' Addresses

 Jon Harrison
 Metaswitch Networks
 100 Church Street
 Enfield
 EN2 6BQ
 U.K.
 Phone: +44 20 8366 1177
 EMail: jon.harrison@metaswitch.com

 Jon Berger
 Metaswitch Networks
 100 Church Street
 Enfield
 EN2 6BQ
 U.K.
 Phone: +44 20 8366 1177
 EMail: jon.berger@metaswitch.com

 Mike Bartlett
 Metaswitch Networks
 100 Church Street
 Enfield
 EN2 6BQ
 U.K.
 Phone: +44 20 8366 1177
 EMail: mike.bartlett@metaswitch.com

Harrison, et al. Standards Track [Page 10]