IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery
RFC 5089
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