brkspg-2662d2zmdbbm9feqrf.cloudfront.net/2013/anz/pdf/brkspg-… · · 2013-03-07... (path...

© 2013 Cisco and/or its affiliates. All rights reserved. BRKSPG-2662 Cisco Public

Software Defined Networks for Service

Providers, A Practical Approach BRKSPG-2662

2


Abstract

Network Operators need to support a diverse customer base, distribute content and applications/services across multiple geographies, topologies and infrastructure layers while offering secure, reliable, and consistent experiences to their users on any device at any location.

Software Defined Networks (SDN) has emerged as a potential solution to this broad new set of customer and user challenges. One of the most critical aspect of SDN architectures is the ability to acquire infrastructure knowledge from each domain and layer.

Orchestration elements such as the SDN-PCE (Path Computation Element) with the ONE Controller (Open Network Environment) are key in this architecture and they allow the Network Operator to consolidate topology, state, resources, analytics and other information sources.

The presentation focuses on the orchestration and controller elements and on one of the key functions consisting of network topology information acquisition (through the use of BGP-LS Extensions).

3


Agenda

Introduction to SDN in SP Networks

Use Cases

Requirements for an SDN capable SP network

SDN Path Computation Element (SDN-PCE)

Topology Acquisition: BGP-LS

Summary

4


Software Defined Networks

Currently, Service Provider networks rely on well established routing

technologies

‒ Link State Routing , BGP, MPLS (Traffic Engineering, VPNs), Tunnelling, …

Traditional routing paradigms

‒ IP Destination Based (SPF algorithms)

‒ MPLS Explicit Routing: Traffic Engineering (RSVP-TE, RSVP-GMPLS), …

‒ MPLS VPNs (L2/L3)

‒ Fast Reroute

Finest granularity is the prefix

‒ More specifics routing requirement results in more prefixes in RIB/FIBs

5



Emerging Requirements come from multiple layers

Application Layer: ‒ CDNs, CDN Federations

‒ Clouds, Data Center overlays

‒ Video Streaming

‒ Service Chaining

‒ Social Networking

‒ …

Mobile layer

Transport, IP/MPLS Layer ‒ Interworking

‒ Dynamic Provisioning and self adaptability

…

6


Evolution of the Intelligent Network Technology Objectives

Make everything go faster, easier and more agile

• Configurable Networks • Orchestrated Networks

• Apps-aware networks • Network-aware apps

• Network interfaces

• Managed Networks

• Programmatic interfaces

• Automated Networks

7


Evolution of the Intelligent Network

Business Objectives Service Velocity and Creation

‒ Enable NetOps to move as fast as SysAdmins and DevOps

Significant cost reduction in Network operations

Offer network functions as a service

Increased set of service and features for customers

Faster development and delivery cycles

8


Classes of Use-Cases “Leveraging APIs and logically centralised control plane components”

Custom Routing (incl. business logic)

Online Traffic Engineering

Consistent Network Policy,

Security, Thread Mitigation

Custom Traffic Processing

(Analytics, Encryption)

Virtualisation and Domain Isolation

(Device/Appliance/Network)

Federating different Network Control Points

(LAN-WAN, DC-WAN, Virtual-Physical, Layer-1-3)

Automation of

Network Control

and Configuration (Fulfillment and Assurance)

Virtual & Physical

9



Software Defined Networking (SDN) is a new approach to networking,

complementing and enhancing traditional network architectures.

It aims at the normalisation of network configuration and control through

open programmatic interfaces to individual network devices as well as to

the whole network.

Incorporates concepts for network and network topology virtualisation,

and enables customised control planes.

Through customised control planes, allows close alignment of the network

forwarding logic to the requirements of applications.

The SDN concept is put into perspective with existing and evolving

network architectures and principles.

10


Orchestration: Controllers and Agents Task Specific Solutions and Generic Controller Infrastructure

Networking already leverages a great breath of Agents and Controllers

‒ Current Agent-Controller pairs always serve a specific task (or set of tasks) in a specific domain

System Design: Trade-off between Agent-Controller and Fully Distributed Control

‒ Control loop requirements differ per function/service and deployment domain

‒ “As loose as possible, as tight as needed”

‒ Latency, Scalability, Robustness, Consistency, Availability

Session Border Control

Wireless LAN Control

Path Computation

SIP-proxy/ SBC

WLC

AP AP AP PCC PCC PCC

PCE

H.248 CAPWAP PCEP

Generic Controller Infrastructure

SBC B2BUA

SBC B2BUA

SBC B2BUA onePK

OF-Agent OF-Agent OF-Agent

onePK onePK

App App App Control Programs leveraging the ONE Controller

ONE Controller

11


Cisco Open Network Environment

SDN

Open APIs

Open Cloud

Virtualisation

Multi-Layer APIs

Virtual

Overlays

Controller & Agents

Bi-Directional Interaction

Orchestration

Automation

Real-Time Analytics

+

Bringing the Network to the Applications World

12


ONE: Open Network Environment

Cisco has a solid strategy

‒ Evolutionary step for networking

‒ Complement/evolve the Network Control Plane where needed

Focused on delivering open, programmable environment for real-world use cases

‒ No one-size-fits-all

‒ Focus on automation – Make network Operations and Service Delivery faster

ONE Strategy is being put into action

‒ Building – onePK, ONE Controller, Nexus 1000v enhancements, PCE, CSR 1000v, OpenStack

‒ Services

‒ Partnerships (Citrix, MSFT, RHAT, IBM, etc.)

‒ Acquisitions (Virtuata, vCider, Cloupia, Cariden, BroadHop, …)

The Industry’s Broadest Approach to Programmatic Access to the Network

13


Not All Networking APIs Are The Same

APIs Follow Their Scope Classify Networking APIs

based on their scope

‒ API Scopes: Location independent; Area; Particular place; Specific device

‒ Alternate approaches like device/network/service APIs difficult to associate with use cases

‒ Location where an API is hosted can differ from the scope of the API

Different network planes could implement different flavors of APIs, based on associated abstractions

14

Utility

Area/Set

Place in the Network

Element

Example: Get Auth, Publish Log,..

Scope: Location independent

Example: Domain, OSPF-area,..

Scope: Group/Set/Area

Example: Edge Session, NAT

Scope: Specific place/location

Example: interface statistics

Scope: Specific element

14


Cisco onePK (One Platform Kit) Rapid Application Development

C, JAVA, REST, Python

onePK API Presentation – Service Sets

onePK API Infrastructure

IOS / XE (Catalyst, ISR, ASR1K)

NXOS (Nexus Platforms)

IOS XR (ASR 9K, CRS)

Data Path Policy Element Route Utility

Others… Discovery LISP Developer

Flexible Application Deployment

• On a Service Blade

• On an External Server

• Directly on the Device

Comprehensive and

Consistent Platform Support:

• IOS/XE, NX-OS, IOS-XR

Comprehensive Service Sets

• Flexible Apps;

• New Services Monetisation

Opportunity

Developer Environment

• Language of Choice

• Programmatic Interfaces

• Rich Data Delivery via APIs

15


onePK APIs are Grouped in Service Sets

Base Service Set Description

Data Path Provides packet delivery service to application: Copy, Punt, Inject

Policy Provides filtering (NBAR, ACL), classification (Class-maps, Policy-maps), actions

(Marking, Policing, Queuing, Copy, Punt) and applying policies to interfaces on

network elements

Routing Read RIB routes, add/remove routes, receive RIB notifications

Element Get element properties, CPU/memory statistics, network interfaces, element and

interface events

Discovery L3 topology and local service discovery

Utility Syslog events notification, Path tracing capabilities (ingress/egress and interface

stats, next-hop info, etc.)

Developer Debug capability, CLI extension which allows application to extend/integrate

application’s CLIs with network element

Cisco Confidential 16


Towards the Open Network Environment for SDN

Enable modularisation and componentisation of network control- and data-plane functions, with

associated open interfaces: Allow for optimised placement of these components (network devices,

dedicated servers, application servers) and close interlock between applications and network functions;

combining the benefits of distributed and centralised control plane components

Anticipated benefits include: Closely align the control plane with the needs of applications, enable

componentisation with associated APIs, improve performance and robustness, enhance manageability,

operations and consistency – while maintaining benefits of standardised distributed control planes.

Implementation Perspective: Evolve the Control-Plane Architecture

Traditional Control Plane

Architecture Control Plane Architecture with SDN (Examples)

Control-plane component(s) Data-plane component(s)

…

Application components 17


** Past experience (e.g. PSTN AIN, Softswitches/IMS, SBC): CP/DP split requires complex protocols between CP and DP.

* See also: Martin Casado’s Blog: http://networkheresy.wordpress.com/2011/11/17/is-openflowsdn-good-at-forwarding/

Logically

centralised (servers)

fully distributed (“on-box”)

Rapid prototyping (TTM vs. performance)

Algorithms which require coordination between instances, benefit from “a global view”

Large scale tables with relatively infrequent updates (ARP,..)

Software/Algorithm for tightly coupled homogeneous environments

Controlled/tightly-managed Environments

Rapid response to Topology Changes: Efficient “plain vanilla” Layer-3-style forwarding

Rapid response to data-plane events / packet forwarding

Simplicity of Control- and Data-Plane Integration**

On the Question of Centralised vs Distributed …

18

http://networkheresy.wordpress.com/2011/11/17/is-openflowsdn-good-at-forwarding/










Software Defined Networks: PCE

ANALYTICS Orchestration

• Computation

‒ Explicit path routing, application-specific, per

flow, per service, network guidance/ALTO, …

‒ E.g.: PCALC/TE, ALTO,

Service Chaining, FRR, …

• Forwarding State Programming

‒ RIB/FIB programming

‒ E.g.: PCEP, Openflow, Netconf, …

POLICY

Program for Optimised Experience

Harvest Network

Intelligence

Network

• Collection of Network/Infrastructure information

‒ Cisco ONE Controller: Collection of Multi-layer and

multi-domain topologies, state, configuration, policies,

statistics.

• Cisco SDN Path Computation Element (PCE) is the orchestration

component performing all centralised functions in SDN enabled networks

19


Software Defined Networks: PCE

Cisco SDN Path Computation Element

(SDN-PCE) is the orchestration component

performing all centralised functions in SDN

enabled networks

Apps overlays CDN

. . .

SDN PCE ONE Controller

Cloud *aaS Application

Layer

Network

Layer

Northbound APIs

DNS

Southbound APIs

20

Use Cases

21


Generic Use Case: Explicit Routing Routing Technology:

‒ Shortest Path, Destination Based Routing: Link-state and BGP routing

‒ Explicit Routing: Traffic Engineering

Shortest Path Routing

‒ Well known algorithm also allowing FRR mechanisms without additional signalling

‒ Not very flexible: shortest path only

Explicit Routing

‒ Efficient, allows better use of resources

‒ Not scalable: requires additional signalling on a per path base

Requirement:

‒ Flexible, Scalable and adaptive scheme for Explicit Routing

‒ Scalability should NOT be bound to number of paths

Applicability:

‒ Path diversity – Protection strategies

‒ Traffic Engineering (multi-layer / multi-domains)

A

B

C D

E

Shortest Path

Explicit Routing Path

22


Multi-Area/Level and Multi-AS Explicit Routing

End-to-end visibility at head-end

allows optimality

SDN-PCE needs a Topology feed

No inter-area IGP feed is required

ABR-4

ABR-1 ABR-2

PE-2

PE-1

ABR-3

PCEP

Area 1

Area 2

Area 0

Topology Info

23


Multi-Area/Level and Multi-AS Explicit Routing

ASBRs exchange their respective

LSDB/TED

ASBRs advertise topologies they

received from peering AS into

their domain PCE

SDN-PCEs are capable of

computing end-to-end inter-AS

paths

Each ASBR keeps control on

what to advertise

ASBR2

ASBR1

PE-1

PE-2

Topology Info

Topology Info

PCEP

AS 1

AS 2

Topology Info Topology Info

24


Use Case: nLight

A Generic Multi-Layer

Routing and Optimisation Architecture

Allows upper (IP/MPLS) layer to request an optical path

Router then signals to the optical layer the circuit request

Optical layer responds with Circuit-ID

O3

O2

O1

R1

R2 R3

25


Use Case: Optimised Content Delivery Network ALTO

Network

Layer

CDN Portal

Content

Delivery

Network

BGP-LS

ALTO API SDN PCE

ONE Controller

26


Enhanced DNS Resolution

Service foo

(ipaddr: IP2) Service foo

(ipaddr: IP1)

DNS

Link BW Utilisation Link BW Utilisation

2

1

3

3

Site-1

Site-2

Site-3


27


Mobile: Backhaul Congestion Notification

eNB S-GW P-GW

Internet

Other MOs

1

2

4 5

3

6

Orchestration Layer

Network Layer

Topology , State,

Resources, …

Mobile Layer

PCRF


28


Information Acquisition Example: SPs and CDNs

OTT/CDN • How to signal to the CDN a change in the link

resources availability ?

• Without re-advertising all affected SP prefixes !

• If CDN is able to understand some form of topology, the SP could advertise the change and instruct the CDN to use alternate peering point

SP/OTT Peering points


29

Requirements for an SDN Capable

Infrastructure

30


Use Cases Requirements A network layer capable of delivering connectivity and network

resources in a differentiated mode

Different applications have different specific network requirements

Applications requirements drive Network Services requirements

inside SP infrastructure

SP Networks must be capable of

‒ Retrieve Network Information: topology, state, resources, analytics, …

‒ Compute ad-hoc/explicit path on a per request (application, flow) base

‒ Route traffic based on flows, application, policy, encapsulation, tunnels,

…

Scalability and Simplicity MUST be part of the whole picture

31


Path Computation Element (PCE)

Commonality between all use cases: a network component with

global view of the infrastructure in all of its aspects:

‒ Topology, Layering, Resources, State, …

Centralised function: Path Computation Element (PCE)

On top of a distributed routing infrastructure

‒ Cope with Multi-Layer, Multi-Domain and Multi-encapsulation contexts

Optical Transport

IP/MPLS

TE Tunnels

Apps Overlay


32

Multi-Layer and Multi-Domain PCE

33


Use Cases Requirements

A network layer capable of delivering connectivity and network

resources in a differentiated mode

Different applications have different specific network requirements

Applications requirements drive Network Services requirements

inside SP infrastructure

SP Networks must be capable of

‒ Retrieve Network Information: topology, state, resources, analytics, …

‒ Compute ad-hoc/explicit path on a per request (application, flow) base

‒ Route traffic based on flows, application, policy, encapsulation, tunnels,

…

Scalability and Simplicity MUST be part of the whole picture

34


SP SDN WAN Orchestration (SDN-PCE) Solution Space

collector Programming

Bandwidth

Orchestrator

Visualisation/

Analytics

API

Elastic Clouds

Apps

Elastic Clouds

IP/MPLS

Optical

35


WAN Orchestration: SDN-PCE

Bandwidth and Topology Orchestration Platform

Enhanced data collection with interfaces to Cisco/3rd Applications

(e.g. Analytics and Modeling)

Predictive Simulation Engine

APIs for Cisco and 3rd party Apps

Leverages ONE Controller with extensions for PCEP, I2RS,

OpenFlow, BGP-LS, onePk

Supports persistent and transient demands

Agile development principles

Initial functions are demand and path placement across WAN

36



ABR-4

ABR-1 ABR-2

PE-1

ABR-3

PE-2

• Without end-to-end visibility, the ABR selection for path computation can lead into sub-optimal paths

• However, area (or AS) hop-by-hop computation is necessary due to segmentation of topology information

• Clearly a limitation of a distributed approach

Area 1

Area 2

Area 0

37



• End-to-end visibility at head-end allows optimality

• PCE only needs a BGP-LS feed

• No inter-area IGP feed is required

ABR-4

ABR-1 ABR-2

PE-2

PE-1

ABR-3 BGP-LS

PCEP

Area 1

Area 2

Area 0

38



• ASBRs exchange their respective LSDB/TED

• ASBRs advertise topologies they received from peering AS into their domain PCE

• PCEs are capable of computing end-to-end inter-AS paths

• Each ASBR keeps control on what to advertise

ASBR2

ASBR1

PE-1

PE-2

BGP-LS

BGP-LS

BGP-LS

PCEP

AS 1

AS 2

BGP-LS

39


Edge Router Edge Router

Hi-Pri TE-Tunnel

Hi-Pri Flow

Traffic-Steering App

PCEP OF/I2RS/1PK

Policy-Based Traffic Steering

PCEP

PBR

OF/I2RS/1PK

Set the right

QoS/Priority within the

box

Autoroute

Lo-Pri TE-Tunnel

Lo-Pri Flow

Bandwidth Orchestration

Data Collection

Network Programming

PCE

PCEP

Visualisation/ Analytics

OF/I2RS

40


Summary – Key Takeaways

Cisco has a clear “Programmatic and Orchestration” strategy

Framework to drive efficiency in transport from the infrastructure

layer all the way to applications

The Unified Platform covers the core and coupled with software

and services will enable Enterprise ready applications and

devices

Investments in core networking and Orchestration

‒ Edge, Aggregation, Core, Transport, Gateway functions

‒ Orlando: Mobility and Video

THE NETWORK IS THE WAY

41

Topology Information Acquisition

with BGP-LS

42


Extract Network Infrastructure Data

Why ? What do we want to do ?

‒ Traffic/Demand Engineering

‒ Application Traffic Optimisation / Network Guidance

‒ Service Chaining

‒ Virtualisation of: paths, flows, topologies, infrastructures, …

‒ Network Slicing

‒ Others…

What do we need

‒ A complete and exhaustive view of what’s in the reality underneath our apps.

BGP-LS

‒ North-Bound Distribution of Link-State and TE Information using BGP

‒ draft-ietf-idr-ls-distribution

43


Topology Acquisition: Redefine Terminology

Topology term is to be applied to a multi-layer infrastructure

Challenges:

‒ Define the exhaustive set of components of the infrastructure “topology”

‒ Define a data model through which a topology can be qualified

‒ Define inter-layer correlation

Separate functions

‒ Acquisition

‒ Topology Server/System

‒ Orchestration

‒ Path Computation

‒ Multi Layer Correlation

‒ Signalling

44


Topology Information

Traditional:

‒ A topology is what an LSDB can tell you about

‒ With some improvements like [isis|ospf]-metric-extensions drafts

‒ IOW: IGP+TE+MP-BGP

Reality:

‒ Implementation exist that extract layer-3 topology DB for application optimisation

purposes:

NPS/PCE/ALTO

‒ IETF proposal for carrying topological info in BGP: draft-ietf-idr-ls-distribution

‒ Main advantage: it works!

‒ Uses well known technology: IGP/BGP

‒ Address multilevel/multiarea and multi-AS cases

45


Requirements

Retrieve full LSDB info: any OSPF/ISIS/TE (sub)TLV

‒ Nodes, Links and Prefixes that are present in the LSDB

‒ Including [isis|ospf] TE Metric Extensions drafts

Support multi-area/level/AS deployments

‒ Reasonably straightforward

LSDB

LSDB LSDB

LSDB

AS1 AS2

46


Requirements

Aggregation / Abstraction

‒ Aggregate topology elements: links and nodes

‒ Similar to prefix aggregation

Extendibility

‒ Allow extension of topology

‒ Enhance LSDB information with policy originated info

‒ E.g.: inter layer peering points

‒ See RFC 5316

R1 R2

R3

O1 O2

O3

R1 R2

R3

O1 O2

O3

47


Multilayer Topology Information

Infrastructure is more than just ISIS/OSPF LSDBs

‒ Infrastructure is multilayer: from optical transport up to application overlay (CDN, Cloud, …)

‒ Infrastructure is about elements not used but accountable (e.g.: standby interfaces, backup paths, …)

‒ Analytics: Traffic Matrix, Stats, …

‒ Configurations, Policies

‒ …

Multiple Information Sources:

‒ Today means multiple APIs, Collectors, Servers, Orchestrations, …

Next Steps:

‒ A layer-agnostic, function independent, topology data model ?

Optical Transport

IP/MPLS

TE Tunnels

Apps Overlay

48


BGP-LS

Introduces the ability to “redistribute” an IGP topology into a BGP database

Redistribution takes the IGP LSDB as the input but…

Redistribution is NOT limited to the content of an LSDB

‒ Ability to extend/enrich topology data

‒ Ability to aggregate/hide/abstract topology data

Allows over-the-top topology export

‒ No need to access IGPs from external topology consumers

‒ Topology Servers/Systems are BGP-LS consumers: PCE, NPS/ALTO, …

BGP policy mechanisms can be used to control the redistribution and advertisement topology data

Control is kept by network operator

49


Information Acquisition Example: BGP-LS for PCE Servers

BGP-LS Speaker

BGP-LS RR

BGP-LS Speaker

1. IGP Redistribution into BGP-

LS

2. Advertisement of BGP-LS

NLRIs to RR

3. Advertisement of BGP-LS

NLRIs to PCE/ALTO server

• Benefits:

• Single API from network to PCE Srv

• Isolation of IGP from upper layers

• Leverage BGP Policies

• Allows virtualisation/aggregation of topology information

• Control is kept in network layer

50


BGP-LS and IGP Extensions

Latest extensions to ISIS/OSPF allow the advertisement of new subTLVs

‒ draft-previdi-isis-te-metric-extensions

‒ draft-ospf-te-metric-extensions

Delay, BW and Loss information

Allow IGP to carry resources utilisation/availability from a “real” use perspective

‒ Vs. TE-provisioning info

Goal: enhance SPF/CSPF/xSPF tree computation with additional metrics

‒ Natural extension to the 4 metrics of ISIS (Default, Delay, Expense, Error)

BGP-LS is agnostic regarding IGP data

‒ Transparently advertise IGP TLVs

‒ Extensions to IGPs are de facto integrated into BGP-LS

51


BGP-LS: Elements

New BGP objects: NLRI, AFI/SAFI, Attribute

Link State NLRI

‒ Describe a topology element: link, node or prefix

‒ Different NLRI types

Link State Attribute

‒ New attribute describing a topology element: link, node or prefix

52


BGP-LS: Example

RtrA is described by

‒ Node NLRI: RtrA’s Router-ID/System-ID

‒ Node Attribute: TE-Capabilities, ISIS level/area, MT-ID, …

Link RtrA-RtrB is described by:

‒ Link NLRI: <RtrA, RtrB> tuple (directional), interface addresses, …

‒ Link Attribute: TE subTLVs, …

Link RtrB-RtrA is described by:

‒ Link NLRI: <RtrB, RtrA> tuple (directional), interface addresses, …

‒ Link Attribute: TE subTLVs, …

Prefix PfxAB is described by:

‒ Prefix NLRI: <Originator Node, addr/mask (v4/v6)>

‒ Prefix Attributes: Route Tags, Route Type, …

RtrA

PfxAB

RtrB

53


Information Acquisition Example: Multi-Layer (IP/MPLS & Optical) PCE

• Multi-layer applicability of PCE by acquiring topology from different layers

• Allows upper (IP/MPLS) layer to request (from PCE) an optical path

• Router then signals to the optical layer

O3

O2

O1

OSPF-Optical L0-BGP-LS

BGP-LS

PCEP

R1

R2 R3

BGP-LS with

L3 Topology

54


Next Steps: Topology Acquisition Topology term is to be applied to a multi-layer infrastructure

Challenges:

‒ Define the exhaustive set of components of the infrastructure “topology”

‒ Define a data model through which a topology can be qualified

‒ Define inter-layer correlation

Separate functions

‒ Acquisition


‒ Orchestration

‒ Path Computation

‒ Multi Layer Correlation

‒ Signalling

‒ APIs

55


Topology Acquisition

Functions Definitions

‒ Acquisition


‒ Orchestration

‒ APIs

Topology

Acquisition Topology

Acquisition

Topology

DB

Topology

System

Topology

Acquisition Topology

Acquisition

Topology

DB

Topology

System

Topology DB

Orchestration:

PCE/NPS/CDNI/Clo

ud, …

1

2

3

4

4 4

Clients Requests (e.g. PCC/ALTO)

56


Cost Matrix

Cost Matrix

Cost Matrix

Network Topology Virtualisation From Topology to Views

View-1 Grp-1 Grp-2

Grp-6 Grp-3

Grp-5 Grp-4

View-2 Grp-1

Grp-6 Grp-3

Grp-5

View-3 Grp-2

Grp-5 Grp-4

Routing Databases

Policy

Databases

State & Performance Data

Location

Information

Traffic Matrix …

57


Summary: Topology Acquisition

Requirements and BGP-LS

BGP-LS is the first step in network information acquisition

‒ Allows over-the-top topology export

‒ Gives control to exporter (i.e.: infra)

‒ Allows aggregation, virtualisation and customisation of advertised topologies

Use cases: multiple “Topology Servers” or “Topology Consumers”

‒ Network Positioning System (NPS/ALTO)

‒ Path Computation Element (PCE)

‒ Multi-level

‒ Multi-domain

‒ Multi-layer

58


Summary: Topology Acquisition

Requirements and BGP-LS Each layer has its own mechanisms for defining, structuring and delivering topology

information

‒ Optical: Optical-OSPF

‒ IP: IGPs/BGP

‒ TE: PCEP

‒ Application overlays: DHT, XMPP, app-specifics, …

Emerging requirement:

‒ Consolidated structured definition of a topology set

‒ Common and universal API for extracting Topology Information from any network in the

infrastructure

Work in progress in IETF: I2RS WG

‒ BGP-LS is a first attempt

59

Summary


Summary Software Defined Networks allows network infrastructure programmability

Better ad-hoc routing based on specific and individual application requirements WITHOUT compromise network scalability and ease of operations

Cisco architecture is articulated around the SDN-PCE and ONE Controller components that:

‒ Collects through various southbound APIs the state, configuration, topology and resources utilisation information from the infrastructure

‒ Implements a variety of path computation algorithms allows to deliver services such as congestion notification, network guidance, traffic engineering, demand engineering, explicit routing, …

‒ Implements northbound APIs in order to allow application elements to request network services

61


Summary

Cisco SDN-PCE and ONE Controller is more than just separating

control and data planers and opens applicability of additional

signalling protocols

Cisco SDN-PCE and ONE Controller allows a gradual

enhancement of routing paradigms in conjunction with traditional

routing methods

Cisco approach in Service Providers Networks takes into account

the need for apply centralised functions requiring an exhaustive

and end to end view of the network infrastructure

62


Complete Your Online Session

Evaluation

Give us your feedback and receive

a Cisco Live 2013 Polo Shirt!

Complete your Overall Event Survey and 5

Session Evaluations.

Directly from your mobile device on the

Cisco Live Mobile App

By visiting the Cisco Live Mobile Site

www.ciscoliveaustralia.com/mobile

Visit any Cisco Live Internet Station located

throughout the venue

Polo Shirts can be collected in the World of

Solutions on Friday 8 March 12:00pm-2:00pm

Don’t forget to activate your

Cisco Live 365 account for

access to all session material,

64

communities, and on-demand and live activities throughout

the year. Log into your Cisco Live portal and click the

"Enter Cisco Live 365" button.

www.ciscoliveaustralia.com/portal/login.ww

http://www.ciscoliveaustralia.com/mobile

http://www.ciscoliveaustralia.com/portal/login.ww

brkspg-2662d2zmdbbm9feqrf.cloudfront.net/2013/anz/pdf/brkspg-… · · 2013-03-07... (path...

Documents