Adrian Farrel : Old Dog Consulting Net-Centric 2016 The Path Computation Element as a Centralized Controller in advanced SDN Operations Adrian Farrel : Old Dog Consulting adrian@olddog.co.uk www.isocore.com/2016

Agenda Remember - What is a PCE? What does SDN look like? The role of PCE in SDN The implications of putting PCE at the centre What could we do with a “PCE-Based Centralized Controller” What would it take? Why would we do it? Who is doing it?

PCE Refresher Well, do we really need a PCE refresher? History Origins A mechanism to provide inter-domain paths A tool to offload path computation in MPLS systems Rapid developments Path computation for all connection oriented systems MPLS-TE, GMPLS, MPLS-TP, … Server functionality Receives path computation requests Sends responses

A Functional Entity PCE is a functional component It can be embedded in other components It can be a stand-alone sever It’s just a things that computes paths LSR NMS PCE server LSR TED PCC TED TED PCE NMS PCE PCE PCC Signalling engine PCE server PCE co-located in the LSR PCC PCE in the NMS PCE in a dedicated server

Developments Over Time It was a request/response server “Please compute a path” / “Here is your answer” Stateful PCE is valuable Coordinate with other LSPs in the system Delegated control PCE sends “suggested” updates when the network changes PCE-Initiated LSPs PCE sends unsolicited LSP setup “requests” All these features become important for SDN

What is Software Defined Networking? Let’s not re-open this debate (please!) Centralized control Especially of end-to-end services Network convergence Converged services and infrastructure Network “abstraction” Partitioning of resources Network automation Application-to-network relationship Provides access to the forwarding plane of network devices Momentum being driven for commercial benefits Rapidly provide cool services at lower prices Reduce OPEX and simplify network operations Enable better monitoring and diagnostics

Some Popular SDN Architectures PCE TED Orchestrator Application/Service Requester Controller Lots of pictures Most show some form of path computation being performed Applications Application Service Coordinator PCE ABNO Controller Choices I2RS OAM Handler Provisioning Manager Choices Controllers PCEP

Why is PCE at the Centre? This is really simple Its all about coordination of network resources Centralization avoid contention And its all about traffic engineering Centralization aids planning and optimization And it uses complex and intensive algorithms May be best to offload from the “dumb” network And it can benefit from large databases Network capabilities Traffic demands and intentions Telemetrics

What Does it Mean To Be At the Centre? PCE-Based Centralized Control PCE is there in all the pictures That means PCE is central to the decision-making processes From there on it is a labelling function Controllers/Orchestrators/OSS use PCE PCE-enabled Controllers/Orchestrators/OSS PCE-based Controllers/Orchestrators/OSS PCE-based Central Controller PCE as a Central Controller This is mainly semantics A lot of it is about how you build software and how you market product

Some Useful Functions Answer computation enquiries (already supported) Modify an LSP that is already in place (stateful PCE) Cause an LSP to be set up (PCE-initiated LSPs) Say what an LSP is for Apply to other technologies Deterministic networking Time-sliced channel hopping (IEEE 802.15.4e) Segment Routing Service Function Chaining PCEP as an SDN Southbound Interface – Static LSPs LSP stitching as a hybrid use case Answer computation enquiries (already supported) Modify an LSP that is already in place (stateful PCE) Cause an LSP to be set up (PCE-initiated LSPs) Say what an LSP is for Apply to other technologies Deterministic networking Time-sliced channel hopping (IEEE 802.15.4e) Segment Routing Service Function Chaining PCEP as an SDN Southbound Interface – Static LSPs LSP stitching as a hybrid use case

Traffic Classification – What is The LSP For? When a TE-LSP is set up, the head end needs to know how to use it What traffic to send on the LSP Whether it is a virtual link Whether to advertise it in the IGP What bits of this information to signal to the tail end What to do with traffic received on an LSP PCEP allows an Active PCE to set up or modify LSPs But we have no way to tell the head end how to use the LSP This is because of history It used to be the LER that made the request of the PCE, so it knew why it wanted the LSP This function is presumably necessary But it is currently missing

But LSPs Are Used Today – How? There are several possibilities No-one uses Active PCE The problem doesn’t arise Active PCE is used only in controlled environments Head end always knows what the LSP is for Active PCE is used in conjunction with configuration The LSP is set up using PCEP Some other mechanism tells the head end what to do Active PCE is used in conjunction with BGP Flowspec Possibly not what BGP Flowspec was designed for But it works Note that the last two of these seem a waste Why separate the functions? Could use one protocol for everything

What Features for “LSP Purposing”? Describe: How to use the LSP What traffic to place on the LSP We already have ways of describing traffic flows e.g., BGP Flowspec How to advertise the LSP Does it appear as a link in a topology? Which instance, what metric, what bandwidth? Compare with RFC 6107 Extra signalling information Other stuff gets signalled to coordinate LSP end points Features of “LSP usage”

Segment Routing Path Programming and Classification Segment routing is a form of source routing A central controller can Compute paths through the network Instruct the head end about what “stack” to impose This is like Normal stateful path computation Stateful path programming Traffic classification 1st hop 2nd hop 3rd hop nth hop Payload header Payload

Further Proposed SR Task Labels have to be selected and assigned Selection benefits from centralization Assignment has competing protocol solutions PCE allocates Labels (SID) for node, Adjacency. PCEP for traffic classification and installing label stack PCEP for label mapping for node and adjacency. 1417 4106 payload 4106 payload

Static LSPs A TE-LSP is a series of “cross connects” and “resource reservations” Familiar in “legacy” transport networks Popular with “MPLS-TP” MPLS-TE without a control plane Order of programming is not important Can program in parallel Incoming interface/label  Outgoing interface/label

Static LSPs – PCEP as an SDN SBI PCEP allows an active PCE to install LSPs to be signalled in a TE network The “cross-connects” are indicated by the ERO An ERO can include label information (GMPLS) Incoming label and outgoing label LSPs can be short A single hop ERO can be just one “cross-connect” PCEP is already an SBI for static LSPs

SBI Thoughts The ERO approach is a little ugly It might trigger the signalling component to attempt to do work We haven’t worked much on “upstream interface for head-end LER” in GMPLS or PCEP We could add to PCEP specifically for this function Not a lot of work

Claimed Benefit of Central Control and SBI Recovery from error cases can result in contention for resources and signalling storms Central control enables prioritisation and optimization Comparing apples with apples? Central control of signalled LSPs Central control with programming of cros-connects Contrast with single point of failure Consider congestion of management plane Convergence Time Number of LSPs Source: Huawei Technologies – IETF-94

LSP Stitching LSPs or pseudowires are stitched to form end-to-end services Stitching normally uses configuration Some signalling extensions exist This is an additional “static LSP” feature Adding “cross connect LSPs” to normal LSP setup ASBR1 ASBR3 CE2 CE1 PE2 PE1 ASBR2 ASBR4 Signaled LSP Signaled LSP Signaled LSP

Modifications to PCE and PCEP Adding traffic classification to an LSP message is “just another Object” We already have experience with BGP Flowspec Segment Routing paths are just hop-by-hop paths Each hop TLV needs to encode a SID Static LSPs are just very short LSPs with no signalling Should be possible to use existing messages and objects Could add specialist messages Bottom line Only tweaking PCEP not making radical changes

Competition with Other Protocols Need to be aware of other “competing” protocols OpenFlow is an SBI Netconf/RESTconf with YANG is ubiquitous BGP is used in many places Proprietary and legacy protocol usages XMPP, TL1, CLI, … So why use PCEP? Should this talk be about a “PCEP-based Centralized Controller”? It’s a question still to be answered, but… PCE is at the centre It makes sense to add these functions to PCE PCE talks PCEP Why would you want a PCE to talk multiple protocols? But PCE implementations may be configured using Netconf/YANG

Work in Progress The IETF is looking at this stuff TEAS working group Responsible for traffic Engineering Architecture draft-ietf-teas-pce-central-control “An Architecture for Use of PCE and PCEP in a Network with Central Control” PCE working group Responsible for extensions to PCEP draft-ietf-pce-segment-routing PCEP Extensions for Segment Routing draft-li-pce-pcep-flowspec PCEP Extension for Flow Specification

Questions adrian@olddog.co.uk