Subject: [Sdn] Thoughts on Defining control and Management Planes

From: Shivleela Arlimatti <[email-masked]>
Date: Thu, 14 Nov 2013 19:15:36 +0800

Hi to all
 Really after reading all these definitions we the budding researchers will
get lot of  information about subject.. even we want to contribute
something..may be it will take time ...we need to get more knowledge...
any way thanks to all

Shivaleela Arlimatti
Research scholar,
InterNetworks Research Lab, CAS
UUM Sintok, Malaysia.

On Thu, Nov 14, 2013 at 4:01 AM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.irtf.org/mailman/listinfo/sdn
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send sdn mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.irtf.org/mailman/listinfo/sdn
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sdn digest..."
>
>
> Today's Topics:
>
>    1. Re: Thoughts on Defining control and Management Planes
>       (Russ White)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Nov 2013 12:45:54 -0600
> From: Russ White <[email-masked]>
> To: Alan Clark <[email-masked]>, "[email-masked]"
>         <[email-masked]>
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
>
> If the definitions change over time, then we can't build stable interfaces
> and their associated data models, nor can we understand how to compare one
> network or service model against another....
>
> So... I'd argue for a functional model (what it does), that is going to be
> stable over time... Not time, service, or "who did this," or...
>
> :-)
>
> Russ
>
> -----Original Message-----
> From: "Alan Clark" <[email-masked]>
> Sent: ?11/?13/?2013 12:13 PM
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [Sdn] Thoughts on Defining control and Management Planes
>
> How about a definition along the following lines?
>
> The functionality of a switching or routing system is typically divided
> into three layers, Data Plane, Control Plane and Management Plane. As
> network architectures evolve, the functions incorporated into these planes
> may change; for example adaptive algorithms incorporated into the Control
> Plane may automate configuration or optimization tasks that would
> historically be performed by the Management Plane.
>
> The Data Plane is distributed throughout the network and exists within
> each network node. The Data Plane provides switch, routing, transformation
> and filtering functions such as packet forwarding, encapsulation and
> address translation.  These functions and the associated interfaces are
> configured by the Control Plane.
>
> The Control Plane may be distributed or centralized and is primarily
> responsible for configuration of the Data Plane. Typical Control Plane
> functions include maintaining knowledge of the local or global topology and
> current loading of the network, calculating optimal routes through the
> network based on policy and with minimal cost, instantiating the route by
> configuring the Data Plane in the nodes traversed by the route and
> maintaining data on the routes currently configured in the network. Control
> plane functions may also include failure handling mechanisms such as link
> failure detection and fail over, and automated provisioning of devices from
> a server.  A Control Plane typically incorporates some detection and
> reporting of faults and exceptions, and this data is reported to (or
> retrieved by) the Management Plane. If the Control Plane was disconnected
> from the Data Plane then the current configuration of the Data Plane would
> remain unchanged (i.e. no new routes would be set
>   up, no new devices would be provisioned...) and data could still be
> forwarded according to that configuration.
>
> The Management Plane is typically centralized and is primarily responsible
> for ensuring that the network or system is running optimally when viewed
> from an overall service and business perspective. The Management Plane will
> effect this by gathering data from the network on usage, performance and
> faults, determining either manually or automatically if changes to the
> configuration of the Control Plane would improve overall performance,
> resource utilization, security and reliability of the network and those
> services or applications running over it and making changes to Control
> Plane configuration if needed, converting collected data into accounting
> information for billing or operational cost models, and overriding the
> normal operation of the Control Plane to handle exception conditions.  A
> Management Plane always includes some element of reporting faults and
> exceptions to human operators. If the Management Plane was disconnected
> from the Control Plane, the network would continue
>   to operate normally however issues or traffic pattern changes that
> affect the performance and reliability of the network may not be detected
> and the network may operate sub-optimally.
>
> As a non-network example - the set of traffic lights at a junction have a
> local control function (Control Plane element) that applies a configured
> set of rules to decide when to change lights based on time and road
> sensors. This may be locally optimal in terms of minimum queuing delay at a
> junction however may not be globally optimal. A Management Plane would have
> visibility over the entire road system and could make adjustments to the
> rules used by each local control function in order to achieve global
> optimization. If at some future time the local control functions become
> integrated into a system-wide Control Plane and this is able to use
> system-wide data to optimize traffic light operation across the network
> then it has become a more intelligent Control Plane and the Management
> Plane's role evolves to one of controlling the configuration of the
> system-wide optimization algorithm.
>
> Regards
>
> Alan
>
>
>
> On 11/13/13, 9:33 AM, Scott Brim wrote:
>
> On Tue, Nov 12, 2013 at 8:31 AM, Russ White <[email-masked]> wrote:
>
>
> >       > For me the difference is between something that is supposed to be
> > in continuous operation, and something that is supposed to set up that
> > continuous operation.  I see the former as control plane and forwarding
> > plane, and the latter as management.  When you perform a management
> > function, then you can sit back and watch to make sure you did it right.
> A
> > control function, on the other hand, continues _as part of_ things going
> right.
> >
> >       I think this merges the control and data planes, though -- and I
> think
> > we want to be able to differentiate between them.
> >
> > Russ, maybe it merges your concepts of planes, but I'm trying to get you
> to
> > use different concepts. In what I said, control and management are
> clearly
> > separated. We can get to specifics if you like, as tests of conceptual
> models.
> > Just keep in mind that components function in multiple planes
> > simultaneously.
>
> Given your definition --these things are all in continuous operation,
>
>
> That's not what I meant to say, and sorry for using those words. Trying
> again: management sets up and monitors the network machinery, while control
> operates it. I'll give up on getting succinct sound bytes soon.
>
> so
> they must all be control plane:
>
>
> You know that's impossible.
>
> - Forwarding of packets
>
>
>
> Forwarding.
>
>
> (One nit is that forwarding of control or management plane packets has
> generally not been considered "forwarding plane" -- it's special in the
> abstract, even though in IP networks transport of control/mgmt is actually
> done using the same IP forwarding mechanisms.)
>
>
> - Detection of down links
>
>
>
> Categorizing that, and others below, depends on the function that receives
> the result. What does it do? If it changes configuration, it's management.
> If it changes behavior for now but does not change configuration, it's
> control.
>
> - Flooding and maintenance of topology information
>
>
>
> Control
>
> - Monitoring of cpu thermals
> - Monitoring of memory utilization
>
>
>
> Again, it depends on how the information will be responded to.  The
> information isn't the point, it's whether it's used for management or
> control.
>
> - Logging
>
>
>
> Management.
>
> - Reactive configuration to black hole attacks
>
>
>
> Good one. I would call this a rapid response of management.
>
>
> The last time I tried to define planes was in Y.2011.  Here, I originally
> thought the goal was to have consistency with other definitions of
> "planes", but it looks like these definitions are just going to be used in
> SDNRG (they already disagree with at least one other SDN group). If all
> this is local scope, whatever you all decide on is fine. I look forward to
> a draft.
>
>
>
> Scott
>
>
>
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.irtf.org/mail-archive/web/sdn/attachments/20131113/269aa603/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn
>
>
> End of sdn Digest, Vol 19, Issue 31
> ***********************************
>