Misconceptions

1. ConvergencewithoutConflationThe three-slide statementAdrian FarrelOld Dog Consultingadrian@olddog.co.uk

2. Misconceptions • “CAPEX is not an issue” • Everything is relative! • Dark fibre may be cheap, but optical switches are not a commodity • “There can be plenty of capacity” • There may be plenty of dark fibre, but it is dark • We are not time travellers and we need to offer bandwidth now • “Core networks are always over-provisioned and do not need BoD” • True, they may not need to offer BoD, but: • How does the network remain over-provisioned? • “Network operation cannot be automated” • Ploughing with horses is also very nice! • Automation is the only way to drive down OPEX • “There are end-users and network providers” • There is actually a food chain • Everyone (except maybe the end-user) is multi-homed • Transport network operators support (and compete for) multiple access network providers • This means a “user” of a transport network may be very large(for example, a multi-national enterprise), and a change incapacity requirement can be a big thing. • This is a layering problem not a peering problem 2

3. Requirements • Requirements in the IETF • Driven by service providers • Dynamically change the connectivity between routers or between edges • “Connectivity” includes capacity • Assumptions/requirements • Changes in client network configuration have dramatic effects on server network load • Providers need to be able to respond rapidly (i.e., minutes) to new customer requests • Truck-roll to turn up new lambdas is not fast • Client ‘greed’ will be mitigated by server ‘cost’ • But server still does not trust the client! • Server must retain full policy and operations control • Need to support prioritised access to resources (pre-emption) • Virtualisation is a benefit (tends to be connection-oriented) • Virtual private connectivity • Pseudowires • Layer One VPNs • Virtual router adjacencies • Layer 3 tunnels • Transport connections 3

4. Solution Toolkit • Functional decomposition • Control plane (rapid provisioning and repair – GMPLS) • Path computation (via Path Computation Element – PCE) • Network layering • Virtual Network Topology (VNT) • Operator oversight • Policy • Management control (VNT Manager – VNTM) • Integration with service provisioning • Understanding of QoS and other service admission control issues • The IETF will continue to work on this so long as there is service provider demand • For more details see the full slide-set • Why is this less interesting? • Because the technical problems have already been solved • What research work could be done? • We need to know how stable this type of network will be • We need to know what the cost savings are • We need to know how well connected a mesh network needs to be to provide a good non-blocking ratio 4

5. ConvergencewithoutConflationThe full slide-setAdrian FarrelOld Dog Consultingadrian@olddog.co.uk

6. Bandwidth on DemandWhat is the IETF Working On? • Control planes • Essential for rapid provisioning and repair • Not fundamental to BoD • IETF has IP routing, MPLS, MPLS-TE, and GMPLS • Technology-specific control plane extensions • Functional decomposition • Path computation • Network planning • Network operation and policy • Recognition that “on-demand” is really “on-request” • Server network must retain control of its own resources 6

7. Definitions and Scope • A domain is defined as: Any collection of network elements within a common sphere of address management or path computational responsibility [RFC 4726 and RFC 4655] • Classic examples are IGP Areas and ASes • Equally applicable to technology or client/server layers • A layer is defined as separations of technologies (e.g., packet switch capable (PSC), time division multiplex (TDM), or lambda switch capable (LSC)) [RFC 3945] • Sometimes called regions separation of data plane switching granularity levels (e.g., VC4, or VC12) [RFC 5212] • Sometimes called sub-layers a distinction between client and server networking roles [RFC 5212] • The Traffic Engineering Database (TED) • The sum of information about the connectivity in a domain (nodes and links) • Link constraints (available bandwidth, cost, etc.) • Configured or learned from distribution protocols 7

8. Convergence and Bandwidth on Demand • Commercial motivators • Shared server networks resources • Reduced CAPEX • Simultaneous support for more client services • Rapid response to new customers • A new, marketable service • Integrated network operation • Reduced OPEX • Less steep learning curve • Protocol robustness 8

9. What is a Virtual Network Topology? • Links in a network may be physical • Or they may be ‘tunnels’ across a lower layer network • Tunnels can be configured as services • Virtual private wire • The virtual network topology can be tuned on-demand • Management or control plane operation 9

10. Operator Issues - Conflation • Some service providers are really not happy! • “On-demand” sounds like the client is in control • “Customers are not clever” • “The server resources belong to me” • “Dynamic” sounds like it might flap • Transport resources need seconds to provision • Traditional set-up times of days • Typical hold-times of weeks • Client dynamics can be very fast • Client and server granularities are different • Smallest server granularity may be 2.5Gb • Client may deal in micro-flows • Does not suit all topologies • “I have laid the fibre so I might as well provide all the bandwidth” 10

11. Solution Toolkit • Functional decomposition • Policy • Management control • Integration with service provisioning 11

12. Path Computation Element (PCE) • “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” (RFC4655) • PCE is a path computation element that specializes incomplex path computation on behalf of its path computation client (PCC) • PCE can be: • Embedded in an NMS • A dedicated server • Functional component of a switch/router • PCEs collect TE information (the TED) • They can “see” within the domain 12

13. Multi-Layer Path Computation • End-to-end path is not just providing a path across a server network • A single PCE cannot compute a multi-domain or multi-layer path • Why not? • By definition of “domain” (unless the PCE can see all layers) • Layers may be commercially separate • Mixing layer information may “confuse” client layer routing • Combining layers might not scale • How to decide which layer boundary points to use? • PCEs can cooperate to derive the best end-to-end path • Techniques exist for peer domains and can be applied to layers • Backward Recursive Path Computation (BRPC) • But the server layer wants to retain control of expensive resources 13

14. VNT Manager Interactions with PCE • VNT Manager is a policy/management component • Acts on triggers (operator request for a client TE link, client network traffic demand info, client TE link usage info, client path computation failure notification) • Uses PCE to determine paths in lower layer • Uses management systems to provision LSPs and cause them to be advertised as TE links in the client layer 6. Path computation request and response 1. Compute a path 2. I can’t find a path PCE 3. I failed to compute a path VNTM 4. Compute a path 5. Provision an LSP and make a TE link PCE 14

15. Integration with Policy • Policy is fundamental to PCE • What should a PCC do when it needs a path? • What should a PCE do when it gets a computation request? • Which algorithms should a PCE use? • How should PCEs cooperate? • What should a PCE do when it can’t find a path? • Note VNTM requests server layer paths NOT client PCE • Can we set up virtual links ahead of requirement? • When can we tear down a virtual link? • Who is allowed to request what type of link? • RACF PD-FE is a policy component that could use PCE • Inter-domain paths are subject to Business Policy • IPsphere Forum is working on business boundaries • Business policy may guide PCE in its operation • Selection of domains based on business parametersis a path computation that PCE could help with 15

16. Network attachment control functions TRC-FE TED TED PCE PCE Service Management • 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 VNTM TRC-FE PE-FE CPE PE-FE PE-FE PE-FE CPN Core network Access network 16

17. Choosing a Server Layer • Previous consideration is multiple clients • Client might be connected by multiple servers • Need to select a server that provides connectivity to the right client site • Problem can be seen as VPN membership • BUT connectivity isn’t the only issues • Bandwidth • Quality of Service • Price • Problem is similar to selecting a multi-AS path • Simply solved by client PCE consulting multiple server VNTMs or PCEs Client Site 1 Client Site 2 Client Site 3 Server Network 1 Server Network 2 17

18. Cascaded Server Layers Client Site 1 Client Site 2 Client Site 3 • Much more complex to plan end-to-end routes • Server network could “hide” complexity • Could use a coordinating PCE • Hierarchical PCE • Try to resist “TE abstraction” • Must enter and leave technology layers in thesame way! 18

19. Network Reoptimisation • Forgotten element of BoD • Server network may become a mess! • Incremental addition and removal of services • Parallel, partially used virtual links • Minimally used high-capacity resources • We want to reoptimise the server layer, but: • Need to consider the impact on the clients • What traffic can be re-groomed? • What traffic can be re-routed? • What bandwidth will be demanded again soon? • Server layer re-optimisation needs to be holistic • Optimising individual paths is rarely efficient • Network optimisation needs to be holistic • Optimise client and server layers as one function • This is the job of an off-line planning tool 19

20. IETF References • The IETF is the main originating body for PCE and VNTM • PCE working group home pagehttp://www.ietf.org/html.charters/pce-charter.html • RFC 4655 A Path Computation Element (PCE)-Based Architecture • RFC 5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks • draft-ietf-pce-inter-layer-frwk-09.txt Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering • draft-ietf-pce-brpc-09.txt A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched (to become RFC 5441) • draft-ietf-pce-global-concurrent-optimization-08.txtPath Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization 20

21. Other References • The IPsphere Forum can be found at http://www.ipsphereforum.org • The ITU-T has worked on several relevant documents • Access documents viahttp://www.itu.int/publications/sector.aspx?sector=2 • G.7715.2 ASON routing architecture and requirements for remote route query • Y.2111 Resource and admission control functions in NextGeneration Networks 21

22. Questions adrian@olddog.co.uk 22