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