Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Sponsored by
Thank you for joining us today! The presentation will begin shortly.
Thank you for your patience.
© 2015 SDNCentral. All Rights Reserved. December 2, 2015
Sponsored by © 2015 SDNCentral. All Rights Reserved.
SDN’s Hottest Topics: A Panel Discussion
Solving Interoperability& Operations Issues – The Guide to SDN for Optical Networks
December 2, 2015
Sponsored by © 2015 SDNCentral. All Rights Reserved.
Your Presenters for Today
Roy Chua
Co-Founder SDxCentral
December 2, 2015
Lyndon Ong
Chair, ONF Open Transport WG
ONF
Vishnu Shukla
Vice Chair, Open Transport WG
Verizon
Dave Brown
VP of Marketing, Board Member
OIF
Sponsored by
Agenda
• Why do transport networks need SDN? • What are the challenges of making transport SDN work in the
real world? • How are we (industry, ONF, OIF) addressing these challenges? • How to get started and get involved with transport SDN • Wrap-‐up and Q&A
© 2015 SDNCentral. All Rights Reserved.
Hot Topics in SDN Panel Discussion
Sponsored by © 2015 SDNCentral. All Rights Reserved.
Welcome to SDxCentral Webinar with Open Networking Foundation (ONF) Relevant Industries Who Should A4end? Key Takeaways
• CommunicaRon service providers
• Internet content providers • Research and educaRon
networks
• Engineers
• Infrastructure architects
• ApplicaRon developers
• Deploy SDN in the service transport network
• Carrier view: Make SDN more widely deployable in the SP network
• OIF’s toolbox for service provider SDN deployment
December 2, 2015
Carrier SDN Transformation
→ Proprietary, vendor-specific silos→ Complex to operate, integrate across
vendors/technologies
→ Centralized, vendor-agnostic control and service orchestration
→ Virtualization of physical network resources→ Open, programmable carrier networks
OSS Platform
Proprietary OSVendor X HW
Proprietary OSVendor Y HW
Proprietary OSVendor Z HW
Current Networks Software-Defined Networks
OSS Platform/SDN Apps
Multi-vendor Network with Integrated SDN Control
SDN SW
SDN-enabled HW
Open APIsVendor EMS
SDN Control Infrastructure
ONF Open Transport WG ���(formerly Optical Transport WG)• Objectives
• Develop SDN and OpenFlow® standard-based control capabilities for carrier transport networks.• Recent change: addition of Wireless Transport project
• Leadership• WG Chair: Lyndon Ong, Ciena• Vice Chairs: Vishnu Shukla, Verizon; Maarten Vissers, Huawei; Karthik Sethuraman, NEC
• Work to date• Transport SDN Use Cases & Functional Requirements• OpenFlow Extensions for Optical Transport• 2014 Joint Demo with OIF
• In Progress: T-API, Information Model & OpenFlow v1.1
Wireless Transport Work���POC Madrid October 2015
• Supported by • Telefonica• 5 largest microwave vendors (90%
of the market)• Based on ONOS controller
with basic microwave port extensions
• Presenting two SDN apps:• Capacity driven air interface• Flow based shaping
• Whitepaper available at ONF
8
CoriantCoriant
Tester
ONOS Controller
Capacity driven air interface
APP
Flow Based Shaping APP
VirtualRouter
VirtualRouter
9
• Introduce OPTICAL_TRANSPORT port type – specifies port description properties – key information that characterizes the port• Port (Base Layer) Signal Type• Port Capabilities
• Supported Signal Types• Supported Adaptations (Layer stack) above the base port layer
• Port Constraints• Signal Compatibility – Optical Interface Class (Application code/ID)
• Add Adjacency Discovery• specify/retrieve an identity string being sent• specify an identity string(s) to be expected, • retrieve peer identity string(s) received
OpenFlow Optical Extensions: ���Port Attributes for support of L0/L1 connections
OpenFlow Optical Extensions���Match/Action extensions for L0 and L1 connections
10
ODU-XC Port #1
Port #2
Port #3
Port #4
Port #5
Port #6
Match Action In_port = #1ODU_Sigtype=ODU1ODU_SigID={TPN=1, tslen=2,tsmap=[1,0]}
Out_port = #4Set Field ODU_SigID={TPN=3, tslen=2,tsmap=[0,1]}
In_port = #1ODU_Sigtype= ODU1ODU_SigID={TPN=2,tslen=2, tsmap=[0,1]}
Out_port = #5Set Field ODU_SigID={TPN=4,tslen=2,tsmap=[1,0]}
Example: Match/Action for ODU-XC
OIF/ONF Global Transport SDN Demo ���Implementation Experience• OIF/ONF Joint Prototype Demo in
Fall 2014• Multi-vendor, Multi-domain Demo• 5 carrier labs worldwide
• OpenFlow Optical Transport Extensions• Vendor X NE vs. Vendor Y
Controller• Prototype NBI for Connectivity
Service and Topology• (more on this later)
Application Layer
Control Layer
Infrastructure LayerDomain 1
NE NE NE
Domain 2
NE NE NE
Domain 3
NE NE NE
Network Orchestrator
Parent Controller
DomainController
DomainController
DomainController
SBI
NBI
SBI
CloudOrchestrator
Compute Storage
SDN Framework for Transport ���Multi-Domain Integration ���Transport SDN framework for carrier networks
• Can be realized over diverse carrier networks
• Highly flexible - multiple technology layers, multiple domains, greenfield and brownfield
Need standards on application layer interface to control layer (NBI)
• Programmability of Transport SDN across controller and NE vendors
ONF Transport API Project• Project chartered under OTWG
• Project lead: Karthik Sethuraman• Objective – realize a software-centric approach to standardization
• Purpose-specific API to facilitate SDN control of Transport networks• Focus is on functional aspects of transport network control/mgmt• Target is YANG & JSON API libraries
• Scope – based on use case discussions• Topology Service
• Retrieve Topology, Node, Link & Edge-Point details• Connectivity Service
• Retrieve & Request P2P, P2MP, MP2MP connectivity for (L0/L1/L2) layers• Path Computation Service
• Request for Computation & Optimization of paths• Virtual Network Service
• Create, Update, Delete Virtual Network topologies
13
ONF Transport API Project
Applications include Bandwidth on Demand, Data Center Interconnect, IP over DWDM, Virtual Network Services, Network Analytics, etc.
14
Topology Service
Connectivity Service
Network Information Model Database
Path Computation
Network Virtualization
D/I-‐CPI
A/I-‐CPI
NENENE NENEN/EMS NENESDN
Controller NENELegacy
Controller
NENESDN
ControllerNENEApplication
Transport API
Transport APIOpenflow Legacy Protocols Legacy APIs
API Divergence Problem���Absent Standards • Potential API divergence
• Vendor-specific
• Controller-specific
• Technology-specific
• Language-specific• SDO-specific
• Need commonality
• Common core model
• Common minimal subset
• Plus extensions
ONF Common Information Model
• Define a common object model for all types of Software Defined Networks• Basic components like network resources,
service constructs• Use protocol-independent method
(UML model)• Capable of being mapped to different
schemas and protocols• YANG/NETCONF, JSON/REST, OpenFlow
• Work to develop common view across groups• ONF, ITU-T, TMF, MEF, OIF, etc.
ONFCIM
TMF
ONF ITU-T
T-API High Level Work Process• Use cases – describe concepts and API usage
• Contributions from ONF members• Functional Requirements
• Formal requirements TR• Information Model
• T-API UML Module within the ONF Common IM • Based on and extends ONF Core IM
• Data Schema• Develop JSON and YANG schema encoding• Based on the T-API IM
• Software Prototyping• Testing with OIF• Separate project under ONF Open Source SDN• Follow “Agile” development and “fail-fast” processes
• Work on all items (Req, IM, API) in parallel
17
Add, Modify, Clarify Functional
Requirements
Update Transport API Information Model (UML in Papyrus)
Update Transport API Data-Schema
(JSON/YANG)
Prototype the APIs
Collect and Analyze the Purpose-specific
Use cases
Achieving Common APIs��� The Tools and Remaining Challenges
Keys to achieving interoperable common APIs • Base efforts on Common Information Model and API specification • Verify APIs interoperability and function via Implementation and Testing
• Joint OIF/ONF Interop of both SBI and NBI Open-Source Friendly Process with Open Documentation • Draft TAPI documents available via github (ONF OpenTransport project
“Snowmass” ) • https://github.com/OpenNetworkingFoundation/ONFOpenTransport
• Open Source Implementation project “Englewood” • Part of ONF OpenSource SDN Initiative • https://github.com/OpenNetworkingFoundation/Englewood
Accelerating the Deployment of Practical, Programmable Transport Networks
Dave Brown
OIF VP of Marketing Alcatel-Lucent
SDxCentral Webinar
December 2, 2015
Moving Transport SDN Forward OIF Activities
Completed: ü SDN Reference Architecture ü Carrier SDN Requirements ü 2014 Global Transport SDN Demo ü Framework for Transport SDN In-Progress: • Transport API Implementation Agreements • Virtual Transport Network Service Definition • Transport SDN Operator’s Toolbox • 2016 Global Transport SDN/NFV Demo Planning
20
SDN Reference Architecture Components of Transport SDN
Data Center
DC Mgt/ Controller
Orchestrator
ServiceApplication Plane
Mgt- &Control-Plane
DataPlane
Service Service
Transport
TN Controller
TransportNetwork
TN ControllerMgt
TN ControllerMgt
SDN southbound:OF, XML, SNMP, PCEP, … (could be NE-internal)
OF, MTOSI, REST, …
SDN northbound:OGF NSI, …
DC Mgt/ ControllerDC Mgt/
Controller
Carrier Requirements: Transport Networks in SDN Architectures
• Based on contributions of major carriers worldwide
• Comprises requirements on Transport SDN • Orchestrator (transport network relevant
part) • Control and management planes • Data plane
• Being used as guidance within OIF but also communicated to other SDO’s and forums
2014 Global Transport SDN Demo
• Testing conducted in carrier labs over 7 week period August-September
• China Mobile, China Telecom, Deutsche Telekom, TELUS, Verizon
• Participating vendors • ADVA, Alcatel-Lucent, Ciena, Coriant,
FiberHome, Fujitsu, Huawei, NEC, ZTE
• Consulting members
• China Academy of Telecommunications Research, KDDI R&D Laboratories, Orange
2014 Global Transport SDN Demo Outcome
◆ Successful demonstration of SDN Architecture for carriers • Can be realized over WAN and provide carrier benefits
• Highly flexible - multiple technology layers, multiple domains, greenfield and brownfield
◆ Identified a lack of definition for how user applications interact with transport network applications and resource functions
• The programmability of Transport SDN requires some of the internal interfaces used by ASON to become open
◆ Whitepaper jointly published by OIF and ONF ◆ OIF project started to develop API implementation agreements (IAs)
• Build on Service Request and Topology APIs prototyped in the demo • Liaise and align with ONF
Transport SDN Framework ◆ Validated in the OIF/ONF
Prototype Demo in Fall 2014 ◆ MulK-‐layer control ◆ MulK-‐vendor, MulK-‐domain
Demo • 5 Carrier Labs • 9 Vendors
◆ OpenFlow OpKcal Transport Extensions
◆ Prototype NBI for ConnecKvity Service and Topology
◆ Whitepaper available with details
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
Transport APIs Work in Progress
◆ Northbound Interface – OIF API Project • OIF Project to define API specs
• Based on OIF/ONF prototyping and testing of REST/JSON APIs • Service Request, Topology, others
• Joint with ONF for commonality across technologies & SDOs • Common Core Information Model • Mapping to REST/JSON interfaces
Ø Common Transport API
Virtual Transport Network Service Definition
Work in Progress ◆ An example service definition activity ◆ Takes advantage of virtualization in SDN ◆ Offer customers controllable network slice
Leased Line
VPN
VNS
Client site A
Client site B
Client site A
Client site B
Client site D
Client site C
Client site A
Client site B
Client site D
Client site C Virtual network with vNE & vLink
Client controller
Ctrl of virtual XC
ConnecRon controlled by network providers
RenRng P2P connecRons
Leasing virtual network (connecRon)
Leasing virtual network + connecRon control over the virtual network
Similar to SCS
(PVNS) Static
Dynamic
Service requirements VNS
Virtual network with vNE & vLink
Client controller Rent virtual network
resources from provider
(SVNS) Client site
Virtual network recursive creaRon
Client site Client site Client site
Client site Client site Client site
Leasing virtual network + recursive virtual network creaRon
Transport SDN Toolkit Work in Progress
◆ Essential tools for Transport SDN deployment • 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
Architecture
Identifiers Discovery
SCN APIs Integration with MP
Interoperability demos Security
2016 Global Transport SDN/NFV Demo In Early Planning Stage
◆ OIF-managed, co-op with ONF/others, carrier-hosted ◆ Target testing and readout timeframe - Fall 2016 ◆ Potential test candidates:
• Standardized OpenFlow Optical extensions • Based on Technical Spec issued by ONF
• IA work on Transport APIs • Service Request, Topology, others • Cooperative efforts by OIF and ONF, e.g., IM
• NFV and other test applications
Carrier view: what is needed to make SDN more widely deployable in the service
provider network Vishnu Shukla
Verizon
The SDN and Virtualization Business Case Virtualised environment Resources shared across services, reducing stranded capacity and reducing total cost of network build. (Build to average + margin across all services rather than to peak for each service).
Service reliability achieved at application level, without incurring hardware reliability costs. (1 for M vs. 1 for 1)
Reduced power, cooling and other facility requirements.
Standard (COTS) hardware Large scale drives cost down (Economy of Scale)
One Spare holding SKU, drastically reducing the number of units needed.
Disaster recovery/business continuity can be simplified
Software Implementation of Network Functions Introduce new services quickly without deploying an entire network of new hardware. (Velocity)
New services can be inserted and withdrawn without loss of capital investment due to reuse of hardware. Easy to introduce service changes. (Flexibility)
Move workloads around the network to tactically handle capacity issues in specific geographical areas. (Adaptability.)
Verizon 2015 All Rights Reserved
Why Does Transport Need SDN?︎
• Optical and transport networks continue to be difficult and expensive to manage, with many manual processes and very long provisioning times
• SDN and virtualization have the promise of simplifying optical transport network control, adding management flexibility, and allowing the rapid development of new service offerings by enabling programmatic control of optical transport networks and equipment
• Can also reduce the cost of optical switches by moving control and management planes from embedded processors to general-purpose COTS hardware and virtualized software
• Utilize centralized network-wide management and control to drive efficiency and speed
Verizon 2015 All Rights Reserved
SDN Promise
SDN advocates for greater programmability Provide new behaviors not considered by Standards, Vendor implementations
Facilitates Network application eco-system Seamless/Rapid relocation of endpoints
Abstracted NEs
Virtual Networks
Programmability and Application Awareness
Verizon 2015 All Rights Reserved
Potential Benefits of Transport SDN SDN Benefit Transport Network Impact Network Utilization • Application-aware optimization of resources
• Multilayer optimization across packet and circuit
Improved Service Development/Deployment
• Greater separation of service development/deployment and network element embedded software
• Virtualization of network resources Simplified/Streamlined Operations • Streamline and integrate operations across different
domains • Circumvent or remove restrictions of legacy
operations systems Monetization of Resources • Improved charging for network resource usage and
class of service
Verizon 2015 All Rights Reserved
SDN Architecture Issues
How will Multi-Domain be handled? • What is the relationship between controllers?
– Peer or overlay
How will Multi-Layer be handled? • E.g., location and triggering of adaptation
What is the relationship to Network Management? • OF control vs. EMS/NMS control (mediation device)
Verizon 2015 All Rights Reserved
Sponsored by
Challenges
• OperaRonal simplicity • On-‐board new clients rapidly
• DifferenRated service delivery
• Automate resource allocaRon on the fly • Scalability
• Support X transacRons per hour • Security
• Service isolaRon and authenRcaRon per client
• ConRnuous Availability • Disaster avoidance / recovery
• Current transport business model
• MigraRon Path
• Many SDOs, Open source acRviRes
• Common InformaRon Model
Verizon 2015 All Rights Reserved
SDOs
ONF OIF
(Transport)
IETF/IRTF
InterDC ATIS
SW Infrastructure
Southbound Interface
Northbound Interface
Openstack
BBF, MEF
ODL,
NFV OPNFV
OPEN SOURCE
3GPP
High Level SDN/Data Center Reference Architecture with SDOs/Forums Focus
Data Center HW
Orchestration & Management
Service Service Service
Transport
SDN Controller
DC Mgt
ONOS
Summary
SDN has great promise to improve transport control • Programmability
– Ability to deliver new behaviors not (yet) considered by standards, vendors, …
• Simplified multi-layer control
• Common behaviors in heterogeneous NE deployments Operational issues
Role of SDOs
Monetizing Network
Verizon 2015 All Rights Reserved
Sponsored by
Questions & Answers
© 2015 SDNCentral. All Rights Reserved. December 2, 2015
Sponsored by © 2015 SDNCentral. All Rights Reserved.
Upcoming SDxCentral Events
Visit https://www.sdxcentral.com/resources/events/ to view upcoming events by SDxCentral!
December 2, 2015