Internet Engineering Task Force                              J. Harrison
INTERNET-DRAFT                                                 J. Berger
Expires July 2005                                            M. Bartlett
                                               Data Connection Ltd (DCL)
                                                            January 2005

                    IPv6 Traffic Engineering in IS-IS
                    <draft-ietf-isis-ipv6-te-00.txt>

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright Notice

   Copyright (C) The Internet Society 2005. All Rights Reserved.


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 2005                                               [Page 1]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


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 2005                                               [Page 2]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


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 is 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 2005                                               [Page 3]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


   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  IPv6 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 2005                                               [Page 4]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


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 2005                                               [Page 5]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


   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 2005                                               [Page 6]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


   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 2005                                               [Page 7]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


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]  "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)", ISO 10589, 2002.

   [IPv6]    C. Hopps, "Routing IPv6 with IS-IS",
             draft-ietf-isis-ipv6-05.txt, January 2003
             (work in progress).

   [TE]      H. Smit and T. Li, "Intermediate System to Intermediate
             System (IS-IS) Extensions for Traffic Engineering (TE)",
             RFC 3784, June 2004.

   [GMPLS]   K.Kompella and Y.Rekhter, "IS-IS Extensions in Support of
             Generalized Multi-Protocol Label Switching",
             draft-ietf-isis-gmpls-extensions-19.txt, October 2003
             (work in progress).







Expires July 2005                                               [Page 8]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005

7.2  Informative References

   [GMPLS-ROUTING]
             K.Kompella and Y.Rekhter, "Routing Extensions in Support of
             Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt,
             October 2003 (work in progress).


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 2005                                               [Page 9]


Internet Draft       IPv6 Traffic Engineering in IS-IS      January 2005


9.  Full Copyright Statement

   Copyright (C) The Internet Society 2004.  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.

   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.

   This document may not be modified, and derivative works of it may
   not be created, except to publish it as an RFC and to translate it
   into languages other than English.


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 IETF's procedures with respect to rights in IETF 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.








Expires July 2005                                              [Page 10]