Convergence without Conflation The three-slide statement Adrian Farrel Old Dog Consulting [e-mail]

1
ConvergencewithoutConflationThe three-slide
statementAdrian FarrelOld Dog
Consultingadrian_at_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

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

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

5
ConvergencewithoutConflationThe full
slide-setAdrian FarrelOld Dog
Consultingadrian_at_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

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

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

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

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

11
Solution Toolkit

• Functional decomposition
• Policy
• Management control
• Integration with service provisioning

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 in complex 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

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

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 cant 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
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 cant 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

16
Service Management

• ITU-Ts 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
CPE
PE-FE
PE-FE
PE-FE
PE-FE
CPN
Core network
Access network
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 isnt 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
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!

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

20
IETF References

• The IETF is the main originating body for PCE and
  VNTM
• PCE working group home pagehttp//www.ietf.org/ht
  ml.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.t
  xt Path Computation Element Communication
  Protocol (PCEP) Requirements and Protocol
  Extensions In Support of Global Concurrent
  Optimization

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/publicatio
  ns/sector.aspx?sector2
• G.7715.2 ASON routing architecture and
  requirements for remote route query
• Y.2111 Resource and admission control functions
  in NextGeneration Networks

22

• Questions
• adrian_at_olddog.co.uk