Path Computation Element A Retrospective and Some Predictions

Path Computation Element A Retrospective and Some Predictions Adrian Farrel Juniper Networks i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, 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 Po. P – I can see in my domain, but not into my peer’s – Which exit-point should I choose? i. POP 2013, 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 Po. P use case – PCE function in head-end LSR for local domain – PCE function in remote ASBR accessed through remote call i. POP 2013, 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 Po. P use case the domain was an AS i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, 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) i. POP 2013, 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? i. POP 2013, 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 i. POP presenters – But it does raise some questions for me… i. POP 2013, 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 a Akiko Yosano 与謝野 晶子 number of other functions, too. i. POP 2013, 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 Management Planning Recovery Reoptimisation Configuration Provisioning Computation Request/Response TE Info Collection Inventory Info Alarms i. POP 2013, 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 i. POP 2013, 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. i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, Tokyo, Japan Copyright © Juniper Networks 2013 Page 22

Architecture for TE Abstraction PCE BGP-LS UNI BGP-LS 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 i. POP 2013, 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) – Open. Flow is used to program the network devices • ITU-T Resource and Admission Control Function – This is a service-based model of resource provisioning i. POP 2013, 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 Network attachment control functions CPN RACF PD-FE PCE TRC-FE TED CPE RACF PD-FE PE-FE TRC-FE PE-FE Access network TED Core network Figure based on ITU-T Y. 2111 i. POP 2013, Tokyo, Japan Copyright © Juniper Networks 2013 Page 25

Application-Based Network Operation (ABNO) NMS/OSS Application/Service Requester ABNO Controller I 2 RS Agent Network Policy Off. Board Routing Protocol I 2 RS Config/N etconf Open. Flow/ Forces Virtual Network Topology Manager PCE Resource Manager Open. Flow/Forces • • • IRS/PCEP TED LSP-DB BGP-LS 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 i. POP 2013, 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 G IN TH – Utility companies i. POP 2013, Tokyo, Japan CE P 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 IPv 4 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? 1 st hop 2 nd hop 3 rd hop i. POP 2013, 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 i. POP 2013, 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 “ 6 TSCH” – IEEE 802. 15. 4 e TSCH time synchronised channel-hoping wireless – PCE provides MAC layer transmission scheduling and end-to-end routing i. POP 2013, 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 i. POP 2013, 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 i. POP 2013, Tokyo, Japan Copyright © Juniper Networks 2013 Page 32

Questions and Answers Have a look at draft-farrkingel-pce-questions adrian@olddog. co. uk afarrel@juniper. net i. POP 2013, Tokyo, Japan Copyright © Juniper Networks 2013 Page 33