IETF-%2060%20

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 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)) ? PCELSR
• Examples (centralized) centralized GMPLS TE LSP
  path (draft-choi-pce-e2e-centralized-restoration-s
  rlg 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 (SServer)? 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

TE metric-optimized for delay in transit ASes
Attribute Flags set for real-time paths
Higher interconnect Topological density
CE3
GSP1 (AS100)
Metro-Area Ethernet over SONET/SDH /DWDM
RSP (AS300)
CE1
CustA EMEA HQ
Inter-ASBR path resources and performance not
known well within GSPs
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 dont have paths, queries sent to
PCEs in other ASes
R-PE1 propgates queries R-ASBR1 and 2 (PCE)
CE1(PCC) sends two requests for T1T2 destined to
CE3
R-ASBR1
G1-ASBR1
R-PE1
CE3
G1-PE1
G1-ASBR2
GSP1 (AS100)
RSP (AS300)
CE1
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_at_kddi.com
• 60th IETF PCE BOF_at_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 isnt 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 isnt 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 doesnt 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
• Wed 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 doesnt 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 gt 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 ATT 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 ASs ? inter-area
  inter-AS TE
• network efficiency ? desire for shortest TE paths
  across areas/ASs
• 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_at_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 PCEcaps.
• - 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.tx
  t 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-0
  0.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.t
xt

• 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 gt
  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-re
q-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
Requirements for Path Computation Element in
GMPLS and IP/MPLS Networksdraft-oki-pce-gmpls-req
-00.txt
Detail requirements in TE scenarios and
functionality

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

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-gmpl
  s-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.tx
t

• 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-cen
tralized-restoration-srlg-00.txt)
PCE BOF (60th IETF) August 5, 2004 San Diego, CA
Jun Kyun Choi (jkchoi_at_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 PR
• 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 PR

37
Conclusion

• The draft introduces a centralized path
  computation model for fast PR 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 PR 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 PR 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