Software Defined Networks in SP Environments

Transcription

1 Software Defined Networks in SP Environments Architecture, Elements and Use Cases Stefano Previdi Distinguished Engineer Cisco Systems Darmstadt, October 25, Cisco and/or its affiliates. All rights reserved. 1

2 Cisco SDN approach POLICY Orchestration ANALYTIC S Harvest Network Intelligence Program for Optimized Experience Application Developer Environment Networ k Analysis and Monitoring, Performance and Security Harvest Network Intelligence Program for Optimized Experience z Network Elements and Abstraction 2

3 s gres o r P In Use Case: ioverlay Architecture Overlay client uses service from Server layer The two layers are independent and decoupled I for Information: all the required information is flowing between the two layers Client or Overlay R3 R1 R2 O1 Server O2 O3 i for Information flowing between layers at the UNI boundaries 3

4 Depl oyed Use Case: Content Delivery Network CDS-IS Service Router with NPS CDN Portal? 4

5 s gres o r P In Mobile: Backhaul Congestion Notification Internet GTP enb S-GW GTP or PMIP P-GW Other MOs Orchestration Layer and State BGP-LS, PCEP, ) Network Layer IGP Metric Extensions for BW and Delay information PCEP for LSP state information BGP-LS for topology (including IGP Metric Extensions) 5

6 s gres o r P In 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 6

7 On the question of Centralized vs Distributed fully distributed Logically centralized ( on-box ) (servers) 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 Changes: Efficient plain vanilla Layer-3-style forwarding Rapid response to data-plane events / packet forwarding Simplicity of Control- and Data-Plane Integration** ** 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: 7

8 Network Information Acquisition 8

9 Information Why? What do we want to do? Traffic/Demand Engineering Application Traffic Optimization Service Chaining Virtualization of: paths, flows, topologies, infrastructures, Segment Routing Others What do we need A complete and exhaustive view of what s in the reality underneath our apps. System AS#1 AS#2 9

10 Requirements Aggregation / Abstraction Aggregate topology elements: links and nodes Similar to prefix aggregation R 3 R 1 R 2 O 1 O 2 O 3 Extendibility Allow extension of topology Enhance LSDB information with policy originated info E.g.: inter layer peering points R 3 R 1 R 2 O 1 O 3 O 2 10

11 Requirements Multi-layer / Multi-domain The same mechanism must be re-usable between any pair of layers Multilayer Apps Overlay TE Tunnels IP/MPLS Optical Transport 11

12 Acquisition DB Functions Definitions Acquisition Server/System Orchestration APIs Orchestration: PCE/NPS/CDNI/ Cloud, 4 DB 4 System System 4 DB 3 1 Acquisitio n Acquisitio n Acquisitio n Acquisitio n 2 12

13 Information Acquisition Example: BGP-LS for NPS/ALTO Servers Benefits: Single API from network to ALTO Srv Isolation of IGP from ALTO Leverage BGP Policies 3. Advertisement of BGP-LS NLRIs to NPS/PCE server Allows virtualization/aggregation of topology information 2. Advertisement of BGP-LS NLRIs to RR Control is kept in network layer 1. IGP Redistribution into BGPLS BGP-LS Speaker BGP-LS RR BGP-LS Speaker 13

14 Servers/Systems and Network Programmability PCE, NPS, ALTO 14

15 Requirements: Network Virtualization Segment Routing Virtualization multiple overlays (application, vpn) share the network Flow engineering traffic is engineered on a per-flow basis, maximize utility High Frequency overlays may change their per-flow path at high frequency Simplicity 15

16 Multi-Domain / Multi-Layer PCE e Servic aul Backh e Servic aul h k c a B Services Services Inter PCE Tunn el el Tunn Tunnel Inter-layer PCE APIs Inter-layer PCE APIs Tunn el el Tunn Tunnel Link Link Inter PCE IP/MPLS λ IP/MPLS λ λ Inter-layer PCE APIs Inter-layer PCE APIs λ λ λ r Fibe r Fibe DWDM DWDM Inter PCE 16

17 Cisco Approach: Multilayer/Multidomain NPS/PCE Northbound APIs Path Request APIs (PCEP) East/West APIs Network Guidance APIs (ALTO, NPS) Inter-PCE APIs: Redundancy, Load Share, Orchestration layer Management: Multilayer, Multidomain, Aggregation, Virtualization, Stitching, Active/Passive Information Databases: topologies, analytics, traffic matrix, inventory, locations, Algorithms and Service computations: PCALC, ALTO, NPS, SPF/RSPF, CDNI, Southbound APIs /State/Resources Information Acquisition APIs (BGP-LS/BGP/IGPs/ ) State Signaling APIs (PCEP, OF, ) Infrastructure Optical IP/MPLS L2 Switching Video Mobile DC Networ k DC Comput e DC Storage... 17

18 Summary: Cisco Perspective on SDN Cisco continues to pursue software defined networking SDN includes (1) network overlay virtualization (2) programmatic device APIs (3) network functional abstractions Cisco s portfolio already includes several key components of an SDN solution PCE/PCEP, ALTO, OpenFlow, OpenFlow is a protocol, not an architecture OpenFlow primarily define a protocol for packet forwarding Migration to SDN will be evolutionary Cisco will take a use-case driven approach Cisco will in the near term engage with specific customers on SDN and OpenFlow as a prototype technology Emerging upper level requirements Network Virtualization, Slicing Service Chaining 18

19 Thank you. 19