Transcript PPT Version

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 Farrel
ADs: Alex Zinin/Bill Fenner
1
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
2
1) Intro, admin, objectives
•
•
•
•
Blue sheets
Minute takers
Agenda bash
At the mic…
– Questions for clarification only
– Save the rest for open discussion session
3
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
4
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
5
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
6
Path Computation Element (PCE)
Architecture
draft-ash-pce-architecture-00.txt
Jerry Ash
AT&T
[email protected]
Adrian Farrel
Old Dog Consulting
[email protected]
JP Vasseur
Cisco Systems, Inc.
[email protected]
Outline
• quick summary
– you read the draft
• issues raised on list
– next step: incorporate comments
7
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
8
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
9
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
10
Composite PCE Node
--------------|
--------| Routing
---------| |
| | Protocol |
|
| |
TED
|<-+----------+->
|
| |
| |
|
|
|
--------|
|
|
|
|
|
|
|
|
| Input |
|
|
|
v
|
|
|
|
--------|
|
|
| |
| |
| Adjacent |
| |
PCE
| |
|
Node
|
| |
| |
|
|
|
--------|
|
|
|
^
|
|
|
|
|Request |
|
|
|
|Response|
|
|
|
v
|
|
|
|
--------|
|
|
Service | |
| | Signaling|
|
Request | |Signaling| | Protocol |
|
------+->| Engine |<-+----------+->
|
| |
| |
|
|
|
--------|
------------------------
11
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
|
------------------12
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
|
---------------------------------
13
Multiple PCE Path Computation
with 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
|
----------------------------
14
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 & PCE15
PCE messages
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
16 ERO
segment
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
17
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
18
4) Existing and new Drafts
• draft-ietf-ccamp-interdomain-framework-0.txt
– Techniques for establishing and controlling (G)MPLS LSPs in multidomain 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
19
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
20
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 ?
21
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.
22
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.
23
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.
24
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 for25interdomain (G)MPLS Traffic Engineering.
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 ?
26
Summary and Conclusions
• Room, Co-chairs, ADs
27
Appendix
28
Requirements for Path Computation Element
in 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
29
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
30
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
31
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-pcearchitecture-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
32
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?
33
Limitations induced by BGP on the computation of inter-AS LSPs
Draft-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 ?
34
– To be addressed during PCE WG next step
Cristel Pelsser - CSE/UCL (Belgium)
[email protected]
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
[email protected]
35
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
36
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
37
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
38
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
AS2
AS1
AS3
AS5
AS4
AS2
AS1
AS3
AS4
AS5
High level view of the domains
The interconnected aggregated domains
as presented at each PCE
Note: Domain and AS is used interchangeably here
=
….
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
39
Bijan Jabbari
Path Computing Element Metric Protocol
(PCEMP) and PCE architecture framework
draft-choi-pce-metric-protocol-00.txt
draft-choi-pce-e2e-centralized-restoration-srlg-01.txt
draft-choi-pce-l1vpn-framework-00.txt
draft-choi-pcemp-ipv6-00.txt
PCE BOF (61st IETF)
November 10, 2004
Washington D.C.
Jun Kyun Choi
([email protected])
40
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)
41
 metric definition and analysis requirements of PCE models
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
42
computation within the scope of the PCE WG Charter
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
43
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
44
PCE issues