ONOS Packet/Opccal
ONOS Packet/Op-cal Marc De Leenheer ONRC & ON.Lab Review Mee-ng May 12th, 2015 Problem Statement ¡ Today IP packet and transport networks are separate. ¡ They are planned, designed and operated separately by different teams. ¡ This leads to significant inefficiencies. ¡ They are subject to under-‐u-lized networks with significant pre-‐planning and highly over-‐provisioned for worst case. ¡ A lot of the path planning in these networks is off-‐line. Given these considera-ons, WAN links are typically provisioned to 30-‐40% average u?liza?on. This allows the network service provider to mask virtually all link or router failures from clients. Such overprovisioning delivers admirable reliability at the very real costs of 2-‐3x bandwidth over-‐ provisioning and high-‐end rou-ng gear. S. Jain, et. al., “B4: Experience with a Globally-‐Deployed So>ware Defined WAN,” SIGCOMM 2013. Mul--‐Layer Network without Converged Control Plane Logical Tunnels Full Mesh MPLS C A ROADMs E IP IP Mul-ple protec-on modes (up to 4 -mes BW) Primary IP Routers IP IP B P1 IP Protected R1 ROADM IP IP Peak rate provisioning P3 IP P5 IP P4 P2 IP IP Sta-c planning R7 R4 R2 ROADM Light Paths ROADM Lightpaths D ROADM ROADM ROADM R3 R5 ROADM R6 Conceptual Solu-on: Mul--‐Layer SDN Control BW Calendaring Control Apps Config Apps Mgmt Apps ONOS 1. Centralized control of packet and optical 2. Multi-layer optimization based on availability, economics and policies Datacenter 2 Datacenter 1 Packet Network Optical circuit re-routed Op-cal Network Implementa-on ¡ Code is king ¡ Less is more ¡ Vendor & protocol neutral (what about technology neutral?) ¡ Scalability, high availability, performance ¡ Work focused on the three SDN layers ¡ Data plane ¡ Control plane ¡ Applica-ons Implementa-on – Data Plane ROADMs Packet Switches ¡ Open and standardized interface to forwarding plane ¡ Open and standardized interface to forwarding plane? ¡ Reality ¡ Reality ¡ OpenFlow ¡ Available today in many products ¡ Legacy protocols such as TL1 ¡ Vendor specific Built an op-cal emula-on pla^orm with our partner Infoblox h`ps://github.com/FlowForwarding/LINC-‐Switch Implementa-on – Control Plane ¡ Southbound protocol for ROADMs ¡ ONF Op-cal Transport Working Group ¡ OpenFlow 1.3+ experimenter messages Control Apps Config Apps Mgmt Apps ¡ Discovery ¡ Automa-c L3 topology discovery (LLDP) ¡ Sta-c configura-on of L0 topology ¡ L0 discovery work in progress ¡ Packet and op-cal layer restora-on ¡ First try packet layer, then op-cal layer ¡ Easily add mul--‐layer protec-on and restora-on mechanisms SDN Network Opera-ng System OpenFlow Implementa-on – Applica-ons Mul--‐Layer GUI Bandwidth on Demand Applica-on Intent Framework: APIs, Policy Enforcement, Conflict resolu-on Distributed Core Southbound Core API Southbound OpenFlow Bandwidth Calendaring Hardware Interfaces Vendor Interfaces ¡ TL1 ¡ PCEP ¡ Open source? Open Interfaces ¡ OpenFlow 1.3+: ONF Op-cal Transport Working Group Mul--‐Layer Abstrac-ons ¡ Converged topology model WDM Port ¡ Control both packet and op-cal layers ¡ Vendor-‐neutral ROADM model WSS ¡ Allows adding addi-onal layers, e.g., OTN OTN WSS ¡ Mul--‐Layer PCE ¡ Constraints and resource management ¡ Protocol-‐agnos-c tunnel providers ¡ Supported in intent framework WSS Line-‐side Port (L-‐port) T-‐port Transponder ¡ Wavelength con-nuity, bandwidth, latency, … ¡ Tunnel sub-‐system Line-‐side Port (L-‐port) WSS WDM Port WDM Port Proof of Concept On-Demand Optical Bandwidth Menlo Park, CA SDN Solu?ons Showcase Open Networking Summit 2015 June 15-‐18, Santa Clara, CA BGP Router Multi-layer GUI Multi-instance ONOS OF provider O[awa, Ontario Ciena TL1 provider Fujitsu TL1 provider Richardson, TX Huawei PCEP provider Plano, TX Summary ¡ Building converged packet/op-cal control for service providers ¡ Scalability, HA, performance ¡ Poten-al to drama-cally decrease CAPEX & OPEX ¡ Innova-ve services using DevOps model ¡ Need the right abstrac-ons ¡ Intent framework ¡ Mul--‐layer graph ¡ Southbound interface BW Calendaring Control Apps Config Apps Mgmt Apps ONOS 1. Centralized Control of packet and optical 2. Multi-layer optimization based on availability, economics and policies Datacenter 2 Datacenter 1 Packet Network Optical circuit re-routed Op?cal Network Software-defined Transformation of Service Provider Networks Join the journey @ onosproject.org ROADM Emula-on Basics ¡ Emulates op-cal layer topology from predefined table ¡ Includes characteris-cs of op-cal cross connect and Packet to Op-cal Link Interface (Add/Drop) ¡ Ports, links and switches are remotely reconfigurable by Mininet ¡ Supports OpenFlow 1.3+ Op-cal Add/Drop match ac-ons ¡ Supports failure scenarios of links, ports, and ROADM ¡ Work in progress ¡ Emulates channel signal/power measurement ¡ Regenerator support ROADM Module ROADM Module O P M DROPs ADDs Forwarding Model for ROADMs ¡ Match/ac-on abstrac-on for ROADMs ¡ ROADM has three func-ons: add, drop, and forward ¡ Match is really about wavelength provisioning packets packets ROADM ROADM Add Match Packet port and traffic type Ac-on Transponder uses lambda and output to op-cal port Drop ROADM Forwarding Match Op-cal port and lambda Ac-on Output to op-cal port (easy to extend when considering regenerators) Match Op-cal port and lambda Ac-on Transponder uses lambda and output to packet port Forwarding Model for Packet and ROADM Layer IP IP ROADM IP Forwarding" Constraints" Match! Ac-on! Match! Tuple on port3 Encaps IP DESTxxx IP, DESTxxx Ac-on! Egress! Values! Capacity 10GbE Lambda Forwarding" Ac-on! IP Forwarding" ROADM Match! Ac-on! IP, Destxxx Pop IP Packet on port3 Match! Tuple Constraints" Ac-on! Forward to port12 Egress! Values! Capacity 10GbE LAG No Cost 10 LAG Cost Match! ROADM Match! No 10 Constraints" Ac-on! TPND port 5 PushOCH Lambda 66 Forward to Lambda 66 WDM port1 Egress! Lambda Forwarding" Values! Match! Capacity MUXPDR Cost Loss NF PMDest Dispest 100Gb Yes 250 2.5 4.75 0.1 40 l66 on port2 Ac-on! Forward WDM port6 Lambda Forwarding" Constraints " Egress! Values! Capacity 100Gb REGEN Cost Loss NF PMDest Dispest No 250 2 4.25 0.05 25 Match! l66 on port3 Ac-on! Match! Constraints" Ac-on! Forward TPND l66 on TPND POP OCH and egress port3 port3 Egress! Values! Capacity 40Gb LAG NA Cost 100 Transport Network Metering Model IP Metering Packets dropped Total packets Queue Port overflow status Queue Overflow count IP OAM Delay BFD Ji`er Loss Metering Errored OTU-‐ seconds Frame/ Severely OCH/ errored TPND seconds ROADM ROADM ROADM OAM OTU-‐ LOS Frame/ LOF OCH/ TPND Protec-on LOL WDM LBC Metering Errored OTU-‐ seconds Frame/ Severely OCH/ errored TPND seconds OAM OTU-‐ LOS Frame/ LOF OCH/ TPND Protec-on LOL WDM LBC Metering Errored OTU-‐ seconds Frame/ Severely OCH/ errored TPND seconds Metering Packets dropped Total packets Queue Port overflow status Queue Overflow count OAM OTU-‐ LOS Frame/ LOF OCH/ TPND Protec-on LOL WDM LBC Red items implies access only if a regenerator is used OAM Delay BFD Ji`er Loss Ver-cal Integra-on: Packet Switches Features Control Apps Features Control plane Hardware Config Apps Mgmt Apps ne Control p la SDN Network Opera-ng System Closed Packet switches are undergoing this transforma-on right now! Hardware Agent OS Loader Merchant Silicon Whitebox Legacy Ver-cal Integra-on: ROADMs ROADM controller Control Apps Control and config of WSS and transponders Signal Monitoring and Adjustment Metering and alarms fiber Why is this de-‐aggrega-on not happening? pass through add/drop WSS transponder Mgmt Apps SDN Network Opera-ng System mux demux Config Apps Agent OS HAL controller Hardware Whitebox Legacy What Makes Op-cal Devices Different? ¡ “We need specialized mix of L0, L1, and L2 func-ons” ¡ “Physical impairments are too complex to monitor and manage externally” ¡ “Our analog transmission system is custom designed” ¡ “Every vendor has his own DSP which is proprietary and without programmable dynamics ” ¡ “It’s impossible to control all configura-on and forwarding at scale” ¡ “You can’t achieve sub-‐50ms failovers” ¡ And so on… None of this is fundamental! De-‐aggrega-on is inevitable Open Op-cal Hardware ¡ Hardware Abstrac-on Layer ¡ Hides op-cal impairments, thermal instability, power balancing, etc. ¡ Can autonomously fix problems or perform maintenance ¡ OS Agent OS HAL ¡ Server-‐like environment for switches ¡ Manages various hardware sensors ¡ Boot loader, u-ls, switch management, etc. ¡ Agent controller Hardware Whitebox Legacy ¡ Open and standardized interface for forwarding, configura-on, and observability Invi-ng all vendors to join us! Call to Ac-on ¡ Open and standardize hardware interfaces ¡ Achieve control plane interoperability ¡ Eliminate vendor-‐specific domains Control Apps Config Apps ¡ Achieve L0 data plane interoperability SDN Network Opera-ng System ¡ Remove vendor-‐specific approaches (EMS & NMS) Agent OS HAL Hardware Whitebox Mgmt Apps X controller X X X Legacy ¡ If exis-ng vendors don’t take ac-on, others will step in! X
© Copyright 2024