IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery
RFC 5089
Document | Type | RFC - Proposed Standard (January 2008; Errata) | |
---|---|---|---|
Authors | Jean-Louis Le Roux , Vasseur Jp , Raymond Zhang , Yuichi Ikejiri | ||
Last updated | 2015-10-14 | ||
Replaces | draft-ietf-pce-disco-proto-igp | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5089 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | (None) |
Network Working Group JL. Le Roux, Ed. Request for Comments: 5089 France Telecom Category: Standards Track JP. Vasseur, Ed. Cisco System Inc. Y. Ikejiri NTT Communications R. Zhang BT January 2008 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. Le Roux, et al. Standards Track [Page 1] RFC 5089 IS-IS Protocol Extensions for PCE Discovery January 2008 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................4 3. Overview ........................................................5 3.1. PCE Discovery Information ..................................5 3.2. Flooding Scope .............................................5 4. The IS-IS PCED Sub-TLV ..........................................5 4.1. PCE-ADDRESS Sub-TLV ........................................6 4.2. The PATH-SCOPE Sub-TLV .....................................7 4.3. PCE-DOMAIN Sub-TLV .........................................9 4.4. NEIG-PCE-DOMAIN Sub-TLV ...................................10 4.5. PCE-CAP-FLAGS Sub-TLV .....................................10 5. Elements of Procedure ..........................................11 6. Backward Compatibility .........................................12 7. IANA Considerations ............................................12 8. Security Considerations ........................................12 9. Manageability Considerations ...................................13 9.1. Control of Policy and Functions ...........................13 9.2. Information and Data Model ................................13 9.3. Liveness Detection and Monitoring .........................13 9.4. Verify Correct Operations .................................13 9.5. Requirements on Other Protocols and Functional Components ................................................13 9.6. Impact on Network Operations ..............................14 10. Acknowledgments ...............................................14 11. References ....................................................15 11.1. Normative References .....................................15 11.2. Informative References ...................................15 1. Introduction [RFC4655] describes the motivations and architecture for a Path Computation Element (PCE)-based path computation model for Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Paths (TE LSPs). The model allows for the separation of the PCE from a Path Computation Client (PCC) (also referred to as a non co-located PCE) and allows for cooperation between PCEs (where one PCE acts as a PCC to make requests of the other PCE). This relies on a communication protocol between a PCC and 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]. The PCE architecture requires that a PCC be aware of the location of one or more PCEs in its domain, and, potentially, of PCEs in other domains, e.g., in the case of inter-domain TE LSP computation.Show full document text