Light Reading BTE_SDNtoolbox_June_2015
1 like593 views
The document discusses the transport SDN framework and APIs. It provides an overview of the transport SDN toolkit, including the SDN framework, APIs, and a global transport SDN prototype demonstration. The framework uses a three-layer model with an infrastructure layer containing network elements, a control layer with multiple controllers, and an application layer. Transport SDN APIs are being developed to standardize the southbound and northbound interfaces. The demonstration showed a multi-domain, multi-vendor transport SDN deployment across five carrier labs and nine system vendors.
Light Reading BTE_SDNtoolbox_June_2015
- 1. Transport SDN Toolkit Network Orchestration Controller Hierarchy Multi-domain Architecture SDN Framework SDN APIs Service Request Path Computation Topology Providing carriers with essential tools in the Transport SDN toolkit • How to apply SDN to a carrier’s multi-domain, multi-layer transport network • Transport SDN API specifications to allow deployment of SDN applications • Prototyping and testing of real implementations for experience and interoperability
- 2. SDN Benefit and Challenges SDN Software Availability & Functionality Network Structure & Technology Adaptation of Customer Processes Successful IOC/SDN deployment Benefit: Totally automated, programmable, integrated and flexible network – leveraging the installed base in and optimized way. Challenges: Technical: • Agree on standardized architectures and abstraction/virtualization models – • Performance of centralized systems & OF Commercial: • Open Source business models – • New business models leveraging SDN Organizations: • Adapt processes to leverage SDN flexibility Availability: • Carrier grade SDN systems for field deployments • Availability of new network technology in field deployments & legacy network
- 3. What is the Transport SDN Framework? Infrastructure Layer Control Layer Applica4on Layer Business Applica4ons NBI Controller Framework NBI NBI Network Services • SDN 3 Layer Model • Application, Controller, Infrastructure Common APIs Standard Interfaces Open Pla5orm • How is this applied to a Carrier’s Transport Network? • Multiple Layers • Multiple Vendors • Multiple Domains, e.g., Vendor or Administrative
- 4. Multi-Domain Carrier Transport SDN Framework Infrastructure Layer – contains Network Elements Multi-domain/multi- technology • Geographic/ Administrative domains (e.g., metro, core) • Technology domains (L0/1/2) • Vendor-specific domains Accessed via SouthBound Interface of Controller Infrastructure Layer Domain 1 NE NE NE Domain 2 NE NE NE Domain 3 NE NE NE SBISBI
- 5. Multi-Domain Carrier Transport SDN Framework Control Layer • Carrier network will likely have multiple controllers • Administrative and other reasons • May have hierarchical controllers • SBI-type interface from Parent to Domain controller Control Layer Infrastructure Layer Domain 1 NE NE NE Domain 2 NE NE NE Domain 3 NE NE NE Parent Controller Domain Controller Domain Controller Domain Controller SBISBI
- 6. Multi-Domain Carrier Transport SDN Framework Application Layer • Business apps • Network apps • Orchestration Isolated from Controller • Accesses Control layer via NorthBound Interface such as REST/JSON Application Layer Control Layer Infrastructure Layer Domain 1 NE NE NE Domain 2 NE NE NE Domain 3 NE NE NE Network Orchestrator Parent Controller Domain Controller Domain Controller Domain Controller SBI NBI SBI Cloud Orchestrator Compute Storage
- 7. SDN Framework Validation Tested in 2014 OIF/ONF Demonstration • 5 Carrier Labs • 2 Consulting Carriers • 9 System Vendors • L2 and L1 Switches • Greenfield and Brownfield environments • SDN Controller and EMS • 3 Layer SDN Framework Model • Infrastructure Layer with Real NEs • Controller Layer with multiple implementations • Application Layer with network orchestration 7
- 8. The Interfaces: Transport SDN SBI SDN SouthBound Interface • Open interface for Network Element switching and forwarding control • Logical Switch abstraction • Model both physical & virtual • E.g. OpenFlow • Multi – Layer Support • L0 - Optical/WDM/OCH • L1 – TDM/OTN/ODU • L2 – Packet/Ethernet/MPLS-TP • Utilizes Common protocol neutral Information Model Domain 1 NE NE NE User App Domain Controller Protect App Optimize App SBI
- 9. The Interfaces: Transport SDN NBI SDN NorthBound Interface • Common interface for controlling and analyzing networks • BoD services • Cross-domain provisioning • Enabling Analytics • Flexible interface • Different levels of control • Potential abstraction • Virtual networks • Utilizes Common Information Model • Consistency rather than divergence Domain 1 NE NE NE User App Domain Controller Protect App Optimize App NBI
- 10. • Standards talking mainly about service creation/restoration • Packet layer to steer the flows (OpenFlow as standard exists) • Transport layer to create services (under development ONF/OIF/ IETF/etc…) • Operators may want to solve other problems • Integration problems between vendors • Interworking between layers • Planning and equipment management • Optimization of the network General Use Cases – What are use cases driving the NBI?
- 11. Flavors of service creation use case Multi-vendor support Network or Transport as a Service (NaaS / TaaS) Datacenter interconnections Multi-layer network management Data Center IP Router DWDM Transport Control Vendor A Vendor B Vendor C Ethernet ODU Och Automatic load dependent fast service creation One standardized SDN control interface for easy integration of 3rd party vendors Multilayer optimized L0-3 system with • common workflows • automatic routing • interworking Fully automate service requests incl. network planning and equipment configuration Matching Hypergrowth in data volume Extremely dynamic traffic pattern Dealing with Heterogeneous technologies Optimized layer usage Addressing Non- automated Operational processes High network complexity Dealing with Different control interfaces Missing control IF between vendors Automated service creation covering L0 to L3 Addressing Time to service Ease of operation Service differentiatio n Service Management Elastic bandwidth provisioning Creation of elastic services with automatic or “on request” changes in bandwidth Dealing with Statistical bandwidth sharing Dynamic data flow changes
- 12. What does the NBI access? A look at the ITU-T ASON Control Model ITU-T ASON Model Identifies key control elements • Call and connection control • Routing and topology • Resource management • Protocols 12 ASONCallControl ConnectionControl Directory Signaling PC Routing PCTAP LRM Discovery Agent RoutingControl Net TopologyPath Query ASON Control Components* * Figure does not imply specific distribution of components, e.g., centralized or distributed
- 13. APIs to Access Functions: Service Creation External APIs to ASON Control Functions • Request service from the network • Service Level determines call control processing • Control virtual network slice • Allocate dedicated resources for connection 13 ASONCallControl ConnectionControl Directory Signaling PC Routing PCTAP LRM Discovery Agent RoutingControl Net TopologyPath Query SNC SNC + Reroute Service Level Business Application Business Application Virtualization/AbstractionASON Control Components* * Figure does not imply specific distribution of components, e.g., centralized or distributed
- 14. APIs to Access Functions: Information Retrieve information from the network • Request Path Computation between endpoints • Network returns path (plus alternatives, backup paths) • Request Topology information • Invoke analytics or external path computation algorithms 14 ASONCallControl ConnectionControl Directory Signaling PC Routing PCTAP LRM Discovery Agent RoutingControl Net TopologyPath Query SNC SNC + Reroute Service Level Business Application Business Application Virtualization/Abstraction ASON Control Components* * Figure does not imply specific distribution of components, e.g., centralized or distributed
- 15. SDN Controller for Transport - Functional Tool Box Network Topology/Graph Abstraction Service- request /Intent Resolver Connection Control Southbound/Legacy Device/Protocol specific drivers/adapters Path Computation Tenant Network Virtualization Network Planning Southbound API (D/I‐CPI) Northbound API (A/I‐CPI)
- 16. SDN Controller for Transport – Functional Tool Box (2) Southbound Protocol Driver and Device Control Interface Module • Responsible for interfacing to network elements using device specific protocols (incl. Openflow) • Could also interface with legacy management systems as well as non-SDN control systems Multilayer Network Topology Abstraction and Virtualization • Maintains network topology database • Provides abstracted topology views to clients as per negotiated policy and contract • Assigns network resources to virtual abstractions Multilayer Path Computation and Connection Control • Works with multi-layer (logical) network detail and logic for path computation • Coordinates provisioning of the connections into the network (elements) • Monitors the health and status of connections • Manages autonomous restoration Northbound API - Service/Intent Resolver • Interfaces with client applications requesting connectivity (P2P, P2MP, MP) service • Allows separation of service intent from components used to deliver the service • Service endpoints, traffic & QoS parameters • Requirements for bandwidth, availability, reliability, resiliency, diversity, etc
- 17. Network Virtualization and Abstraction Network Abstraction • Reduce underlying complexity - simplified logical representation of resources/topology • Information hiding – filter/summarize details • Management/control software systems use abstracted logical model of the network • e.g. ITU-T G.805 architecture • Subnetwork (forwarding domain/ switch) • Link (physical, logical server trails) • Termination Point (logical port) • Subnetwork (cross) Connection (forwarding relationship in device) • Link Connection (monitoring & capacity assigned to a connection) Network Virtualization • Abstraction to decouple the logical view from underlying physical resources • Involves a mapping function to dedicate real network resources to the presented virtual entities • Allows for presenting every client with its own exclusive virtual view of same provider network • Allows for provider to dynamically optimize and effectively manage/maintain network resources • Subject to negotiated policy and pricing between the provider and its client • Provides a level of flexibility to the clients to allocate and manage their “virtual resources”
- 18. Network Virtualization: Service-specific Abstraction Type of virtual network topology exposed to client would be based on negotiated contract • Prune irrelevant nodes/links, subject to constraints, information hiding and reduction Based on granularity • Client’s desired level of detail which depends on its intended application and its sophistication • More granular topology would provide client software with more dynamic control flexibility, but at higher-end of pricing model • e.g. dynamic VN topology-change events Based on Service Objectives • Presented VN topology abstraction could be a function of service objective s: e.g. optimization: lowest latency, lowest cost, highest reliability, etc
- 19. Quick Survey of Current Work Transport SDN Framework Transport API Project E-NNI Specifications 19 IETF Open Networking Foundation Optical Transport Protocol Extensions Transport API’s project Common Information Model Previous GMPLS work PCE Interface for path computation Newer work such as I2RS • ASON Modeling • SG15 Architecture and Modeling • Aligning with ONF SDN Architecture & Common Information Model work • Infrastructure Network • SDN for Inter-NFVI PoP
- 20. Next Steps: Filling the Toolbox • SDN Framework Whitepaper • Documenting model and identifying APIs • Northbound Interface – OIF API Project • Use ONF work aiming at commonality across platforms • Common Core Information Model across technologies • Mappable to REST/JSON interfaces • OIF Project to define Transport API specs • Use joint OIF/ONF prototyping and testing, ideally with open source participation such as ONOS, ODL • East/West Interface (future) • Peer controllers – e.g., carrier-to-carrier • Work still in early stages • OIF E-NNI principles can be applied • Potential 2016 interop demonstration
- 22. Agenda Transport SDN Drivers, Needs, Challenges • Dave Brown, OIF VP of Marketing; Alcatel-Lucent Global Transport SDN Prototype Demo • Jonathan Sadler, OIF Technical Committee Vice Chair; Coriant Transport SDN Tool Kit - SDN Framework and APIs • John McDonough, OIF Vice President; NEC Corporation of America Virtual Transport Network Service • Evelyne Roch, OIF Networking and Operations Working Group Chair; Huawei Technologies Co., Ltd. Wrap up