Download RSVP Path computation request and reply messages

IETF- 60 – San Diego
Path Computation Element (PCE) BOF
Co-chairs: JP Vasseur/Adrian Farrel
ADs: Alex Zinin/Bill Fenner
1
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
2
1)
Admin and Objectives (10 minutes) Adrian
-
Blue sheets
-
Minutes
-
Agenda bash
-
Division of labor
-
-
-
JP does technical work
-
Adrian does admin and policing
At the mic…
-
Questions for clarification only
-
Save the rest for open discussion session
Objectives
-
State the perceived requirements for PCE work
-
Summarize the work already under way
-
Is this necessary work?
-
Is this work for the IETF?
-
Should there be a new Working Group, and with what scope?
3
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
PCS (S=Server) PCE
 *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-vasseurccamp-inter-domain-path-comp (in both scenarios))  PCE=LSR
Examples (centralized): centralized GMPLS TE LSP path (draft-choi-pce-e2ecentralized-restoration-srlg and draft-kompella-mpls-multiarea-te-05.txt (scenario 5))
• May be stateless or statefull
• Packet or non-packet, MPLS and GMPLS
The PCE-based approach is *one* approach that can be used so as to solve
specific problems (partial visibility, CPU intensive computation, …) and
4
address specific requirements (shortest path, multi-constraints optimality, …)
Requirements for PCE Based Path
Computation
Raymond Zhang - Infonet
5
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
Higher interconnect
Topological density
Attribute Flags
set for real-time paths
TE metric-optimized
for delay in transit ASes
CE3
CE1
CE2
Metro-Area
Ethernet over
SONET/SDH
/DWDM
RSP
(AS300)
GSP1
(AS100)
CustA
EMEA
HQ
CE4
CustA AP HQ
CustA – Customer A
GSP – Global SP
RSP – Regional SP
Inter-ASBR path
resources and
performance
not known well
within GSPs
IGP metric-optimized
for delay in transit ASes
GSP2
(AS200)
6
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; viipglobal pool)
R-PE1 propgates queries
R-ASBR1 and 2 (PCE)
CE1(PCC) sends two requests
for T1&T2 destined to CE3
If PCEs in RSP don’t have paths, queries
sent to PCEs in other ASes…
R-ASBR1
G1-ASBR1
R-PE1
G1-ASBR2
CE1
RSP
(AS300) R-ASBR2
GSP1
(AS100)
G1-PE1
T1-VoIP
CE2
T2-ViIP
R-PE2
CustA AP HQ
R-ASBR3
G2-ASBR1
G2-ASBR2
ERO1(voip): R-PE1(L):G-ASBR1(L):CE3(L)
ERO2(viip): R-PE2(L):G2-ASBR2(L):CE4(L):CE3(L)
GSP2
(AS200)
CE3
CustA
EMEA
HQ
CE4
G2-PE1
7
Requirements for PCE-based
path computation
KDDI Corporation
Kenji Kumaki
[email protected]
60th IETF PCE BOF@SanDiego
8
Requirements for PCE-based
path computation
• Multi-ASes, inter-SP environments
– Shortest end to end path
• For voice traffic
– Reoptimization for inter-AS TE LSPs
• If FRR acts, end to end path isn’t necessarily shortest path.
• Multi-IGP areas environments
– Scalability for inter-area TE LSPs
– Shortest end to end path
• For voice traffic
– Reoptimization for inter-area TE LSPs
• If FRR acts, end to end path isn’t necessarily shortest path.
9
Why do we need a PCE-based
path computation?
• Multi-ASes, inter-SP environments
– It is difficult to get a shortest end to end path through multi-ASes.
– Head-end router doesn’t have TE information about all of the links
between Head-end and Tail-end. (Tail-end lies in a separate AS.)
• Multi-IGP areas environments
– We’d like to establish inter-area TE LSPs between many routers,
but we face scalability issues because of routing and signaling
overhead.
– It is difficult to get a shortest end to end path through multi-IGP
areas.
– Head-end router doesn’t have TE information about all of the links
between Head-end and Tail-end. (Tail-end lies in a separate area.)
10
Motivations for
PCE Based Path Computation
J.L. Le Roux, France Telecom
11
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 HeadEnd CSPF based computation
– Some Complex routing problems requiring high CPU & Memory consuming heuristics:
• Steiner tree computation for P2MP MPLS (NP-hard)
• Multi constraints path computation like e.g. bounded delay minimum cost path (NP-hard)
– Backup Path Computation for bandwidth protection:
• It is difficult to achieve bandwidth sharing between backup tunnels protecting independent
facilities
• No coordination between PLRs => Potential inability to find a backup tunnel placement even
if such a placement exist
– Inter-domain path computation:
• Cannot rely on CSPF that requires the full graph in order to compute an end-to-end shortest
path or a diverse path
12
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
13
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
14
Potential Application of PCE
Jerry Ash (ATT)
15
 migration of AT&T architecture
 converged voice/data IP/MPLS global network
 legacy TDM voice to VoIP
 QoS CAC with RSVP-TE (DSTE/MAR) (NOTE: not committed)
 PCE for inter-area/AS/SP TE (NOTE: not committed)
 architecture needs
 very large scale network  scalability for TE
 multiple OSPF areas & multiple AS’s  inter-area & inter-AS TE
 network efficiency  desire for shortest TE paths across
areas/AS’s
 needs support adoption of PCE approach
 network-wide view needed to provide realistic grooming
 SP desire for standards-based interoperable solutions
16
Requirements for PCE-based
P2MP TE path computation
Seisho Yasukawa
NTT
([email protected])
17
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.
18
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.
19
PCE requirements
Venkata Josyula – MCI
20
Inter-AS LSP with hierarchical IGPs
within each AS
ASy
ASx
ASz
21
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
22
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
23
4) Functional requirements of a PCE-based path computation system
(10 minutes) JP
• Discovery of PCE in a network
- Static  Dynamic via IGP/BGP extensions (see OSPF and ISIS capability drafts
discussed in OSPF and ISIS WG). Can be used to advertise PCE’caps.
- Allows for load sharing among multiple PCE, PCE survivability (primary, backup),
specialized PCE, …
• Distribution of information to PCE
- Full: Routing adjacency (overload bit set) to get the LSDB,
- Null: exchange of partially computed path between PCEs without any
resource/topology information sharing
• LSR-PCE signaling
Clear requirement for a signaling protocol between an LSR (PCC – Path
Computation Client) and a PCE. Requirement document to be defined. Currently
Multiple solutions have been proposed … Questions:
• Re-use of existing RSVP-TE objects to pass constraints ?
• Connection oriented versus connectionless ?
Requirement doc needed ??
• Reliable,
24
•…
4) Functional requirements of a PCE-based path computation system
(10 minutes) JP
• Monitoring and management: definition of the set of management objects (number
of requests (satisfied (partially or completely) / non-satisfied), PCE availability, PCE
response time, …
• Policy/Security/Confidentiality: particularly required in the case of inter-domain for
both MPLS and GMPLS.
Example: draft-ietf-tewg-interas-mpls-te-req-07.txt related to Inter-AS TE
requirements:
•“In some cases, policy control might be necessary at the AS boundaries, namely ingress
policy controls enabling SPs to enforce the inter-AS policies per interconnect agreements
or modify some requested parameters conveyed by incoming inter-AS MPLS TE
signaling requests.” (Policy)
•The proposed solution(s) MUST address security issues across multiple SP
administrative domains (Security, authentication)
•Since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the
solution MIGHT allow hiding the set of hops used by the TE LSP within an AS as
illustrated in the following (Confidentiality)
25
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
Not enough time for each
draft …
* •• draft-vasseur-mpls-computation-rsvp-05.txt
draft-lee-mpls-path-request-03.txt
Just the drafts flagged with *
• Modified TE Flooding
will be briefly covered
• draft-lee-mpls-te-exchange-01.txt
• Applications
* • draft-choi-pce-e2e-centralized-restoration-srlg-00.txt
• draft-vasseur-ccamp-inter-domain-path-comp-00.txt
26
Framework for PCE-based FRR backup path computation
draft-leroux-pce-backup-comp-frwk-00.txt
• Context: Computation of FRR Bypass tunnels satisfying capacity constraints
– For bandwidth protection purposes
• This draft proposes a PCE-based computation model, allowing for complete
bandwidth sharing among bypass tunnel protecting independent elements
• Both centralized and distributed PCE scenarii are proposed
– Centralized PCE that computes all backups for a given area
– Distributed PCE: Each LSR computes its own protection
•
•
•
•
Concept of backup pool + Coordinated placement => no extensions to LSP sig
Concept of SDLG (SRLG Union) to handle links that belong to multiple SRLGs
Support for DS-TE
Protocol specific extensions will be addressed in a separate draft
27
Requirements for Path Computation
Element
in GMPLS and IP/MPLS Networks
draft-oki-pce-gmpls-req-00.txt
Aug. 5, 2004
Eiji Oki (NTT)
Takashi Kurimoto (NTT)
Ichiro Inoue (NTT)
Kohei Shiomoto (NTT)
28
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)
29
Requirements for Path Computation Element in GMPLS and IP/MPLS Networks
draft-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.
30
• Note that other GMPLS constraints should also be considered.
Requirements for Path Computation Element in GMPLS and IP/MPLS Networks
draft-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
31
Generalized Traffic Engineering Protocol
draft-oki-ccamp-gtep-00.txt
Aug. 5, 2004
Eiji Oki (NTT)
Daisaku Shimazaki (NTT)
Kohei Shiomoto (NTT)
32
Generalized Traffic Engineering Protocol (GTEP)
draft-oki-ccamp-gtep-00.txt
Draft overview
• GTEP communicates between PCE and GMPLS node for
support of the requirements in “draft-oki-pce-gmplsreq-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.
33
RSVP Path Computation Request & Reply Messages
draft-vasseur-mpls-computation-rsvp-05.txt
• Extends RSVP so it allows re-use of all existing RSVP
& RSVP-TE objects defined for (g)MPLS.
– Same objects used to specify constraints
– Reliable messaging mechanisms in RSVP can be reused
• Minimal new objects required
– Path Computation Request/Reply Message
– Mandatory Request-ID
– Optional objects to manage complex scenarios (e.g. multiple
correlated paths for protection) and provide additional
constraints.
• Draft has considered the numerous scenarios of
concern to ensure that the mechanisms are available.
Alia Atlas - Avici
34
Fast End-to-End Restoration
Mechanism with SRLG using
Centralized Control
(draft-choi-pce-e2e-centralizedrestoration-srlg-00.txt)
PCE BOF (60th IETF)
August 5, 2004
San Diego, CA
Jun Kyun Choi
([email protected])
35
Summary of the draft
▣ Main area of PCE : SRLG based path computation
▣ Network Architecture for centralized Control and Path
Computation
 The role of the centralized Controller
 Network and Control Structure
 CP hierarchy architecture for SRLG based P&R
▣ Logical Ring Configuration based on SRLG and PCE
 Conceptual aspects of the logical ring with SRLG
 Concept of segmentation of the logical ring by the
centralized Controller during path computation
 Resource allocation with SRLG by the Controller
▣ Underlying key point : Guaranteed disjoint backup
path establishment and hence extremely Fast P&R
36
Conclusion
▣ The draft introduces a centralized path computation
model for fast P&R in OTNs using SRLG concepts.
▣ Ring SRLG with the centralized Controller guarantees
the survivability of backup paths with constraints to
the other logical ring configurations.
▣ Our proposed integrated P&R provisioning scheme
simplifies and reduces network management
complexity by eliminating cumbersome co-ordination
of provisioning in separate network layers
▣ I propose this as a new work item to the new PCE WG.
▣ Future work:
 Protocol based P&R mechanisms in the ring
 Signaling and Integrated Service Provisioning
37
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
38
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 ?
39
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 interprovider TE LSPs path computation for Point-to-Point, Point-to-Multipoint and Multipoint-toMultipoint 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
40
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.
41
7) Summary and conclusion
- Next actions…
42