summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5316.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5316.txt')
-rw-r--r--doc/rfc/rfc5316.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5316.txt b/doc/rfc/rfc5316.txt
new file mode 100644
index 0000000..9135bd3
--- /dev/null
+++ b/doc/rfc/rfc5316.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group M. Chen
+Request for Comments: 5316 R. Zhang
+Category: Standards Track Huawei Technologies Co., Ltd
+ X. Duan
+ China Mobile
+ December 2008
+
+
+ ISIS Extensions in Support of Inter-Autonomous System (AS)
+ MPLS and GMPLS Traffic Engineering
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2008 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.
+
+Abstract
+
+ This document describes extensions to the ISIS (ISIS) protocol to
+ support Multiprotocol Label Switching (MPLS) and Generalized MPLS
+ (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems
+ (ASes). It defines ISIS-TE extensions for the flooding of TE
+ information about inter-AS links, which can be used to perform inter-
+ AS TE path computation.
+
+ No support for flooding information from within one AS to another AS
+ is proposed or defined in this document.
+
+
+
+
+
+
+
+
+
+
+Chen, et al. Standards Track [Page 1]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Conventions Used in This Document ..........................3
+ 2. Problem Statement ...............................................3
+ 2.1. A Note on Non-Objectives ...................................4
+ 2.2. Per-Domain Path Determination ..............................4
+ 2.3. Backward Recursive Path Computation ........................6
+ 3. Extensions to ISIS-TE ...........................................7
+ 3.1. Inter-AS Reachability TLV ..................................7
+ 3.2. TE Router ID ...............................................9
+ 3.3. Sub-TLV Detail .............................................9
+ 3.3.1. Remote AS Number Sub-TLV ............................9
+ 3.3.2. IPv4 Remote ASBR ID Sub-TLV ........................10
+ 3.3.3. IPv6 Remote ASBR ID Sub-TLV ........................11
+ 3.3.4. IPv4 TE Router ID sub-TLV ..........................11
+ 3.3.5. IPv6 TE Router ID sub-TLV ..........................12
+ 4. Procedure for Inter-AS TE Links ................................12
+ 4.1. Origin of Proxied TE Information ..........................14
+ 5. Security Considerations ........................................14
+ 6. IANA Considerations ............................................15
+ 6.1. Inter-AS Reachability TLV .................................15
+ 6.2. Sub-TLVs for the Inter-AS Reachability TLV ................15
+ 6.3. Sub-TLVs for the IS-IS Router Capability TLV ..............17
+ 7. Acknowledgments ................................................17
+ 8. References .....................................................17
+ 8.1. Normative References ......................................17
+ 8.2. Informative References ....................................17
+
+1. Introduction
+
+ [ISIS-TE] defines extensions to the ISIS protocol [ISIS] to support
+ intra-area Traffic Engineering (TE). The extensions provide a way of
+ encoding the TE information for TE-enabled links within the network
+ (TE links) and flooding this information within an area. The
+ extended IS reachability TLV and traffic engineering router ID TLV,
+ which are defined in [ISIS-TE], are used to carry such TE
+ information. The extended IS reachability TLV has several nested
+ sub-TLVs that describe the TE attributes for a TE link.
+
+ [ISIS-TE-V3] and [GMPLS-TE] define similar extensions to ISIS [ISIS]
+ in support of IPv6 and GMPLS traffic engineering, respectively.
+
+ Requirements for establishing Multiprotocol Label Switching (MPLS) TE
+ Label Switched Paths (LSPs) that cross multiple Autonomous Systems
+ (ASes) are described in [INTER-AS-TE-REQ]. As described in [INTER-
+ AS-TE-REQ], a method SHOULD provide the ability to compute a path
+ spanning multiple ASes. So a path computation entity that may be the
+
+
+
+Chen, et al. Standards Track [Page 2]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ head-end Label Switching Router (LSR), an AS Border Router (ASBR), or
+ a Path Computation Element (PCE [PCE]) needs to know the TE
+ information not only of the links within an AS, but also of the links
+ that connect to other ASes.
+
+ In this document, a new TLV, which is referred to as the inter-AS
+ reachability TLV, is defined to advertise inter-AS TE information,
+ and three new sub-TLVs are defined for inclusion in the inter-AS
+ reachability TLV to carry the information about the remote AS number
+ and remote ASBR ID. The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3],
+ and other documents for inclusion in the extended IS reachability TLV
+ for describing the TE properties of a TE link are applicable to be
+ included in the inter-AS reachability TLV for describing the TE
+ properties of an inter-AS TE link as well. Also, two more new sub-
+ TLVs are defined for inclusion in the IS-IS router capability TLV to
+ carry the TE Router ID when the TE Router ID needs to reach all
+ routers within an entire ISIS routing domain. The extensions are
+ equally applicable to IPv4 and IPv6 as identical extensions to
+ [ISIS-TE] and [ISIS-TE-V3]. Detailed definitions and procedures are
+ discussed in the following sections.
+
+ This document does not propose or define any mechanisms to advertise
+ any other extra-AS TE information within ISIS. See Section 2.1 for a
+ full list of non-objectives for this work.
+
+1.1. Conventions Used in This Document
+
+ 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 [RFC2119].
+
+2. Problem Statement
+
+ As described in [INTER-AS-TE-REQ], in the case of establishing an
+ inter-AS TE LSP that traverses multiple ASes, the Path message
+ [RFC3209] may include the following elements in the Explicit Route
+ Object (ERO) in order to describe the path of the LSP:
+
+ - a set of AS numbers as loose hops, and/or
+
+ - a set of LSRs including ASBRs as loose hops.
+
+ Two methods for determining inter-AS paths are currently being
+ discussed. The per-domain method [PD-PATH] determines the path one
+ domain at a time. The backward recursive method [BRPC] uses
+ cooperation between PCEs to determine an optimum inter-domain path.
+ The sections that follow examine how inter-AS TE link information
+ could be useful in both cases.
+
+
+
+Chen, et al. Standards Track [Page 3]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+2.1. A Note on Non-Objectives
+
+ It is important to note that this document does not make any change
+ to the confidentiality and scaling assumptions surrounding the use of
+ ASes in the Internet. In particular, this document is conformant to
+ the requirements set out in [INTER-AS-TE-REQ].
+
+ The following features are explicitly excluded:
+
+ o There is no attempt to distribute TE information from within one
+ AS to another AS.
+
+ o There is no mechanism proposed to distribute any form of TE
+ reachability information for destinations outside the AS.
+
+ o There is no proposed change to the PCE architecture or usage.
+
+ o TE aggregation is not supported or recommended.
+
+ o There is no exchange of private information between ASes.
+
+ o No ISIS adjacencies are formed on the inter-AS link.
+
+2.2. Per-Domain Path Determination
+
+ In the per-domain method of determining an inter-AS path for an
+ MPLS-TE LSP, when an LSR that is an entry-point to an AS receives a
+ Path message from an upstream AS with an ERO containing a next hop
+ that is an AS number, it needs to find which LSRs (ASBRs) within the
+ local AS are connected to the downstream AS. That way, it can
+ compute a TE LSP segment across the local AS to one of those LSRs and
+ forward the Path message to that LSR and hence into the next AS. See
+ Figure 1 for an example.
+
+ R1------R3----R5-----R7------R9-----R11
+ | | \ | / |
+ | | \ | ---- |
+ | | \ | / |
+ R2------R4----R6 --R8------R10----R12
+ : :
+ <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
+
+ Figure 1: Inter-AS Reference Model
+
+ The figure shows three ASes (AS1, AS2, and AS3) and twelve LSRs (R1
+ through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8 are
+ ASBRs in AS2. R9 and R10 are ASBRs in AS3.
+
+
+
+
+Chen, et al. Standards Track [Page 4]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ If an inter-AS TE LSP is planned to be established from R1 to R12,
+ the AS sequence will be: AS1, AS2, AS3.
+
+ Suppose that the Path message enters AS2 from R3. The next hop in
+ the ERO shows AS3, and R5 must determine a path segment across AS2 to
+ reach AS3. It has a choice of three exit points from AS2 (R6, R7,
+ and R8), and it needs to know which of these provide TE connectivity
+ to AS3, and whether the TE connectivity (for example, available
+ bandwidth) is adequate for the requested LSP.
+
+ Alternatively, if the next hop in the ERO is the entry ASBR for AS3
+ (say R9), R5 needs to know which of its exit ASBRs has a TE link that
+ connects to R9. Since there may be multiple ASBRs that are connected
+ to R9 (both R7 and R8 in this example), R5 also needs to know the TE
+ properties of the inter-AS TE links so that it can select the correct
+ exit ASBR.
+
+ Once the Path message reaches the exit ASBR, any choice of inter-AS
+ TE link can be made by the ASBR if not already made by the entry ASBR
+ that computed the segment.
+
+ More details can be found in Section 4 of [PD-PATH], which clearly
+ points out why advertising of inter-AS links is desired.
+
+ To enable R5 to make the correct choice of exit ASBR, the following
+ information is needed:
+
+ o List of all inter-AS TE links for the local AS.
+
+ o TE properties of each inter-AS TE link.
+
+ o AS number of the neighboring AS connected to by each inter-AS TE
+ link.
+
+ o Identity (TE Router ID) of the neighboring ASBR connected to by
+ each inter-AS TE link.
+
+ In GMPLS networks, further information may also be required to select
+ the correct TE links as defined in [GMPLS-TE].
+
+ The example above shows how this information is needed at the entry-
+ point ASBRs for each AS (or the PCEs that provide computation
+ services for the ASBRs). However, this information is also needed
+ throughout the local AS if path computation functionality is fully
+ distributed among LSRs in the local AS, for example to support LSPs
+ that have start points (ingress nodes) within the AS.
+
+
+
+
+
+Chen, et al. Standards Track [Page 5]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+2.3. Backward Recursive Path Computation
+
+ Another scenario using PCE techniques has the same problem. [BRPC]
+ defines a PCE-based TE LSP computation method (called Backward
+ Recursive Path Computation) to compute optimal inter-domain
+ constrained MPLS-TE or GMPLS LSPs. In this path computation method,
+ a specific set of traversed domains (ASes) are assumed to be selected
+ before computation starts. Each downstream PCE in domain(i) returns
+ to its upstream neighbor PCE in domain(i-1) a multipoint-to-point
+ tree of potential paths. Each tree consists of the set of paths from
+ all boundary nodes located in domain(i) to the destination where each
+ path satisfies the set of required constraints for the TE LSP
+ (bandwidth, affinities, etc.).
+
+ So a PCE needs to select boundary nodes (that is, ASBRs) that provide
+ connectivity from the upstream AS. In order for the tree of paths
+ provided by one PCE to its neighbor to be correlated, the identities
+ of the ASBRs for each path need to be referenced. Thus, the PCE must
+ know the identities of the ASBRs in the remote AS that are reached by
+ any inter-AS TE link, and, in order to provide only suitable paths in
+ the tree, the PCE must know the TE properties of the inter-AS TE
+ links. See the following figure as an example.
+
+ PCE1<------>PCE2<-------->PCE3
+ / : :
+ / : :
+ R1------R3----R5-----R7------R9-----R11
+ | | \ | / |
+ | | \ | ---- |
+ | | \ | / |
+ R2------R4----R6 --R8------R10----R12
+ : :
+ <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
+
+ Figure 2: BRPC for Inter-AS Reference Model
+
+ The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1,
+ PCE2, and PCE3), and twelve LSRs (R1 through R12). R3 and R4 are
+ ASBRs in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are
+ ASBRs in AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS
+ path computation and are responsible for path segment computation
+ within their own domain(s).
+
+ If an inter-AS TE LSP is planned to be established from R1 to R12,
+ the traversed domains are assumed to be selected: AS1->AS2->AS3, and
+ the PCE chain is: PCE1->PCE2->PCE3. First, the path computation
+ request originated from the PCC (R1) is relayed by PCE1 and PCE2
+ along the PCE chain to PCE3. Then, PCE3 begins to compute the path
+
+
+
+Chen, et al. Standards Track [Page 6]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ segments from the entry boundary nodes that provide connection from
+ AS2 to the destination (R12). But, to provide suitable path
+ segments, PCE3 must determine which entry boundary nodes provide
+ connectivity to its upstream neighbor AS (identified by its AS
+ number), and must know the TE properties of the inter-AS TE links.
+ In the same way, PCE2 also needs to determine the entry boundary
+ nodes according to its upstream neighbor AS and the inter-AS TE link
+ capabilities.
+
+ Thus, to support Backward Recursive Path Computation, the same
+ information listed in Section 2.2 is required. The AS number of the
+ neighboring AS connected to by each inter-AS TE link is particularly
+ important.
+
+3. Extensions to ISIS-TE
+
+ Note that this document does not define mechanisms for distribution
+ of TE information from one AS to another, does not distribute any
+ form of TE reachability information for destinations outside the AS,
+ does not change the PCE architecture or usage, does not suggest or
+ recommend any form of TE aggregation, and does not feed private
+ information between ASes. See Section 2.1.
+
+ In this document, for the advertisement of inter-AS TE links, a new
+ TLV, which is referred to as the inter-AS reachability TLV, is
+ defined. Three new sub-TLVs are also defined for inclusion in the
+ inter-AS reachability TLV to carry the information about the
+ neighboring AS number and the remote ASBR ID of an inter-AS link.
+ The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents
+ for inclusion in the extended IS reachability TLV are applicable to
+ be included in the inter-AS reachability TLV for inter-AS TE links
+ advertisement. Also, two other new sub-TLVs are defined for
+ inclusion in the IS-IS router capability TLV to carry the TE Router
+ ID when the TE Router ID is needed to reach all routers within an
+ entire ISIS routing domain.
+
+ While some of the TE information of an inter-AS TE link may be
+ available within the AS from other protocols, in order to avoid any
+ dependency on where such protocols are processed, this mechanism
+ carries all the information needed for the required TE operations.
+
+3.1. Inter-AS Reachability TLV
+
+ The inter-AS reachability TLV has type 141 (see Section 6.1) and
+ contains a data structure consisting of:
+
+
+
+
+
+
+Chen, et al. Standards Track [Page 7]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ o 4 octets of Router ID
+ o 3 octets of default metric
+ o 1 octet of control information, consisting of:
+ - 1 bit of flooding-scope information (S bit)
+ - 1 bit of up/down information (D bit)
+ - 6 bits reserved
+ o 1 octet of length of sub-TLVs
+ o 0-246 octets of sub-TLVs, where each sub-TLV consists of a
+ sequence of:
+ - 1 octet of sub-type
+ - 1 octet of length of the value field of the sub-TLV
+ - 0-244 octets of value
+
+ Compared to the extended reachability TLV, which is defined in
+ [ISIS-TE], the inter-AS reachability TLV replaces the "7 octets of
+ System ID and Pseudonode Number" field with a "4 octets of Router ID"
+ field and introduces an extra "control information" field, which
+ consists of a flooding-scope bit (S bit), an up/down bit (D bit), and
+ 6 reserved bits.
+
+ The Router ID field of the inter-AS reachability TLV is 4 octets in
+ length, which contains the Router ID of the router who generates the
+ inter-AS reachability TLV. The Router ID MUST be unique within the
+ ISIS area. If the router generates inter-AS reachability TLV with
+ entire ISIS routing domain flooding scope, then the Router ID MUST
+ also be unique within the entire ISIS routing domain. The Router ID
+ could be used to indicate the source of the inter-AS reachability
+ TLV.
+
+ The flooding procedures for inter-AS reachability TLV are identical
+ to the flooding procedures for the GENINFO TLV, which are defined in
+ Section 4 of [GENINFO]. These procedures have been previously
+ discussed in [ISIS-CAP]. The flooding-scope bit (S bit) SHOULD be
+ set to 0 if the flooding scope is to be limited to within the single
+ IGP area to which the ASBR belongs. It MAY be set to 1 if the
+ information is intended to reach all routers (including area border
+ routers, ASBRs, and PCEs) in the entire ISIS routing domain. The
+ choice between the use of 0 or 1 is an AS-wide policy choice, and
+ configuration control SHOULD be provided in ASBR implementations that
+ support the advertisement of inter-AS TE links.
+
+ The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents
+ for describing the TE properties of a TE link are also applicable to
+ the inter-AS reachability TLV for describing the TE properties of an
+ inter-AS TE link. Apart from these sub-TLVs, three new sub-TLVs are
+ defined for inclusion in the inter-AS reachability TLV defined in
+ this document:
+
+
+
+
+Chen, et al. Standards Track [Page 8]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ Sub-TLV type Length Name
+ ------------ ------ ---------------------------
+ 24 4 remote AS number
+ 25 4 IPv4 remote ASBR identifier
+ 26 16 IPv6 remote ASBR identifier
+
+ The detailed definitions of the three new sub-TLVs are described in
+ Section 3.3.
+
+3.2. TE Router ID
+
+ The IPv4 TE Router ID TLV and IPv6 TE Router ID TLV, which are
+ defined in [ISIS-TE] and [ISIS-TE-V3] respectively, only have area
+ flooding-scope. When performing inter-AS TE, the TE Router ID MAY be
+ needed to reach all routers within an entire ISIS routing domain and
+ it MUST have the same flooding scope as the inter-AS reachability TLV
+ does.
+
+ [ISIS-CAP] defines a generic advertisement mechanism for ISIS, which
+ allows a router to advertise its capabilities within an ISIS area or
+ an entire ISIS routing domain. [ISIS-CAP] also points out that the
+ TE Router ID is a candidate to be carried in the IS-IS router
+ capability TLV when performing inter-area TE.
+
+ This document uses such mechanism for TE Router ID advertisement when
+ the TE Router ID is needed to reach all routers within an entire ISIS
+ Routing domain. Two new sub-TLVs are defined for inclusion in the
+ IS-IS router capability TLV to carry the IPv4 and IPv6 TE Router IDs,
+ respectively:
+
+ Sub-TLV type Length Name
+ ------------ ------ -----------------
+ 11 4 IPv4 TE Router ID
+ 12 16 IPv6 TE Router ID
+
+ Detailed definitions of the two new sub-TLVs are described in Section
+ 3.3.
+
+3.3. Sub-TLV Detail
+
+3.3.1. Remote AS Number Sub-TLV
+
+ A new sub-TLV, the remote AS number sub-TLV, is defined for inclusion
+ in the inter-AS reachability TLV when advertising inter-AS links.
+ The remote AS number sub-TLV specifies the AS number of the
+ neighboring AS to which the advertised link connects.
+
+
+
+
+
+Chen, et al. Standards Track [Page 9]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ The remote AS number sub-TLV is TLV type 24 (see Section 6.2) and is
+ 4 octets in length. The format is as follows:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote AS Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Remote AS number field has 4 octets. When only 2 octets are used
+ for the AS number, as in current deployments, the left (high-order) 2
+ octets MUST be set to 0. The remote AS number sub-TLV MUST be
+ included when a router advertises an inter-AS TE link.
+
+3.3.2. IPv4 Remote ASBR ID Sub-TLV
+
+ A new sub-TLV, which is referred to as the IPv4 remote ASBR ID sub-
+ TLV, is defined for inclusion in the inter-AS reachability TLV when
+ advertising inter-AS links. The IPv4 remote ASBR ID sub-TLV
+ specifies the IPv4 identifier of the remote ASBR to which the
+ advertised inter-AS link connects. This could be any stable and
+ routable IPv4 address of the remote ASBR. Use of the TE Router ID as
+ specified in the Traffic Engineering router ID TLV [ISIS-TE] is
+ RECOMMENDED.
+
+ The IPv4 remote ASBR ID sub-TLV is TLV type 25 (see Section 6.2) and
+ is 4 octets in length. The format of the IPv4 remote ASBR ID sub-TLV
+ is as follows:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote ASBR ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The IPv4 remote ASBR ID sub-TLV MUST be included if the neighboring
+ ASBR has an IPv4 address. If the neighboring ASBR does not have an
+ IPv4 address (not even an IPv4 TE Router ID), the IPv6 remote ASBR ID
+ sub-TLV MUST be included instead. An IPv4 remote ASBR ID sub-TLV and
+ IPv6 remote ASBR ID sub-TLV MAY both be present in an extended IS
+ reachability TLV.
+
+
+
+
+
+
+Chen, et al. Standards Track [Page 10]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+3.3.3. IPv6 Remote ASBR ID Sub-TLV
+
+ A new sub-TLV, which is referred to as the IPv6 remote ASBR ID sub-
+ TLV, is defined for inclusion in the inter-AS reachability TLV when
+ advertising inter-AS links. The IPv6 remote ASBR ID sub-TLV
+ specifies the IPv6 identifier of the remote ASBR to which the
+ advertised inter-AS link connects. This could be any stable and
+ routable IPv6 address of the remote ASBR. Use of the TE Router ID as
+ specified in the IPv6 Traffic Engineering router ID TLV [ISIS-TE-V3]
+ is RECOMMENDED.
+
+ The IPv6 remote ASBR ID sub-TLV is TLV type 26 (see Section 6.2) and
+ is 16 octets in length. The format of the IPv6 remote ASBR ID sub-
+ TLV is as follows:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote ASBR ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote ASBR ID (continued) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote ASBR ID (continued) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote ASBR ID (continued) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The IPv6 remote ASBR ID sub-TLV MUST be included if the neighboring
+ ASBR has an IPv6 address. If the neighboring ASBR does not have an
+ IPv6 address, the IPv4 remote ASBR ID sub-TLV MUST be included
+ instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID
+ sub-TLV MAY both be present in an extended IS reachability TLV.
+
+3.3.4. IPv4 TE Router ID sub-TLV
+
+ The IPv4 TE Router ID sub-TLV is TLV type 11 (see Section 6.3) and is
+ 4 octets in length. The format of the IPv4 TE Router ID sub-TLV is
+ as follows:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TE Router ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Chen, et al. Standards Track [Page 11]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+
+ When the TE Router ID is needed to reach all routers within an entire
+ ISIS routing domain, the IS-IS Router capability TLV MUST be included
+ in its LSP. If an ASBR supports Traffic Engineering for IPv4 and if
+ the ASBR has an IPv4 TE Router ID, the IPv4 TE Router ID sub-TLV MUST
+ be included. If the ASBR does not have an IPv4 TE Router ID, the
+ IPv6 TE Router sub-TLV MUST be included instead. An IPv4 TE Router
+ ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an
+ IS-IS router capability TLV.
+
+3.3.5. IPv6 TE Router ID sub-TLV
+
+ The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) and is
+ 4 octets in length. The format of the IPv6 TE Router ID sub-TLV is
+ as follows:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TE Router ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TE Router ID (continued) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TE Router ID (continued) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TE Router ID (continued) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ When the TE Router ID is needed to reach all routers within an entire
+ ISIS routing domain, the IS-IS router capability TLV MUST be included
+ in its LSP. If an ASBR supports Traffic Engineering for IPv6 and if
+ the ASBR has an IPv6 TE Router ID, the IPv6 TE Router ID sub-TLV MUST
+ be included. If the ASBR does not have an IPv6 TE Router ID, the
+ IPv4 TE Router sub-TLV MUST be included instead. An IPv4 TE Router
+ ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an
+ IS-IS router capability TLV.
+
+4. Procedure for Inter-AS TE Links
+
+ When TE is enabled on an inter-AS link and the link is up, the ASBR
+ SHOULD advertise this link using the normal procedures for ISIS-TE
+ [ISIS-TE]. When either the link is down or TE is disabled on the
+ link, the ASBR SHOULD withdraw the advertisement. When there are
+ changes to the TE parameters for the link (for example, when the
+ available bandwidth changes), the ASBR SHOULD re-advertise the link
+ but MUST take precautions against excessive re-advertisements.
+
+
+
+Chen, et al. Standards Track [Page 12]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ Hellos MUST NOT be exchanged over the inter-AS link, and
+ consequently, an ISIS adjacency MUST NOT be formed.
+
+ The information advertised comes from the ASBR's knowledge of the TE
+ capabilities of the link, the ASBR's knowledge of the current status
+ and usage of the link, and configuration at the ASBR of the remote AS
+ number and remote ASBR TE Router ID.
+
+ Legacy routers receiving an advertisement for an inter-AS TE link are
+ able to ignore it because they do not know the new TLV and sub-TLVs
+ that are defined in Section 3 of this document. They will continue
+ to flood the LSP, but will not attempt to use the information
+ received.
+
+ In the current operation of ISIS TE, the LSRs at each end of a TE
+ link emit LSAs describing the link. The databases in the LSRs then
+ have two entries (one locally generated, the other from the peer)
+ that describe the different 'directions' of the link. This enables
+ Constrained Shortest Path First (CSPF) to do a two-way check on the
+ link when performing path computation and eliminate it from
+ consideration unless both directions of the link satisfy the required
+ constraints.
+
+ In the case we are considering here (i.e., of a TE link to another
+ AS), there is, by definition, no IGP peering and hence no
+ bidirectional TE link information. In order for the CSPF route
+ computation entity to include the link as a candidate path, we have
+ to find a way to get LSAs describing its (bidirectional) TE
+ properties into the TE database.
+
+ This is achieved by the ASBR advertising, internally to its AS,
+ information about both directions of the TE link to the next AS. The
+ ASBR will normally generate an LSA describing its own side of a link;
+ here we have it 'proxy' for the ASBR at the edge of the other AS and
+ generate an additional LSA that describes that device's 'view' of the
+ link.
+
+ Only some essential TE information for the link needs to be
+ advertised; i.e., the Interface Address, the remote AS number, and
+ the remote ASBR ID of an inter-AS TE link.
+
+ Routers or PCEs that are capable of processing advertisements of
+ inter-AS TE links SHOULD NOT use such links to compute paths that
+ exit an AS to a remote ASBR and then immediately re-enter the AS
+ through another TE link. Such paths would constitute extremely rare
+ occurrences and SHOULD NOT be allowed except as the result of
+ specific policy configurations at the router or PCE computing the
+ path.
+
+
+
+Chen, et al. Standards Track [Page 13]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+4.1. Origin of Proxied TE Information
+
+ Section 4 describes how an ASBR advertises TE link information as a
+ proxy for its neighbor ASBR, but does not describe where this
+ information comes from.
+
+ Although the source of this information is outside the scope of this
+ document, it is possible that it will be a configuration requirement
+ at the ASBR, as are other local properties of the TE link. Further,
+ where BGP is used to exchange IP routing information between the
+ ASBRs, a certain amount of additional local configuration about the
+ link and the remote ASBR is likely to be available.
+
+ We note further that it is possible, and may be operationally
+ advantageous, to obtain some of the required configuration
+ information from BGP. Whether and how to utilize these possibilities
+ is an implementation matter.
+
+5. Security Considerations
+
+ The protocol extensions defined in this document are relatively minor
+ and can be secured within the AS in which they are used by the
+ existing ISIS security mechanisms (e.g., using the cleartext
+ passwords or Hashed Message Authentication Codes - Message Digest 5
+ (HMAC-MD5) algorithm, which are defined in [ISIS] and [RFC5304],
+ respectively).
+
+ There is no exchange of information between ASes, and no change to
+ the ISIS security relationship between the ASes. In particular,
+ since no ISIS adjacency is formed on the inter-AS links, there is no
+ requirement for ISIS security between the ASes.
+
+ Some of the information included in these new advertisements (e.g.,
+ the remote AS number and the remote ASBR ID) is obtained manually
+ from a neighboring administration as part of a commercial
+ relationship. The source and content of this information should be
+ carefully checked before it is entered as configuration information
+ at the ASBR responsible for advertising the inter-AS TE links.
+
+ It is worth noting that in the scenario we are considering, a Border
+ Gateway Protocol (BGP) peering may exist between the two ASBRs and
+ that this could be used to detect inconsistencies in configuration
+ (e.g., the administration that originally supplied the information
+ may be lying, or some manual mis-configurations or mistakes may be
+ made by the operators). For example, if a different remote AS number
+ is received in a BGP OPEN [BGP] from that locally configured to
+ ISIS-TE, as we describe here, then local policy SHOULD be applied to
+ determine whether to alert the operator to a potential mis-
+
+
+
+Chen, et al. Standards Track [Page 14]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ configuration or to suppress the ISIS advertisement of the inter-AS
+ TE link. Note further that if BGP is used to exchange TE information
+ as described in Section 4.1, the inter-AS BGP session SHOULD be
+ secured using mechanisms as described in [BGP] to provide
+ authentication and integrity checks.
+
+ For a discussion of general security considerations for IS-IS, see
+ [RFC5304].
+
+6. IANA Considerations
+
+ IANA has made the following allocations from registries under its
+ control.
+
+6.1. Inter-AS Reachability TLV
+
+ This document defines the following new ISIS TLV type, described in
+ Section 3.1, which has been registered in the ISIS TLV codepoint
+ registry:
+
+ Type Description IIH LSP SNP
+ ---- ---------------------- --- --- ---
+ 141 inter-AS reachability n y n
+ information
+
+6.2. Sub-TLVs for the Inter-AS Reachability TLV
+
+ This document defines the following new sub-TLV types (described in
+ Sections 3.3.1, 3.3.2, and 3.3.3) of top-level TLV 141 (see Section
+ 6.1 above), which have been registered in the ISIS sub-TLV registry
+ for TLV 141. Note that these three new sub-TLVs SHOULD NOT appear in
+ TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222).
+
+ Type Description
+ ---- ------------------------------
+ 24 remote AS number
+ 25 IPv4 remote ASBR Identifier
+ 26 IPv6 remote ASBR Identifier
+
+ As described above in Section 3.1, the sub-TLVs defined in [ISIS-TE],
+ [ISIS-TE-V3], and other documents for describing the TE properties of
+ a TE link are applicable to describe an inter-AS TE link and MAY be
+ included in the inter-AS reachability TLV when adverting inter-AS TE
+ links.
+
+ IANA has updated the registry that was specified as "Sub-TLVs for TLV
+ 22" to be named "Sub-TLVs for TLVs 22, 141, and 222". Three new
+ columns have been added to the registry to show in which TLVs the
+
+
+
+Chen, et al. Standards Track [Page 15]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ sub-TLVs may be present. All sub-TLVs currently defined may be
+ present in all three TLVs, hence the registry (with the definition of
+ the new sub-TLVs defined here) should read as follows.
+
+ TLV TLV TLV
+ Type Description 22 141 222 Reference
+ ------- ------------------------------------ --- --- --- ---------
+ 0 Unassigned y y y
+ 1 Unassigned y y y
+ 2 Unassigned y y y
+ 3 Administrative group (color) y y y [RFC5305]
+ 4 Link Local/Remote Identifiers y y y
+ [RFC4205][RFC5307]
+ 5 Unassigned y y y
+ 6 IPv4 interface address y y y [RFC5305]
+ 7 Unassigned y y y
+ 8 IPv4 neighbor address y y y [RFC5305]
+ 9 Maximum link bandwidth y y y [RFC5305]
+ 10 Maximum reservable link bandwidth y y y [RFC5305]
+ 11 Unreserved bandwidth y y y [RFC5305]
+ 12 Unassigned y y y
+ 13 Unassigned y y y
+ 14 Unassigned y y y
+ 15 Unassigned y y y
+ 16 Unassigned y y y
+ 17 Unassigned y y y
+ 18 TE Default metric y y y [RFC5305]
+ 19 Link-attributes y y y [RFC5029]
+ 20 Link Protection Type y y y
+ [RFC4205][RFC5307]
+ 21 Interface Switching Capability Desc y y y
+ [RFC4205][RFC5307]
+ 22 Bandwidth Constraints y y y [RFC4124]
+ 23 Unconstrained TE LSP Count (sub-)TLV y y y [RFC5330]
+ 24 remote AS number n y n [RFC5316]
+ 25 IPv4 remote ASBR identifier n y n [RFC5316]
+ 26 IPv6 remote ASBR identifier n y n [RFC5316]
+ 27-249 Unassigned
+ 250-254 Reserved for Cisco-specific exts
+ 255 Reserved for future expansion
+
+ Further sub-TLVs may be defined in the future for inclusion in any of
+ the TLVs 22, 141, or 222. The re-naming of the registry as above
+ ensures that there is no accidental overlap of sub-TLV codepoints.
+ The introduction of the columns within the registry clarify the use
+ of the sub-TLVs.
+
+
+
+
+
+Chen, et al. Standards Track [Page 16]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+6.3. Sub-TLVs for the IS-IS Router Capability TLV
+
+ This document defines the following new sub-TLV types, described in
+ Sections 3.3.4 and 3.3.5, of top-level TLV 242 (which is defined in
+ [ISIS-CAP]) that have been registered in the ISIS sub-TLV registry
+ for TLV 242:
+
+ Type Description Length
+ ---- ------------------------------ --------
+ 11 IPv4 TE Router ID 4
+ 12 IPv6 TE Router ID 16
+
+7. Acknowledgments
+
+ The authors would like to thank Adrian Farrel, Jean-Louis Le Roux,
+ Christian Hopps, Les Ginsberg, and Hannes Gredler for their review
+ and comments on this document.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
+ Srinivasan, V., and G. Swallow, "RSVP-TE:
+ Extensions to RSVP for LSP Tunnels", RFC 3209,
+ December 2001.
+
+ [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
+ Authentication", RFC 5304, October 2008.
+
+ [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
+ and dual environments", RFC 1195, December 1990.
+
+ [ISIS-CAP] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal,
+ Ed., "Intermediate System to Intermediate System
+ (IS-IS) Extensions for Advertising Router
+ Information", RFC 4971, July 2007.
+
+8.2. Informative References
+
+ [INTER-AS-TE-REQ] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS
+ Inter-Autonomous System (AS) Traffic Engineering
+ (TE) Requirements", RFC 4216, November 2005.
+
+
+
+
+
+Chen, et al. Standards Track [Page 17]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+ [PD-PATH] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang,
+ "A Per-Domain Path Computation Method for
+ Establishing Inter-Domain Traffic Engineering (TE)
+ Label Switched Paths (LSPs)", RFC 5152, February
+ 2008.
+
+ [BRPC] Vasseur, JP., Ed., Zhang, R., Bitar, N., JL. Le
+ Roux, "A Backward Recursive PCE-Based Computation
+ (BRPC) Procedure to Compute Shortest Inter-Domain
+ Traffic Engineering Label Switched Paths", Work in
+ Progress, April 2008.
+
+ [PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture", RFC
+ 4655, August 2006.
+
+ [ISIS-TE] Li, T. and H. Smit, "IS-IS Extensions for Traffic
+ Engineering", RFC 5305, October 2008.
+
+ [ISIS-TE-V3] Harrison, J., Berger, J., and Bartlett, M., "IPv6
+ Traffic Engineering in IS-IS", Work in Progress,
+ June 2008.
+
+ [GMPLS-TE] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
+ Extensions in Support of Generalized Multi-Protocol
+ Label Switching (GMPLS)", RFC 5307, October 2008.
+
+ [BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed.,
+ "A Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+ January 2006.
+
+ [GENINFO] L. Ginsberg., Previdi, S., and M. Shand,
+ "Advertising Generic Information in IS-IS", Work in
+ Progress, June 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al. Standards Track [Page 18]
+
+RFC 5316 ISIS Extensions for Inter-AS TE December 2008
+
+
+Authors' Addresses
+
+ Mach (Guoyi) Chen
+ Huawei Technologies Co., Ltd
+ KuiKe Building, No.9 Xinxi Rd.
+ Hai-Dian District
+ Beijing, 100085
+ P.R. China
+
+ EMail: mach@huawei.com
+
+
+ Renhai Zhang
+ Huawei Technologies Co., Ltd
+ KuiKe Building, No.9 Xinxi Rd.
+ Hai-Dian District
+ Beijing, 100085
+ P.R. China
+
+ EMail: zhangrenhai@huawei.com
+
+
+ Xiaodong Duan
+ China Mobile
+ 53A, Xibianmennei Ave.
+ Xunwu District
+ Beijing, China
+
+ EMail: duanxiaodong@chinamobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al. Standards Track [Page 19]
+