IETF-61

1
IETF-61 Washington DCPath
Computation Element (PCE) BOF-2Slides can be
found athttp//rtg.ietf.org/bof/pce/pce-bof-2.ppt
Co-chairs JP Vasseur/Adrian FarrelADs 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, ATT, 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

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
Adrian Farrel Old Dog Consulting adrian_at_olddog.co.
uk
JP Vasseur Cisco Systems, Inc. jpv_at_cisco.com
Jerry Ash ATT gash_at_att.com
Outline

• quick summary
• you read the draft
• issues raised on list
• next step incorporate comments

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 Computationwith 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 Elementin
GMPLS and IP/MPLS Networksdraft-oki-pce-gmpls-re
q-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 2004.

draft-oki-ccamp-gtep-01.txt
33
Path Computation Model for Recovery LSPs Using
External PCEdraft-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 LSPsDraft-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 (Belgium)
Pelsser_at_info.ucl.ac.be
35
A PCE-based Approach for providing inter-AS
MPLS-based QoS tunnelsdraft-boucadair-pce-intera
s-00.txt draft-boucadair-pcp-interas-00.txt
draft-boucadair-pce-discovery-00.txtPCE
BOF-November 2004

• Mohamed BOUCADAIR
• mohamed.boucadair_at_francetelecom.com

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

High level view of the domains
The interconnected aggregated domains as
presented at each PCE
Bijan Jabbari
Note Domain and AS is used interchangeably here
40
Path Computing Element Metric Protocol (PCEMP)
and PCE architecture framework
draft-choi-pce-metric-protocol-00.txtdraft-choi-p
ce-e2e-centralized-restoration-srlg-01.txtdraft-c
hoi-pce-l1vpn-framework-00.txtdraft-choi-pcemp-ip
v6-00.txt
PCE BOF (61st IETF) November 10, 2004 Washington
D.C.
Jun Kyun Choi (jkchoi_at_icu.ac.kr)
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 PR
• 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 PR
  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