From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5316.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc5316.txt (limited to 'doc/rfc/rfc5316.txt') 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] + -- cgit v1.2.3