Upload
lawrence-sanders
View
215
Download
1
Embed Size (px)
Citation preview
Cooperating Layered Architecture for SDN (CLAS)
<draft-contreras-sdnrg-layered-sdn-02>Luis M. Contreras
Telefónica
Carlos J. Bernardos Universidad Carlos III de Madrid (UC3M)
Diego R. LópezTelefónica
Mohamed Boucadair France Télécom/Orange
Dallas, SDNRG WG, March 2015
1
92th IETF, Dallas
Rationale• Existing proposals for SDN centralize control capabilities
with very different objectives and purposes• No separation between services and transport control
– No clear responsibility for service provision and delivery– Complicated reutilization of components for delivering different
services– Monolithic control architectures, driving to lock-in– Difficult interoperability, then difficult interchange of some
modules by others– No clear business boundaries– Complex service/network diagnosis and troubleshooting
2
Cooperating Layered Architecture for SDN• Key concept: separation of the control functions associated to
services from those associated to transport– Service control becomes independent from transport control
• Functional Strata– Service stratum: functions related to the provision of services (including
capabilities exposed to external applications) – Transport stratum: functions related to the transfer of data between
communication end-points• Plane separation
– Control plane: control of resources in each strata– Management plane: management of resources and control plane in each
strata– Resource plane: resources required for a given service (can be or not the
termination points of a transport function)• Despite differentiation, tight cooperation is needed for an efficient
service provision
392th IETF, Dallas
Cooperating Layered Architecture
492th IETF, Dallas
Cooperating Layered Architecture – Topics to address
5
• Means to expose transport capabilities to external services
• Means to notify service intelligence with underlying transport events
• Means to instruct the underlying transport capabilities to accommodate new requirements
• Means to capture service requirements of services
ABSTRACTION
ClientRelationship
Transfer of Data
Service Provision
and Capabilities to
External Applications
(*) Depending on the kind of Service the resources at Service Stratum could be or not the End-Points of the Transport Resources
(*)
92th IETF, Dallas
Additional topics to address• Multi-domain scenarios in Transport Stratum
– Transport resources being part of different administrative, topological or technological domains
• Recursiveness– Transport Stratum is itself structured in Service and
Transport Stratum
• Security and trust– Security in the communication between strata
• Event notification, OAM, diagnosis
692th IETF, Dallas
Deployment Scenarios• Full SDN environment
– Multiple Service Strata associated to a single Transport Stratum
– Single Service Stratum associated to a multiple Transport Strata
– (And 1:1 and N:N cases, of course)
• Hybrid environments– SDN-based Service Stratum associated to a legacy
Transport stratum– Legacy Service Stratum associated to a SDN-based
Transport stratum792th IETF, Dallas
Potential use cases / scenarios – e.g., NFV (*)
8(*) Telefónica, “Operational separation of SDN control for Service-oriented and Connectivity-oriented actions in the framework of NFV”, NFVEVE(15)000066
92th IETF, Dallas
Next Steps• Collect interest from the community
– E.g., Ericsson Research contributing in multi-domain scenarios (more details in next draft version)
• Work in the following areas:– Document a gap analysis– Define and document different use cases– Describe requirements for interface definition between
strata– Security (in the communication between strata)– Others(e.g., monitoring, inter-domain provision, SLA, etc)
992th IETF, Dallas