Path Computation Element

33
POP2013, Tokyo, Japan Path Computation Path Computation Element Element A Retrospective and Some A Retrospective and Some Predictions Predictions Adrian Farrel Adrian Farrel Juniper Networks Juniper Networks

description

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 - PowerPoint PPT Presentation

Transcript of Path Computation Element

Page 1: Path Computation Element

iPOP2013, Tokyo, Japan

Path Computation ElementPath Computation Element

A Retrospective and Some PredictionsA Retrospective and Some Predictions

Adrian FarrelAdrian Farrel

Juniper NetworksJuniper Networks

Page 2: Path Computation Element

Copyright © Juniper Networks 2013 Page 2iPOP2013, 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

Page 3: Path Computation Element

Copyright © Juniper Networks 2013 Page 3iPOP2013, Tokyo, Japan

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

Page 4: Path Computation Element

Copyright © Juniper Networks 2013 Page 4iPOP2013, Tokyo, Japan

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

8 5

4

10

4

2

8

10

1015

7

9

Page 5: Path Computation Element

Copyright © Juniper Networks 2013 Page 5iPOP2013, Tokyo, Japan

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

8 5

4

10

4

2

8

10

1015

7

9

Page 6: Path Computation Element

Copyright © Juniper Networks 2013 Page 6iPOP2013, Tokyo, Japan

Multi-Path Problems

5 MB Link

10 MB Link7 MB Demand

5 MB Demand

• The classic “fish” problem of ordered provisioning• Diverse routes for protection paths• More sophisticated algorithms

– k-shortest paths– Linear programming

Page 7: Path Computation Element

Copyright © Juniper Networks 2013 Page 7iPOP2013, Tokyo, Japan

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 34 3 + 2 + 2 = 7

Page 8: Path Computation Element

Copyright © Juniper Networks 2013 Page 8iPOP2013, Tokyo, Japan

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

Page 9: Path Computation Element

Copyright © Juniper Networks 2013 Page 9iPOP2013, Tokyo, Japan

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?

Page 10: Path Computation Element

Copyright © Juniper Networks 2013 Page 10iPOP2013, Tokyo, Japan

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

Page 11: Path Computation Element

Copyright © Juniper Networks 2013 Page 11iPOP2013, Tokyo, Japan

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

Page 12: Path Computation Element

Copyright © Juniper Networks 2013 Page 12iPOP2013, Tokyo, Japan

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

Page 13: Path Computation Element

Copyright © Juniper Networks 2013 Page 13iPOP2013, Tokyo, Japan

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

Page 14: Path Computation Element

Copyright © Juniper Networks 2013 Page 14iPOP2013, Tokyo, Japan

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)

Page 15: Path Computation Element

Copyright © Juniper Networks 2013 Page 15iPOP2013, Tokyo, Japan

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?

Page 16: Path Computation Element

Copyright © Juniper Networks 2013 Page 16iPOP2013, Tokyo, Japan

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…

Page 17: Path Computation Element

Copyright © Juniper Networks 2013 Page 17iPOP2013, Tokyo, Japan

A Philosophical Interlude

Raichō Hiratsuka 平塚 らいてう

• 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. Akiko Yosano 与謝野 晶子

Page 18: Path Computation Element

Copyright © Juniper Networks 2013 Page 18iPOP2013, Tokyo, Japan

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

Computation Request/Response

TE Info Collection

Inventory Info

PlanningRecoveryReoptimisation

Alarms

Page 19: Path Computation Element

Copyright © Juniper Networks 2013 Page 19iPOP2013, Tokyo, Japan

The Purist Model

• PCE is the hub• But PCE only performs computations

PCEInventoryLSP-TB

TED

NMS

EMS

OSS Alarm Management System

Service Calendaring

Page 20: Path Computation Element

Copyright © Juniper Networks 2013 Page 20iPOP2013, Tokyo, Japan

Another Philosophical View – PCE as God

• 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.

• 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

Page 21: Path Computation Element

Copyright © Juniper Networks 2013 Page 21iPOP2013, Tokyo, Japan

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

Page 22: Path Computation Element

Copyright © Juniper Networks 2013 Page 22iPOP2013, Tokyo, Japan

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

Page 23: Path Computation Element

Copyright © Juniper Networks 2013 Page 23iPOP2013, Tokyo, Japan

Architecture for TE Abstraction

• 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

UNI

PCE

BGP-LS

PCE

BGP-LS

Page 24: Path Computation Element

Copyright © Juniper Networks 2013 Page 24iPOP2013, Tokyo, Japan

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

Page 25: Path Computation Element

Copyright © Juniper Networks 2013 Page 25iPOP2013, Tokyo, Japan

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)

Figure based on ITU-T Y.2111

Service control functionsService stratum

Transport stratum

Network attachment control functions

CPE

CPN

PE-FE PE-FEPE-FEPE-FE

PD-FE PD-FE

TRC-FE TRC-FE

RACF RACF

Access network Core network

TED

PCE

TED

PCE

Page 26: Path Computation Element

Copyright © Juniper Networks 2013 Page 26iPOP2013, Tokyo, Japan

Application-Based Network Operation (ABNO)

• An integrated architectural view of many network control components• PCE is the centre of the architecture• Work in hand

– draft-farrkingel-pce-abno-architecture

I2RSConfig/Netconf

OpenFlow/Forces

Routers

PCE

TEDLSP-DB

Resource Manager

PCEPOpenFlow/Forces

I2RS Agent

Virtual Network Topology Manager

BGP-LS

ABNO Controller

Network Policy

NMS/OSS Application/Service Requester

IRS/PCEPOff-

BoardRouting Protocol

MPLS / GMPLS

Page 27: Path Computation Element

Copyright © Juniper Networks 2013 Page 27iPOP2013, Tokyo, Japan

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

THIN

G

Page 28: Path Computation Element

Copyright © Juniper Networks 2013 Page 28iPOP2013, Tokyo, Japan

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

nth hop

Payload header

Payload

Page 29: Path Computation Element

Copyright © Juniper Networks 2013 Page 29iPOP2013, Tokyo, Japan

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

Page 30: Path Computation Element

Copyright © Juniper Networks 2013 Page 30iPOP2013, Tokyo, Japan

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

Page 31: Path Computation Element

Copyright © Juniper Networks 2013 Page 31iPOP2013, Tokyo, Japan

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

Page 32: Path Computation Element

Copyright © Juniper Networks 2013 Page 32iPOP2013, Tokyo, Japan

PCE Solves All Known Problems

• It is true that PCE can be usedin a surprisingly large numberof 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

Page 33: Path Computation Element

Copyright © Juniper Networks 2013 Page 33iPOP2013, Tokyo, Japan

Questions and Answers

Have a look at draft-farrkingel-pce-questions

[email protected]

[email protected]