1 ietf-61 – washington dc path computation element (pce) bof-2 slides can be found at co-chairs:...
TRANSCRIPT
1
IETF-61 – Washington DC
Path Computation Element (PCE) BOF-2
Slides can be found at
http://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, AT&T, FT, NTT, MCI)• Several distinct problems being solved
– Shortest inter-area/AS/SP TE LSP path– Diverse path computation (intra and inter domain)– Complex constraints
• Delay optimization• Optical constraints
– Sophisticated computation requirements• Multiple diverse paths (protection and load sharing)• Re-optimization• Minimal pre-emption• Point-to-multipoint
– Common theme is MPLS TE LSP path computation• Prevailing sub-text is inter-domain computation
• Unclear on what needs to be specified (i.e. what is the scope of the work?)
• Need for clear architectural specification
• Directive from AD– Write architecture– Narrow the scope of work– Draft charter
6
Consensus on CCAMP mailing listCCAMP 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.txtJerry AshAT&[email protected]
Adrian FarrelOld Dog [email protected]
JP VasseurCisco Systems, [email protected]
• quick summary– you read the draft
• issues raised on list– next step: incorporate comments
Outline
8
Terminology• path computation element (PCE)
– entity (component, application or network node) capable of computing a network path based on network graph & computational constraints
– e.g., PCE computes path of a TE LSP by using TED & bandwidth/other constraints
• path computation client (PCC)– any client application requesting a path computation by the PCE
• domain– any collection of network elements within a common sphere of address management or path
computational responsibility– e.g., IGP areas, AS, multiple ASs within a SP network, multiple ASs across multiple SP networks
• single PCE path computation: single PCE computes a path in a domain• multiple PCE path computation: multiple PCEs compute a path in a domain• centralized computation model: all paths in a domain computed by a single, centralized
PCE• distributed computation model: computation of paths in a domain shared among multiple
PCEs
9
Assumptions• PCE may or may not be located at head-end
– e.g. nodes on path contribute to path computation (e.g., loose hops) making them PCEs– path computation may be made by PCE physically distinct from the computed path
• path computed by PCE may be– complete: full explicit path of strict hops– partial: mix of strict & loose hops (may be an abstract node such as an AS)
• PCE path computation can be used in conjunction with other path computation models– e.g., inter-AS TE LSP may be computed using PCE in some domains but not others
• no assumptions made about PCE implementation– e.g., could be implemented on a router, LSR, dedicated network server, etc.– PCE function independent of forwarding capability of node on which it is implemented
10
Motivation for PCE Architecture
• inter-area/AS optimal path computation (node has partial visibility) • computation of inter-area/AS diverse path (node has partial
visibility) • CPU-intensive path computation/global optimization • backup path computation for bandwidth protection with backup
capacity optimization • multi-layer networks e.g. TDM network provides connectivity for
client-layer (IP, MPLS, L2, etc.) • absence of TED or use of non-TE-enabled IGP • node outside routing domain (e.g., CE to PE path computation) • network element lacks control plan or routing capability
11
Composite PCE Node
--------------- | --------- | Routing ---------- | | | | Protocol | | | | TED |<-+----------+-> | | | | | | | | --------- | | | | | | | | | | Input | | | | v | | | | --------- | | | | | | | | Adjacent | | | PCE | | | Node | | | | | | | | --------- | | | | ^ | | | | |Request | | | | |Response| | | | v | | | | --------- | | | Service | | | | Signaling| | Request | |Signaling| | Protocol | | ------+->| Engine |<-+----------+-> | | | | | | | | --------- | ---------- ---------------
12
External PCE Node
---------- | ----- | | | TED |<-+------------> | ----- | TED synchronization | | | mechanism (for example, routing protocol) | | | | v | | ----- | | | PCE | | | ----- | ---------- ^ | Request/ | Response v Service ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | ---->| Node |<---------->| Node | ---------- ----------
13
Multiple PCE Path Computation
---------- ---------- | | | | | PCE | | PCE | | | | | | ----- | | ----- | | | TED | | | | TED | | | ----- | | ----- | ---------- ---------- ^ ^ | Request/ | Request/ | Response | Response v v Service ---------- Signaling ------------- Signaling ------------ Request| Head-End | Protocol |Intermediate | Protocol |Intermediate| ---->| Node |<---------->| Node |<--------->| Node | ---------- ------------- ------------
14
Multiple PCE Path Computationwith Inter-PCE Communication
---------- ---------- | | Inter-PCE Request/Response | | | PCE |<--------------------------------->| PCE | | | | | | ----- | | ----- | | | TED | | | | TED | | | ----- | | ----- | ---------- ---------- ^ | Request/ | Response v Service ---------- Signaling ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | ---->| Node |<---------->| Node |<---------->| Node | ---------- ---------- ----------
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 CharterProposed 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 CharterProposed 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 CharterProposed 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 CharterProposed 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 Networks
draft-oki-pce-gmpls-req-01.txt
Nov. 10, 2004
Eiji Oki (NTT)Takashi Kurimoto (NTT)
Ichiro Inoue (NTT)Kohei Shiomoto (NTT)
draft-oki-pce-gmpls-req-01.txt
30
Requirement draft target
• Scope in the proposed WG milestone– “Submit a requirements draft describing the function
necessary for the use of PCE to compute the paths of inter-domain (G)MPLS TE LSPs.”
• Ready to make a PCE requirement draft based our draft.
• Describes MPLS and GMPLS TE scenarios and requirements.
• Feedbacks are welcome.
draft-oki-pce-gmpls-req-01.txt
31
Generalized Traffic Engineering Protocol(GTEP)
draft-oki-ccamp-gtep-01.txt
Nov. 10, 2004
Eiji Oki (NTT)Daisaku Shimazaki (NTT)
Kohei Shiomoto (NTT)
draft-oki-ccamp-gtep-01.txt
32
GTEP draft target
• GTEP communicates between PCC and PCE • Scope in the proposed WG milestone
– “Submit a draft of a communication protocol for use between a PCC and a PCE, and between PCEs.”
• Scope in the architecture draft, “draft-ash-pce-architecture-00.txt”– Section 6.6. PCC-PCE & PCE-PCE Communication
– Section 6.7. PCE TED Synchronization– Section 6.8. Stateful Versus Stateless PCEs
• GTEP running code was demonstrated in a public event in 2004.
draft-oki-ccamp-gtep-01.txt
33
Path Computation Model for Recovery LSPs Using External PCE
draft-ogino-pce-recovery-pc-model-00.txt
• This draft proposes a path computation model for recovery LSPs in the shared mesh restoration.
– This model uses external PCE that exclusively preserves complete TE information within a domain.
– This model can promote bandwidth sharing between recovery LSPs without any extension of the present IGP-TE.
• Prerequisites of this model Network state recognized by the external PCE is identical to real network state at any
time.– Recovery LSPs are certainly established along the routes computed by the external
PCE.– External PCE is always notified when the recovery LSPs are released.
• Scalability problems of this model– Domain size should be decided based on the capacity of centralized PCE.– Fast synchronization of TE information is required between distributed PCEs.
• Starting point for the framework document of GMPLS-based recovery path computation?
34
Limitations induced by BGP on the computation of inter-AS 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) [email protected]
35
A PCE-based Approach for providing inter-AS MPLS-based QoS tunnels
draft-boucadair-pce-interas-00.txt draft-boucadair-pcp-interas-00.txt
draft-boucadair-pce-discovery-00.txt
PCE BOF-November 2004 Mohamed BOUCADAIR
36
Inter-Domain QoS• Ensure QoS for emerging applications like
– Inter-provider VoIP services • Enterprise VoIP• PSTN migration to VoIP
– Inter-provider IP VPNs
• Provide hard guarantees for mission critical applications– Traffic Isolation– Bandwidth reservation– Network Availability– Resiliency
• Extend QoS service offering beyond a single provider boundaries
• Establish inter-domain QoS-driven MPLS TE tunnels
37
Inter-Domain TE LSP
• Each SP deploys at least one PCE per domain
• PCE functions– Compute an inter-domain constrained path
– Negotiate inter-domain contracts along AS-path for the computed TE LSP
– When agreement is end-to-end reached,• Establish inter-domain TE LSP
38
Draft contents• Describes a solution for offering inter-provider end to end QoS-based
services– Highlights service considerations in order to ease inter-provider cooperation
• draft-boucadair-pce-interas-00.txt– Specifies PCE functions and interfaces– Describes inter-domain routing features– Suggest PCE to LER communication means
• draft-boucadair-pcp-interas-00.txt– Describes PCE to PCE communication
• draft-boucadair-pcp-interas-00.txt– Describe a Path Computation Service Discovery mechanism
39
Aggregation-based Inter-AS (Domain) TE Path Computation (B. Jabbari)
1. PCE in each domain computes the aggregated model and communicates it to other PCEs dynamically or after a threshold change
2. For an LSP request in a domain, the PCE in that domain computes up to the K Shortest Paths (KSPs)3. If constraints cannot be satisfied, the request may be denied immediately4. Otherwise, while establishing the TE path, the KSPs are evaluated for path optimality in each domain
Aggregated domain span
= ….
An abstract model for representation of topology, resources and constraints of each domain
Abstraction may span a virtual node to full network
Bijan Jabbari
High level view of the domainsThe interconnected aggregated
domainsas presented at each PCE
AS1AS2
AS3
AS4 AS5
AS1
AS2
AS3
AS4 AS5
Note: Domain and AS is used interchangeably here
40
Path Computing Element Metric Protocol (PCEMP) and PCE architecture framework
Jun Kyun Choi
PCE BOF (61st IETF)November 10, 2004Washington D.C.
draft-choi-pce-metric-protocol-00.txtdraft-choi-pce-e2e-centralized-restoration-srlg-01.txt
draft-choi-pce-l1vpn-framework-00.txtdraft-choi-pcemp-ipv6-00.txt
41
draft-choi-pce-metric-protocol-00.txt
▣ Scope of the draft and PCE BOF: Analysis of a Path Computation Element Metric Protocol (PCEMP)
▣ Main functionalities of PCEMP: PCEMP acts as a generic computational model for path based
metrics in large multi-domain or multi-layer networks Protocol mechanism can serve as an application path
computation framework for any PCE
▣ Protocol architecture and PCE architecture framework Implementation considerations of the PCEMP protocol state
machines within the PCE framework scope Analysis of PCEMP metrics in terms of protocol cost
▣ Underlying key point : Addresses inter-domain partitioning and management issues through the concept of PCE peers drafted by PCEMP
▣ Conclusion: draft issues and new PCE WG: protocol metrics for an inter-domain PCE framework (path
quality measurement criteria, algorithm complexity, scalability) metric definition and analysis requirements of PCE models
42
draft-choi-pce-e2e-centralized-restoration-srlg-01.txt
▣ Scope of the draft and PCE BOF: Use of ring SRLG for PCE based backup path computation
▣ PCEMP protocol for distributing PCE mapping table▣ PCE architecture framework in guaranteed disjoint backup
path establishment using ring SRLGs Network and control structure framework in the scenario of
PCEMP and fast P&R
▣ Architectural framework for PCE-based backup path computation using SRLG Segmentation of the logical ring during path computation
▣ Underlying key point : Guaranteed disjoint backup path establishment and hence extremely fast P&R in PCE peers
▣ Conclusion: draft issues and new PCE WG: Mechanism for integrated provisioning and protection for the
purpose of fast backup path computation Possibility of explicitly including PCE-based backup path
computation within the scope of the PCE WG Charter
43
draft-choi-pce-l1vpn-framework-00.txt
▣ Scope of the draft and PCE BOF: Path computation framework in management systems for Layer 1 VPNs
▣ Viewpoint of PCEMP in large multi-domain networks▣ Path computation fundamentals applicable to dynamic L1
provisioning Network, control structure, inter-domain segmentation
framework using PCEMP Complete network topology for L1 VPN networks: A PCE
perspective
▣ Underlying key point : A path computation technique based architecture for dynamic L1 VPN provisioning
▣ Conclusion: draft issues and new PCE WG: Per VPN peer solutions using PCE techniques Functional specifications of Generalized Traffic Engineered
LSP path computation techniques involving Path Computation Element (s) in the PCE WG Charter
44
draft-choi-pcemp-ipv6-00.txt
▣ Scope of the draft and PCE BOF: Router handling improvement procedures on individual PCE nodes
▣ Fast PCE peer advertisement▣ Fast processing of PCE peer solicitations
PCE peer architecture as “seen” by PCEMP Configuration of PCE peers for fast processing of solicitations
▣ Underlying key point : The PCEMP architecture enables the corresponding PCE peers to exchange information tags instantaneously upon discovery at any point of time – less inter-domain path computation response time
▣ Conclusion: draft issues and new PCE WG: Guideline to specifications of modifying existing protocols to
facilitate communication between LSRs, PCEs and PCE peers Concept of sync of information between PCE nodes in case of
a change in the PCE Domain Area can help in fast default PCE peer acquisition
PCE peers capable of being “soft-configured” in inter-domain PCE issues