[Sdnp] Proposed BOF Charter
Thomas Nadeau
tnadeau at lucidvision.com
Fri Sep 30 21:02:19 EDT 2011
On Sep 30, 2011, at 8:06 PM, Ong, Lyndon wrote:
> Hi Tom,
>
> Not wanting to slow things down, but the charter has a lot of descriptive material in it that I think is already in your problem statement draft. I took a shot at cutting back on the descriptive material and focusing on the deliverables in the attached, to see what this might look like. Please use or ignore as you see fit.
The reason why they might be suspiciously similar is that I wrote one right after the other today and did a fair bit of copy/paste. I would like to not cut out any of the descriptive text for now given how many people have reviewed it already, but I will definitely fix the editorial errors you fixed. If you have any non-editorial changes besides cutting the charter down, please point those out; that is the kind of stuff I think we need to focus on right now.
> Also, wondering why the focus on just MPLS, IP and Ethernet, would it not make sense to include GMPLS as well?
Those were just the top three that came to mind as I sped along writing today. If there is consensus to
do other cases, we will do those as well. Remember the next goal/milestone is the BOF, so none of this is
set in stone. Please bring your use case/reasoning to (hopefully) the BOF! 8)
--Tom
>
> Thanks,
>
> Lyndon
>
>
>
> -----Original Message-----
> From: sdnp-bounces at lucidvision.com [mailto:sdnp-bounces at lucidvision.com] On Behalf Of Thomas Nadeau
> Sent: Friday, September 30, 2011 7:41 AM
> To: sdnp at lucidvision.com
> Subject: [Sdnp] Proposed BOF Charter
>
>
> Guys,
>
> I've taken the time to incorporate what I think are all of the comments received on and off the list over the past week or so since publishing the initial proposed charter. Please comment ASAP as we will be submitting this as-is to the IESG over the weekend unless we hear otherwise.
>
> --Tom
>
>
>
> Working Group Name:
> Software Driven Networks (SDN)
>
> IETF Area:
> Routing Area
>
> Chair(s):
> TBD
>
> Routing 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
> Archive: 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 enables
> applications to converse with and manipulate the control software of
> network devices and resources. Applications use the resources provisioned
> and controlled by networks. Applications can benefit from knowing the
> avialable resources and from requesting that the network makes the
> resources available in specific ways.
>
> To this end, there is a requirement to couple applications more closely to
> the underlying resources on which they depend, consume and interact with.
> In particular, modern applications require interaction with and the
> manipulation of both physical and virtual compute, storage and connectivity
> resources and abstract interfaces to these things. 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 an overlay or
> logical/virtual network as well as those possibly same components that comprise
> the underlying physical network.
>
> These services include path computation, topology discovery, firewall services,
> domain name services, network address translation services, virtual private
> networks and the like. These services and elements may be physical or virtual.
>
> One requirement is to create a means by which applications can communicate
> with the control planes of the underlying network devices or entities
> which control and own network resources on which they depend. Note that
> the "control planes" of network devices will be referred to as "controlling
> software" to abstract away the concept of the software that controls a device's
> data plane. The control planes of devices, whether physically co-located with
> a device and its data plane, or externally located for example in the case
> of an OpenFlow "controller", provide coherent control of the network apparatus.
> However, the "controlling software" of a virtual machine might be a hypervisor.
> There is a desire by network operators and service providers to control,
> configure, mange or set policy on controlling software and do so using
> applications for different network control and manipulation options.
>
> This working group shall only interact with the controlling software
> that marshals control over one or more data planes. This working group
> will not work on creating data planes of devices, abstractions of data planes
> or extentions to any hardware abstraction models of data planes. This
> working group will not re-define the efforts of the ONF in terms of
> defining a data plane ehardware abstraction layer (HAL), or a protocol to
> interact directly with a data plane by redefining the OpenFlow protocol.
>
> One requirement is for the SDN archtiecture to work in a multi-vendor environment.
> To this end, a standards-based framework in which software can be used to drive the
> network control functions must be provided. For example, the work that is output
> from this working group could be used by an Openstack controller to manipulate network
> elements to create virtual private network paths on behalf of a network of virtual machines
> that it is in charge of controlling. Another example might be a troubleshooting
> application responsible for monitoring the network performance of a database
> application. This application might need to interact with the underlying network
> and resources in order to monitor the network paths and their attributes, or
> manipulate them in the event it detects subpar performance.
>
> The controler of control planes, known as the SDN Orchestrator, must be capable
> of requesting object models from each of the controlling software it is responsible
> for managing, and therefore each controlling software element must be capable of
> producing a self-describing object model with which the Orchestrator can use
> when issuing instructions to manipulate it. Furthermore, communications
> between the Orchestrator and the control planes must also be rationalized. To
> this end, the working group will define SDN "plug-ins" which are the abstracted
> interface to each type of control plane. The working group will also define
> a protocol that is used for communcations bewteen the Orchestrator and the plug-in.
>
> It should be noted that the SDN Orchestrator function is conceptually centralized
> in that applications should have a centralized means of locating the Orchestrator
> within its network. However, in reality the Orchstrator will be designed and
> architected so as to exist in a distributed manner if so desired operationally.
> Furthermore, resilliency of a SDN infrastructure and network of components is
> required as these elements and functional controls are to be used in highly
> available production environments; therefore, the working group will define
> mechanisms by which the SDN Orchestrator will operate in this manner as a minimum
> requirement.
>
> The working group will define an interface between the SDN Orchestrator and
> applications that wish to interact with it. This interface, given an appropriate
> set of permissions, can be implemented to manage certain functions of the control
> planes it is allowed to communicate with.
>
>
> One major responsibility of each SDN 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.
> 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 Orchestrator:
>
> 1) Define the architecture of an "orchstrator" of controlling software
> and it's functions. These functions must include the manipulation of
> and interaction with, control planes and other controlling software
> via the SDN Plug-In protocol and specifiction. This must also include
> optional security, authentication and redundancy/resilliency features.
>
> The Orchestrator will not interact directly with any hardware data plane.
>
> 2) The working group will define a protocol and API that is ReST-based,
> with which external software entities can communicate with the
> Orchestrator. The protocol definition will describe how the API is
> carried "on the wire".
>
> 3) A self-describing object model of an Orchestrator that can be used by
> external applications to manipulate and control network resources and
> controlling software. This will include gereral elements software is
> allowed to manipulate on any Orchestrator, and the operational actions
> that can be taken based on authentication and authorization abilities.
>
> 4) An interface to external policy engines and a definition of how a controler
> will interact with such policy engines. If existing engines require extension,
> the working group will define them.
>
> 5) A discovery mechanism by which software can quickly and easily locate
> an Orchestrator, as well as all available Orchestrators in a particular
> network domain.
>
> 6) A high availability framework and architecture for Orchestrators that provides
> for uninterrupted operaetion of Orchestrators.
>
> 7) A protocol that describes intra-Orchestrator communications to facillitate
> coordination, and other functional distribution among Orchestrators.
>
> The SDN control-plane plug-ins:
>
> 8) A specification for how "plug-ins" are to be defined that will include
> common guidelines and a schema for defining plug-ins. Since these are
> specific translator functions for each type of control plane, initially,
> the WG will limit itself to plugins for MPLS, IP and Ethernet control
> planes. Other plug-ins will be considered as charter additions once
> the work for the initial controlling software plug-ins has been completed.
>
> 9) Each plug in will be be based on a ReST-like API that also provides a self-
> describing object model of the control plane. The object model's language
> definition will be as defined by Netconf/YANG. If extensions to the language
> are required, this working group will cooperate with the NETCONF working
> group to make such changes.
>
> 10) A protocol by which each Orchestrator converses with plug-ins. This protocol
> will allow for bi-directional communication between controlling software
> and an Orchestrator so as to facillitate alarm notifications, for example.
>
>
> One Working Example:
>
> 11) In order to interact with an SDN Orchestrator, applications must first
> know how to locate one or more SDN Orchestrators. Once located,
> the Orchestrator should be able to athenticate the application via the
> policy interface. Once complete, it should present the application with
> a list of authorized items that it might manipulate based on one of the
> currently in-scope plug-ins. The working group will produce a document
> describing the "soup to nuts" operation of such an example.
>
> Architecture Spec:
>
> 12) An informational document describing the SDN Architecture including
> description of the functional components of an Orchestrator and
> Plug-Ins will be produced.
>
>
> Applicability and Problem Statement:
>
> 13) The working group will produce an informational document describing
> desired "use cases" that describe applicability of SDN and its
> components.
>
> Requirements:
>
> 14) The working group will produce an informational document describing
> operational requirements that are to be used as input in forming
> the architecture document, as well as driving the work items
> described in the working group's charter.
>
>
> 6. What Not to Do
>
> The working group will not define data planes or data plane
> abstractions. Specifically, the WG will not attempt to redifine
> ongoing efforts such as Open Flow.
>
> The working group will not define new network management protocols
> (i.e.: SNMP, Netconf, etc...).
>
>
> 7. Dates
>
>
> The initial draft set:
>
> draft-nadeau-sdn-framework
> draft-nadeau-sdn-problem-statement
> draft-pan-sdn-requirements
>
>
> Goals and Milestones:
>
> <TBD>: Informational document defining the problem statement.
>
> <TBD>: Informational document defining the architecture framework.
>
> <TBD>: Informational document defining the requirements.
>
> <TBD>: Specification defining the protocol between application and SDN Orchestrator.
>
> <TBD>: Specification defining the protocol between SDN Orcestrator and Plug-ins,
>
> <TBD>: Specification of 3 Plug-Ins (MPLS, IP and ethernet)
>
> <TBD>: Specification of the protocol between the Orchestrator and one Policy engine.
>
> _______________________________________________
> SDNP mailing list
> SDNP at lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp
>
>
> <Working Group Charter-lyo.doc>
More information about the SDNP
mailing list