| < draft-ietf-pce-disco-proto-isis-07.txt | draft-ietf-pce-disco-proto-isis-08.txt > | |||
|---|---|---|---|---|
| Network Working Group J.L. Le Roux (Editor) | Network Working Group J.L. Le Roux (Editor) | |||
| Internet Draft France Telecom | Internet Draft France Telecom | |||
| Intended Status: Standard Track | Intended Status: Standard Track | |||
| Expires: March 2008 J.P. Vasseur (Editor) | Expires: April 2008 J.P. Vasseur (Editor) | |||
| Cisco System Inc. | Cisco System Inc. | |||
| Yuichi Ikejiri | Yuichi Ikejiri | |||
| NTT Communications | NTT Communications | |||
| Raymond Zhang | Raymond Zhang | |||
| BT Infonet | BT Infonet | |||
| September 2007 | October 2007 | |||
| IS-IS protocol extensions for Path Computation Element (PCE) Discovery | IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery | |||
| draft-ietf-pce-disco-proto-isis-07.txt | draft-ietf-pce-disco-proto-isis-08.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 2, line 9 ¶ | skipping to change at page 2, line 9 ¶ | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The IETF Trust (2007). All rights reserved. | Copyright (C) The IETF Trust (2007). All rights reserved. | |||
| Abstract | Abstract | |||
| There are various circumstances where it is highly desirable for a | There are various circumstances where it is highly desirable for a | |||
| Path Computation Client (PCC) to be able to dynamically and | Path Computation Client (PCC) to be able to dynamically and | |||
| automatically discover a set of Path Computation Elements (PCE), | automatically discover a set of Path Computation Elements (PCEs), | |||
| along with some information that can be used for PCE selection. When | along with information that can be used by the PCC for PCE selection. | |||
| the PCE is a Label Switching Router (LSR) participating in the | When the PCE is a Label Switching Router (LSR) participating in the | |||
| Interior Gateway Protocol (IGP), or even a server participating | Interior Gateway Protocol (IGP), or even a server participating | |||
| passively in the IGP, a simple and efficient way to discover PCEs | passively in the IGP, a simple and efficient way to announce PCEs | |||
| consists of using IGP flooding. For that purpose this document | consists of using IGP flooding. For that purpose this document | |||
| defines extensions to the Intermediate System to Intermediate System | defines extensions to the Intermediate System to Intermediate System | |||
| (IS-IS) routing protocol for the advertisement of PCE Discovery | (IS-IS) routing protocol for the advertisement of PCE Discovery | |||
| information within an IS-IS area or within the entire IS-IS routing | information within an IS-IS area or within the entire IS-IS routing | |||
| domain. | domain. | |||
| Conventions used in this document | Conventions used in this document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| Table of Contents | Table of Contents | |||
| Terminology........................................................3 | 1. Terminology.................................................3 | |||
| 1. 3 | ||||
| 2. Introduction................................................4 | 2. Introduction................................................4 | |||
| 3. Overview....................................................5 | 3. Overview....................................................5 | |||
| 3.1. PCE Information.............................................5 | 3.1. PCE Discovery Information...................................5 | |||
| 3.1.1. PCE Discovery Information...................................5 | 3.2. Flooding Scope..............................................5 | |||
| 3.1.2. PCE Overload Information....................................6 | ||||
| 3.2. Flooding Scope..............................................6 | ||||
| 4. The IS-IS PCED Sub-TLV......................................6 | 4. The IS-IS PCED Sub-TLV......................................6 | |||
| 4.1. PCE-ADDRESS Sub-TLV.........................................7 | 4.1. PCE-ADDRESS Sub-TLV.........................................7 | |||
| 4.2. The PATH-SCOPE Sub-TLV......................................7 | 4.2. The PATH-SCOPE Sub-TLV......................................7 | |||
| 4.3. PCE-DOMAIN Sub-TLV..........................................9 | 4.3. PCE-DOMAIN Sub-TLV..........................................9 | |||
| 4.4. NEIG-PCE-DOMAIN Sub-TLV....................................10 | 4.4. NEIG-PCE-DOMAIN Sub-TLV....................................10 | |||
| 4.5. PCE-CAP-FLAGS Sub-TLV......................................11 | 4.5. PCE-CAP-FLAGS Sub-TLV......................................10 | |||
| 4.6. The OVERLOAD Sub-TLV.......................................11 | 5. Elements of Procedure......................................11 | |||
| 5. Elements of Procedure......................................12 | 6. Backward Compatibility.....................................12 | |||
| 5.1. OVERLOAD Sub-TLV Specific Procedures.......................12 | 7. IANA Considerations........................................12 | |||
| 6. Backward Compatibility.....................................13 | 8. Security Considerations....................................12 | |||
| 7. IANA Considerations........................................13 | 9. Manageability Considerations...............................12 | |||
| 8. Security Considerations....................................13 | 9.1. Control of Policy and Functions............................12 | |||
| 9. Manageability Considerations...............................14 | 9.2. Information and Data Model.................................13 | |||
| 9.1. Control of Policy and Functions............................14 | 9.3. Liveness Detection and Monitoring..........................13 | |||
| 9.2. Information and Data Model.................................14 | 9.4. Verify Correct Operations..................................13 | |||
| 9.3. Liveness Detection and Monitoring..........................14 | ||||
| 9.4. Verify Correct Operations..................................14 | ||||
| 9.5. Requirements on Other Protocols and Functional | 9.5. Requirements on Other Protocols and Functional | |||
| Components...............................................14 | Components...............................................13 | |||
| 9.6. Impact on Network Operations...............................13 | ||||
| 9.6. Impact on Network Operations...............................15 | 10. Acknowledgments............................................14 | |||
| 10. Acknowledgments............................................15 | 11. References.................................................14 | |||
| 11. References.................................................15 | 11.1. Normative References.......................................14 | |||
| 11.1. Normative References.......................................15 | 11.2. Informative References.....................................14 | |||
| 11.2. Informative References.....................................16 | 12. Editors' Addresses:........................................15 | |||
| 12. Editors' Addresses:........................................16 | 13. Contributors' Adresses:....................................15 | |||
| 13. Contributors' Adresses:....................................16 | 14. Intellectual Property Statement............................15 | |||
| 14. Intellectual Property Statement............................17 | ||||
| 1. Terminology | 1. Terminology | |||
| ABR: IS-IS Area Border Router. | ||||
| AS: Autonomous System. | AS: Autonomous System. | |||
| IGP: Interior Gateway Protocol. Either of the two routing | IGP: Interior Gateway Protocol. Either of the two routing | |||
| protocols Open Shortest Path First (OSPF) or Intermediate System | protocols Open Shortest Path First (OSPF) or Intermediate System | |||
| to Intermediate system (IS-IS). | to Intermediate system (IS-IS). | |||
| Intra-area TE LSP: A TE LSP whose path does not cross IGP area | Intra-area TE LSP: A TE LSP whose path does not cross an IGP area | |||
| boundaries. | boundary. | |||
| Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries. | Intra-AS TE LSP: A TE LSP whose path does not cross an AS | |||
| boundary. | ||||
| Inter-area TE LSP: A TE LSP whose path transits two or | Inter-area TE LSP: A TE LSP whose path transits two or | |||
| more IGP areas. That is a TE-LSP that crosses at least one IGP | more IGP areas. That is a TE LSP that crosses at least one IGP | |||
| area boundary. | area boundary. | |||
| Inter-AS TE LSP: A TE LSP whose path transits two or more | Inter-AS TE LSP: A TE LSP whose path transits two or more | |||
| ASes or sub-ASes (BGP confederations). That is a TE-LSP that | ASes or sub-ASes (BGP confederations). That is a TE LSP that | |||
| crosses at least one AS boundary. | crosses at least one AS boundary. | |||
| IS-IS LSP: Link State PDU | IS-IS LSP: Link State PDU | |||
| LSR: Label Switching Router. | LSR: Label Switching Router. | |||
| PCC: Path Computation Client: Any client application requesting a | PCC: Path Computation Client. Any client application requesting a | |||
| path computation to be performed by a Path Computation Element. | path computation to be performed by a Path Computation Element. | |||
| PCE: Path Computation Element: An entity (component, application, | PCE: Path Computation Element. An entity (component, application, | |||
| or network node) that is capable of computing a network path or | or network node) that is capable of computing a network path or | |||
| route based on a network graph, and applying computational | route based on a network graph, and applying computational | |||
| constraints. | constraints. | |||
| PCE-Domain: In a PCE context this refers to any collection of | PCE-Domain: In a PCE context this refers to any collection of | |||
| network elements within a common sphere of address management or | network elements within a common sphere of address management or | |||
| path computational responsibility (referred to as "domain" in | path computational responsibility (referred to as a "domain" in | |||
| [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. | [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. | |||
| This should be distinguished from an IS-IS routing domain as | This should be distinguished from an IS-IS routing domain as | |||
| defined by [ISO]. | defined by [ISO]. | |||
| PCEP: Path Computation Element communication Protocol. | PCEP: Path Computation Element communication Protocol. | |||
| TE LSP: Traffic Engineered Label Switched Path. | TE LSP: Traffic Engineered Label Switched Path. | |||
| 2. Introduction | 2. Introduction | |||
| [RFC4655] describes the motivations and architecture for a Path | [RFC4655] describes the motivations and architecture for a Path | |||
| Computation Element (PCE)-based path computation model for Multi | Computation Element (PCE)-based path computation model for Multi- | |||
| Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic | Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic | |||
| Engineered Label Switched Paths (TE-LSPs). The model allows for the | Engineered Label Switched Paths (TE LSPs). The model allows for the | |||
| separation of the PCE from a Path Computation Client (PCC) (also | separation of the PCE from a Path Computation Client (PCC) (also | |||
| referred to as a non co-located PCE) and allows for cooperation | referred to as a non co-located PCE) and allows for cooperation | |||
| between PCEs. This relies on a communication protocol between PCC and | between PCEs (where one PCE acts as a PCC to make requests of the | |||
| PCE, and between PCEs. The requirements for such a communication | other PCE). This relies on a communication protocol between PCC and | |||
| protocol can be found in [RFC4657] and the communication protocol is | PCE, and also between PCEs. The requirements for such a communication | |||
| protocol can be found in [RFC4657], and the communication protocol is | ||||
| defined in [PCEP]. | defined in [PCEP]. | |||
| The PCE architecture requires that a PCC be aware of the location of | The PCE architecture requires that a PCC be aware of the location of | |||
| one or more PCEs in its domain, and also potentially of some PCEs in | one or more PCEs in its domain, and also, potentially, of PCEs in | |||
| other domains, e.g. in case of inter-domain TE LSP computation. | other domains, e.g., in the case of inter-domain TE LSP computation. | |||
| A network may contain a large number of PCEs with potentially | A network may contain a large number of PCEs, each with potentially | |||
| distinct capabilities. In such a context it is highly desirable to | distinct capabilities. In such a context it is highly desirable to | |||
| have a mechanism for automatic and dynamic PCE discovery, which | have a mechanism for automatic and dynamic PCE discovery that allows | |||
| allows PCCs to automatically discover a set of PCEs, along with | PCCs to automatically discover a set of PCEs along with additional | |||
| additional information about each PCE that may be required for the | information about each PCE that may be used by a PCC to perform PCE | |||
| PCC to perform PCE selection. Additionally, it is valuable for a PCC | selection. Additionally, it is valuable for a PCC to dynamically | |||
| to dynamically detect new PCEs or any modification of the PCE | detect new PCEs, failed PCEs, or any modification to the PCE | |||
| information. Detailed requirements for such a PCE discovery mechanism | information. Detailed requirements for such a PCE discovery mechanism | |||
| are provided in [RFC4674]. | are provided in [RFC4674]. | |||
| Moreover, it may also be useful to discover when a PCE experiences | Note that the PCE selection algorithm applied by a PCC is out of the | |||
| processing overload and when it exits such a state, in order for the | scope of this document. | |||
| PCCs to take some appropriate actions (e.g. redirect their requests | ||||
| to another PCE). Note that the PCE selection algorithm applied by a | ||||
| PCC is out of the scope of this document. | ||||
| When PCCs are LSRs participating in the IGP (OSPF, IS-IS), and PCEs | When PCCs are LSRs participating in the IGP (OSPF, IS-IS), and PCEs | |||
| are either LSRs or servers also participating in the IGP, an | are either LSRs or servers also participating in the IGP, an | |||
| effective mechanism for PCE discovery within an IGP routing domain | effective mechanism for PCE discovery within an IGP routing domain | |||
| consists of utilizing IGP advertisements. | consists of utilizing IGP advertisements. | |||
| This document defines IS-IS extensions to allow a PCE in an IS-IS | This document defines extensions to IS-IS [ISO] to allow a PCE in an | |||
| routing domain to advertise its location along with some information | IS-IS routing domain to advertise its location along with some | |||
| useful to a PCC for PCE selection, so as to satisfy dynamic PCE | information useful to a PCC for PCE selection, so as to satisfy | |||
| discovery requirements set forth in [RFC4674]. This document also | dynamic PCE discovery requirements set forth in [RFC4674]. | |||
| defines extensions allowing a PCE in an IS-IS routing domain to | ||||
| advertise its processing overload state. | ||||
| Generic capability advertisement mechanisms for IS-IS are defined in | Generic capability advertisement mechanisms for IS-IS are defined in | |||
| [IS-IS-CAP]. These allow a router to advertise its capabilities | [IS-IS-CAP]. These allow a router to advertise its capabilities | |||
| within an IS-IS area or an entire IS-IS routing domain. This document | within an IS-IS area or an entire IS-IS routing domain. This document | |||
| leverages this generic capability advertisement mechanism to fully | leverages this generic capability advertisement mechanism to fully | |||
| satisfy the aforementioned dynamic PCE discovery requirements. | satisfy the dynamic PCE discovery requirements. | |||
| This document defines a new sub-TLV (named PCE Discovery (PCED)) to | This document defines a new sub-TLV (named the PCE Discovery (PCED)) | |||
| be carried within the IS-IS Router Capability TLV ([IS-IS-CAP]). | to be carried within the IS-IS Router Capability TLV ([IS-IS-CAP]). | |||
| The PCE information advertised is detailed in section 3. Protocol | The PCE information advertised is detailed in Section 3. Protocol | |||
| extensions and procedures are defined in section 4 and 5. | extensions and procedures are defined in Sections 4 and 5. | |||
| The IS-IS extensions defined in this document allow for PCE discovery | The IS-IS extensions defined in this document allow for PCE discovery | |||
| within an IS-IS Routing domain. Solutions for PCE discovery across AS | within an IS-IS routing domain. Solutions for PCE discovery across AS | |||
| boundaries are beyond the scope of this document, and for further | boundaries are beyond the scope of this document, and for further | |||
| study. | study. | |||
| This document defines a set of sub-TLVs that are nested within each | This document defines a set of sub-TLVs that are nested within each | |||
| other. When the degree of nesting TLVs is 2 (a TLV is carried within | other. When the degree of nesting TLVs is 2 (a TLV is carried within | |||
| another TLV) the TLV carried within a TLV is called a sub-TLV. | another TLV) the TLV carried within a TLV is called a sub-TLV. | |||
| Strictly speaking, when the degree of nesting is 3, a subsub-TLV is | Strictly speaking, when the degree of nesting is 3, a subsub-TLV is | |||
| carried within a sub-TLV that is itself carried within a TLV. For the | carried within a sub-TLV that is itself carried within a TLV. For the | |||
| sake of terminology simplicity, we refer to sub-TLV, a TLV carried | sake of terminology simplicity, a TLV carried within another TLV is | |||
| within a TLV regardless of the degree of nesting. | called a sub-TLV regardless of the degree of nesting. | |||
| 3. Overview | 3. Overview | |||
| 3.1. PCE Information | 3.1. PCE Discovery Information | |||
| The PCE information advertised via IS-IS falls into two categories: | ||||
| PCE Discovery information and PCE Overload information. | ||||
| 3.1.1. PCE Discovery Information | ||||
| The PCE Discovery information is comprised of: | The PCE discovery information is composed of: | |||
| - The PCE location: an IPv4 and/or IPv6 address that is used to reach | - The PCE location: an IPv4 and/or IPv6 address that is used to reach | |||
| the PCE. It is RECOMMENDED to use an address that is always | the PCE. It is RECOMMENDED to use an address that is always | |||
| reachable; | reachable if there is any connectivity to the PCE; | |||
| - The PCE path computation scope (i.e. inter-area, inter-AS, inter- | - The PCE path computation scope (i.e., intra-layer, inter-area, | |||
| layer); | inter-AS, or inter-layer); | |||
| - The set of one or more PCE-Domain(s) into which the PCE has | - The set of one or more PCE-Domain(s) into which the PCE has | |||
| visibility and can compute paths; | visibility and for which the PCE can compute paths; | |||
| - The set of one or more neighbor PCE-Domain(s) towards which a PCE | - The set of zero, one or more neighbor PCE-Domain(s) toward which | |||
| can compute paths; | the PCE can compute paths; | |||
| - A set of communication capabilities (e.g. support for request | - A set of communication capabilities (e.g., support for request | |||
| prioritization) and path computation specific capabilities | prioritization) and path computation-specific capabilities | |||
| (e.g. supported constraints). | (e.g., supported constraints). | |||
| PCE Discovery information is by nature fairly static and does not | PCE discovery information is by nature fairly static and does not | |||
| change with PCE activity. Changes in PCE Discovery information may | change with PCE activity. Changes in PCE discovery information may | |||
| occur as a result of PCE configuration updates, PCE | occur as a result of PCE configuration updates, PCE | |||
| deployment/activation, PCE deactivation/suppression, or PCE failure. | deployment/activation, PCE deactivation/suppression, or PCE failure. | |||
| Hence, this information is not expected to change frequently | Hence, this information is not expected to change frequently. | |||
| 3.1.2. PCE Overload Information | ||||
| The PCE Overload Information is optional and can be used to report | ||||
| a PCE's overload state in order to discourage the PCCs to send new | ||||
| path computation requests. | ||||
| A PCE may decide to clear the overload state according to local | ||||
| implementation triggers (e.g. CPU utilization, average queue length | ||||
| below some pre-defined thresholds). The rate at which a PCE status | ||||
| change is advertised MUST NOT impact by any means the IGP | ||||
| scalability. Particular attention should be given on procedures to | ||||
| avoid state oscillations. | ||||
| 3.2. Flooding Scope | 3.2. Flooding Scope | |||
| The flooding scope for PCE information advertised through IS-IS can | The flooding scope for PCE information advertised through IS-IS can | |||
| be a single L1 area, a L1 area and the L2 sub-domain, or the entire | be a single L1 area, an L1 area and the L2 sub-domain, or the entire | |||
| IS-IS routing domain. | IS-IS routing domain. | |||
| 4. The IS-IS PCED Sub-TLV | 4. The IS-IS PCED Sub-TLV | |||
| The IS-IS PCED sub-TLV is made of a set of non ordered sub-TLVs. | The IS-IS PCED sub-TLV contains a non-ordered set of sub-TLVs. | |||
| The format of the IS-IS PCED sub-TLV and its sub-TLVs is identical to | The format of the IS-IS PCED sub-TLV and its sub-TLVs is identical to | |||
| the TLV format used by the Traffic Engineering Extensions to IS-IS | the TLV format used by the Traffic Engineering Extensions to IS-IS | |||
| [RFC3784]. That is, the TLV is comprised of 1 octet for the type, 1 | [RFC3784]. That is, the TLV is comprised of 1 octet for the type, 1 | |||
| octet specifying the TLV length, and a value field. The Length field | octet specifying the TLV length, and a value field. The Length field | |||
| defines the length of the value portion in octets. | defines the length of the value portion in octets. | |||
| The IS-IS PCED sub-TLV has the following format: | The IS-IS PCED sub-TLV has the following format: | |||
| TYPE: To be assigned by IANA (suggested value = 5) | TYPE: To be assigned by IANA (suggested value = 5) | |||
| LENGTH: Variable | LENGTH: Variable | |||
| VALUE: set of sub-TLVs | VALUE: set of sub-TLVs | |||
| Six sub-TLVs are defined: | Five sub-TLVs are defined: | |||
| Sub-TLV type Length Name | Sub-TLV type Length Name | |||
| 1 variable PCE-ADDRESS sub-TLV | 1 variable PCE-ADDRESS sub-TLV | |||
| 2 3 PATH-SCOPE sub-TLV | 2 3 PATH-SCOPE sub-TLV | |||
| 3 variable PCE-DOMAIN sub-TLV | 3 variable PCE-DOMAIN sub-TLV | |||
| 4 variable NEIG-PCE-DOMAIN sub-TLV | 4 variable NEIG-PCE-DOMAIN sub-TLV | |||
| 5 variable PCE-CAP-FLAGS sub-TLV | 5 variable PCE-CAP-FLAGS sub-TLV | |||
| 6 1 OVERLOAD sub-TLV | ||||
| The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within | The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within | |||
| the PCED sub-TLV. | the PCED sub-TLV. | |||
| The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They | The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They | |||
| MAY be present in the PCED sub-TLV to facilitate selection of inter- | MAY be present in the PCED sub-TLV to facilitate selection of inter- | |||
| domain PCEs. | domain PCEs. | |||
| The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED | The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED | |||
| sub-TLV to facilitate the PCE selection process. | sub-TLV to facilitate the PCE selection process. | |||
| The OVERLOAD sub-TLV is optional and MAY be present in the PCED sub- | Any unrecognized sub-TLV MUST be silently ignored. | |||
| TLV, to indicate a PCE's processing overload state. | ||||
| Any non recognized sub-TLV MUST be silently ignored. | ||||
| The PCED sub-TLV is carried within an IS-IS CAPABILITY TLV defined in | The PCED sub-TLV is carried within an IS-IS CAPABILITY TLV defined in | |||
| [IS-IS-CAP]. | [IS-IS-CAP]. | |||
| No additional sub-TLVs will be added to the PCED TLV in the future. | No additional sub-TLVs will be added to the PCED TLV in the future. | |||
| If a future application requires advertising additional PCE | If a future application requires the advertisement of additional PCE | |||
| information in IS-IS, this will not be carried in the CAPABILITY TLV. | information in IS-IS, this will not be carried in the CAPABILITY TLV. | |||
| The following sub-sections describe the sub-TLVs which may be carried | The following sub-sections describe the sub-TLVs which may be carried | |||
| within the PCED sub-TLV. | within the PCED sub-TLV. | |||
| 4.1. PCE-ADDRESS Sub-TLV | 4.1. PCE-ADDRESS Sub-TLV | |||
| The PCE-ADDRESS sub-TLV specifies the IP address that can be | The PCE-ADDRESS sub-TLV specifies an IP address that can be | |||
| used to reach the PCE. It is RECOMMENDED to make use of an address | used to reach the PCE. It is RECOMMENDED to make use of an address | |||
| that is always reachable, provided the PCE is alive. | that is always reachable, provided the PCE is alive and reachable. | |||
| The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the | The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the | |||
| PCED sub-TLV. It MAY appear twice, when the PCE has both an IPv4 and | PCED sub-TLV. It MAY appear twice, when the PCE has both an IPv4 and | |||
| IPv6 address. It MUST NOT appear more than once for the same address | IPv6 address. It MUST NOT appear more than once for the same address | |||
| type. If it appears more than once only the first occurrence MUST be | type. If it appears more than once only the first occurrence is | |||
| processed and other MUST be ignored. | processed and any others MUST be ignored. | |||
| The PCE-ADDRESS sub-TLV has the following format: | The PCE-ADDRESS sub-TLV has the following format: | |||
| TYPE: 1 | TYPE: 1 | |||
| LENGTH: 5 for IPv4 address and 17 for IPv6 address | LENGTH: 5 for an IPv4 address or 17 for an IPv6 address | |||
| VALUE: This comprises one octet indicating the address-type and 4 | VALUE: This comprises one octet indicating the address-type and 4 | |||
| or 16 octets encoding the IPv4 or IPv6 address to be used | or 16 octets encoding the IPv4 or IPv6 address to be used | |||
| to reach the PCE. | to reach the PCE. | |||
| Address-type: | Address-type: | |||
| 1 IPv4 | 1 IPv4 | |||
| 2 IPv6 | 2 IPv6 | |||
| 4.2. The PATH-SCOPE Sub-TLV | 4.2. The PATH-SCOPE Sub-TLV | |||
| The PATH-SCOPE sub-TLV indicates the PCE path computation scope, | The PATH-SCOPE sub-TLV indicates the PCE path computation scope, | |||
| which refers to the PCE's ability to compute or take part in the | which refers to the PCE's ability to compute or take part in the | |||
| computation of intra-area, inter-area, inter-AS, or inter-layer_TE | computation of paths for intra-area, inter-area, inter-AS, or inter- | |||
| LSP(s). | layer_TE LSPs. | |||
| The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the | The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the | |||
| PCED sub-TLV. There MUST be exactly one instance of the PATH-SCOPE | PCED sub-TLV. There MUST be exactly one instance of the PATH-SCOPE | |||
| sub-TLV within each PCED sub-TLV. If it appears more than once only | sub-TLV within each PCED sub-TLV. If it appears more than once only | |||
| the first occurrence MUST be processed and other MUST be ignored. | the first occurrence is processed and any others MUST be ignored. | |||
| The PATH-SCOPE sub-TLV contains a set of bit flags indicating the | The PATH-SCOPE sub-TLV contains a set of bit flags indicating the | |||
| supported path scopes, and four fields indicating PCE preferences. | supported path scopes, and four fields indicating PCE preferences. | |||
| The PATH-SCOPE sub-TLV has the following format: | The PATH-SCOPE sub-TLV has the following format: | |||
| TYPE: 2 | TYPE: 2 | |||
| LENGTH: 3 | LENGTH: 3 | |||
| VALUE: This comprises a one-octet flags field where flag | VALUE: This comprises a one-octet flags field where each flag | |||
| represents a supported path scope, followed by a 2-octets | represents a supported path scope, followed by a 2-octets | |||
| preferences field indicating PCE preferences. | preferences field indicating PCE preferences. | |||
| Here is the structure of the bits flag: | Here is the structure of the flags field: | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |0|1|2|3|4|5|Res| | |0|1|2|3|4|5|Res| | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| Bit Path Scope | Bit Path Scope | |||
| 0 L bit: Can compute intra-area path | 0 L bit: Can compute intra-area path | |||
| 1 R bit: Can act as PCE for inter-area TE LSP computation | 1 R bit: Can act as PCE for inter-area TE LSP computation | |||
| 2 Rd bit: Can act as a default PCE for inter-area TE LSP | 2 Rd bit: Can act as a default PCE for inter-area TE LSP | |||
| computation | computation | |||
| 3 S bit: Can act as PCE for inter-AS TE LSP computation | 3 S bit: Can act as PCE for inter-AS TE LSP computation | |||
| 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs | 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs | |||
| computation | computation | |||
| 5 Y bit: Can compute or take part into the computation of | 5 Y bit: Can compute or take part into the computation of | |||
| paths across layers | paths across layers | |||
| 6-7 Reserved for future usage. | 6-7 Reserved for future use. | |||
| Here is the structure of the preferences field | Here is the structure of the preferences field | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |PrefL|PrefR|PrefS|PrefY| Res | | |PrefL|PrefR|PrefS|PrefY| Res | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Res: Reserved for future usage. | Res: Reserved for future usage. | |||
| Pref-L field: PCE's preference for intra-area TE LSPs computation. | PrefL field: PCE's preference for intra-area TE LSPs computation. | |||
| Pref-R field: PCE's preference for inter-area TE LSPs computation. | PrefR field: PCE's preference for inter-area TE LSPs computation. | |||
| Pref-S field: PCE's preference for inter-AS TE LSPs computation. | PrefS field: PCE's preference for inter-AS TE LSPs computation. | |||
| Pref-Y field: PCE's preference for inter-layer TE LSPs computation. | Pref-Y field: PCE's preference for inter-layer TE LSPs computation. | |||
| Res: Reserved for future usage. | Res: Reserved for future use. | |||
| The L, R, S, and Y bits are set when the PCE can act as a PCE for | The L, R, S, and Y bits are set when the PCE can act as a PCE for | |||
| intra-area, inter-area, inter-AS or inter-layer TE LSPs computation | intra-area, inter-area, inter-AS or inter-layer TE LSPs computation | |||
| respectively. These bits are non-exclusive. | respectively. These bits are non-exclusive. | |||
| When set the Rd bit indicates that the PCE can act as a default PCE | When set, the Rd bit indicates that the PCE can act as a default PCE | |||
| for inter-area TE LSP computation (that is the PCE can compute a path | for inter-area TE LSP computation (that is, the PCE can compute a | |||
| towards any neighbor area). Similarly, when set, the Sd bit indicates | path toward any neighbor area). Similarly, when set, the Sd bit | |||
| that the PCE can act as a default PCE for inter-AS TE LSP computation | indicates that the PCE can act as a default PCE for inter-AS TE LSP | |||
| (the PCE can compute a path towards any neighbor AS). | computation (the PCE can compute a path toward any neighbor AS). | |||
| When the Rd and Sd bit are set, the PCED sub-TLV MUST NOT contain any | When the Rd and Sd bit are set, the PCED sub-TLV MUST NOT contain a | |||
| NEIG-PCE-DOMAIN sub-TLV (see 4.1.4). | NEIG-PCE-DOMAIN sub-TLV (see Section 4.4). | |||
| When the R/S bit is cleared, the Rd/Sd bit SHOULD be cleared and MUST | When the R bit is clear, the Rd bit SHOULD be clear on transmission | |||
| be ignored. | and MUST be ignored on receipt. When the S bit is clear, the Sd bit | |||
| SHOULD be clear on transmission and MUST be ignored on receipt. | ||||
| The PrefL, PrefR, PrefS and PrefY fields are each three bits long and | The PrefL, PrefR, PrefS and PrefY fields are each three bits long and | |||
| allow the PCE to specify a preference for each computation scope, | allow the PCE to specify a preference for each computation scope, | |||
| where 7 reflects the highest preference. Such preference can be used | where 7 reflects the highest preference. Such preferences can be used | |||
| for weighted load balancing of requests. An operator may decide to | for weighted load balancing of path computation requests. An operator | |||
| configure a preference for each computation scope to each PCE so as | may decide to configure a preference for each computation scope at | |||
| to balance the path computation load among them. The algorithms used | each PCE so as to balance the path computation load among them. The | |||
| by a PCC to balance its path computation requests according to such | algorithms used by a PCC to balance its path computation requests | |||
| PCE preference are out of the scope of this document and is a matter | according to such PCE preferences are out of the scope of this | |||
| for local or network wide policy. The same or distinct preferences | document and are a matter for local or network-wide policy. The same | |||
| may be used for each scopes. For instance an operator that wants a | or different preferences may be used for each scope. For instance, an | |||
| PCE capable of both inter-area and inter-AS computation to be used | operator that wants a PCE capable of both inter-area and inter-AS | |||
| preferably for inter-AS computation may configure a PrefS higher than | computation to be preferred for use for inter-AS computations may | |||
| the PrefR. | configure PrefS higher than PrefR. | |||
| When the L bit, R bit, S bit or Y bit are cleared the PrefL, PrefR, | When the L, R, S, or Y bits are clear, the PrefL, PrefR, PrefS, PrefY | |||
| PrefS, PrefY fields SHOULD respectively be set to 0 and MUST be | fields SHOULD respectively be set to 0 on transmission and MUST be | |||
| ignored. | ignored on receipt. | |||
| Both reserved fields SHOULD be set to zero on transmission and MUST | Both reserved fields SHOULD be set to zero on transmission and MUST | |||
| be ignored on receipt. | be ignored on receipt. | |||
| 4.3. PCE-DOMAIN Sub-TLV | 4.3. PCE-DOMAIN Sub-TLV | |||
| The PCE-DOMAIN sub-TLV specifies a PCE-Domain (areas and/or ASes) | The PCE-DOMAIN sub-TLV specifies a PCE-Domain (areas and/or ASes) | |||
| where the PCE has topology visibility and through which the PCE can | where the PCE has topology visibility and through which the PCE can | |||
| compute paths. | compute paths. | |||
| The PCE-DOMAIN sub-TLV MAY be present when PCE-Domains cannot be | The PCE-DOMAIN sub-TLV SHOULD be present when PCE-Domains for which | |||
| inferred by other IGP information, for instance when the PCE is | the PCE can operate cannot be inferred by other IGP information, for | |||
| inter-domain capable (i.e. when the R bit or S bit is set) and the | instance when the PCE is inter-domain capable (i.e., when the R bit | |||
| flooding scope is the entire routing domain (see section 5 for a | or S bit is set) and the flooding scope is the entire routing domain | |||
| discussion of how the flooding scope is set and interpreted). | (see Section 5 for a discussion of how the flooding scope is set and | |||
| interpreted). | ||||
| A PCED sub-TLV MAY include multiple PCE-DOMAIN sub-TLVs when the PCE | A PCED sub-TLV may include multiple PCE-DOMAIN sub-TLVs when the PCE | |||
| has visibility in multiple PCE-Domains. | has visibility into multiple PCE-Domains. | |||
| The PCE-DOMAIN sub-TLV has the following format: | The PCE-DOMAIN sub-TLV has the following format: | |||
| TYPE: 3 | TYPE: 3 | |||
| LENGTH: Variable | LENGTH: Variable | |||
| VALUE: This is comprised of one octet indicating the domain-type | VALUE: This is composed of one octet indicating the domain-type (area | |||
| (area ID or AS Number) and a variable length IS-IS area ID or a 32 | ID or AS Number) and a variable length IS-IS area ID or a 32 bits AS | |||
| bits AS number, identifying a PCE-domain where the PCE has visibility. | number, identifying a PCE-domain where the PCE has visibility and can | |||
| compute paths. | ||||
| Two domain types are defined: | Two domain types are defined: | |||
| 1 Area ID | 1 Area ID | |||
| 2 AS Number | 2 AS Number | |||
| The Area ID is the area address as defined in [ISO]. | The Area ID is the area address as defined in [ISO]. | |||
| When coded in two octets (which is the current defined format as the | When the AS number is coded in two octets, the AS Number field MUST | |||
| time of writing this document), the AS Number field MUST have its | have its first two octets set to 0. | |||
| left two octets set to 0. | ||||
| 4.4. NEIG-PCE-DOMAIN Sub-TLV | 4.4. NEIG-PCE-DOMAIN Sub-TLV | |||
| The NEIG-PCE-DOMAIN sub-TLV specifies a neighbour PCE-domain (area, | The NEIG-PCE-DOMAIN sub-TLV specifies a neighbor PCE-domain (area or | |||
| AS) toward which a PCE can compute paths. It means that the PCE can | AS) toward which a PCE can compute paths. It means that the PCE can | |||
| take part in the computation of inter-domain TE LSPs whose path | take part in the computation of inter-domain TE LSPs with paths that | |||
| transits this neighbour PCE-domain. | transit this neighbor PCE-domain. | |||
| A PCED sub-TLV MAY include several NEIG-PCE-DOMAIN sub-TLVs when the | A PCED sub-TLV may include several NEIG-PCE-DOMAIN sub-TLVs when the | |||
| PCE can compute paths towards several neighbour PCE-domains. | PCE can compute paths towards several neighbour PCE-domains. | |||
| The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN | The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN | |||
| sub-TLV: | sub-TLV: | |||
| TYPE: 4 | TYPE: 4 | |||
| LENGTH: Variable | LENGTH: Variable | |||
| VALUE: This comprises one octet indicating the domain-type (area ID | VALUE: This comprises one octet indicating the domain-type (area ID | |||
| or AS Number) and a variable length IS-IS area ID or a 32 bits AS | or AS Number) and a variable length IS-IS area ID or a 32 bits AS | |||
| number, identifying a PCE-domain towards which the PCE can compute | number, identifying a PCE-domain toward which the PCE can compute | |||
| paths. | paths. | |||
| Two domain types are defined: | Two domain types are defined: | |||
| 1 Area ID | 1 Area ID | |||
| 2 AS Number | 2 AS Number | |||
| The Area ID is the area address as defined in [ISO]. | The Area ID is the area address as defined in [ISO]. | |||
| When coded in two octets (which is the current defined format as the | When the AS number is coded in two octets, the AS Number field MUST | |||
| time of writing this document), the AS Number field MUST have its | have its first two octets set to 0. | |||
| first two octets set to 0. | ||||
| The NEIG-PCE-DOMAIN sub-TLV MUST be present if the R bit is set and | The NEIG-PCE-DOMAIN sub-TLV MUST be present at least once with domain | |||
| the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is | type 1 if the R bit is set and the Rd bit is clear, and MUST be | |||
| cleared. | present at least once with domain type 2 if the S bit is set and the | |||
| Sd bit is clear. | ||||
| 4.5. PCE-CAP-FLAGS Sub-TLV | 4.5. PCE-CAP-FLAGS Sub-TLV | |||
| The PCE-CAP-FLAGs sub-TLV is an optional sub-TLV used to indicate | The PCE-CAP-FLAGs sub-TLV is an optional sub-TLV used to indicate | |||
| PCEP related capabilities. It MAY be present within the PCED sub-TLV. | PCEP related capabilities. It MAY be present within the PCED sub-TLV. | |||
| It MUST NOT be present more than once. If it appears more than once | It MUST NOT be present more than once. If it appears more than once | |||
| only the first occurrence MUST be processed and other MUST be ignored. | only the first occurrence is processed and any others MUST be ignored. | |||
| The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array | The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array | |||
| of units of 32 bit flags numbered from the most significant as bit | of units of 32 bit-flags numbered from the most significant as bit | |||
| zero, where each bit represents one PCE capability. | zero, where each bit represents one PCE capability. | |||
| The PCE-CAP-FLAGS sub-TLV has the following format: | The PCE-CAP-FLAGS sub-TLV has the following format: | |||
| TYPE: 5 | TYPE: 5 | |||
| LENGTH: Multiple of 4 | LENGTH: Multiple of 4 | |||
| VALUE: This contains an array of units of 32 bit flags numbered | VALUE: This contains an array of units of 32 bit flags numbered | |||
| from the most significant as bit zero, where each bit | from the most significant as bit zero, where each bit | |||
| represents one PCE capability. | represents one PCE capability. | |||
| The PCE capability registry is managed by IANA, it is common | The PCE capability registry is managed by IANA, it is common | |||
| with OSPF and defined in [PCED-OSPF]. | with OSPF and defined in [PCED-OSPF]. | |||
| Reserved bits SHOULD be set to zero on transmission and MUST be | Reserved bits SHOULD be set to zero on transmission and MUST be | |||
| ignored on receipt. | ignored on receipt. | |||
| 4.6. The OVERLOAD Sub-TLV | ||||
| The OVERLOAD sub-TLV is used to indicate that a PCE is experiencing a | ||||
| processing overload state and may optionally include expected PCE | ||||
| overload duration. | ||||
| The OVERLOAD sub-TLV is optional, it MAY be carried within the PCED | ||||
| sub-TLV. It MUST NOT be present more than once. If it appears more | ||||
| than once only the first occurrence MUST be processed and other MUST | ||||
| be ignored. | ||||
| The format of the OVERLOAD sub-TLV is as follows: | ||||
| TYPE: 6 | ||||
| LENGTH: 1 | ||||
| VALUE: This comprises a one octet of bit flags indicating the | ||||
| overload status. Currently only the first flag is defined. | ||||
| Here is the TLV structure | ||||
| +-+-+-+-+-+-+-+-+ | ||||
| |C| Reserved| | ||||
| +-+-+-+-+-+-+-+-+ | ||||
| Value | ||||
| -C bit: When set this indicates that the PCE is overloaded | ||||
| and cannot accept any new request. When cleared this | ||||
| indicates that the PCE is not overloaded and can | ||||
| accept new requests. | ||||
| 5. Elements of Procedure | 5. Elements of Procedure | |||
| The PCED sub-TLV is advertised within an IS-IS Router Capability TLV | The PCED sub-TLV is advertised within an IS-IS Router Capability TLV | |||
| defined in [IS-IS-CAP]. As such, elements of procedures are inherited | defined in [IS-IS-CAP]. As such, elements of procedures are inherited | |||
| from those defined in [IS-IS-CAP]. | from those defined in [IS-IS-CAP]. | |||
| The flooding scope is controlled by the S flag in the IS-IS Router | The flooding scope is controlled by the S flag in the IS-IS Router | |||
| Capability TLV (see [IS-IS-CAP]). When the scope of the PCED sub-TLV | Capability TLV (see [IS-IS-CAP]). When the scope of the PCED sub-TLV | |||
| is area local it MUST be carried within an IS-IS Router Capability | is area local it MUST be carried within an IS-IS Router Capability | |||
| TLV having the S bit cleared. When the scope of the PCED sub-TLV is | TLV having the S bit cleared. When the scope of the PCED sub-TLV is | |||
| the entire IS-IS routing domain, it MUST be carried within an IS-IS | the entire IS-IS routing domain, it MUST be carried within an IS-IS | |||
| Router Capability TLV having the S bit set. Note that when only the L | Router Capability TLV having the S bit set. Note that when only the L | |||
| bit of the PATH-SCOPE sub-TLV is set, the flooding scope MUST be area | bit of the PATH-SCOPE sub-TLV is set, the flooding scope MUST be area | |||
| local. | local. | |||
| Note that a L1L2 node may include both in its L1 and L2 LSPs a PCED | Note that a L1L2 node may include a PCED TLV in a Router Capability | |||
| TLV in a Router Capability TLV with the S bit cleared. This allows | TLV with the S bit cleared in both in its L1 and L2 LSPs. This allows | |||
| restricting the flooding scope to the L1 area and the L2 sub-domain. | the flooding scope to be restricted to the L1 area and the L2 sub- | |||
| domain. | ||||
| An IS-IS router MUST originate a new IS-IS LSP whenever there is a | ||||
| change in a PCED TLV associated with a PCE it advertises. | ||||
| When a PCE is deactivated, the IS-IS Router advertising this PCE MUST | When the PCE function is deactivated, the IS-IS speaker advertising | |||
| originate a new IS-IS LSP that no longer includes the corresponding | this PCE MUST originate a new IS-IS LSP that no longer includes the | |||
| PCED TLV. | corresponding PCED TLV. | |||
| The PCE address(s), i.e. the address(s) indicated within the PCE | The PCE address (i.e., the address indicated within the PCE ADDRESS | |||
| ADDRESS sub-TLV, SHOULD be reachable via some prefix(es) advertised | sub-TLV) SHOULD be reachable via some prefixes advertised by IS-IS. | |||
| by IS-IS; this allows speeding up the detection of a PCE failure. | This allows the detection of a PCE failure to be sped up. When the | |||
| Note that when the PCE address is no longer reachable, this means | PCE address is no longer reachable, the PCE node has failed, has been | |||
| that the PCE node has failed or has been torn down, or that there is | torn down, or there is no longer IP connectivity to the PCE node. | |||
| no longer IP connectivity to the PCE node. | ||||
| A change in PCED information MUST not trigger any SPF computation at | A change in information in the PCED sub-TLV MUST NOT trigger any SPF | |||
| a receiving router. | computation at a receiving router. | |||
| The way PCEs determine the information they advertise is out of the | The way PCEs determine the information they advertise is out of the | |||
| scope of this document. Some information may be configured (e.g., | scope of this document. Some information may be configured (e.g., | |||
| address, preferences, scope) and other information may be | address, preferences, scope) and other information may be | |||
| automatically determined by the PCE (e.g. areas of visibility). | automatically determined by the PCE (e.g. areas of visibility). | |||
| 5.1. OVERLOAD Sub-TLV Specific Procedures | ||||
| When a PCE enters into an overload state, the conditions of which are | ||||
| implementation dependent, a new IS-IS LSP with an OVERLOAD sub-TLV | ||||
| with the C bit set MAY be generated. | ||||
| When a PCE exists from an overload state, the conditions of which are | ||||
| implementation dependent (e.g. CPU utilization, average queue length | ||||
| below some pre-defined thresholds), a new IS-IS LSP with an OVERLOAD | ||||
| sub-TLV with the C bit cleared SHOULD be generated, if an OVERLOAD | ||||
| sub-TLV with the C bit set had previously been generated. | ||||
| A PCE implementation supporting the IS-IS extensions defined in this | ||||
| document SHOULD support an appropriate dampening algorithm so as to | ||||
| dampen flooding of PCE Overload information in order to not impact | ||||
| the IS-IS scalability. It is RECOMMENDED to introduce some hysteresis | ||||
| for overload state transition, so as to avoid state oscillations that | ||||
| may impact IS-IS performance. For instance two thresholds MAY be | ||||
| configured: an upper-threshold and a lower-threshold. An LSR enters | ||||
| the overload state when the CPU load reaches the upper threshold and | ||||
| leaves the overload state when the CPU load goes under the lower | ||||
| threshold. | ||||
| Upon receipt of an updated OVERLOAD sub-TLV a PCC should take | ||||
| appropriate actions. In particular, the PCC SHOULD stop sending | ||||
| requests to an overloaded PCE, and SHOULD gradually start sending | ||||
| again requests to a PCE that is no longer overloaded. | ||||
| 6. Backward Compatibility | 6. Backward Compatibility | |||
| The PCED sub-TLV defined in this document does not introduce any | The PCED sub-TLV defined in this document does not introduce any | |||
| interoperability issues. | interoperability issues. | |||
| An IS-IS router not supporting the PCED sub-TLV will just silently | An IS-IS router not supporting the PCED sub-TLV will just silently | |||
| ignore the TLV as specified in [IS-IS-CAP]. | ignore the sub-TLV as specified in [IS-IS-CAP]. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| Once a registry for the IS-IS Router Capability sub-TLVs, defined in | IANA has defined a registry for the sub-TLVs carried in the IS-IS | |||
| [IS-IS-CAP] has been assigned, IANA will assign a new sub-TLV code- | Router Capability sub-TLVs defined in [IS-IS-CAP]. IANA is requested | |||
| point for the PCED sub-TLV carried within the Router Capability TLV. | to assign a new sub-TLV code-point for the PCED sub-TLV carried | |||
| within the Router Capability sub-TLV. | ||||
| Value Sub-TLV References | Value Sub-TLV References | |||
| ----- -------- ---------- | ----- -------- ---------- | |||
| 5 PCED sub-TLV (this document) | 5 PCED sub-TLV (this document) | |||
| 8. Security Considerations | 8. Security Considerations | |||
| This document defines IS-IS extensions for PCE discovery within an | This document defines IS-IS extensions for PCE discovery within an | |||
| administrative domain. Hence the security of the PCE discovery relies | administrative domain. Hence the security of the PCE discovery relies | |||
| on the security of IS-IS. | on the security of IS-IS. | |||
| Mechanisms defined to ensure authenticity and integrity of IS-IS LSPs | Mechanisms defined to ensure authenticity and integrity of IS-IS LSPs | |||
| [RFC3567], and their TLVs, can be used to secure the PCED sub-TLV as | [RFC3567], and their TLVs, can be used to secure the PCED sub-TLV as | |||
| well. | well. | |||
| IS-IS provides no encryption mechanism for protecting the privacy of | IS-IS provides no encryption mechanism for protecting the privacy of | |||
| LSPs, and in particular the privacy of the PCE discovery information. | LSPs, and in particular the privacy of the PCE discovery information. | |||
| 9. Manageability Considerations | 9. Manageability Considerations | |||
| Manageability considerations for PCE Discovery are addressed in | Manageability considerations for PCE Discovery are addressed in | |||
| section 4.10 of [RFC4674]. | Section 4.10 of [RFC4674]. | |||
| 9.1. Control of Policy and Functions | 9.1. Control of Policy and Functions | |||
| Requirements on the configuration of PCE discovery parameters on PCCs | Requirements for the configuration of PCE discovery parameters on | |||
| and PCEs are discussed in section 4.10.1 of [RFC4674]. | PCCs and PCEs are discussed in Section 4.10.1 of [RFC4674]. | |||
| Particularly, a PCE implementation SHOULD allow configuring the | In particular, a PCE implementation SHOULD allow the following | |||
| following parameters on the PCE: | parameters to be configured on the PCE: | |||
| -The PCE IPv4/IPv6 address(es) (see section 4.1.1) | -The PCE IPv4/IPv6 address(es) (see Section 4.1) | |||
| -The PCE Scope, including the inter-domain functions (inter- | -The PCE Scope, including the inter-domain functions (inter- | |||
| area, inter-AS, inter-layer), the preferences, and whether the | area, inter-AS, inter-layer), the preferences, and whether the | |||
| PCE can act as default PCE (see section 4.1.2) | PCE can act as default PCE (see Section 4.2) | |||
| -The PCE domains (see section 4.1.3) | -The PCE domains (see Section 4.3) | |||
| -The neighbour PCE domains (see section 4.1.4) | -The neighbour PCE domains (see Section 4.4) | |||
| -The PCE capabilities (see section 4.1.5) | -The PCE capabilities (see Section 4.5) | |||
| 9.2. Information and Data Model | 9.2. Information and Data Model | |||
| A MIB module for PCE Discovery is defined in [PCED-MIB]. | A MIB module for PCE Discovery is defined in [PCED-MIB]. | |||
| 9.3. Liveness Detection and Monitoring | 9.3. Liveness Detection and Monitoring | |||
| PCE Discovery Protocol liveness detection relies upon IS-IS liveness | PCE Discovery Protocol liveness detection relies upon IS-IS liveness | |||
| detection. IS-IS already includes a liveness detection mechanism | detection. IS-IS already includes a liveness detection mechanism | |||
| (Hello PDUs), and PCE discovery does not require additional | (Hello PDUs), and PCE discovery does not require additional | |||
| capabilities. | capabilities. | |||
| Procedures defined in section 5.1 allow a PCC detecting when a PCE | Procedures defined in Section 5 allow a PCC to detect when a PCE has | |||
| has been deactivated, or is no longer reachable. | been deactivated, or is no longer reachable. | |||
| 9.4. Verify Correct Operations | 9.4. Verify Correct Operations | |||
| The correlation of information advertised against information | The correlation of information advertised against information | |||
| received can be achieved by comparing the PCED information in the PCC | received can be achieved by comparing the information in the PCED | |||
| and in the PCE, which is stored in the PCED MIB [PCED-MIB]. The | sub-TLV received by the PCC with that stored at the PCE using the | |||
| number of dropped, corrupt, and rejected information elements are | PCED MIB [PCED-MIB]. The number of dropped, corrupt, and rejected | |||
| stored in the PCED MIB. | information elements are available through the PCED MIB. | |||
| 9.5. Requirements on Other Protocols and Functional Components | 9.5. Requirements on Other Protocols and Functional Components | |||
| The IS-IS extensions defined in this document do not imply any | The IS-IS extensions defined in this document do not imply any | |||
| requirement on other protocols. | requirement on other protocols. | |||
| 9.6. Impact on Network Operations | 9.6. Impact on Network Operations | |||
| Frequent changes in PCE information, and particularly in PCE overload | Frequent changes in PCE information advertised in the PCED sub-TLV | |||
| information, may have a significant impact on IS-IS and might | may have a significant impact on IS-IS and might destabilize the | |||
| destabilize the operation of the network by causing the PCCs to swap | operation of the network by causing the PCCs to swap between PCEs. | |||
| between PCEs. | ||||
| As discussed in section 5.1, a PCE implementation SHOULD support an | ||||
| appropriate dampening algorithm so as to dampen IS-IS flooding in | ||||
| order to not impact the IS-IS scalability. | ||||
| Also, as discussed in section 4.10.4 of [RFC4674], it MUST be | As discussed in Section 4.10.4 of [RFC4674], it MUST be possible to | |||
| possible to apply at least the following controls: | apply at least the following controls: | |||
| - Configurable limit on the rate of announcement of changed | - Configurable limit on the rate of announcement of changed | |||
| parameters at a PCE. | parameters at a PCE. | |||
| - Control of the impact on PCCs such as through discovery messages | - Control of the impact on PCCs such as through rate-limiting the | |||
| rate-limiting. | processing of PCED sub-TLVs. | |||
| - Configurable control of triggers that cause a PCC to swap to | - Configurable control of triggers that cause a PCC to swap to | |||
| another PCE. | another PCE. | |||
| 10. Acknowledgments | 10. Acknowledgments | |||
| We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike | We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike | |||
| Shand, Lou Berger, and David Ward, for their useful comments and | Shand, Lou Berger, and David Ward, for their useful comments and | |||
| suggestions. | suggestions. | |||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.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. | |||
| [ISO] "Intermediate System to Intermediate System Intra-Domain | [ISO] "Intermediate System to Intermediate System Intra-Domain | |||
| Routeing Exchange Protocol for use in Conjunction with the | Routeing Exchange Protocol for use in Conjunction with the | |||
| Protocol for Providing the Connectionless-mode Network Service | Protocol for Providing the Connectionless-mode Network Service | |||
| (ISO 8473)", ISO DP 10589, February 1990. | ISO/IEC 10589:2002 Second Edition. | |||
| [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic | [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic | |||
| Engineering", RFC 3784, June 2004. | Engineering", RFC 3784, June 2004. | |||
| [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising | [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising | |||
| router information", draft-ietf-isis-caps, work in progress. | router information", draft-ietf-isis-caps, work in progress. | |||
| [RFC3567] Li, T. and R. Atkinson, "Intermediate System to | [RFC3567] Li, T. and R. Atkinson, "Intermediate System to | |||
| Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, | Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, | |||
| July 2003. | July 2003. | |||
| End of changes. 96 change blocks. | ||||
| 288 lines changed or deleted | 199 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||