[Sdnp] Proposed SDN BOF charter
Navindra Yadav
nyadav at google.com
Thu Sep 22 15:16:31 EDT 2011
"the pointer to some slides describing update on OF hardware abstraction
layer proposal."
The following two links will also help if one is looking at the south bound
interface, we have been discussing.
Open Flow Extensibility Working Group Goals: http://goo.gl/OJrA7
Open Flow 2.0 Forwarding Model Thoughts: http://goo.gl/MDRRx
Examples of networking devices built using Open Flow 2.0 Forwarding Model:
http://goo.gl/HaHci
cheers
Navindra
On Thu, Sep 22, 2011 at 12:11 PM, Robert Raszuk <robert at raszuk.net> wrote:
> Hi Tom,
>
> So would it be the right observation (being now on both sides of the
> efforts) that SDNP WG would be more focused on the northbound API side of
> the controller (here called conductor) to the actual applications while ONF
> WGs are (at least at this point) focused southbound controller <-> switch
> and west/east controller <-> controller coming soon ?
>
> If this is right assessment the only thing a bit disturbing are those
> "plugins" in your charter which you are aiming to work on. And btw those
> plugins are already being discussed by ONF.
>
> Looking at SDNP archives I see that back in July Ed from Google have
> already provided the pointer to some slides describing update on OF hardware
> abstraction layer proposal.
>
> http://goo.gl/MDRRx
>
> Especially if you are not going to touch data plane I am quite puzzled how
> are you going to specify any HAL.
>
> Best regards,
> R.
>
>
>
> On Sep 22, 2011, at 2:00 PM, Monique Morrow (mmorrow) wrote:
>>
>>
>>> Belated ack Tom, and a very reasonable cut to defining the BOF charter,
>>>
>>>
>> Merci! 8)
>>
>>> just a small question:
>>>
>>> Do you seen any differentiation from the proposed work here to say that
>>> of the ONF Extensibility WG?
>>>
>>> Yes, the work here is clearly different from anything being done
>> at the ONF because we do not envision defining or interfacing with the data
>> plane directly; instead, I think we want to talk to a "controller software"
>> (i.e.: the control plane for such things like routers/switches or a
>> hypervisor for say VMs, etc...). The only place where there could have
>> interaction with OF would be a "plug in" that could be defined to adapt to
>> an OF "Controller". Either we could define this, or the ONF's Extensibility
>> group could, or we could collaborate on that. I think that if you take this
>> perspective, the best way to look at the ONF then is as just another
>> "device" that SDN talks to (i.e.: a switch or switches with some control
>> plane). Make sense?
>>
>> --Tom
>>
>>
>>
>>> TIA- Monique
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: sdnp-bounces at lucidvision.com on behalf of Thomas Nadeau
>>> Sent: Mon 9/19/2011 7:15 AM
>>> To: sdnp at lucidvision.com
>>> Subject: [Sdnp] Proposed SDN BOF charter
>>>
>>>
>>> Hi All,
>>>
>>> This is the first cut at the proposed WG charter that we will be
>>> using to drive the BOF for Taipei. Please bash/comment ASAP.
>>>
>>> --Tom
>>>
>>>
>>>
>>>
>>> Working Group Name:
>>> Software Driven Networks (SDN)
>>>
>>> IETF Area:
>>> Routing Area
>>>
>>> Chair(s):
>>> TBD
>>>
>>> Applications Area Director(s):
>>> Adrian Farrel<adrian at olddog.co.uk>
>>>
>>> Routing Area Advisor:
>>> Adrian Farrel<adrian at olddog.co.uk>
>>>
>>> Mailing Lists:
>>> General Discussion: sdnp at lucidvision.com
>>> To Subscribe: https://www.lucidvision.comf/**
>>> mailman/listinfo/sdnp<https://www.lucidvision.comf/mailman/listinfo/sdnp>
>>> Archive: http://www.lucidvision.com/**
>>> mail-archive/web/sdnp <http://www.lucidvision.com/mail-archive/web/sdnp>
>>>
>>> Description of Working Group:
>>>
>>> Software Driven Networks (SDN)
>>>
>>> Software Driven Networks (SDN) is an approach to networks that
>>> applications to converse with and manipulate the control software (i.e.:
>>> control planes, element management system (EMS), etc...) of network devices
>>> and resources in a manner which is secure, light-weight and appilcable to
>>> modern application design methods. To this end, there is a need to associate
>>> applications more closely to the underlying resources on which they depend,
>>> consume and interact with. In particular, modern applications require
>>> compute, storage and connectivity abstractions that allow for interaction
>>> and manipulation of both physical and virtual resources. These abstractions
>>> must also allow applications to manipulate resources at varying levels of
>>> granularity, policy and security. It is also worth noting that modern
>>> Software Driven Networks (SDNs) are comprised of applications, control
>>> software, and interfaces to services that are hosted in a network as well as
>>> those same components th
>>>
>> at comprise
>
>> the underlying network. These services include path computation, topology
>>> discovery, firewall services and the like. These services and elements may
>>> be physical or virtual.
>>>
>>> One manner in which this can be achieved is to create a means by
>>> which applications can communicate with the control software of the
>>> underlying network devices or entities that are responsible for the control
>>> and manipulation of network resources on which they depend. The control
>>> software of devices, whether physically co-located with a device and its
>>> data plane, or externally located, provide coherent and synchronized control
>>> of the network apparatus. There is a desire by network operators and service
>>> providers to extract this functionality into external software entities for
>>> different network control and manipulation options. However, for this to
>>> work in a multi-vendor environment, a unified, standards-based framework in
>>> which software can be used to drive the network control functions must be
>>> provided. The centralized conductor of the control software must be capable
>>> of extracting object models from each of the control software it is
>>> responsible for controlin
>>>
>> g and intera
>
>> cting with, and therefore each control software must be capable of
>>> producing a self-describing object model with which the controller can then
>>> manipulate. Furthermore, communications between this "centralized" function
>>> and the control software must also be rationalized. By software control, it
>>> is meant that any application, given an appropriate set of permissions, can
>>> be implemented to manage certain functions of the control software it is
>>> allowed to communicate with. It should be noted that these functions are
>>> conceptually centralized, but in reality should be designed and architected
>>> so as to coexist in a distributed manner if so desired operationally.
>>> Furthermore, resilliency of this infrastructure of components is required as
>>> these elements and functional controls are to be used in highly available
>>> production environments. This entity is referred to as The SDN Conductor.
>>>
>>> One major responsibility of each control software plug-in is the
>>> capability to provide a self-describing management model of itself. This
>>> model includes its capabilities in terms of manipulation functions, as well
>>> as objects that can be interrogated and manipulated, as well as their
>>> relationsihps to each other. It is envisioned that applications will
>>> interact with this model via a ReSTful interface and that device
>>> capabilities are abstractly modeled using the YANG language. Further,
>>> programmatic interfaces are generated from such models using a Model Driven
>>> Architecture (MDA) approach. The modeled devices are themselves
>>> self-describing and may be physical or virtual.
>>>
>>> The purpose of SDN is to define the aforementioned components and
>>> control functions. In particular, the SDN Working Group will define the
>>> following:
>>>
>>>
>>> The SDN Conductor:
>>>
>>> 1) Define the architecture of a centralized "conductor"
>>> responsible for the orchestration of the various control software and across
>>> a (proper) subset of the entities' functions that reside in the network
>>> domain in which it resides. These functions include the manipulation and
>>> conversation with control planes, element manager software, etc... In
>>> addition optional security and redundancy/resilliency features are required
>>> for both single instances of the conductor function, as well as when it is
>>> implemented in a distributed manner.
>>> 2) An application "friendly" API such as ReST, with which
>>> external software entities can communicate with this
>>> centralized conductor.
>>> 3) A self-describing object model of a conductor that includes
>>> gereral elements software is allowed to manipulate.
>>> 4) An interface to external policy engines and a definition of
>>> how a conductor will interact with such policy engines. If existing engines
>>> require extension, the working group will define them.
>>> 5) A location management system by which software can quickly and
>>> easily locate the centralized conductor function.
>>>
>>> The SDN Control Software Plug-ins:
>>>
>>> 6) A specification for "plug-ins" and a set of "plug-ins" or
>>> translator functions for each type of control plane or control software the
>>> Working Group defines by which a conductor can thereby interact with and
>>> manipulate control software with.
>>> 7) Each plug in will be be based on a ReST-like API that also
>>> provides a self-describing object model of the control software. This object
>>> model's language definition will be standardized. Its actual definition may
>>> or may not be standardized by this working group.
>>> 8) A protocol by which a conductor converses with each plug-in.
>>>
>>>
>>> Plug-In Specifications
>>>
>>> The working group will define Plug-In specifications that are defined
>>> based on an API specification framework document produced by the working
>>> group. This will guide all Plug-in specifications.
>>>
>>> One Working Example
>>>
>>> The working group will produce at least one document that specifies
>>> one working example. This example will be used to guide the progress of the
>>> working group.
>>>
>>> Architecture Spec (Use Cases and Related Issues)
>>>
>>> The working group will produce an architecture specification that
>>> includes the definition of the various components of the SDN archtiecture
>>> and how these components interact. This includes the definition of the SDN
>>> Conductor and Plug-In components.
>>>
>>> 6. What Not to Do
>>>
>>> This WG will focus solely on the communication protocol between
>>> applications and SDN Conductor(s), SDN Conductor(s) and control software
>>> "plug ins".
>>>
>>>
>>> The SDN Working Group will not define data planes or data plane
>>> abstractions. Specifically, the WG will not attempt to redifine efforts such
>>> as Open Flow.
>>>
>>> SDN will not define new network management protocols (i.e.: SNMP,
>>> Netconf).
>>>
>>>
>>>
>>> 7. Dates
>>>
>>> Jan 2012 Working Group Last Call for problem statement
>>> Jan 2012 Working Group Last Call for requirements document
>>> Jan 2012 Working Group Last Call for architecture document
>>>
>>> Jan 2012 Submit problem statement to IESG as Informational
>>> Jan 2012 Submit requirements statement to IESG as Informational
>>> Jan 2012 Submit architecture to IESG as Standards Track
>>>
>>>
>>> Jul 2012 Working Group Last Call for request/response
>>> application-to-conductor protoco
>>> Jul 2012 Working Group Last Call for request/response
>>> conductor-to-plug-in protocol
>>> Jul 2012 Working Group Last Call for object model description definition
>>>
>>> Sep 2012 Submit request/response application-to-conductor protocol to
>>> IESG for Standards Track
>>> Sep 2012 request/response conductor-to-plug-in protocol to IESG for
>>> Standards Track
>>> Sep 2012 object model description definition to IESG for Standards Track
>>>
>>> Nov 2012 Working Group Last Call on one plug-in definition.
>>> Dec 2012 Submit plug-in definition to IESG for Standards Track
>>>
>>> Dec 2012 Dissolve or re-charter
>>>
>>>
>>> The initial draft set:
>>> draft-nadeau-sdn-architecture
>>> draft-nadeau-sdn-problem-**statement
>>> draft-nadeau-sdn-requirements
>>>
>>>
>>> Goals and Milestones:
>>> Jan 2012: Informational document, defining the problem
>>> space, to the IESG for publication.
>>>
>>> Jan 2012: Informational document, defining the
>>> architecture, to the IESG for publication.
>>>
>>> Jan 2012: Informational document, defining the
>>> requirements, to the IESG for publication.w
>>>
>>> Jul 2012: Specification defining the
>>> query mechanism between application and
>>> conductor, to the IESG for publication.
>>>
>>> Jul 2012: Specification defining the
>>> query mechanism between SDN conductor and control
>>> software plug-ins,
>>> to the IESG for publication.
>>>
>>> Jul 2012: Specification for the extended
>>> query mechanism, to the IESG for publication.
>>>
>>> Oct 2012: Informational document, discussing issues
>>> of data transparency, redress, meta-reputation
>>> and other important operational considerations,
>>> to the
>>> IESG for publication.
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> SDNP mailing list
>>> SDNP at lucidvision.com
>>> http://lucidvision.com/**mailman/listinfo/sdnp<http://lucidvision.com/mailman/listinfo/sdnp>
>>>
>>>
>>>
>>
>>
>>
>> ______________________________**_________________
>> SDNP mailing list
>> SDNP at lucidvision.com
>> http://lucidvision.com/**mailman/listinfo/sdnp<http://lucidvision.com/mailman/listinfo/sdnp>
>>
>
> ______________________________**_________________
> SDNP mailing list
> SDNP at lucidvision.com
> http://lucidvision.com/**mailman/listinfo/sdnp<http://lucidvision.com/mailman/listinfo/sdnp>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lucidvision.com/pipermail/sdnp/attachments/20110922/055c1367/attachment-0001.htm>
More information about the SDNP
mailing list