1

IETF- 60 – San Diego

Path Computation Element (PCE) BOF

Co-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

1) 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 both distributed 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

GSP1(AS100)

CustA – Customer AGSP – Global SPRSP – Regional SP

GSP2(AS200)

RSP(AS300)

Higher interconnectTopological density

TE metric-optimizedfor delay in transit ASes

Attribute Flagsset for real-time paths

Metro-AreaEthernet overSONET/SDH

/DWDM

CustA AP HQ

CustAEMEAHQ

IGP metric-optimizedfor delay in transit ASes

CE1

CE2

CE4

CE3

Inter-ASBR pathresources andperformancenot known wellwithin GSPs

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)

GSP1(AS100)

GSP2(AS200)

RSP(AS300)

CE1(PCC) sends two requestsfor T1&T2 destined to CE3

If PCEs in RSP don’t have paths, queries sent to PCEs in other ASes…

CustA AP HQ

CustAEMEAHQ

ERO1(voip): R-PE1(L):G-ASBR1(L):CE3(L)ERO2(viip): R-PE2(L):G2-ASBR2(L):CE4(L):CE3(L)

CE1

CE2

CE4

CE3

R-PE1

R-PE2

R-ASBR1

R-ASBR2

R-ASBR3

G1-ASBR1

G1-ASBR2

G2-ASBR1

G2-ASBR2

G1-PE1

G2-PE1

R-PE1 propgates queriesR-ASBR1 and 2 (PCE)

T1-VoIP

T2-ViIP

8

Requirements for PCE-based path computation

KDDI Corporation

Kenji Kumakike-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 Requirements for PCE-based P2MP TE path computationP2MP TE path computation

Seisho YasukawaNTT

(yasukawa.seisho@lab.ntt.co.jp)

18

Basic backgrounds for P2MP TEBasic backgrounds for P2MP TEP2MP 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 High level requirements for PCE-based P2MP TE path computationPCE-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

ASx

ASy

ASz

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:

Centralized

Distributed

* PCE

Inter-domain (cooperative model)

Backup tunnel path comp

Global opt, GMPLS, CPU-intensive, …

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 computation

draft-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 Element

in GMPLS and IP/MPLS Networks

draft-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

• 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)

Requirement overview

30

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-region LSP is to be setup, PCE decides 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.

Detail requirements in TE scenarios and functionality

31

Requirements for Path Computation Element in GMPLS and IP/MPLS Networksdraft-oki-pce-gmpls-req-00.txt

• 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

Note: Nodal requirements and draft structure

32

Generalized Traffic Engineering Protocol

draft-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.txt

Draft 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 in our 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)

Jun Kyun Choi

(jkchoi@icu.ac.kr)

PCE BOF (60th IETF)August 5, 2004San Diego, CA

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…