 Research on Clean Slate Internet Prof. Nick McKeown at Stanford First concept: ETHANE (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)  Process: SW agent terminates TCP session with Controller Controller pushes flow match and actions to agent Controller OpenFlow Channel OpenFlow Channel Mapped to switch forwarding table actions Modify and forward to port X Forward to Controller Drop Switch Client Switch returns packet counts, port state to the Controller Switch Client Switch does not “understand” packets May forward complete packet to Controller Controller may send packet to switch for forwarding into the datapath 1.     Industry organization dedicated to the standardization, promotion, and adoption of Open Software Defined Networking. ONF Membership Founded in 2011 125+ members Who’s who in the industry  Driven by End-Users Board: Google, Microsoft, Facebook, Deutsche Telekom, NTT, Verizon, Goldman-Sachs, Prof. McKeown and Prof. Shenker Market Education ONF Board and Administration  TAG Architecture CAB Extensibility TLC Config-Mgmt Working Groups Testing Optical Transport Wireless Migration NBI • Officers – Chair – Lyndon Ong, lyong@ciena.com – Vice Chairs - Vishnu Shukla (Verizon), Maarten Vissers (Huawei) – Participating vendors (ADVA, ALU, BTI, Cisco, Coriant, Cyan, ECI, Fiberhome, Fujitsu, Infinera, Juniper, Metaswitch, NEC, PMC-Sierra,Vello, ZTE and others) – Carriers (DT, ESNet, ETRI, KT, NTT, Telefonica, Verizon) • Charter – Extend SDN/OpenFlow to L0/L1 Transport Networks – https://www.opennetworking.org/images/stories/downloa ds/working-groups/charter-optical-transport.pdf Application Layer Control Layer NBI NBI NBI Business Applications Network Services SBI Controller Framework Infrastructure Layer Common APIs Open Platform Standard Interfaces • Diverse applications • Open SW development environment • Common NorthBound Interfaces to apps • Controllers from Open Source SW • Standard, programmatic SouthBound Interfaces such as OpenFlow  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 NE connectivity, compatibility Ability to support monitoring of performance and fault detection Ability to support survivability mechanisms, including locally driven Optical Transport SDN Framework Service Provider Enterprise Client A SDN App Client B SDN App NBI Virtualizer SP Controller CVNI SBI e.g., OpenFlow CDPI SBI e.g., OpenFlow Switch Client Domain Controller Domain Controller Controller Switch Client NE NE NE NE CDPI – Control Data Plane Interface (ONF Whitepaper) CVNI – Control Virtual Network Interface NBI – NorthBound Interface NE NE NE NE NE NE NE NE NE NE  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  NE-based adjacency discovery NE-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 • 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 Transport documents https://www.opennetworking.org/working-groups/optical-transport Architecture document – https://www.opennetworking.org/sdn-resources/sdn-library/technical-papers  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 NEs may provide Autonomous Functions Generation and processing of performance monitoring Protection switching, blocking on mis-connection Based on OAM and often very time-sensitive  Prototype and Test Initial Extensions Joint OIF/ONF Prototype Demonstration Validate extensions, identify clarifications or corrections needed Document guidelines and recommendations  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