1 / 42

Agenda 1) Introduction, admin, statement of objectives of the BOF ( 10 minutes ) Adrian

IETF- 60 – San Diego Path Computation Element ( PCE ) BOF Co-chairs: JP Vasseur/Adrian Farrel ADs: Alex Zinin/Bill Fenner. Agenda 1) Introduction, admin, statement of objectives of the BOF ( 10 minutes ) Adrian 2) Overview of PCE-based LSP Path computation ( 5 minutes ) JP

gabriellej
Download Presentation

Agenda 1) Introduction, admin, statement of objectives of the BOF ( 10 minutes ) Adrian

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF- 60 – San DiegoPath Computation Element (PCE) BOFCo-chairs: JP Vasseur/Adrian FarrelADs: Alex Zinin/Bill Fenner

  2. Agenda 1) Introduction, admin, statement of objectives of the BOF (10 minutes) Adrian 2) Overview of PCE-based LSP Path computation (5 minutes) JP 3) Requirements for PCE-based path computation (30 minutes) Raymond (Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), Jerry (ATT), Javier (Telefonica),Venkat (MCI) 4) Functional requirements of a PCE-based path computation system (10 minutes) JP 5) Current status of drafts (20 minutes) - Several 6) Discussion points, possible goals and milestones ? Adrian, JP 7) Summary and conclusions ADs, JP, Adrian

  3. Admin and Objectives (10 minutes) Adrian • Blue sheets • Minutes • Agenda bash • Division of labor • JP does technical work • Adrian does admin and policing • At the mic… • Questions for clarification only • Save the rest for open discussion session • Objectives • State the perceived requirements for PCE work • Summarize the work already under way • Is this necessary work? • Is this work for the IETF? • Should there be a new Working Group, and with what scope?

  4. 2) Overview of PCE-based path computation – JP (10 minutes) • Terminology - PCE: entity capable of computing a (partial/full) path/route of a TE LSP •  The PCE may or may not be the head-end LSR •  Can be an LSR, router or a server • PCE  centralized path computation •  *but* includes bothdistributed and centralized path computation models • Examples (distributed / cooperative): distributed FRR backup tunnel path computation in draft-leroux-pce-backup-comp-frwk, distributed inter-domain path computation (see draft-farrel-ccamp-inter-domain-framework and draft-vasseur-ccamp-inter-domain-path-comp (in both scenarios))  PCE=LSR • Examples (centralized): centralized GMPLS TE LSP path (draft-choi-pce-e2e-centralized-restoration-srlg and draft-kompella-mpls-multiarea-te-05.txt (scenario 5)) • May be stateless or statefull • Packet or non-packet, MPLS and GMPLS • The PCE-based approach is *one* approach that can be used so as to solve specific problems (partial visibility, CPU intensive computation, …) and address specific requirements (shortest path, multi-constraints optimality, …) PCS (S=Server) PCE

  5. Requirements for PCE Based Path Computation Raymond Zhang - Infonet

  6. Application scenario 1: end-2-end, protected inter-AS TE LSPs with bandwidth guarantee over delay-optimized multi-AS paths for VoIP and ViIP (conferencing): • Combinations of different TE characteristics in transit ASes makes manual loose-hop configuration for an optimal path difficult or impossible… • Need to dynamically establish inter-AS TE LSPs across RSP and GSP1 or GSP2 with little coordination regarding information on the GSP1/GSP2 internal topology vs. interconnect information between GSP(s)/RSP Attribute Flags set for real-time paths TE metric-optimized for delay in transit ASes Higher interconnect Topological density CE3 Metro-Area Ethernet over SONET/SDH /DWDM GSP1 (AS100) CE1 RSP (AS300) Inter-ASBR path resources and performance not known well within GSPs CustA EMEA HQ CE2 CustA AP HQ CE4 CustA – Customer A GSP – Global SP RSP – Regional SP IGP metric-optimized for delay in transit ASes GSP2 (AS200)

  7. Application scenario 1 (cont.) • For example: CE1 wants to build two TE-LSPs to CE3: voip and viip over RSP and GSP1 or GSp2 via any of two PE-CE links: • Delay-optimized over real-time (i.e. jitter sensitive) paths • with the following two different sets of constraints: preemption, CT and bw (voip – subpool; viip-global pool) If PCEs in RSP don’t have paths, queries sent to PCEs in other ASes… R-PE1 propgates queries R-ASBR1 and 2 (PCE) CE1(PCC) sends two requests for T1&T2 destined to CE3 R-ASBR1 G1-ASBR1 R-PE1 G1-PE1 CE3 G1-ASBR2 GSP1 (AS100) CE1 RSP (AS300) T1-VoIP CustA EMEA HQ R-ASBR2 CE2 T2-ViIP R-PE2 R-ASBR3 G2-ASBR1 CustA AP HQ CE4 G2-ASBR2 G2-PE1 ERO1(voip): R-PE1(L):G-ASBR1(L):CE3(L) ERO2(viip): R-PE2(L):G2-ASBR2(L):CE4(L):CE3(L) GSP2 (AS200)

  8. Requirements for PCE-based path computation KDDI Corporation Kenji Kumaki ke-kumaki@kddi.com 60th IETF PCE BOF@SanDiego

  9. Requirements for PCE-based path computation • Multi-ASes, inter-SP environments • Shortest end to end path • For voice traffic • Reoptimization for inter-AS TE LSPs • If FRR acts, end to end path isn’t necessarily shortest path. • Multi-IGP areas environments • Scalability for inter-area TE LSPs • Shortest end to end path • For voice traffic • Reoptimization for inter-area TE LSPs • If FRR acts, end to end path isn’t necessarily shortest path.

  10. Why do we need a PCE-basedpath computation? • Multi-ASes, inter-SP environments • It is difficult to get a shortest end to end path through multi-ASes. • Head-end router doesn’t have TE information about all of the links between Head-end and Tail-end. (Tail-end lies in a separate AS.) • Multi-IGP areas environments • We’d like to establish inter-area TE LSPs between many routers, but we face scalability issues because of routing and signaling overhead. • It is difficult to get a shortest end to end path through multi-IGP areas. • Head-end router doesn’t have TE information about all of the links between Head-end and Tail-end. (Tail-end lies in a separate area.)

  11. Motivations for PCE Based Path Computation J.L. Le Roux, France Telecom

  12. Head-End CSPF based computation • Head-End CSPF based computation is sufficient in most cases for the placement of TE-LSPs • On-demand independent path computation done by Head-End LSRs • Simplicity, scalability, robustness • However, there are some particular cases, where TE-LSP computation cannot rely on a Head-End CSPF based computation • Some Complex routing problems requiring high CPU & Memory consuming heuristics: • Steiner tree computation for P2MP MPLS (NP-hard) • Multi constraints path computation like e.g. bounded delay minimum cost path (NP-hard) • Backup Path Computation for bandwidth protection: • It is difficult to achieve bandwidth sharing between backup tunnels protecting independent facilities • No coordination between PLRs => Potential inability to find a backup tunnel placement even if such a placement exist • Inter-domain path computation: • Cannot rely on CSPF that requires the full graph in order to compute an end-to-end shortest path or a diverse path

  13. Usefulness of PCE-based computation • Useful for complex routing problems (Multi Constraints, Steiner…) • PCE = Dedicated tool with whole CPU and memory dedicated to path computation • Useful for inter-domain e2e shortest/diverse paths computation • Centralized Computation = A PCE for the whole domain • Collaborative computation = A PCE per area/AS (ABR or ASBR) • Recursive CSPF computation • Useful for backup-path computation • Backup path computed by a PCE • Centralized PCE or distributed PCE (an LSR is a PCE for its own protection) • Allows for complete bandwidth sharing and thus significant bandwidth savings • Coordinated computation that maximizes the likeliness to find a backup tunnel placement when such a placement exist • See draft-leroux-pce-backup-comp-frwk-00

  14. Several High-Level requirements • Reliable LSR-PCE signaling: • Acknowledgement… • Automatic discovery of PCEs and their capabilities • Scalability: • Balancing of Path Computation load between PCEs • Distribute PCE function as far as possible • For backup path computation the PCE can be the protected node itself • High Availability: • Redundancy with backup PCEs… • PCE load balancing • Robustness: • Control of the computation time, to allow for rapid convergence in case of topology change • Controlled tradeoff computation time vs. optimality

  15. Potential Application of PCE Jerry Ash (ATT)

  16. migration of AT&T architecture • converged voice/data IP/MPLS global network • legacy TDM voice to VoIP • QoS CAC with RSVP-TE (DSTE/MAR) (NOTE: not committed) • PCE for inter-area/AS/SP TE (NOTE: not committed) • architecture needs • very large scale network  scalability for TE • multiple OSPF areas & multiple AS’s  inter-area & inter-AS TE • network efficiency  desire for shortest TE paths across areas/AS’s • needs support adoption of PCE approach • network-wide view needed to provide realistic grooming • SP desire for standards-based interoperable solutions

  17. Requirements for PCE-based P2MP TE path computation Seisho Yasukawa NTT (yasukawa.seisho@lab.ntt.co.jp)

  18. Basic backgrounds for P2MP TE • P2MP APL requests P2MP forwarding path with various topologies. • IP-TV service with high data volume provided by streaming technology require cost minimum P2MP path. • Video conference service require delay bounded P2MP path. • Need wide variety of path computation algorithm (cost minimum tree, delay minimum tree, delay bounded cost minimum tree etc.). • Need CPU intensive path computation (Dijkstra, PRIM, KMB, Kompella etc) • P2MP APL requests sophisticated P2MP Traffic Engineering techniques. • P2MP backup/load sharing path requires P2MP diverse path computation. • Several P2MP grafting operations request P2MP path modification considering various constrains (e.g. cost/delay). • Inter-domain P2MP transmission requires P2MP path computation over multiple domains. • Need wider communication/coordination between path computation elements over multiple domains.

  19. High level requirements for PCE-based P2MP TE path computation • Capability to implement multiple P2MP path calculation algorithms/ mechanisms and to select appropriate algorithm/mechanism based on computation demands. • Support reliable LSR-PCE signaling. • Support PCE in a centralized and distributed manner. • Capability to calculate a P2MP path by coordinating multiple PCEs. • Detect P2MP capability (P2MP signaling/forwarding support) of LSRs. • Support load balancing between multiple PCEs. • Capability to hold calculated P2MP path information. • Capability to synchronize TEDB/LSDB between PCE and LSR.

  20. PCE requirements Venkata Josyula – MCI

  21. Inter-AS LSP with hierarchical IGPs within each AS ASy ASz ASx

  22. Considerations • Multiple ASes owned by a single business entity • Hierarchical IGP within each AS • Requirements • Optimal within each AS, not necessarily across the entire path • PCE based approach within each individual AS • No additional Traffic Engineering Policy exchange between the various ASes • TE domain would be restricted to each individual AS • Choice of multiple LSP exit points for each AS could match the Layer 3 exit points • Evaluate complexity versus end-to-end optimality for the inter-AS LSP

  23. 4) Functional requirements of a PCE-based path computation system (10 minutes) JP • Path computation models: Distributed Backup tunnel path comp Inter-domain (cooperative model) * PCE Global opt, GMPLS, CPU-intensive, … Centralized

  24. 4) Functional requirements of a PCE-based path computation system (10 minutes) JP • Discovery of PCE in a network • - Static  Dynamic via IGP/BGP extensions (see OSPF and ISIS capability drafts discussed in OSPF and ISIS WG). Can be used to advertise PCE’caps. • - Allows for load sharing among multiple PCE, PCE survivability (primary, backup), specialized PCE, … • Distribution of information to PCE • - Full: Routing adjacency (overload bit set) to get the LSDB, • - Null: exchange of partially computed path between PCEs without any resource/topology information sharing • LSR-PCE signaling • Clear requirement for a signaling protocol between an LSR (PCC – Path Computation Client) and a PCE. Requirement document to be defined. Currently Multiple solutions have been proposed … Questions: • Re-use of existing RSVP-TE objects to pass constraints ? • Connection oriented versus connectionless ? • Reliable, • … Requirement doc needed ??

  25. 4) Functional requirements of a PCE-based path computation system (10 minutes) JP • Monitoring and management: definition of the set of management objects (number of requests (satisfied (partially or completely) / non-satisfied), PCE availability, PCE response time, … • Policy/Security/Confidentiality: particularly required in the case of inter-domain for both MPLS and GMPLS. • Example: draft-ietf-tewg-interas-mpls-te-req-07.txt related to Inter-AS TE requirements: • “In some cases, policy control might be necessary at the AS boundaries, namely ingress policy controls enabling SPs to enforce the inter-AS policies per interconnect agreements or modify some requested parameters conveyed by incoming inter-AS MPLS TE signaling requests.” (Policy) • The proposed solution(s) MUST address security issues across multiple SP administrative domains (Security, authentication) • Since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the solution MIGHT allow hiding the set of hops used by the TE LSP within an AS as illustrated in the following (Confidentiality)

  26. 5) Current status of drafts (20 minutes) Several • Background and framework • draft-ash-pce-problem-statement-00.txt • draft-farrel-ccamp-inter-domain-framework-01.txt • draft-kompella-mpls-multiarea-te • draft-leroux-pce-backup-comp-frwk-00.txt • Requirements • draft-oki-pce-gmpls-req-00.txt • PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs) • PCE signaling • draft-oki-ccamp-gtep-01.txt • draft-vasseur-mpls-computation-rsvp-05.txt • draft-lee-mpls-path-request-03.txt • Modified TE Flooding • draft-lee-mpls-te-exchange-01.txt • Applications • draft-choi-pce-e2e-centralized-restoration-srlg-00.txt • draft-vasseur-ccamp-inter-domain-path-comp-00.txt * * * Not enough time for each draft … Just the drafts flagged with * will be briefly covered * *

  27. Framework for PCE-based FRR backup path computationdraft-leroux-pce-backup-comp-frwk-00.txt • Context: Computation of FRR Bypass tunnels satisfying capacity constraints • For bandwidth protection purposes • This draft proposes a PCE-based computation model, allowing for complete bandwidth sharing among bypass tunnel protecting independent elements • Both centralized and distributed PCE scenarii are proposed • Centralized PCE that computes all backups for a given area • Distributed PCE: Each LSR computes its own protection • Concept of backup pool + Coordinated placement => no extensions to LSP sig • Concept of SDLG (SRLG Union) to handle links that belong to multiple SRLGs • Support for DS-TE • Protocol specific extensions will be addressed in a separate draft

  28. Requirements for Path Computation Elementin GMPLS and IP/MPLS Networksdraft-oki-pce-gmpls-req-00.txt Aug. 5, 2004 Eiji Oki (NTT) Takashi Kurimoto (NTT) Ichiro Inoue (NTT) Kohei Shiomoto (NTT)

  29. Requirements for Path Computation Element in GMPLS and IP/MPLS Networks draft-oki-pce-gmpls-req-00.txt Requirement overview • Support both GMPLS and IP/MPLS networks • Support functional separation of PCE from GMPLS node • Network providers’ choice of algorithm and implementation • Support two PCE placement scenarios • Centralized/distributed • Support various traffic engineering scenarios (next page) • Multi-region GMPLS TE • Triggered lower-region LSP setup • Virtual (lower-region) network topology reconfiguration • Interworking between GMPLS and IP/MPLS networks • Support functionality including collection of TE-link information (next page)

  30. Detail requirements in TE scenarios and functionality Requirements for Path Computation Element in GMPLS and IP/MPLS Networksdraft-oki-pce-gmpls-req-00.txt • LSP setup • Triggered by higher-region LSP setup • When higher-regionLSP is to be setup, PCEdecides need for new lower-region LSPs should be established (and directs setup optionally). • Triggered by PCE • Virtual network topology (VNT) reconfiguration • Definition: VNT is a collection of various region LSPs treated as a single region network from the view point of a higher region • PCE triggers VNT reconfiguration based on traffic demand change, topology change, and network failure • PCE collects TE-link information • Standard opaque TE information • Reserved LSP bandwidth, GMPLS specific parameters, and protection type and link type • Additional information • Measured traffic volume passing through LSP, LSP route, etc. • Note that other GMPLS constraints should also be considered.

  31. Requirements for Path Computation Element in GMPLS and IP/MPLS Networksdraft-oki-pce-gmpls-req-00.txt Note: Nodal requirements and draft structure • GMPLS nodal requirements • PCE request mode • PCE mandatory request mode • PCE normal request mode • ID structure • Functional separation between PCE and GMPLS node • Traffic engineering scenarios • PCE placement scenarios • PCE functional scenarios • PCE requirements • Nodal requirements

  32. Generalized Traffic Engineering Protocoldraft-oki-ccamp-gtep-00.txt Aug. 5, 2004 Eiji Oki (NTT) Daisaku Shimazaki (NTT) Kohei Shiomoto (NTT)

  33. Generalized Traffic Engineering Protocol (GTEP)draft-oki-ccamp-gtep-00.txtDraft overview • GTEP communicates between PCE and GMPLS node for support of the requirements in “draft-oki-pce-gmpls-req-00.txt” • Features • Support triggered lower-region LSP setup • Support TEDB synchronization between PCE and GMPLS node for virtual-network-topology handling efficiently and correctly • Reliable transfer of large date such as TE-link info. (based on TCP) • Support GMPLS specific parameters such as switching type, encoding type, and GPID, etc. • Can support PCE in a centralized and distributed manner • We have GTEP running codes, which were implemented inour PCE and a commercial GMPLS node.

  34. RSVP Path Computation Request & Reply Messagesdraft-vasseur-mpls-computation-rsvp-05.txt • Extends RSVP so it allows re-use of all existing RSVP & RSVP-TE objects defined for (g)MPLS. • Same objects used to specify constraints • Reliable messaging mechanisms in RSVP can be reused • Minimal new objects required • Path Computation Request/Reply Message • Mandatory Request-ID • Optional objects to manage complex scenarios (e.g. multiple correlated paths for protection) and provide additional constraints. • Draft has considered the numerous scenarios of concern to ensure that the mechanisms are available. Alia Atlas - Avici

  35. Fast End-to-End Restoration Mechanism with SRLG using Centralized Control (draft-choi-pce-e2e-centralized-restoration-srlg-00.txt) PCE BOF (60th IETF) August 5, 2004 San Diego, CA Jun Kyun Choi (jkchoi@icu.ac.kr)

  36. Summary of the draft • Main area of PCE : SRLG based path computation • Network Architecture for centralized Control and Path Computation • The role of the centralized Controller • Network and Control Structure • CP hierarchy architecture for SRLG based P&R • Logical Ring Configuration based on SRLG and PCE • Conceptual aspects of the logical ring with SRLG • Concept of segmentation of the logical ring by the centralized Controller during path computation • Resource allocation with SRLG by the Controller • Underlying key point : Guaranteed disjoint backup path establishment and hence extremely Fast P&R

  37. Conclusion • The draft introduces a centralized path computation model for fast P&R in OTNs using SRLG concepts. • Ring SRLG with the centralized Controller guarantees the survivability of backup paths with constraints to the other logical ring configurations. • Our proposed integrated P&R provisioning scheme simplifies and reduces network management complexity by eliminating cumbersome co-ordination of provisioning in separate network layers • I propose this as a new work item to the new PCE WG. • Future work: • Protocol based P&R mechanisms in the ring • Signaling and Integrated Service Provisioning

  38. 5) IDs under work – JP – 5mn • ID related to PCE-based P2MP TE LSP path computation (Seisho) • ID for LSR-PCE sig required … Could be part of a general PCE requirement document. • IDs related to Inter-domain QoS  draft-mescal-pce-interas-00.txt: discovery of QoS-aware path + establishment of Inter-AS MPLS-based tunnels  draft-mescal-pcp-interas-00.txt: client/server-based protocol (PCP, PCE Communication Protocol) in order to facilitate the service negotiation between two PCE elements.  draft-mescal-pceid-00.txt: mechanism for discovery of PCE elements across Internet at the routing level

  39. 6) Discussion points - Adrian/JP – 20 minutes • Several requirements expressed by SPs … • Should this be IETF work? • What is the scope of the work? • Is this work limited to MPLS TE? • Communication protocol between client and server? • Simple requests or complex constraints? • Communication protocol between servers? • Discovery of servers? • How do servers build their TEDB? • Computation algorithm? • CCAMP or new Working Group ? • Possible charter for a new Working Group ?

  40. 6) Possible Working Group Objectives • Definition of Generalized Traffic Engineered LSP paths computation techniques involving Path Computation Element(s). This includes the intra IGP area, inter IGP area, inter-AS and inter- provider TE LSPs path computation for Point-to-Point, Point-to-Multipoint and Multipoint-to- Multipoint TE LSPs. • Definition of protocol-independent metrics and constraints defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques. • Definition of requirements for communication between LSRs and PCEs including routing extensions in support of PCE discovery techniques within an IGP area and across multiple IGP areas, ASes and Provider networks, and including the development of new protocols or protocol extensions for requesting path computation and supplying responses. Any protocol extensions will developed in conjunction with the working groups in charge of the specific protocols. • Specification of routing (OSPF, ISIS, BGP) and signaling extensions (RSVP-TE) required by PCE-based path computation techniques. The extensions will developed in conjunction with the working groups in charge of the specific protocols. • Specification of requirements and protocol extensions related to the policy, security and confidentiality aspects of PCE-based path computation techniques involving PCEs of multiple Providers. • Definition of MIBs, management procedures related to the protocol extensions defined by the WG

  41. 6) Possible Goals and Milestones • Post straw-man WG goals and charter. • Submit WG document defining the framework and applicability of the PCE model. • Select a single candidate protocol from communication between LSRs and PCEs. • Submit document(s) that define various path computation models. • Submit an analysis document examining the requirements for coherent computation techniques and the implication of cooperation between PCEs. • Submit a document defining the protocol for communication between LSRs and PCEs. • Submit document(s) defining extensions to routing and signaling protocols necessary to support the use of a PCE model within MPLS networks. • Submit a document defining MIB modules for modeling and management of PCE systems.

  42. 7) Summary and conclusion • Next actions…

More Related