Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)
RFC 5376
Network Working Group N. Bitar
Request for Comments: 5376 Verizon
Category: Informational R. Zhang
BT
K. Kumaki
KDDI R&D Labs
November 2008
Inter-AS Requirements for the
Path Computation Element Communication Protocol (PCECP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label
Switched Paths (LSPs) may be established wholly within an Autonomous
System (AS) or may cross AS boundaries.
The Path Computation Element (PCE) is a component that is capable of
computing constrained paths for (G)MPLS TE LSPs. The PCE
Communication Protocol (PCECP) is defined to allow communication
between Path Computation Clients (PCCs) and PCEs, as well as between
PCEs. The PCECP is used to request constrained paths and to supply
computed paths in response. Generic requirements for the PCECP are
set out in "Path Computation Element (PCE) Communication Protocol
Generic Requirements", RFC 4657. This document extends those
requirements to cover the use of PCECP in support of inter-AS MPLS
TE.
Bitar, et al. Informational [Page 1]
RFC 5376 Inter-AS Requirements for PCECP November 2008
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Reference Model .................................................4
3.1. Scope of Deployment Model ..................................5
4. Detailed PCECP Requirements for Inter-AS G(MPLS) TE Path
Computation .....................................................6
4.1. PCE Communication Protocol Requirements ....................6
4.1.1. Requirements for Path Computation Requests ..........6
4.1.2. Requirements for Path Computation Responses .........7
4.2. Scalability and Performance Considerations .................8
4.3. Management Considerations ..................................8
4.4. Confidentiality ............................................9
4.5. Policy Controls Affecting Inter-AS PCECP ...................9
4.5.1. Inter-AS PCE Peering Policy Controls ...............10
4.5.2. Inter-AS PCE Re-Interpretation Policies ............10
5. Security Considerations ........................................10
5.1. Use and Distribution of Keys ..............................11
5.2. Application of Policy .....................................11
5.3. Confidentiality ...........................................12
5.4. Falsification of Information ..............................12
6. Acknowledgments ................................................12
7. Normative References ...........................................13
8. Informative References .........................................13
Bitar, et al. Informational [Page 2]
RFC 5376 Inter-AS Requirements for PCECP November 2008
1. Introduction
[RFC4216] defines the scenarios motivating the deployment of inter-AS
Multiprotocol Label Switching Traffic Engineering (MPLS TE) and
specifies the requirements for inter-AS MPLS TE when the ASes are
under the administration of one Service Provider (SP) or the
administration of different SPs.
Three signaling options are defined for setting up an inter-AS TE
Label Switched Path (LSP):
1) contiguous TE LSP as documented in [RFC5151];
2) stitched inter-AS TE LSP discussed in [RFC5150];
3) nested TE LSP as in [RFC4206].
[RFC5152] defines mechanisms for the computation of inter-domain TE
LSPs using network elements along the signaling paths to compute
per-domain constrained path segments. The mechanisms in [RFC5152] do
not guarantee an optimum constrained path across multiple ASes where
an optimum path for a TE LSP is one that has the smallest cost,
Show full document text