Transcript Path Computation Element : A Retrospective and Some Predictions

Path Computation Element
A Retrospective and Some Predictions
Adrian Farrel
Juniper Networks
iPOP2013, Tokyo, Japan
Agenda
•
•
•
•
•
•
History of path computation
Introducing the Path Computation Element
Where are we now?
What are we working on?
The philosophical debate : what PCE is not
Next developments
– TE collection and aggregation
– PCE in SDN
• The future of PCE
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 2
Path Computation Starts with Graph Theory
• In 1735 Leonhard Euler wanted to send a single OAM
packet to test all of the fibres in the Königsberg metro
area network
– He was able to prove it couldn’t be done
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 3
Shortest Path First
• In 1956 Edsger Dijkstra wanted to find the shortest way
home from the coffee house
– Least hops quickly leads to per-hop metrics
– Dijkstra’s algorithm is embedded in OSPF and IS-IS so that all
nodes in the network make the same forwarding assumptions
– SPF is quick to compute even in very large networks
10
15
10
9
10
10
8
5
8
7
4
2
4
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 4
Constraint-based Shortest Path First
• Traffic Engineering is fundamental to planned networking
– Constraints may be per-hop (for example, bandwidth or lambda
continuity)
• Processing is simple pruning of the graph before or during SPF
– Constraints may be cumulative (for example, delay)
• Processing is just like SPF with multiple counters
– CSPF is quick to compute even on complex networks with multiple
constraints
10
15
10
9
10
10
8
5
8
7
4
2
4
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 5
Multi-Path Problems
• The classic “fish” problem of ordered provisioning
• Diverse routes for protection paths
• More sophisticated algorithms
– k-shortest paths
– Linear programming
5 MB Demand
5 MB Link
10 MB Link
7 MB Demand
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 6
Point-to-Multipoint
• Strikingly complex problems
• Different optimization criteria
– Shortest path to each destination
– Least cost tree
• Many sophisticated algorithms exist
• Fun to combine with multi-path problems
5
4
iPOP2013, Tokyo, Japan
3
3+2+2=7
Copyright © Juniper Networks 2013 Page 7
What Do We Know?
• There are lots of path computation problems in networking
• Many problems can be solved off-line
– Service planning
– Plenty of time
– Even failure cases can be pre-planned
• Many problems take considerable computation resources
• Increasing demand for on-line or rapid response
– Not all problems can be solved like this
– Network nodes (routers and switches)
• Do not have big CPUs
• Do not have spare memory
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 8
So Why Was PCE Invented?
• All of these problems point to the use of dedicated path
computation resources (i.e., servers)
• But PCE was invented for a completely different reason
• Aimed to solve a very specific problem
– Find an MPLS-TE path to a virtual PoP
– I can see in my domain, but not into my peer’s
– Which exit-point should I choose?
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 9
Remind Me : What is PCE?
• PCE: Path Computation Element. An entity (component,
application, or network node) that is capable of computing
a network path or route based on a network graph and
applying computational constraints – RFC 4655
– This does not say it is a dedicated server
– It can be embedded in a router
– It can be embedded in every router
• For virtual PoP use case
– PCE function in head-end LSR for local domain
– PCE function in remote ASBR accessed through remote call
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 10
And Remind Me : What is a Domain?
• A domain is any collection of network elements within a
common sphere of address management or path
computation responsibility. Examples of domains include
IGP areas, Autonomous Systems (ASes), and multiple
ASes within a Service Provider network. Domains of path
computation responsibility may also exist as sub-domains
of areas or ASes. – RFC 4655
• A PCE computes paths for a domain because a domain is
what a PCE computes paths for
• For virtual PoP use case the domain was an AS
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 11
So What Have We Built and Deployed?
•
Packet networks have not been a roaring success for PCE
– Initially, only Cisco implemented
– It is implemented and deployed
– Main use cases are
• Dual-homed IGP areas
• Centrally controlled TE domains
•
There is a huge amount of research and experimentation
– More than 20 projects funded by the EU have PCE as a core component
– A number of operators have experimented in depth
•
Commercial and Open Source Implementations
– Software stacks from Metaswitch and Marben
• But these are PCEP implementations, not full PCEs
– Several Open Source implementations exist
– Hardware vendors
– Network operators
•
The best take-up for PCE so far is in optical networks
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 12
PCE in the Optical Network
• Optical networks have an interesting set of characteristics
–
–
–
–
–
Low arrival rates and long hold times for LSPs
Scarce resource/flow ratio
Small domains
Vendor-specific behaviour
Small on-board processors
• These make PCE a very attractive solution
– PCE for a single domain has value
• Complex constraint computation
• Interaction with network management
• Planning of protection paths
• Optimising for multiple LSPs competing for resources
– PCE provides an answer for interconnected micro-domains
• Per-domain and backward-recursive computation techniques
• Hierarchical PCE
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 13
What Are We Coding and Testing Now?
•
•
•
•
Vendor constraints
– An old Internet-Draft now reaching completion (draft-ietf-pce-vendor-constraints)
– Allows standards-based PCEP implementation with vendor-specific hardware
– Particularly handy for optical equipment
GMPLS extensions
– Surprising that this is still under development?
– Most things work fine already
– Some gap filling needed for special or minor cases (draft-ietf-pce-gmpls-aps-req)
• Additional TE quality constraints (e.g., VCAT or single channel)
• Adaptation capabilities
• Asymmetric bandwidth
• etc.
Hierarchical PCE
– The architecture is done (RFC 6805)
– Solutions work progresses with implementations (draft-zhang-pce-hierarchy-extensions)
Stateful PCE
– Architecture, requirements and protocol (draft-ietf-pce-stateful-pce)
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 14
Hierarchical PCE
• The darling of conference presentations for the last four or
five years
• Already implemented and being experimented with
– Particularly for optical networks
• Navigating a mesh of small domains
• Optimising multi-layer networks (especially IP-over-optical)
• Makes sense when all domains under one administration
– No questions of information sharing or security
– Separation is for operational reasons
– Partition may allow vendor specialisation
• Who owns a PCE in a multi-administrator system?
– A Path Computation Broker?
– Or is it all governed by policy?
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 15
Stateful PCE
• The latest hot topic here and at other conferences
• The main difference is knowledge of LSPs
– The state in “stateful” is an LSP-DB
– Information about some or all LSPs in the network
• This empowers more sophisticated path computation
• Also allows PCE to selectively recommend reoptimisation
• New PCEP messages to:
– Report LSP state
– Delegate LSP control to the PCE
– Recommend rerouting of LSPs
• Multiple implementations in hand
– Service providers ready to test
• I will not steal the thunder of other iPOP presenters
– But it does raise some questions for me…
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 16
A Philosophical Interlude
• All good philosophical debates have two sides
• The question we have to ask is:
What is the functional boundary of PCE?
Raichō Hiratsuka 平塚 らいてう
• The purist says:
A PCE is only a computation engine. It may
be remote and accessed by PCEP. Or it may
be built into some other network component.
• The idealist says:
The name PCE can be given to a network
component that includes path computation,
the TED and the LSP-DB, and which can do Akiko Yosano 与謝野 晶子
a number of other functions, too.
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 17
The Idealist Model
• Stateful PCE makes this model much more popular
• Path computation is just one of the functions of PCE
PCE
Configuration
Provisioning
Management
Planning
Recovery
Reoptimisation
Computation
Request/Response
TE Info Collection
Inventory Info
Alarms
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 18
The Purist Model
• PCE is the hub
• But PCE only performs computations
Service
Calendaring
OSS
Alarm Management
System
NMS
EMS
iPOP2013, Tokyo, Japan
PCE
Copyright © Juniper Networks 2013 Page 19
TED
LSP-TB
Inventory
Another Philosophical View – PCE as God
• There is a range of
theologies
• PCE can be placed in
a number of places
– There is one God
who sees and
controls everything
– There is a single
God who answers
prayer, but you
have free choice
– There are many
gods each with
different
responsibilities
– We all contain an
element of God.
iPOP2013, Tokyo, Japan
– In a central
provisioning server
(NMS)
– In a dedicated
computation server
– There may be
multiple PCEs with
different capabilities
in different parts of
the network
– The PCE function
can be distributed
into the routers
Copyright © Juniper Networks 2013 Page 20
Next Steps for PCE
• Several new developments of PCE “in the pipe”
– Being worked on for real
• In the IETF
• In research projects
• In product development
• Extensions of the Traffic Engineering model
– PCE has implied a strict separation of TE information
– What if we were able to share information between domains?
• Software Defined Networking
– Everyone is talking about it
– PCE has a key role
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 21
Traffic Engineering – A New Model
• I have spoken before about problems with TE aggregation
Virtual Link aggregation
needs compromises and
frequent updates
Virtual Node aggregation
hides internal connectivity
issues
• But what if we could provide an abstraction model based on policy?
– A network leaks only selective potential connectivity
• Abstract links are stable and represent “the idea of connectivity”
• Local policy dictates which links to advertise
– PCE plays an important role in both networks
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 22
Architecture for TE Abstraction
PCE
BGP-LS
BGP-LS
UNI
PCE
•
•
•
•
Mechanism relies on determining potential connectivity
Then distribution of information about abstract links
Enablement on-demand
Work in progress
– draft-ietf-idr-ls-distribution
– draft-farrel-interconnected-te-info-exchange
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 23
Software Defined Networks
• Controlling networks from software to enable services
• We are all familiar with GMPLS
– GMPLS is a form of SDN
– The management software makes decisions about what paths
should be used
• PCE is used to prepare paths
• A provisioning request is made
• GMPLS control plane just does the provisioning
• Open Networking Foundation Architecture
– The Controller plans paths using path computation (PCE)
– OpenFlow is used to program the network devices
• ITU-T Resource and Admission Control Function
– This is a service-based model of resource provisioning
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 24
Service Management – An Old ITU-T SDN View
•
ITU-T’s Resource and Admission Control Function (RACF)
– Plans and operates network connectivity in support of services
•
Policy Decision Functional Entity
– Examines how to meet the service requirements using the available resources
•
Transport Resource Controller Functional Entity
– Provisions connectivity in the network (may use control plane)
Service control functions
Service stratum
Transport stratum
RACF
PD-FE
Network attachment
control functions
RACF
PD-FE
PCE
PCE
TRC-FE
TED
CPE
CPN
PE-FE
TRC-FE
PE-FE
PE-FE
PE-FE
Access network
TED
Core network
Figure based on ITU-T Y.2111
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 25
Application-Based Network Operation (ABNO)
NMS/OSS
Application/Service Requester
ABNO Controller
I2RS Agent
Network
Policy
OffBoard
Routing
Protocol
IRS/PCEP
PCE
Resource Manager
OpenFlow/Forces
PCEP
•
•
•
TED
LSP-DB
BGP-LS
I2RS
Config/
Netconf
OpenFlow/
Forces
Virtual Network
Topology Manager
Routers
MPLS /
GMPLS
An integrated architectural view of many network control components
PCE is the centre of the architecture
Work in hand
– draft-farrkingel-pce-abno-architecture
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 26
The Future of PCE
• Ideas and applications for PCE keep growing
• Every new technology looks to use PCE
–
–
–
–
–
–
–
–
–
IP-Over-Flexigrid Networks
Ever more SDN ideas
NFV
IP Fast Reroute
MPLS Source Routing
Multi-segment Pseudowires
Managed Ethernet (e.g. TRILL)
Power-aware networking
Internet of Things
• Even applied to nontelecoms applications
– Utility companies
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 27
Source Routing
•
•
MPLS-TE and GMPLS are a form of source routing
– A packet is placed on an LSP according to a choice at the source
– Once on the LSP, the packet’s path is predetermined
– The Explicit Route in signalling has determined the path
– The mechanisms uses PCE at LSP establishment
– Call this “per-flow source routing”
“Per-packet source routing” is being re-investigated
– Familiar to old IPv4 enthusiasts
– Each packet carries the path to follow
– Now investigated for MPLS networks
• Pop a label and forward the packet
• Interesting for ECMP, FRR, TE
– Many things think about
• How deep is the label stack?
• Can each packet take a different path?
• How does PCE supply the paths to use?
1st
hop
2nd
hop
3rd
hop
iPOP2013, Tokyo, Japan
nth
hop
Payload
header
Copyright © Juniper Networks 2013 Page 28
Payload
Power-Aware Networking
• Route traffic to reduce network-wide power consumption
• There are many unanswered questions
–
–
–
–
Will I turn off a router line card?
Does it make sense to turn down provisioned optical resource?
What aspects of equipment consume the power?
Does a card at 100% consume more power and need more
cooling than two cards at 50%
• Early research shows potential savings of up to 25% in
IP networks
– That probably means real savings as low as 10%
• If this catches on then PCE will be important
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 29
Internet of Things
•
Interconnection of people and devices
– Key features are low power, low memory, and low-quality links
•
Interconnection may be:
– Route-over
– Mesh-under
•
•
•
Routing protocols use power and memory
Packets may be source-routed
New IETF work “6TSCH”
– IEEE802.15.4e TSCH time synchronised channel-hoping wireless
– PCE provides MAC layer transmission scheduling and end-to-end
routing
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 30
Is The Future Bright for PCE?
• There are many applications that call for the computation
of paths or the selection of resources
• The is no real purpose in debating the definition of PCE
– However, it is helpful to state what we mean when we say “PCE”
– It is important to clarify what you mean when you talk about PCE
• A key differentiator is the level of function in the interfaces
–
–
–
–
Base PCEP (RFC 5440)
Extended PCEP for stateful PCE (draft-ietf-pce-stateful-pce)
Additional PCEP function
Other protocols
• There is still no “killer application” for PCE
– All the great ideas are just great ideas until they are implemented
and widely deployed
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 31
PCE Solves All Known Problems
• It is true that PCE can be used
in a surprisingly large number
of environments
– Much more than we considered
when we worked on RFC 4655
• It appears that PCE is real
– Some actual deployments
– A lot of potential
• PCE is my baby and of course…
– My baby is beautiful
• Despite evidence to the contrary…
– PCE is not magic
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 32
Questions and Answers
Have a look at draft-farrkingel-pce-questions
[email protected]
[email protected]
iPOP2013, Tokyo, Japan
Copyright © Juniper Networks 2013 Page 33