330 likes | 532 Views
Path Computation Element. A Retrospective and Some Predictions Adrian Farrel Juniper Networks. 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
E N D
Path Computation Element A Retrospective and Some Predictions Adrian Farrel Juniper Networks
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
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
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
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
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 7 MB Demand 10 MB Link
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 3 3 + 2 + 2 = 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
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?
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
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
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
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
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)
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?
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…
A Philosophical Interlude • All good philosophical debates have two sides • The question we have to ask is: What is the functional boundary of PCE? • 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 a number of other functions, too. Raichō Hiratsuka 平塚 らいてう Akiko Yosano 与謝野 晶子
The Idealist Model • Stateful PCE makes this model much more popular • Path computation is just one of the functions of PCE PCE Management Planning Recovery Reoptimisation Configuration TE Info Collection Computation Request/Response Inventory Info Provisioning Alarms
The Purist Model • PCE is the hub • But PCE only performs computations Service Calendaring OSS Alarm Management System NMS PCE TED EMS LSP-TB Inventory
Another Philosophical View – PCE as God • PCE can be placed in a number of places • 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 • There is a range of theologies • 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.
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
Traffic Engineering – A New Model • I have spoken before about problems with TE aggregation • 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 Virtual Link aggregation needs compromises and frequent updates Virtual Node aggregation hides internal connectivity issues
Architecture for TE Abstraction 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 BGP-LS BGP-LS UNI PCE
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
Network attachment control functions TRC-FE TED TED PCE PCE 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 RACF PD-FE PD-FE TRC-FE PE-FE CPE PE-FE PE-FE PE-FE CPN Core network Access network Figure based on ITU-T Y.2111
Application-Based Network Operation (ABNO) NMS/OSS Application/Service Requester • An integrated architectural view of many network control components • PCE is the centre of the architecture • Work in hand • draft-farrkingel-pce-abno-architecture ABNO Controller I2RS Agent Virtual Network Topology Manager IRS/PCEP Network Policy Off-Board Routing Protocol PCE Resource Manager TEDLSP-DB PCEP OpenFlow/Forces BGP-LS I2RS Config/Netconf MPLS / GMPLS Routers OpenFlow/Forces
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 non-telecoms applications • Utility companies PCE THING
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? Payload header 1st hop 2nd hop 3rd hop nth hop 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
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
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
PCE Solves All Known Problems • It is true that PCE can be usedin a surprisingly large numberof environments • Much more than we consideredwhen 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
Questions and Answers Have a look at draft-farrkingel-pce-questions adrian@olddog.co.uk afarrel@juniper.net