Research on Clean Slate Internet Prof. Nick McKeown at Stanford First concept: ETHANE (2004) Follow up: OpenFlow (2008) Research on Optical Transport

Transcription

1

2

3 Research on Clean Slate Internet Prof. Nick McKeown at Stanford First concept: ETHA (2004) Simplified, user-friendly policy control Admission and forwarding all centrally controlled Follow up: OpenFlow (2008) Centrally controlled forwarding and packet processing Network operating system Research on Optical Transport Ciena and Stanford (2009/2010) European research (2010/2011)

4 OpenFlow Channel Client Switch Controller OpenFlow Channel Switch Client Process: SW agent terminates TCP session with Controller Controller pushes flow match and actions to agent Mapped to switch forwarding table actions Modify and forward to port X Forward to Controller Drop Switch returns packet counts, port state to the Controller Switch does not understand packets May forward complete packet to Controller Controller may send packet to switch for forwarding into the datapath

5 1.

6

7 Industry organization dedicated to the standardization, promotion, and adoption of Open Software Defined Networking. ONF Membership Founded in members Who s who in the industry ONF Board and Administration TAG CAB TLC Working Groups Market Education Architecture Extensibility Config-Mgmt Testing Driven by End-Users Optical Transport Board: Google, Microsoft, Facebook, Deutsche Telekom, NTT, Verizon, Goldman-Sachs, Prof. McKeown and Prof. Shenker Wireless Migration NBI

8 Officers Chair Lyndon Ong, Vice Chairs - Vishnu Shukla (Verizon), Maarten Vissers (Huawei) Participating vendors (ADVA, ALU, BTI, Cisco, Coriant, Cyan, ECI, Fiberhome, Fujitsu, Infinera, Juniper, Metaswitch, C, PMC-Sierra,Vello, ZTE and others) Carriers (DT, ESNet, ETRI, KT, NTT, Telefonica, Verizon) Charter Extend SDN/OpenFlow to L0/L1 Transport Networks ds/working-groups/charter-optical-transport.pdf

9 Application Layer Business Applications NBI NBI NBI Common APIs Diverse applications Open SW development environment Common NorthBound Interfaces to apps Control Layer Network Services Controller Framework Open Platform Controllers from Open Source SW Infrastructure Layer SBI Standard Interfaces Standard, programmatic SouthBound Interfaces such as OpenFlow

10 Transport Network Attributes Heterogeneous technologies, including multiple layer networks Operability across technologies common base Information Model Wide area environment, affecting Signaling Control Network behavior* Service Level Assurance OAM/monitoring capabilities Event notification Range of survivability mechanisms, both locally driven and driven at higher level Protocol Impacts Ability to extend OpenFlow to additional technologies, esp. OTN L1/L0 Ability to support discovery of connectivity, compatibility Ability to support monitoring of performance and fault detection Ability to support survivability mechanisms, including locally driven

11 Optical Transport SDN Framework Enterprise Service Provider NBI Client A SDN App Client B SDN App CVNI SBI e.g., OpenFlow CDPI SBI e.g., OpenFlow Controller Domain Controller Virtualizer SP Controller Domain Controller Client Switch Switch Client CDPI Control Data Plane Interface (ONF Whitepaper) CVNI Control Virtual Network Interface NBI NorthBound Interface

12

13 Match extensions for L0 and L1 Match on wavelength, tributary slot Specify outgoing characteristics port, wave, tributary slot, TPN Port extensions for L0 and L1 Define ports to have L0 and L1 characteristics Express port limitations such as clients supported -based adjacency discovery -based mechanism such as TTI, LLDP Push results to the controller rather than having controller micromanage the process Aim to add to the next version of the OpenFlow specification Being prototyped by Joint OIF/ONF group

14 OpenFlow-enabled Transport SDN Whitepaper (05/2014) SDN Architecture 1.0 (06/2014) Optical Transport Use Cases (08/2014) Requirements Analysis for Transport OpenFlow/SDN (09/2014) Optical Transport Protocol Recommendations 1.0 (in progress) Optical Transport Information Model (in progress) Optical Architecture Transport documents - document

15 OpenFlow is defined to work on unidirectional flows Identified by match fields Subjected to specified actions Transport assumes relationships between flows User data flow and OAM/control flow E.g., L1 data plus OTN overhead; L0 wavelength plus OSC; GACH, etc. For L1/L0, this cannot be directly forwarded to or sourced from the Controller Bidirectional flows OAM reverse indications and monitoring Linked actions, e.g., protection Transport s may provide Autonomous Functions Generation and processing of performance monitoring Protection switching, blocking on mis-connection Based on OAM and often very time-sensitive

16

17 Prototype and Test Initial Extensions Joint OIF/ONF Prototype Demonstration Validate extensions, identify clarifications or corrections needed Document guidelines and recommendations

18 Follow-on Extensions Socialize requirements Integrate into OpenFlow design/principles Methods to support OAM/Monitoring Ability to create/control Monitoring Points Ability to provide notification of events Methods to support Protection Esp. local flow modification between Working and Protect flows Methods to support Multilayer Explicit control over adaptation between layer networks/fabrics

19