summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7399.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7399.txt')
-rw-r--r--doc/rfc/rfc7399.txt1627
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc7399.txt b/doc/rfc/rfc7399.txt
new file mode 100644
index 0000000..6cb40e8
--- /dev/null
+++ b/doc/rfc/rfc7399.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Farrel
+Request for Comments: 7399 Juniper Networks
+Category: Informational D. King
+ISSN: 2070-1721 Old Dog Consulting
+ October 2014
+
+
+ Unanswered Questions in the Path Computation Element Architecture
+
+Abstract
+
+ The Path Computation Element (PCE) architecture is set out in RFC
+ 4655. The architecture is extended for multi-layer networking with
+ the introduction of the Virtual Network Topology Manager (VNTM) in
+ RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.
+
+ These three architectural views of PCE deliberately leave some key
+ questions unanswered, especially with respect to the interactions
+ between architectural components. This document draws out those
+ questions and discusses them in an architectural context with
+ reference to other architectural components, existing protocols, and
+ recent IETF efforts.
+
+ This document does not update the architecture documents and does not
+ define how protocols or components must be used. It does, however,
+ suggest how the architectural components might be combined to provide
+ advanced PCE function.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7399.
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 1]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 2]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................4
+ 2. What Is Topology Information? ...................................4
+ 3. How Is Topology Information Gathered? ...........................5
+ 4. How Do I Find My PCE? ...........................................6
+ 5. How Do I Select between PCEs? ...................................7
+ 6. How Do Redundant PCEs Synchronize TEDs? .........................8
+ 7. Where Is the Destination? .......................................9
+ 8. Who Runs or Owns a Parent PCE? .................................10
+ 9. How Do I Find My Parent PCE? ...................................11
+ 10. How Do I Find My Child PCEs? ..................................11
+ 11. How Is the Parent PCE Domain Topology Built? ..................12
+ 12. Does H-PCE Solve the Internet? ................................12
+ 13. What are Sticky Resources? ....................................13
+ 14. What Is a Stateful PCE for? ...................................14
+ 15. How Is the LSP-DB Built? ......................................14
+ 16. How Do Redundant Stateful PCEs Synchronize State? .............15
+ 17. What Is an Active PCE? What Is a Passive PCE? .................16
+ 18. What is LSP Delegation? .......................................17
+ 19. Is an Active PCE with LSP Delegation Just a Fancy NMS? ........18
+ 20. Comparison of Stateless and Stateful PCE ......................18
+ 21. How Does a PCE Work with a Virtual Network Topology? ..........19
+ 22. How Does PCE Communicate with VNTM ............................21
+ 23. How Does Service Scheduling and Calendering Work? .............21
+ 24. Where Does Policy Fit In? .....................................22
+ 25. Does PCE Play a Role in SDN? ..................................23
+ 26. Security Considerations .......................................23
+ 27. References ....................................................25
+ 27.1. Normative References .....................................25
+ 27.2. Informative References ...................................25
+ Acknowledgements ..................................................29
+ Authors' Addresses ................................................29
+
+1. Introduction
+
+ Over the years since the architecture for the Path Computation
+ Element (PCE) was documented in [RFC4655], many new people have
+ become involved in the work of the PCE working group and wish to use
+ or understand the PCE architecture. These people often missed out on
+ early discussions within the working group and are unfamiliar with
+ questions that were raised during the development of the
+ documentation.
+
+
+
+
+
+
+
+Farrel & King Informational [Page 3]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ Furthermore, the base architecture has been extended to handle other
+ situations and requirements: the architecture was extended for multi-
+ layer networking with the introduction of the Virtual Network
+ Topology Manager (VNTM) [RFC5623] and was generalized to include
+ Hierarchical PCE (H-PCE) [RFC6805].
+
+ These three architectural views of PCE deliberately leave some key
+ questions unanswered, especially with respect to the interactions
+ between architectural components. This document draws out those
+ questions and discusses them in an architectural context with
+ reference to other architectural components, existing protocols, and
+ recent IETF efforts.
+
+ This document does not update the architecture documents and does not
+ define how protocols or components must be used. It does, however,
+ suggest how the architectural components might be combined to provide
+ advanced PCE function.
+
+1.1. Terminology
+
+ Readers are assumed to be thoroughly familiar with terminology
+ defined in [RFC4655], [RFC4726], [RFC5440], [RFC5623], and [RFC6805].
+ More information about terms related to stateful PCE can be found in
+ [STATEFUL-PCE].
+
+ Throughout this document, the term "area" is used to refer equally to
+ an OSPF area and an IS-IS level. It is assumed that the reader is
+ able to map the small differences between these two use cases.
+
+2. What Is Topology Information?
+
+ [RFC4655] specifies that a PCE performs path computations based on a
+ view of the available network resources and network topology. This
+ information is collected into a Traffic Engineering Database (TED).
+
+ However, [RFC4655] does not provide a detailed description of what
+ information is present in the TED. It simply says that the TED
+ "contains the topology and resource information of the domain." The
+ precise information that needs to be held in a TED depends on the
+ type of network and nature of the computation that has to be
+ performed. As a basic minimum, the TED must contain the nodes and
+ links that form the domain, and it must identify the connectivity in
+ the domain.
+
+ For most traffic-engineering needs (for example, MPLS Traffic
+ Engineering - MPLS-TE), the TED would additionally contain a basic
+ metric for each link and knowledge of the available (unallocated)
+ resources on each link.
+
+
+
+Farrel & King Informational [Page 4]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ More advanced use cases might require that the TED contain additional
+ data that represents qualitative information such as:
+
+ - link delay
+ - link jitter
+ - node throughput capabilities
+ - optical impairments
+ - switching capabilities
+ - limited node cross-connect capabilities
+
+ Additionally, an important information element for computing paths,
+ especially for protected services, is the Shared Risk Group (SRG).
+ This is an indication of resources in the TED that have a common risk
+ of failure. That is, they have a shared risk of failure from a
+ single event.
+
+ In short, the TED needs to contain as much information as is needed
+ to satisfy the path computation requests subject to the objective
+ functions (OFs). This, in itself, may not be a trivial issue in some
+ network technologies. For example, in some optical networks, the
+ path computation for a new Label Switched Path (LSP) may need to
+ consider the impact that turning up a new laser would have on the
+ optical signals already being carried by fibers. It may be possible
+ to abstract this information as parameters of the optical links and
+ nodes in the TED, but it may be easier to capture this information
+ through a database of existing LSPs (see Sections 14 and 15).
+
+3. How Is Topology Information Gathered?
+
+ Clearly, the information in the TED discussed in Section 2 needs to
+ be gathered and maintained somehow. [RFC4655] simply says "The TED
+ may be fed by Interior Gateway Protocol (IGP) extensions or
+ potentially by other means." In this context, "fed" means built and
+ maintained.
+
+ Thus, one way that the PCE may construct its TED is by participating
+ in the IGP running in the network. In an MPLS-TE network, this would
+ depend on OSPF TE [RFC3630] and IS-IS TE [RFC5305]. In a GMPLS
+ network, it would utilize the GMPLS extensions to OSPF and IS-IS,
+ [RFC4203] and [RFC5307].
+
+ However, participating in an IGP, even as a passive receiver of IGP
+ information, can place a significant load on the PCE. The IGP can be
+ quite "chatty" when there are frequent updates to the use of the
+ network, meaning that the PCE must dedicate significant processing to
+ parsing protocol messages and updating the TED. Furthermore, to be
+ truly useful, a PCE implementation would need to support OSPF and IS-
+ IS.
+
+
+
+Farrel & King Informational [Page 5]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ An alternative feed from the network to the PCE's TED is offered by
+ BGP-LS [LS-DISTRIB]. This approach offers the alternative of
+ leveraging an in-network BGP speaker (such as an Autonomous System
+ Border Router or a Route Reflector) that already has to participate
+ in the IGP and that is specifically designed to apply filters to IGP
+ advertisements. In this usage, the BGP speaker filters and
+ aggregates topology information according to configured policy before
+ advertising it "north-bound" to the PCE to update the TED. The PCE
+ implementation has to support just a simplified subset of BGP rather
+ than two full IGPs.
+
+ But BGP might not be convenient in all networks (for example, where
+ BGP is not run, such as in an optical network or a BGP-free core).
+ Furthermore, not all relevant information is made available through
+ standard TE extensions to the IGPs. In these cases, the TED must be
+ built or supplemented from other sources such as the Network
+ Management System (NMS), inventory management systems, and directly
+ configured data.
+
+ It has also been proposed that the PCE Communication Protocol (PCEP)
+ [RFC5440] could be extended to serve as an information collection
+ protocol to supply information from network devices to a PCE. The
+ logic is that the network devices may already speak PCEP; so, the
+ protocol could easily be used to report details about the resources
+ and state in the network, including the LSP state discussed in
+ Sections 14 and 15.
+
+ Note that a PCE that is responsible for more than one domain must, of
+ course, collect TE information from each domain to build its TED or
+ TEDs.
+
+4. How Do I Find My PCE?
+
+ A Path Computation Client (PCC) needs to know the identity/location
+ of a PCE in order to be able to make computation requests. This is
+ because PCEP is a transaction-based protocol carried over TCP, and
+ the architectural decision made in Section 6.4 of RFC 4655 required
+ targeted PCC-PCE communications.
+
+ As described in [RFC4655], a PCC could be configured with the
+ knowledge of the IP address of its PCE. This is a relatively
+ lightweight option considering all of the other configuration that a
+ router may require, but it is open to configuration errors, and does
+ not meet the need for minimal-configuration operation. Furthermore,
+ configuration communication with multiple PCEs could become onerous,
+ while handling changes in PCE identities and coping with failure
+ events would be an issue for a configured system.
+
+
+
+
+Farrel & King Informational [Page 6]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ [RFC4655] offers the possibility for PCEs to advertise themselves in
+ the IGP, and this requirement is developed in [RFC4674] and made
+ possible in OSPF and IS-IS through [RFC5088] and [RFC5089]. In
+ general, these mechanisms should be sufficient for PCCs in a network
+ where an IGP is used and where the PCE participates in the IGP.
+
+ Note, however, that not all PCEs will participate in the IGP (see
+ Section 3). In these cases, assuming configuration is not
+ appropriate as a discovery mechanism, some other server
+ announcement/discovery function may be needed, such as DNS [RFC4848]
+ as used for discovery of the Local Location Information Server (LIS)
+ [RFC5986] and in the Application-Layer Traffic Optimization (ALTO)
+ discovery function [ALTO-SERVER-DISC].
+
+5. How Do I Select between PCEs?
+
+ When more than one PCE is discovered or configured, a PCC will need
+ to select which PCE to use. It may make this decision on any
+ arbitrary algorithm (for example, first-listed, or round robin), but
+ it may also be the case that different PCEs have different
+ capabilities and path computation scope; in which case, the PCC will
+ want to select the PCE most likely to be able to satisfy any one
+ request. The first requirement, of course, is that the PCE can
+ compute paths for the relevant domain.
+
+ PCE advertisement in OSPF or IS-IS per [RFC5088] and [RFC5089] allows
+ a PCE to announce its capabilities as required in [RFC4657]. A PCC
+ can select between PCEs based on the capabilities that they have
+ announced. However, these capabilities are expressed as flags in the
+ PCE advertisement so only the core capabilities are presented, and
+ there is not scope for including detailed information (such as
+ support for specific objective functions) in the advertisement.
+
+ Additional and more complex PCE capabilities, including the
+ capability to perform point-to-multipoint (P2MP) path computations
+ [RFC6006], may be announced by the PCE as optional PCEP type-length-
+ value (TLV) Type Indicators in the Open message described in
+ [RFC5440]. This mechanism is not limited to just a set of flags, and
+ detailed capability information may be presented in sub-TLVs.
+
+ Note that this exchange of PCE capabilities is in the form of an
+ announcement, not a negotiation. That is, a PCC that wants specific
+ function from a PCE must examine the advertised capabilities and
+ select which PCE to use for a specific request. There is no scope
+ for a PCC to request a PCE to support features or functions that it
+ does not offer or announce.
+
+
+
+
+
+Farrel & King Informational [Page 7]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ A PCC may also vary which PCE it uses according to congestion
+ information reported by the PCEs using the Notification Object and
+ Notification Type [RFC5440]. In a heavily overloaded PCE system,
+ note that reports from one PCE that it is overloaded may simply
+ result in all PCCs switching to another PCE, which will, itself,
+ immediately become overloaded. Thus, PCCs should exercise a certain
+ amount of discretion and queueing theory before selecting a PCE
+ purely based on reported load.
+
+ Note that a PCC could send all requests to all PCEs that it knows
+ about. It can then select between the results, perhaps choosing the
+ first result it receives, but this approach is very likely to
+ overload all the PCEs in the network considering that one of the
+ reasons for multiple PCEs is to share the load.
+
+6. How Do Redundant PCEs Synchronize TEDs?
+
+ A network may have more than one PCE, as discussed in the previous
+ sections. These PCEs may provide redundancy for load-sharing,
+ resilience, or partitioning of computation features.
+
+ In order to achieve some consistency between the results of different
+ PCEs, it is desirable that they operate on the same TE information.
+
+ The TED reflects the actual state of the network and is not a
+ resource reservation or booking scheme. Therefore, a PCE-based
+ system does not prevent competition for network resources during the
+ provisioning phase, although a process of "sticky resources" that are
+ temporarily reduced in the TED after a computation may be applied
+ purely as a local implementation feature.
+
+ One option for ensuring that multiple PCEs use the same TE
+ information is simply to have the PCEs driven from the same TED.
+ This could be achieved in implementations by utilizing a shared
+ database, but it is unlikely to be efficient.
+
+ More likely is that each PCE is responsible for building its own TED
+ independently, using the techniques described in Section 3. If the
+ PCEs participate in the IGP, it is likely that they will attach at
+ different points in the network; so, there may be minor and temporary
+ inconsistencies between their TEDs caused by IGP convergence issues.
+ If the PCEs gather TE information via BGP-LS [LS-DISTRIB] from
+ different sources, the same inconsistencies may arise. However, if
+ the PCEs attach to the same BGP speaker, it may be possible to
+ achieve consistency between TEDs modulo the BGP-LS process itself.
+
+
+
+
+
+
+Farrel & King Informational [Page 8]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ A final option is to provide an explicit synchronization process
+ between the TED of a "master" PCE and the TEDs of other PCEs. Such a
+ process could be achieved using BGP-LS or a database synchronization
+ protocol (which would allow check-pointing and sequential updates).
+ This approach is fraught with issues around selection of the master
+ PCE and handling failures. It is, in fact, a mirrored database
+ scenario: a problem that is well known and the subject of plenty of
+ work.
+
+ Noting that the provisioning protocols such as RSVP-TE [RFC3209]
+ already handle contention for resources, that the differences between
+ TEDs are likely to be relatively small with moderate arrival rates
+ for new services, and that contention in all but the most busy
+ networks is relatively unlikely, there may be no value in any attempt
+ to synchronize TEDs between PCEs.
+
+ However, see Section 16 for a discussion of synchronizing other state
+ between redundant PCEs.
+
+7. Where Is the Destination?
+
+ Path computation provides an end-to-end path between a source and a
+ destination. If the destination lies in the source domain, then its
+ location will be known to the PCE and there are no issues to be
+ solved. However, in a multi-domain system a path must be found to a
+ remote domain that contains the destination, and that can only be
+ achieved by knowledge of the location of the destination or at least
+ knowing the next domain in the path toward the domain that contains
+ the destination.
+
+ The simplest solution here is achieved when a PCE has visibility into
+ multiple domains. Such may be the case in a multi-area network where
+ the PCE is aware of the contents of all of the IGP areas. This
+ approach is only likely to be appropriate where the number of nodes
+ is manageable, and it is unlikely to extend over administrative
+ boundaries.
+
+ The per-domain path computation method for establishing inter-domain
+ traffic engineering LSPs [RFC5152] simply requires a PCE to compute a
+ path to the next domain toward the destination. As the LSP setup
+ (through signaling) progresses domain by domain, the Label Switching
+ Router (LSR) at the entry point to each domain requests its local PCE
+ to compute the next segment of the path, that is from that LSR to the
+ next domain in the sequence toward the destination. Thus, it is not
+ necessary for any PCE (except the last) to know in which domain the
+ destination exists. But, in this approach, each PCE must somehow
+ determine the next domain toward the destination, and it is not
+ obvious how this is achieved.
+
+
+
+Farrel & King Informational [Page 9]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ [RFC5152] suggests that, in an IP/MPLS network, it is good enough to
+ leverage the IP reachability information distributed by BGP and
+ assume that TE reachability can follow the same Autonomous System
+ (AS) path. This approach might not guarantee the optimal TE path
+ and, of course, might result in no path being found in degenerate
+ cases. Furthermore, in many network technologies (such as optical
+ networks operated by GMPLS) there may be limited or no end-to-end IP
+ connectivity.
+
+ The Backward Recursive PCE-based Computation (BRPC) procedure
+ [RFC5441] is able to achieve a more optimal end-to-end path than the
+ per-domain method, but depends on the knowledge of both the domain in
+ which the destination is located and the sequence of domains toward
+ the destination. This information is described in [RFC5441] as being
+ known a priori. Clearly, however, information is not always known a
+ priori, and it may be hard for the PCE that serves the source PCC to
+ discover the necessary details. While there are several approaches
+ to solving the question of establishing the domain sequence (for
+ example, BRPC trial and error or H-PCE [RFC6805]), none of them
+ addresses the issue of determining where the destination lies.
+
+ One argument that is often made is that an end-to-end connection
+ expressed as an LSP is a feature of a service agreement between
+ source and destination. If that is the case, it is argued, it stands
+ to reason that the location of the destination must be known to the
+ source node in the same way that the source has determined the IP
+ address of the destination. Presumably, this would be through a
+ commercial process or an administrative protocol.
+
+ [RFC4974] introduced the concept of Calls and Connections for LSPs.
+ A Call does not provide the actual connectivity for transmitting user
+ traffic, but builds a relationship that will allow subsequent
+ Connections to be made. A Call might be considered an agreement to
+ support an end-to-end LSP that is made between the endpoint nodes.
+ Call messages are sent and routed as normal IP messages, so the
+ sender does not need to know the location of the destination.
+
+ Furthermore, Call requests are responded, and the Call Response can
+ carry information (such as the identity of the domain containing the
+ destination) for use by Call initiator. Thus, the use of GMPLS Calls
+ might provide a mechanism to discover destination's location.
+
+8. Who Runs or Owns a Parent PCE?
+
+ A parent PCE [RFC6805] is responsible for selecting inter-domain path
+ by coordinating with child PCEs and maintaining a domain topology
+ map.
+
+
+
+
+Farrel & King Informational [Page 10]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ In the case of multi-domains (e.g., IGP areas or multiple ASes)
+ within a single service provider network, the management
+ responsibility for the parent PCE would most likely be handled by the
+ service provider.
+
+ In the case of multiple ASes within different service provider
+ networks, it may be necessary for a third party to manage the parent
+ PCEs according to commercial and policy agreements from each of the
+ participating service providers. Note that the H-PCE architecture
+ does not require disclosure of internals of a child domain to the
+ parent PCE. Thus, there is ample scope for a parent PCE to be run by
+ one of the connected service providers or by a third party without
+ compromising commercial issues. In fact, each service provider could
+ run its own parent PCE while allowing its child PCEs to be contacted
+ by outsider parent PCEs according to configured policy and security.
+
+9. How Do I Find My Parent PCE?
+
+ [RFC6805] specifies that a child PCE must be configured with the
+ address of its parent PCE in order for it to interact with its parent
+ PCE. There is no scope for parent PCEs to advertise their presence;
+ however, there is potential for directory systems (such as DNS
+ [RFC4848] as used in the ALTO discovery function [ALTO-SERVER-DISC])
+ to be used as described in Section 4.
+
+ According to [RFC6805], note that the child PCE must also be
+ authorized to peer with the parent PCE. This is discussed from the
+ viewpoint of the parent PCE in Section 10. The child PCE may need to
+ participate in a key distribution protocol in order to properly
+ authenticate its identity to the parent PCE.
+
+10. How Do I Find My Child PCEs?
+
+ Within the hierarchical PCE framework [RFC6805], the parent PCE must
+ only accept path computation requests from authorized child PCEs. If
+ a parent PCE receives a request from an unauthorized child PCE, the
+ request should be dropped.
+
+ This requires a parent PCE to be configured with the identities and
+ security credentials of all of its child PCEs, or there must be some
+ form of shared secret that allows an unknown child PCE to be
+ authorized by the parent PCE.
+
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 11]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+11. How Is the Parent PCE Domain Topology Built?
+
+ The parent PCE maintains a domain topology map of the child domains
+ and their interconnectivity. This map does not include any
+ visibility into the child domains. Where inter-domain connectivity
+ is provided by TE links, the capabilities of those links may also be
+ known to the parent PCE.
+
+ The parent PCE maintains a TED for the parent domain in the same way
+ that any PCE does. The nodes in the parent domain will be
+ abstractions of the child domains (connected by real or virtual TE
+ links), but the parent domain may also include real nodes and links.
+
+ The mechanism for building the parent TED is likely to rely heavily
+ on administrative configuration and commercial issues because the
+ network was probably partitioned into domains specifically to address
+ these issues. However, note that in some configurations (for
+ example, collections of small optical domains) a separate instance of
+ a routing protocol (probably an IGP) may be run within the parent
+ domain to advertise the domain interconnectivity. Additionally,
+ since inter-domain TE links can be advertised by the IGPs operating
+ in the child domains, this information could be exported to the
+ parent PCE either by the child PCEs or using a north-bound export
+ mechanism such as BGP-LS [LS-DISTRIB].
+
+12. Does H-PCE Solve the Internet?
+
+ The model described in [RFC6805] introduced a hierarchical
+ relationship between domains. It is applicable to environments with
+ small groups of domains where visibility from the ingress LSRs is
+ limited. Applying the hierarchical PCE model to large groups of
+ domains such as the Internet is not considered feasible or desirable.
+
+ This does open up a harder question: how many domains can be handled
+ by an H-PCE system? In other words: what is a small group of
+ domains? The answer is not clear and might be "I know it when I see
+ it." At the moment, a rough guide might be around 20 domains as a
+ maximum.
+
+ An associated question would be: how many hierarchy levels can be
+ handled by H-PCE? Architecturally, the answer is that there is no
+ limit, but it is hard to construct practical examples where more than
+ two or possibly three levels are needed.
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 12]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+13. What are Sticky Resources?
+
+ When a PCE computes a path, it has a reasonable idea that an LSP will
+ be set up and that resources will be allocated within the network.
+ If the arrival rate of computation requests is faster than the LSP
+ setup rate combined with the IGP convergence time, it is quite
+ possible that the PCE will perform its next computation before the
+ TED has been updated to reflect the setup of the previous LSP. This
+ can result in LSP setup failures if there is contention for
+ resources. The likelihood of this problem is particularly high
+ during recovery from network failures when a large number of LSPs
+ might need new paths.
+
+ A PCE may choose to make a provisional assignment of the resources
+ that would be needed for an LSP and to reduce the available resources
+ in its TED so that the problem is mitigated. Such resources are
+ informally known as "sticky resources".
+
+ Note that using sticky resources introduces a number of other
+ problems that can make managing the TED difficult. For example:
+
+ - When the TED is updated as a result of new information from the
+ IGP, how does the PCE know whether the reduction in available
+ resources is due to the successful setup of the LSP for which it
+ is holding sticky resources or due to some other network event
+ (such as the setup of another LSP)? This problem may be
+ particularly evident if there are multiple PCEs that do not
+ synchronize their sticky resources or if not all LSPs utilize PCE
+ computation.
+
+ - When LSP setup fails, how are the sticky resources released?
+ Since the PCE doesn't know about the failure of the LSP setup, it
+ needs some other mechanism to release them.
+
+ - What happens if a path computation was made only to investigate
+ the potential for an LSP but not to actually set one up?
+
+ - What if the path used by the LSP does not match that provided by
+ the PCE (for example, because the control plane routes around some
+ problem)?
+
+ Some of these issues can be mitigated by using a Stateful PCE (see
+ Section 14) or by timers.
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 13]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+14. What Is a Stateful PCE for?
+
+ A Stateless PCE can perform path computations that take into account
+ the existence of other LSPs if the paths of those LSPs are supplied
+ on the computation request. This function can be particularly useful
+ when arranging protection paths so that a working and protection LSP
+ do not share any links or nodes. It can also be used when a group of
+ LSPs are to be reoptimized at the same time in the process known as
+ Global Concurrent Optimization (GCO) [RFC5557].
+
+ However, this mechanism can be quite a burden on the protocol
+ messages, especially when large numbers of LSP paths need to be
+ reported.
+
+ A Stateful PCE [STATEFUL-PCE] maintains a database of LSPs (the LSP-
+ DB) that are active in the network, i.e., have been provisioned such
+ that they use network resources although they might or might not be
+ carrying traffic. This database allows a PCC to refer to an LSP
+ using only its identifier -- all other details can be retrieved by
+ the PCE from the LSP-DB.
+
+ A Stateful PCE can use the LSP-DB for many other functions, such as
+ balancing the distribution of LSPs in the network. Furthermore, the
+ PCE can correlate LSPs with network resource availability placing new
+ LSPs more cleverly.
+
+ A Stateful PCE that is also an Active PCE (see Section 17) can
+ respond to changes in network resource availability and predicted
+ demands to reroute LSPs that it knows about.
+
+ Section 20 offers a brief comparison of the different modes of PCE
+ with reference to stateful and stateless PCE.
+
+15. How Is the LSP-DB Built?
+
+ The LSP-DB contains information about the LSPs that are active in the
+ network, as mentioned in Section 14. This state information can be
+ constructed by the PCE from information it receives from a number of
+ sources including from provisioning tools and from the network, but
+ no matter how the information is gleaned, a Stateful PCE needs to
+ synchronize its LSP-DB with the state in the network. Just as
+ described in Section 13, the PCE cannot rely on knowledge about
+ previous computations it has made, but it must find out the actual
+ LSPs in the network.
+
+
+
+
+
+
+
+Farrel & King Informational [Page 14]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ A simple solution is for all ingress LSRs to report all LSPs to the
+ PCE as they are set up, modified, or torn down. Since PCEP already
+ has the facility to fully describe LSP routes and resources in the
+ protocol messages, this is not a difficult problem, and the LSP State
+ Report (PCRpt) message has been defined for this purpose
+ [STATEFUL-PCE].
+
+ The situation can be more complex, however, if there are ingress LSRs
+ that do not support PCEP, support PCEP but not the PCRpt, or that are
+ unaware of the requirement to report LSPs to the PCE. This might
+ happen if the LSRs are able to compute paths themselves or if they
+ receive LSP setup instructions with pre-computed paths from an NMS.
+
+ An alternative approach is to note that any LSR on the path of an LSP
+ can probably see the whole path (through the Record Route object in
+ RSVP-TE signaling [RFC3209]) and knows the bandwidth reserved for the
+ LSP. Thus, any LSR could report the LSP to the PCE, noting that it
+ will not hurt (beyond additional message processing and potential
+ overload of the PCE or the network) for the LSP to be reported
+ multiple times because it is clearly identified. In fact, this would
+ also provide a cross-check mechanism.
+
+ Nevertheless, it is possible that some LSPs will traverse only LSRs
+ that are not aware of the PCE's need to learn LSP state and build an
+ LSP-DB. In these cases, the stateful PCE must either only have
+ limited knowledge of the LSPs in the network or must learn about LSPs
+ through some other mechanism (such as reading the MPLS and GMPLS MIB
+ modules [RFC3812] [RFC4802]).
+
+ Ultimately, there may be no substitute for all LSRs being aware of
+ Stateful PCEs and able to respond to requests for reports on all LSPs
+ that they know about. This will allow a Stateful PCE to build its
+ LSP-DB from scratch (which it may need to do at start of day) and to
+ verify its LSP-DB against the network (which may be important if the
+ PCE has suffered some form of outage).
+
+16. How Do Redundant Stateful PCEs Synchronize State?
+
+ It is important that two PCEs operating in a network have similar
+ views of the available resources. That is, they should have the same
+ or substantially similar TEDs. This is easy to achieve either by
+ building the TEDs from the network in the same way or by one PCE
+ synchronizing its TED to the other PCE using a TED export protocol
+ such as BGP-LS [LS-DISTRIB] or the Network Configuration Protocol
+ (NETCONF) [RFC6241] (see Section 6).
+
+
+
+
+
+
+Farrel & King Informational [Page 15]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ Synchronizing the LSP-DB can be a more complicated issue. As
+ described in Section 15, building the LSP-DB can be an involved
+ process, so it would be best to not have multiple PCEs each trying to
+ build an LSP-DB from the network. However, it is still important
+ that where multiple PCEs operate in the network (either as
+ distributed PCEs or with one acting as a backup for the other), their
+ LSP-DBs are kept synchronized.
+
+ Thus, there is likely to be a need for a protocol mechanism for one
+ PCE to update its LSP-DB with that of another PCE. This is no
+ different from any other database-synchronization problem and could
+ use existing mechanisms or a new protocol. Note, however, that in
+ the case of distributed PCEs that are also Active PCEs (see Section
+ 17), each PCE will be creating entries in its own LSP-DB; so, the
+ synchronization of databases must be incremental and bidirectional,
+ not just simply a database dump.
+
+ It may be helpful to clarify the word "redundant" in the context of
+ this question. One interpretation is that a redundant PCE exists
+ solely as a backup such that it only performs a function in the
+ network in the event of a failure of the primary PCE. This seems
+ like a waste of expensive resources, and it would make more sense for
+ the redundant PCE to take its share of computation load all the time.
+ However, that scenario of two (or more) active PCEs creates exactly
+ the state synchronization issue described above.
+
+ Various deployment options have been suggested where one PCE serves a
+ set of PCCs as the primary computation server, and only addresses
+ requests from other PCCs in the event of the failure of some other
+ PCE; however, this mode of operation still raises questions about the
+ need for synchronized state even in non-failure scenarios if the LSPs
+ that will be computed by the different PCEs may traverse the same
+ network resources.
+
+17. What Is an Active PCE? What Is a Passive PCE?
+
+ A Passive PCE is one that only responds to path computation requests.
+ It takes no autonomous actions. A Passive PCE may be stateless or
+ stateful.
+
+ An Active PCE is one that issues provisioning "recommendations" to
+ the network. These recommendations may be new routes for existing
+ LSPs or routes for new LSPs (that is, an Active PCE may recommend the
+ instantiation of new LSPs). An Active PCE may be stateless or
+ stateful, but in order for it to reroute existing LSPs effectively,
+ it is likely to hold state for at least those LSPs that it will
+ reroute.
+
+
+
+
+Farrel & King Informational [Page 16]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ Many people consider that the PCE, itself, cannot be Active. That
+ is, they hold that the PCE's function is purely to compute paths. In
+ that worldview, the "Active PCE" is actually the combination of a
+ normal, passive PCE and an additional architectural component
+ responsible for issuing commands or recommendations to the network.
+
+ In some configurations, the VNTM discussed in Sections 21 and 22
+ provides this additional component.
+
+ Section 20 offers a brief comparison of the different modes of PCE
+ with reference to passive and active PCE.
+
+18. What is LSP Delegation?
+
+ LSP delegation [STATEFUL-PCE] is the process where a PCC (usually an
+ ingress LSR) passes responsibility for triggering updates to the
+ attributes of an LSP (such as bandwidth or path) to the PCE. In this
+ case, the PCE would need to be both Stateful and Active.
+
+ LSP delegation allows an LSP to be set up under the control of the
+ ingress LSR potentially using the services of a PCE. Once the LSP
+ has been set up, the LSR (a PCC) tells the PCE about the LSP by
+ providing details of the path and resources used. It delegates
+ responsibility for the LSP to the PCE so that the PCE can make
+ adjustments to the LSP as dictated by changes to the TED and the
+ policies in force at the PCE. The PCE makes the adjustments by
+ sending a new path to the LSR with the instruction/recommendation
+ that the LSP be re-signaled.
+
+ There may be some debate over whether the PCE "owns" the LSP after
+ delegation. That is, if the PCE supplies a new path, is the ingress
+ LSR required to act or can it take the information "under
+ advisement"? It may be too soon to answer this question
+ definitively; however, there is certainly an expectation that the LSR
+ will act on the advice it receives. A comparison may be drawn with a
+ visit to the doctor: the doctor has an expectation that the patient
+ will take the medicine, but the patient has free will.
+
+ It is important, however, to distinguish between an LSP established
+ within the network and subsequently delegated to a PCE and an LSP
+ that was established as the result of an Active PCE's recommendation
+ for LSP instantiation.
+
+ Section 20 offers a brief comparison of the different modes of PCE
+ with reference to LSP delegation.
+
+
+
+
+
+
+Farrel & King Informational [Page 17]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+19. Is an Active PCE with LSP Delegation Just a Fancy NMS?
+
+ In many ways the answer here is "yes". But the PCE architecture
+ forms part of a new way of looking at network operation and
+ management. In this new view, the network operation is more dynamic
+ and under the control of software applications without direct
+ intervention from operators. This is not to say that the operator
+ has no say in how their network runs, but it does mean that the
+ operator sets policies (see Section 24) and that new components (such
+ as an Active PCE) are responsible for acting on those policies to
+ dynamically control the network.
+
+ There is a subtle distinction between an NMS and an Active PCE with
+ LSP delegation. An NMS is in control of the LSPs in the network and
+ can command that they are set up, modified, or torn down. An Active
+ PCE can only make suggestions about LSPs that have been delegated to
+ the PCE by a PCC, or make recommendations for the instantiation of
+ new LSPs.
+
+ For more details, see the discussion of an architecture for
+ Application-Based Network Operation (ABNO) in [NET-OPS]
+
+20. Comparison of Stateless and Stateful PCE
+
+ Table 1 shows a comparison of stateless and stateful PCEs to show how
+ they how might be instantiated as passive or active PCEs with or
+ without control of LSPs. The terms used relate to the concepts
+ introduced in the previous sections. The entries in the table refer
+ to the notes that follow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 18]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ | Stateless | Stateful |
+ ------------------------+-----------+-----------+
+ Passive | 1 | 2 |
+ Active delegated LSPs | 3 | 4 |
+ Active suggest new LSPs | 5 | 6 |
+ Active instantiate LSPs | 7 | 7 |
+
+ Notes:
+ 1. Passive is the normal mode for a stateless PCE.
+ 2. A passive mode stateful PCE may have value for more complex
+ environments and for computing protected services.
+ 3. Delegation of LSPs to a stateless PCE is relatively pointless,
+ but could add value at moment of delegation.
+ 4. This is the normal mode for a stateful PCE.
+ 5. There is only marginal potential for a stateless PCE to
+ recommend new LSPs because without a view of existing LSPs, the
+ PCE cannot determine when new ones might be needed.
+ 6. This mode has potential for recommending the instantiation of
+ new LSPs.
+ 7. These modes are out of scope for PCE as currently described.
+ That is, the PCE can recommend instantiation, but cannot
+ actually instantiate the LSPs.
+
+ Table 1 : Comparing Stateless and Stateful PCE
+
+21. How Does a PCE Work with a Virtual Network Topology?
+
+ A Virtual Network Topology (VNT) is described in [RFC4397] as a set
+ of Hierarchical LSPs that is created (or could be created) in a
+ particular network layer to provide network flexibility (data links)
+ in other layers. Thus, the TE topology of a network can be
+ constructed from TE links that are simply data links, from TE links
+ that are supported by LSPs in another layer of the network, or from
+ TE links that could be supported by LSPs ("potential LSPs") that
+ would be set up on demand in another network layer. This third type
+ of TE link is known as a Virtual TE Link in [RFC5212].
+
+ [RFC5212] also gives a more detailed explanation of a VNT, and it
+ should be noted that the network topology in a packet network could
+ be supported by LSPs in a number of different lower-layer networks.
+ For example, the TE links in the packet network could be achieved by
+ connections (LSPs) in underlying Synchronous Optical Network or
+ Synchronous Digital Hierarchy (SONET/SDH) and photonic networks.
+ Furthermore, because of the hierarchical nature of MPLS, the TE links
+ in a packet network may be achieved by setting up packet LSPs in the
+ same packet network.
+
+
+
+
+
+Farrel & King Informational [Page 19]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ A PCE obviously works with the TED that contains information about
+ the TE links in the network. Those links may be already established
+ or may be virtual TE links. In a simple TED, there is no distinction
+ between the types of TE link; however, there may be advantages to
+ selecting TE links that are based on real data links over those based
+ on dynamic LSPs in lower layers because the data links may be more
+ stable. Conversely, the TE links based on dynamic LSPs may be able
+ to be repaired dynamically giving better resilience. Similarly, a
+ PCE may prefer to select a TE link that is supported by a data link
+ or existing LSP in preference to using a virtual TE link because the
+ latter may need to be set up (taking time) and the setup could
+ potentially fail. Thus, a PCE might want to employ additional
+ metrics or indicators to help it view the TED and select the right
+ path for LSPs.
+
+ If a PCE uses a virtual TE link, then some action will be needed to
+ establish the LSP that supports that link. Some models (such as that
+ in [RFC5212]) trigger the setup of the lower-layer LSPs on-demand
+ during the signaling of the upper-layer LSP (i.e., when the upper
+ layer comes to use the virtual TE link, the upper-layer signaling is
+ paused and the lower-layer LSP is established). Another view,
+ described in [RFC5623], is that when the PCE computes a path that
+ will use a virtual TE link, it should trigger the setup of the lower-
+ layer LSP to properly create the TE link so that the path it returns
+ will be sure to be viable. This latter mode of operation can be
+ extended to allow the PCE to spot the need for additional TE links
+ and to trigger LSPs in lower layers in order to create those links.
+
+ Of course, such "interference" in a lower-layer network by a PCE
+ responsible for a higher-layer network depends heavily on policy. In
+ order to make a clean architectural separation and to facilitate
+ proper policy control, [RFC5623] introduces the Virtual Network
+ Topology Manager (VNTM) as a functional element that manages and
+ controls the VNT. [RFC5623] notes that the PCE and VNT Manager are
+ distinct functional elements that may or may not be collocated.
+ indeed, it should be noted that there will be a PCE for the upper
+ layer, and a PCE for each lower layer, and a VNTM responsible for
+ coordinating between the PCEs and for triggering LSP setup in the
+ lower layers. Therefore, the combination of all of the PCEs and the
+ VNTM produces functionally similar to an Active, multi-layer PCE.
+
+ See [TE-INFO] for additional discussion of the construction of
+ networks using virtual and potential links.
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 20]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+22. How Does PCE Communicate with VNTM
+
+ The VNTM described in Section 21 and [RFC5623] has several interfaces
+ (see also [NET-OPS]).
+
+ - In order to make decisions on whether to create new TE links, the
+ VNTM needs to learn from the upper-layer PCE about resource
+ shortages and the need for additional TE links. It can then make
+ policy-based decisions to determine whether to create new TE links
+ and how to support them through existing or new LSPs.
+
+ - The VNTM will need to coordinate with the PCEs in the lower
+ layers, but this is simply a normal use of PCEP.
+
+ - The VNTM will need to issue provisioning requests/commands (via
+ the Provisioning Manager described in [NET-OPS]) to the lower-
+ layer networks to cause LSPs to be set up to act as TE links in
+ the higher layer network. A number of potential protocols exist
+ for this function as described in [NET-OPS], but it should be
+ noted that it makes a lot of sense for this interface to be the
+ same as that used by an Active PCE when providing paths to the
+ network.
+
+23. How Does Service Scheduling and Calendering Work?
+
+ LSP scheduling or calendaring is a process where LSPs are planned
+ ahead of time, and they are only set up when needed. The challenge
+ here is to ensure that the resources needed by an LSP and that were
+ available when the LSP's path was computed are still available when
+ the LSP needs to be set up. This needs to be achieved using a
+ mechanism that allows those resources to be used in the meantime.
+
+ Previous discussion of this topic has suggested that LSPs should be
+ pre-signaled so that each LSR along the path could make a "temporal
+ reservation" of resources. But this approach can become very
+ complicated requiring each network node to store multi-dimensional
+ state.
+
+ Conversely, a centralized database of resources and LSPs (such as the
+ database maintained by a Stateful PCE) can be enhanced with a time-
+ based booking system. If the PCE is also Active, then when the time
+ comes for the LSP to be set up (or later, when it is to be torn
+ down), the PCE can issue recommendations to the network.
+
+ In a busy network (and why would one bother with a scheduling service
+ in a network that is not busy?), it should be noted that the
+ computation algorithm can be quite complex. It may also be necessary
+ to reposition existing or planned LSPs as new bookings arrive.
+
+
+
+Farrel & King Informational [Page 21]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ Furthermore, the booking database that contains both the scheduled
+ LSPs and their impact on the network resources can become quite
+ large. A very important factor in the size of the active database
+ (depending on implementation) may be the timeslices that are
+ available in the calendering process.
+
+24. Where Does Policy Fit In?
+
+ Policy is critical to the operation of a network. In a PCE context,
+ it provides control and management of how a PCE selects network
+ resources for use by different PCEs.
+
+ [RFC5394] introduced the concept of PCE-based policy-enabled path
+ computation. It is based on the Policy Core Information Model (PCIM)
+ [RFC3060] as extended by [RFC3460], and provides a framework for
+ supporting path computation policy.
+
+ Policy enters into all aspects of the use of a PCE starting from the
+ very decision to use a PCE to off-load computation function from the
+ LSRs.
+
+ - Each PCC must select which computations will be delegated to a
+ PCE.
+
+ - Each PCC must select which PCEs it will use.
+
+ - Each PCE must determine which PCCs are allowed to use its services
+ and for what computations.
+
+ - The PCE must determine how to collect the information in its TED,
+ who to trust for that information, and how to refresh/update the
+ information.
+
+ - Each PCE must determine which objective functions and which
+ algorithms to apply.
+
+ - Inter-domain (and particularly H-PCE) computations will need to be
+ sensitive to commercial and reliability information about domains
+ and their interactions.
+
+ - Stateful PCEs must determine what state to hold, when to refresh
+ it, and which network elements to trust for the supply of the
+ state information.
+
+ - An Active PCE must have a policy relationship with its LSRs to
+ determine which LSPs can be modified or triggered, and what LSP
+ delegation is supported.
+
+
+
+
+Farrel & King Informational [Page 22]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ - Multi-layer interactions (especially those using virtual or
+ dynamic TE links) must provide policy control to stop server layer
+ LSPs (which are fat and expensive by definition) from being set up
+ on a whim to address micro-flows or speculative computations in
+ higher layers.
+
+ - A PCE may supply, along with a computed path, policy information
+ that should be signaled during LSP setup for use by the LSRs along
+ the path.
+
+ It may be seen, therefore, that a PCE is substantially a policy
+ engine that computes paths. It should also be noted that the work of
+ the PCE can be substantially controlled by configured policy in a way
+ that will reduce the options available to the PCC, but also
+ significantly reduce the need for the use of optional parameters in
+ the PCEP messages.
+
+25. Does PCE Play a Role in SDN?
+
+ Software-Defined Networking (SDN) is the latest shiny thing in
+ networking. It refers to a separation between the control elements
+ and the forwarding components so that software running in a
+ centralized system called a controller, can act to program the
+ devices in the network to behave in specific ways.
+
+ A required element in an SDN architecture is a component that plans
+ how the network resources will be used and how the devices will be
+ programmed. It is possible to view this component as performing
+ specific computations to place flows within the network given
+ knowledge of the availability of network resources, how other
+ forwarding devices are programmed, and the way that other flows are
+ routed. This, it may be concluded, is the same function that a PCE
+ might offer in a network operated using a dynamic control plane.
+ Thus, a PCE could form part of the infrastructure for an SDN.
+
+ A view of how PCE integrates into a wider network control system
+ including SDN is presented in [NET-OPS].
+
+26. Security Considerations
+
+ The use of a PCE-based architecture and subsequent impact on network
+ security must, itself, be considered in the context of existing
+ routing and signaling protocols and techniques. The nature of multi-
+ domain network scenarios and establishment of relationships between
+ PCCs and PCEs may increase the vulnerability of the network to
+ security attacks. However, this informational document does not
+ define any new protocol elements or mechanism. As such, it does not
+ introduce any new security issues and security is deemed to be a
+
+
+
+Farrel & King Informational [Page 23]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ "previously answered question" even if the answers previously
+ supplied are not perfect. Previous PCE RFCs have given some
+ attention to security concerns in the use of PCE (RFC 4655), PCE
+ discovery (RFC 4674, RFC 5088, and RFC 5089), and PCEP (RFC 4657 and
+ RFC 5440).
+
+ It is worth noting that PCEP operates over TCP. An analysis of the
+ security issues for routing protocols that use TCP (including PCEP)
+ is provided in [RFC6952], while [PCE-PCEPS] discusses an experimental
+ approach to provide secure transport for PCEP.
+
+ A number of the questions raised and answered in this document should
+ be given consideration in the light of security requirements. Some
+ of these are called out explicitly (Sections 8 and 10), but attention
+ should also be paid to security in all aspects of the use of PCE.
+ For example:
+
+ - Topology and other information about the network needs to be kept
+ private and protected from modification or forgery. That means
+ that access to the TED, LSP-DB, etc., needs to be secured and that
+ mechanisms used to gather topology and other information (Sections
+ 2, 11, 14, and 15) need to include security.
+
+ - PCE discovery (Sections 4, 5, 9, and 10) needs to protect against
+ impersonation or misconfiguration so that PCCs know that they are
+ getting correct paths and so that PCEs know that they are only
+ serving legitimate computation requests.
+
+ - Synchronization of information and state between PCEs (Sections 6
+ and 16) is subject to the same security requirements in that the
+ information exchanged is sensitive and needs to be protected
+ against interception and modification.
+
+ - PCE computes paths for components that may provision the network.
+ Those component are responsible for the security of the
+ provisioning mechanisms, however, if PCE operates as a
+ provisioning protocol (Sections 17, 18, 19, and 25).
+
+ - A PCE may also need to interface with other network components
+ (Sections 19, 21, 22, and 25). Those communications, if external
+ to an implementation, also need to be secure.
+
+
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 24]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+27. References
+
+27.1. Normative References
+
+ [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture", RFC
+ 4655, August 2006,
+ <http://www.rfc-editor.org/info/rfc4655>.
+
+ [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
+ Computation Element (PCE) Communication Protocol
+ (PCEP)", RFC 5440, March 2009,
+ <http://www.rfc-editor.org/info/rfc5440>.
+
+ [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
+ "Framework for PCE-Based Inter-Layer MPLS and GMPLS
+ Traffic Engineering", RFC 5623, September 2009,
+ <http://www.rfc-editor.org/info/rfc5623>.
+
+ [RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of
+ the Path Computation Element Architecture to the
+ Determination of a Sequence of Domains in MPLS and
+ GMPLS", RFC 6805, November 2012,
+ <http://www.rfc-editor.org/info/rfc6805>.
+
+27.2. Informative References
+
+ [ALTO-SERVER-DISC]
+ Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M.,
+ and H. Song, "ALTO Server Discovery", Work in
+ Progress, draft-ietf-alto-server-discovery-10,
+ September 2013.
+
+ [LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and
+ S. Ray, "North-Bound Distribution of Link-State and TE
+ Information using BGP", Work in Progress,
+ draft-ietf-idr-ls-distribution-06, September 2014.
+
+ [NET-OPS] King, D., and A. Farrel, "A PCE-based Architecture for
+ Application-based Network Operations", Work in
+ Progress, draft-farrkingel-pce-abno-architecture-13,
+ October 2014.
+
+ [PCE-PCEPS] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
+ "Secure Transport for PCEP", Work in Progress,
+ draft-ietf-pce-pceps-02, October 2014.
+
+
+
+
+
+Farrel & King Informational [Page 25]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A.
+ Westerinen, "Policy Core Information Model -- Version
+ 1 Specification", RFC 3060, February 2001,
+ <http://www.rfc-editor.org/info/rfc3060>.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+ V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
+ LSP Tunnels", RFC 3209, December 2001,
+ <http://www.rfc-editor.org/info/rfc3209>.
+
+ [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
+ Extensions", RFC 3460, January 2003
+ <http://www.rfc-editor.org/info/rfc3460>.
+
+ [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
+ Engineering (TE) Extensions to OSPF Version 2", RFC
+ 3630, September 2003,
+ <http://www.rfc-editor.org/info/rfc3630>.
+
+ [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+ "Multiprotocol Label Switching (MPLS) Traffic
+ Engineering (TE) Management Information Base (MIB)",
+ RFC 3812, June 2004,
+ <http://www.rfc-editor.org/info/rfc3812>.
+
+ [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
+ Extensions in Support of Generalized Multi-Protocol
+ Label Switching (GMPLS)", RFC 4203, October 2005,
+ <http://www.rfc-editor.org/info/rfc4203>.
+
+ [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
+ Interpretation of Generalized Multiprotocol Label
+ Switching (GMPLS) Terminology within the Context of
+ the ITU-T's Automatically Switched Optical Network
+ (ASON) Architecture", RFC 4397, February 2006,
+ <http://www.rfc-editor.org/info/rfc4397>.
+
+ [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol Generic
+ Requirements", RFC 4657, September 2006,
+ <http://www.rfc-editor.org/info/rfc4657>.
+
+ [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
+ Element (PCE) Discovery", RFC 4674, October 2006,
+ <http://www.rfc-editor.org/info/rfc4674>.
+
+
+
+
+
+
+Farrel & King Informational [Page 26]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
+ Framework for Inter-Domain Multiprotocol Label
+ Switching Traffic Engineering", RFC 4726, November
+ 2006, <http://www.rfc-editor.org/info/rfc4726>.
+
+ [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
+ Multiprotocol Label Switching (GMPLS) Traffic
+ Engineering Management Information Base", RFC 4802,
+ February 2007,
+ <http://www.rfc-editor.org/info/rfc4802>.
+
+ [RFC4848] Daigle, L., "Domain-Based Application Service Location
+ Using URIs and the Dynamic Delegation Discovery
+ Service (DDDS)", RFC 4848, April 2007,
+ <http://www.rfc-editor.org/info/rfc4848>.
+
+ [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS
+ (GMPLS) RSVP-TE Signaling Extensions in Support of
+ Calls", RFC 4974, August 2007,
+ <http://www.rfc-editor.org/info/rfc4974>.
+
+ [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and
+ R. Zhang, "OSPF Protocol Extensions for Path
+ Computation Element (PCE) Discovery", RFC 5088,
+ January 2008,
+ <http://www.rfc-editor.org/info/rfc5088>.
+
+ [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and
+ R. Zhang, "IS-IS Protocol Extensions for Path
+ Computation Element (PCE) Discovery", RFC 5089,
+ January 2008,
+ <http://www.rfc-editor.org/info/rfc5089>.
+
+ [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
+ Per-Domain Path Computation Method for Establishing
+ Inter-Domain Traffic Engineering (TE) Label Switched
+ Paths (LSPs)", RFC 5152, February 2008,
+ <http://www.rfc-editor.org/info/rfc5152>.
+
+ [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL.,
+ Vigoureux, M., and D. Brungard, "Requirements for
+ GMPLS-Based Multi-Region and Multi-Layer Networks
+ (MRN/MLN)", RFC 5212, July 2008,
+ <http://www.rfc-editor.org/info/rfc5212>.
+
+ [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
+ Engineering", RFC 5305, October 2008,
+ <http://www.rfc-editor.org/info/rfc5305>.
+
+
+
+Farrel & King Informational [Page 27]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
+ Extensions in Support of Generalized Multi-Protocol
+ Label Switching (GMPLS)", RFC 5307, October 2008,
+ <http://www.rfc-editor.org/info/rfc5307>.
+
+ [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J.
+ Ash, "Policy-Enabled Path Computation Framework", RFC
+ 5394, December 2008,
+ <http://www.rfc-editor.org/info/rfc5394>.
+
+ [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le
+ Roux, "A Backward-Recursive PCE-Based Computation
+ (BRPC) Procedure to Compute Shortest Constrained
+ Inter-Domain Traffic Engineering Label Switched
+ Paths", RFC 5441, April 2009,
+ <http://www.rfc-editor.org/info/rfc5441>.
+
+ [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
+ Computation Element Communication Protocol (PCEP)
+ Requirements and Protocol Extensions in Support of
+ Global Concurrent Optimization", RFC 5557, July 2009,
+ <http://www.rfc-editor.org/info/rfc5557>.
+
+ [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the
+ Local Location Information Server (LIS)", RFC 5986,
+ September 2010,
+ <http://www.rfc-editor.org/info/rfc5986>.
+
+ [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda,
+ T., Ali, Z., and J. Meuric, "Extensions to the Path
+ Computation Element Communication Protocol (PCEP) for
+ Point-to-Multipoint Traffic Engineering Label Switched
+ Paths", RFC 6006, September 2010,
+ <http://www.rfc-editor.org/info/rfc6006>.
+
+ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J.,
+ Ed., and A. Bierman, Ed., "Network Configuration
+ Protocol (NETCONF)", RFC 6241, June 2011,
+ <http://www.rfc-editor.org/info/rfc6241>.
+
+ [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis
+ of BGP, LDP, PCEP, and MSDP Issues According to the
+ Keying and Authentication for Routing Protocols (KARP)
+ Design Guide", RFC 6952, May 2013,
+ <http://www.rfc-editor.org/info/rfc6952>.
+
+
+
+
+
+
+Farrel & King Informational [Page 28]
+
+RFC 7399 Questions in PCE Architecture October 2014
+
+
+ [STATEFUL-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
+ Extensions for Stateful PCE", Work in Progress,
+ draft-ietf-pce-stateful-pce-10, October 2014.
+
+ [TE-INFO] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
+ Ceccarelli, D, and X. Zhang, "Problem Statement and
+ Architecture for Information Exchange Between
+ Interconnected Traffic Engineered Networks", Work in
+ Progress, draft-farrel-interconnected-te-info-
+ exchange-07, September 2014.
+
+Acknowledgements
+
+ Thanks for constructive comments go to Fatai Zhang, Oscar Gonzalez de
+ Dios, Xian Zhang, Cyril Margaria, Denis Ovsienko, Ina Minei, Dhruv
+ Dhody, and Qin Wu.
+
+ This work was supported in part by the FP-7 IDEALIST project under
+ grant agreement number 317999.
+
+ This work received funding from the European Union's Seventh
+ Framework Programme for research, technological development and
+ demonstration through the PACE project under grant agreement no.
+ 619712.
+
+Authors' Addresses
+
+ Adrian Farrel
+ Juniper Networks
+ EMail: adrian@olddog.co.uk
+
+
+ Daniel King
+ Old Dog Consulting
+ EMail: daniel@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel & King Informational [Page 29]
+