1. 1 Path Computation Element (PCE) Architecture (draft-ash-pce-architecture-01.txt) Jerry Ash AT&T gash@att.com Adrian Farrell Old Dog Consulting adrian@olddog.co.uk JP Vasseur Cisco Systems, Inc. jpv@cisco.com qPCE architecture summary vprovided in backup slides vyou read the draft qI-D updates based on comments raised on list qnext step: working group draft Outline

2. 2 PCE Architecture Summary (see backup slides attached) qterminology qassumptions qmotivation for PCE architecture qPCE architectural considerations qsecurity & confidentiality qPCE evaluation metrics qPCE architecture overview vcomposite PCE vexternal PCE vmultiple PCE path computation vmultiple PCE path computation with inter-PCE communication qarchitecture non-goal to specify protocols vprotocol extensions will be worked out in other IDs

3. 3 Composite PCE Node

4. 4 External PCE Node

5. 5 Multiple PCE Path Computation

6. 6 Multiple PCE Path Computation with Inter-PCE Communication

7. 7 I-D Updates Based on Issues Raised on List qPCE should advertise its capabilities, for example vset of constraints it can account for (diversity, SRLGs, optical impairments, wavelength continuity, etc.) vtext added to Section 6.4 qpath computation request include if near-disjoint paths acceptable vtext added to Section 6.6 qTED information can include info from sources other than IGP (e.g. LSP routes, reserved bandwidth, measured traffic volume) vneeded to perform LSP re-optimization vneeded to reconfigure virtual network topology (VNT) lower layer (e.g., optical) paths vtext added to Section 6.7 qelaborate on advantages of stateful PCE & pitfalls of using stateful PCE in a distributed PCE environment vtext added to Section 6.8 qevaluation metrics should include TED synchronization speed & impact on the data flows vtext added to Section 7

8. 8 I-D Updates Based on Issues Raised on List qidentify areas for standardization vadded Section 5.5 “Areas for Standardization” –based on PCE Charter qother editorial changes

9. 9 Next Steps qpropose draft as PCE WG draft

10. 10 Backup Slides

11. 11 Terminology qpath computation element (PCE) ventity (component, application or network node) capable of computing a network path based on network graph & computational constraints ve.g., PCE computes path of a TE LSP by using TED & bandwidth/other constraints qpath computation client (PCC) vany client application requesting a path computation by the PCE qdomain v any collection of network elements within a common sphere of address management or path computational responsibility ve.g., IGP areas, AS, multiple ASs within a SP network, multiple ASs across multiple SP networks qsingle PCE path computation: single PCE computes a path in a domain qmultiple PCE path computation: multiple PCEs compute a path in a domain qcentralized computation model: all paths in a domain computed by a single, centralized PCE qdistributed computation model: computation of paths in a domain shared among multiple PCEs

12. 12 Assumptions qPCE may or may not be located at head-end ve.g. nodes on path contribute to path computation (e.g., loose hops) making them PCEs vpath computation may be made by PCE physically distinct from the computed path qpath computed by PCE may be vcomplete: full explicit path of strict hops vpartial: mix of strict & loose hops (may be an abstract node such as an AS) qPCE path computation can be used in conjunction with other path computation models ve.g., inter-AS TE LSP may be computed using PCE in some domains but not others qno assumptions made about PCE implementation ve.g., could be implemented on a router, LSR, dedicated network server, etc. vPCE function independent of forwarding capability of node on which it is implemente

13. 13 Motivation for PCE Architecture qinter-area/AS optimal path computation (node has partial visibility) qcomputation of inter-area/AS diverse path (node has partial visibility) qCPU-intensive path computation/global optimization qbackup path computation for bandwidth protection with backup capacity optimization qmulti-layer networks e.g. TDM network provides connectivity for client-layer (IP, MPLS, L2, etc.) qabsence of TED or use of non-TE-enabled IGP qnode outside routing domain (e.g., CE to PE path computation) qnetwork element lacks control plan or routing capability

14. 14 PCE Architectural Considerations qsynchronization vnon-synchronized (e.g., PCE makes multiple individual path computations to generate set of paths) vsynchronized (e.g., single PCE invokes computations by other PCEs before supplying result to PCC qPCE discovery & load balancing qdetecting PCE liveness qPCC-PCE & PCE-PCE communication qPCE TED synchronization qstateful vs. stateless PCEs qmonitoring qpolicy & confidentiality vmust preserve confidentiality across multiple SPs vmust ensure confidentiality & security of PCC-PCE & PCE- PCE messages

15. 15 Security & Confidentiality qPCC-PCE communication vsubject to "usual" security issues vsnooping not a significant issue –might want to encrypt vspoofing is very serious –must offer strong authentication –protocol is P2P so this is relatively easy vDoS important because of 'centralized' nature of PCE qPCE-PCE communication vsame as for PCC-PCE, but add confidentiality qconfidentiality (protection of domain topology information) vuse loose routes vPCE encrypts ERO segments –decrypt on entry to domain vreplace ERO segment with cookie –entry point to domain consults local PCE using cookie to retrieve next ERO segment

16. 16 PCE Evaluation Metrics qoptimality qscalability qload sharing qmultiple path computation qreoptimization qpath computation time qnetwork stability qsynchronization vbetween TED & network topology/resource states vspeed of TED synchronization vimpact of synchronization on data flows