1 IETF-61 – Washington DC Path Computation Element (PCE) BOF-2 Slides can be found at Co-chairs: JP Vasseur/Adrian Farrel ADs: Alex Zinin/Bill Fenner

2 Agenda 1) Introduction, admin, statement of objectives of this second BOF (5 minutes) Adrian/JP 2) Quick summary of the conclusion of the first BOF held in San Diego (5 minutes) JP 3) Problem space: recap of the PCE architecture ID draft-ash-pce-architecture-00.txt (15 minutes) Jerry 4) Summary of existing/future drafts (5 minutes) Adrian/JP 5) Proposed charter (15 minutes) 6) Discussion (and possibly conclusion!) (45 minutes) - Need for this work and need for a working group - Architecture - Charter 7) Summary and conclusions (15 minutes) Chairs and ADs

3 1) Intro, admin, objectives Blue sheets Minute takers Agenda bash At the mic… –Questions for clarification only –Save the rest for open discussion session

4 1) Intro, admin, objectives Scope of the Potential PCE WG –Specify a set of mechanism for PCE-based path computation of MPLS Traffic Engineering LSP in the context of specific application  No intent to come up with a new Inter-domain routing paradigm  Scoped applicability to a limited number of TE LSPs  Scoped applicability to a ‘simple’ topology of ASes or areas Objectives of this BOF –Examine proposed architecture –Recap different perceived requirement spaces by summary of existing drafts –Agree a proposed charter for a working group

5 2) Summary of the BOF in San Diego Clear statements of requirements from many providers –(Infonet, KDDI, AT&T, FT, NTT, MCI) Several distinct problems being solved –Shortest inter-area/AS/SP TE LSP path –Diverse path computation (intra and inter domain) –Complex constraints Delay optimization Optical constraints –Sophisticated computation requirements Multiple diverse paths (protection and load sharing) Re-optimization Minimal pre-emption Point-to-multipoint –Common theme is MPLS TE LSP path computation Prevailing sub-text is inter-domain computation Unclear on what needs to be specified (i.e. what is the scope of the work?) Need for clear architectural specification Directive from AD –Write architecture –Narrow the scope of work –Draft charter

6 Consensus on CCAMP mailing list CCAMP was asked for its opinion on: does PCE address an inter-domain problem that need addressing ? does the proposed architecture provide and acceptable way to resolve the problem ? Responses were positive and summarized by CCAMP chair as: Many people, especially SPs, consider PCE may be appropriate to solve, Path computation issues associated with inter-domain MPLS TE, CCAMP commits to help provide requirements for PCE for this work, Some reservations stating that architecture needs more work

7 Path Computation Element (PCE) Architecture draft-ash-pce-architecture-00.txt Jerry Ash AT&T Adrian Farrel Old Dog Consulting JP Vasseur Cisco Systems, Inc. quick summary –you read the draft issues raised on list –next step: incorporate comments Outline

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

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

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

11 Composite PCE Node

12 External PCE Node

13 Multiple PCE Path Computation

14 Multiple PCE Path Computation with Inter-PCE Communication

15 PCE Architectural Considerations synchronization –non-synchronized (e.g., PCE makes multiple individual path computations to generate set of paths) –synchronized (e.g., single PCE invokes computations by other PCEs before supplying result to PCC PCE discovery & load balancing detecting PCE liveness PCC-PCE & PCE-PCE communication PCE TED synchronization stateful vs. stateless PCEs monitoring policy & confidentiality –must preserve confidentiality across multiple SPs –must ensure confidentiality & security of PCC-PCE & PCE- PCE messages

16 Security & Confidentiality PCC-PCE communication –subject to "usual" security issues –snooping not a significant issue might want to encrypt –spoofing is very serious must offer strong authentication protocol is P2P so this is relatively easy –DoS important because of 'centralized' nature of PCE PCE-PCE communication –same as for PCC-PCE, but add confidentiality confidentiality (protection of domain topology information) –use loose routes –PCE encrypts ERO segments decrypt on entry to domain –replace ERO segment with cookie entry point to domain consults local PCE using cookie to retrieve next ERO segment

17 PCE Evaluation Metrics optimality scalability load sharing multiple path computation reoptimization path computation time network stability synchronization –between TED & network topology/resource states –speed of TED synchronization –impact of synchronization on data flows

18 Issues Raised on List PCE should advertise its capabilities, for example –set of constraints it can account for (diversity, SRLGs, optical impairments, wavelengh continuity, etc.) –drafts already exist that must be expanded to include GMPLS specific capabilities path computation request include if near-disjoint paths acceptable TED information can include info from sources other than IGP (e.g. LSP routes, reserved bandwidth, measured traffic volume) –needed to perform LSP re-optimization –needed to reconfigure virtual network topology (VNT) lower layer (e.g., optical) paths evaluation metrics should include TED synchronization speed & impact on the data flows elaborate on advantages of stateful PCE & pitfalls of using stateful PCE in a distributed PCE environment provide guidance on architecture recommendations

19 4) Existing and new Drafts draft-ietf-ccamp-interdomain-framework-0.txt –Techniques for establishing and controlling (G)MPLS LSPs in multi- domain networks –Presents PCE as a possible approach draft-vasseur-ccamp-inter-area-as-te-comp-00.txt –Procedural and operational considerations for PCE in inter-domain TE draft-leroux-pce-backup-comp-frwk-00.txt –Use of PCE for MPLS Fast Reroute draft-oki-pce-gmpls-req-01.txt –GMPLS considerations for PCE (multi-region, MPLS/GMPLS…) draft-oki-ccamp-gtep-01.txt –Generalized Traffic Engineering Protocol –Proposal for communications between LSRs and PCE draft-choi-pce-e2e-centralized-restoration-srlg-01.txt –Use of ring-based SRLG for back-up path computation

20 Agenda 5) New drafts published since IETF-60 a. draft-draft-ogino-pce-recovery-pc-model-00.txt b. draft-pelsser-bgp-pce-00.txt c. draft-boucadair-pce-discovery-00.txt d. draft-boucadair-pce-interas-00.txt e. draft-boucadair-pcp-interas-00.txt f. Aggregation-based Inter-AS TE Path Computation g. draft-choi-pce-metric-protocol-00.txt h. draft-choi-pce-l1vpn-framework-00.txt i. draft-choi-pcemp-ipv6-00.txt See appendix for short draft description

21 Key questions.. Clear requirements have been expressed by many Service Providers during the last BOF in San Diego, on the mailing list, … This work belongs to the IETF (under the IETF scope of expertise) Is there enough interest on this architecture ? –CCAMP consensus Ready to create a new WG ?

22 Proposed Charter Proposed PCE Working Charter and Milestones The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically be removed from the head-end LSR. There may be many applications for such a model, but the primary concern of this Working Group is the application to inter-domain TE LSPs where a domain can be a layer, IGP area or Autonomous System such that there is limited topology visibility from the head-end LSR. One of the main area for standardization is the specification of a communication protocol for use between LSRs (termed Path Computation Clients – PCCs) and PCEs, and between cooperating PCEs. This protocol must be capable of representing requests for path computation including a full set of constraints, must be able to return multiple paths with consideration of confidentiality and security, and must itself be secure.

23 Proposed Charter Proposed PCE Working Charter and Milestones The Working Group will determine requirements for extensions to existing routing and signaling protocols in support of such functions as PCE discovery and the secure and confidential signaling of inter-domain paths. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on protocol-independent metrics defining path quality measurement criteria and scalability criteria related to path computation techniques. Work Items - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation techniques involving Path Computation Element(s). This includes the case of intra and inter-domain (where a domain might be a specific layer, an IGP area or an Autonomous System) TE LSPs path computation and applies to Point to Point and Point to Multipoint TE LSPs. Such path computation techniques include primary, protection and recovery paths as well as load balancing and reoptimization techniques.

24 Proposed Charter Proposed PCE Working Charter and Milestones - Specification of the PCE-based architecture. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required by PCE-based path computation techniques. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols, this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of protocol-independent metrics defining path quality measurement criteria and scalability criteria related to path computation techniques. - Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple administrative entities.

25 Proposed Charter Proposed PCE Working Charter and Milestones - Definition of MIBs and management procedures related to the new protocols, protocol extensions and operational elements defined by the WG. The WG will work closely with the following other WGs for the derivation of requirements and for the specification of any necessary protocol extensions: CCAMP, MPLS, ISIS, OSPF and IDR; Proposed WG Goals and initial Milestones (date to be determined) - Submit a requirements draft describing the function necessary for the use of PCE to compute the paths of inter-domain (G)MPLS TE LSPs. - Submit a draft describing the PCE architecture. - Submit a draft specifying requirements for a communication protocol for use between a PCC and a PCE, and between PCEs. - Submit a draft of a communication protocol for use between a PCC and a PCE, and between PCEs. - Submit an applicability draft describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter- domain (G)MPLS Traffic Engineering.

26 Key questions.. Clear requirements have been expressed by many Service Providers during the last BOF in San Diego, on the mailing list, … This work belongs to the IETF (under the IETF scope of expertise) Is there enough interest on this architecture ? –CCAMP consensus Ready to create a new WG ?

27 Summary and Conclusions Room, Co-chairs, ADs

28 Appendix

29 Requirements for Path Computation Element in GMPLS and IP/MPLS Networks draft-oki-pce-gmpls-req-01.txt Nov. 10, 2004 Eiji Oki (NTT) Takashi Kurimoto (NTT) Ichiro Inoue (NTT) Kohei Shiomoto (NTT) draft-oki-pce-gmpls-req-01.txt

30 Requirement draft target Scope in the proposed WG milestone –“ Submit a requirements draft describing the function necessary for the use of PCE to compute the paths of inter-domain (G)MPLS TE LSPs. ” Ready to make a PCE requirement draft based our draft. Describes MPLS and GMPLS TE scenarios and requirements. Feedbacks are welcome. draft-oki-pce-gmpls-req-01.txt

31 Generalized Traffic Engineering Protocol (GTEP) draft-oki-ccamp-gtep-01.txt Nov. 10, 2004 Eiji Oki (NTT) Daisaku Shimazaki (NTT) Kohei Shiomoto (NTT) draft-oki-ccamp-gtep-01.txt

32 GTEP draft target GTEP communicates between PCC and PCE Scope in the proposed WG milestone –“Submit a draft of a communication protocol for use between a PCC and a PCE, and between PCEs.” Scope in the architecture draft, “draft-ash-pce- architecture-00.txt” –Section 6.6. PCC-PCE & PCE-PCE Communication –Section 6.7. PCE TED Synchronization –Section 6.8. Stateful Versus Stateless PCEs GTEP running code was demonstrated in a public event in draft-oki-ccamp-gtep-01.txt

33 Path Computation Model for Recovery LSPs Using External PCE draft-ogino-pce-recovery-pc-model-00.txt This draft proposes a path computation model for recovery LSPs in the shared mesh restoration. –This model uses external PCE that exclusively preserves complete TE information within a domain. –This model can promote bandwidth sharing between recovery LSPs without any extension of the present IGP-TE. Prerequisites of this model Network state recognized by the external PCE is identical to real network state at any time. –Recovery LSPs are certainly established along the routes computed by the external PCE. –External PCE is always notified when the recovery LSPs are released. Scalability problems of this model –Domain size should be decided based on the capacity of centralized PCE. –Fast synchronization of TE information is required between distributed PCEs. Starting point for the framework document of GMPLS-based recovery path computation?

34 Limitations induced by BGP on the computation of inter-AS LSPs Draft-pelsser-bgp-pce-00.txt Simulation study for inter-AS TE-LSP setup – Simple case : two interconnected ASes – Main result Inter-AS primary and backup paths found depend on quality of the interdomain routes learned One Route Reflector per POP inside each AS – Head-end can compute primary LSPs, but not backup LSPs – PCE colocated with Route Reflector is able to find more paths for primary and backup LSPs than ASBRs but this is still not sufficient to compute all backup LSPs – Conclusion PCE can help in the establishment of inter-AS LSPs provided that they have detailed BGP tables →How to gather enough information about inter-AS paths at the PCE for constraint-based path selection ? – To be addressed during PCE WG next step Cristel Pelsser - CSE/UCL

35 A PCE-based Approach for providing inter-AS MPLS-based QoS tunnels draft-boucadair-pce-interas-00.txt draft-boucadair-pcp-interas-00.txt draft-boucadair-pce-discovery-00.txt PCE BOF-November 2004 Mohamed BOUCADAIR

36 Inter-Domain QoS Ensure QoS for emerging applications like –Inter-provider VoIP services Enterprise VoIP PSTN migration to VoIP –Inter-provider IP VPNs Provide hard guarantees for mission critical applications –Traffic Isolation –Bandwidth reservation –Network Availability –Resiliency Extend QoS service offering beyond a single provider boundaries Establish inter-domain QoS-driven MPLS TE tunnels

37 Inter-Domain TE LSP Each SP deploys at least one PCE per domain PCE functions –Compute an inter-domain constrained path –Negotiate inter-domain contracts along AS-path for the computed TE LSP –When agreement is end-to-end reached, Establish inter-domain TE LSP

38 Draft contents Describes a solution for offering inter-provider end to end QoS-based services –Highlights service considerations in order to ease inter-provider cooperation draft-boucadair-pce-interas-00.txt –Specifies PCE functions and interfaces –Describes inter-domain routing features –Suggest PCE to LER communication means draft-boucadair-pcp-interas-00.txt –Describes PCE to PCE communication draft-boucadair-pcp-interas-00.txt –Describe a Path Computation Service Discovery mechanism

39 Aggregation-based Inter-AS (Domain) TE Path Computation (B. Jabbari) 1. PCE in each domain computes the aggregated model and communicates it to other PCEs dynamically or after a threshold change 2. For an LSP request in a domain, the PCE in that domain computes up to the K Shortest Paths (KSPs) 3. If constraints cannot be satisfied, the request may be denied immediately 4. Otherwise, while establishing the TE path, the KSPs are evaluated for path optimality in each domain Aggregated domain span = …. An abstract model for representation of topology, resources and constraints of each domain Abstraction may span a virtual node to full network Bijan Jabbari High level view of the domains The interconnected aggregated domains as presented at each PCE AS1 AS2 AS3 AS4 AS5 AS1 AS2 AS3 AS4 AS5 Note: Domain and AS is used interchangeably here

40 Path Computing Element Metric Protocol (PCEMP) and PCE architecture framework Jun Kyun Choi PCE BOF (61 st IETF) November 10, 2004 Washington D.C. draft-choi-pce-metric-protocol-00.txt draft-choi-pce-e2e-centralized-restoration-srlg-01.txt draft-choi-pce-l1vpn-framework-00.txt draft-choi-pcemp-ipv6-00.txt

41 draft-choi-pce-metric-protocol-00.txt ▣ Scope of the draft and PCE BOF: Analysis of a Path Computation Element Metric Protocol (PCEMP) ▣ Main functionalities of PCEMP:  PCEMP acts as a generic computational model for path based metrics in large multi-domain or multi-layer networks  Protocol mechanism can serve as an application path computation framework for any PCE ▣ Protocol architecture and PCE architecture framework  Implementation considerations of the PCEMP protocol state machines within the PCE framework scope  Analysis of PCEMP metrics in terms of protocol cost ▣ Underlying key point : Addresses inter-domain partitioning and management issues through the concept of PCE peers drafted by PCEMP ▣ Conclusion: draft issues and new PCE WG:  protocol metrics for an inter-domain PCE framework (path quality measurement criteria, algorithm complexity, scalability)  metric definition and analysis requirements of PCE models

42 draft-choi-pce-e2e-centralized-restoration-srlg-01.txt ▣ Scope of the draft and PCE BOF: Use of ring SRLG for PCE based backup path computation ▣ PCEMP protocol for distributing PCE mapping table ▣ PCE architecture framework in guaranteed disjoint backup path establishment using ring SRLGs  Network and control structure framework in the scenario of PCEMP and fast P&R ▣ Architectural framework for PCE-based backup path computation using SRLG  Segmentation of the logical ring during path computation ▣ Underlying key point : Guaranteed disjoint backup path establishment and hence extremely fast P&R in PCE peers ▣ Conclusion: draft issues and new PCE WG:  Mechanism for integrated provisioning and protection for the purpose of fast backup path computation  Possibility of explicitly including PCE-based backup path computation within the scope of the PCE WG Charter

43 draft-choi-pce-l1vpn-framework-00.txt ▣ Scope of the draft and PCE BOF: Path computation framework in management systems for Layer 1 VPNs ▣ Viewpoint of PCEMP in large multi-domain networks ▣ Path computation fundamentals applicable to dynamic L1 provisioning  Network, control structure, inter-domain segmentation framework using PCEMP  Complete network topology for L1 VPN networks: A PCE perspective ▣ Underlying key point : A path computation technique based architecture for dynamic L1 VPN provisioning ▣ Conclusion: draft issues and new PCE WG:  Per VPN peer solutions using PCE techniques  Functional specifications of Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element (s) in the PCE WG Charter

44 draft-choi-pcemp-ipv6-00.txt ▣ Scope of the draft and PCE BOF: Router handling improvement procedures on individual PCE nodes ▣ Fast PCE peer advertisement ▣ Fast processing of PCE peer solicitations  PCE peer architecture as “seen” by PCEMP  Configuration of PCE peers for fast processing of solicitations ▣ Underlying key point : The PCEMP architecture enables the corresponding PCE peers to exchange information tags instantaneously upon discovery at any point of time – less inter-domain path computation response time ▣ Conclusion: draft issues and new PCE WG:  Guideline to specifications of modifying existing protocols to facilitate communication between LSRs, PCEs and PCE peers  Concept of sync of information between PCE nodes in case of a change in the PCE Domain Area can help in fast default PCE peer acquisition  PCE peers capable of being “soft-configured” in inter-domain PCE issues