Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New:Software-Defined Networking Research Group (SDNRG)

From: [email-masked]
Date: Wed, 16 Jan 2013 11:38:36 +0530 (IST)

Hi Sharon,
 It is interesting that you earlier mentioned aggregation points and split
points. As you mention below, the semantics of the term reachability
could be looked at in a wider sense going beyond the network traffic
reachability, which is likely what you mean by the terminology of basic
reachability.
 In ITU-T and TMF model there is an important architectural component
called the adaptation.  A Termination Point could be associated, in
addition to a termination component, to also an adapatation component.
 The global policies that you have given as illustrations to the problem
can be fundamentally viwed as Adaptations. Adaptations and Terminations
together therefore could serve as a unifying generalization of the
aggregation abstraction.
 What strikes me is the relationship of adapations to the generalized
reachability alluded to earlier. Once you have the physical network
infrastructure in place (relatively long lived, slowly changing
characterstic of the network ) your universe set of the relationship
between the adapataions and the associated generalized reach could get
significantltly narrowed. A case then for programmability of the same.
Here we are now closer to making the problem of relating the architecture
of the system to it programmability more tractable.
 Could we explore any existing programming language that can handle graphs
and operations on it well..ie a language for graphs?
 Also the levels of control (Network Device level, Protocol level, Control
Plane level, User App level) needs to be factored in.
 The concept underlying IEEEs OAM Standardization based on MEPs/MIPs come
to mind.. Is there value in adapting those in a unified framework?
 SDN is to networks it appears as Reconfigurable Computing is to the
Computing industry....
Sitaraman

> Yes, but not exactly.
>
> In the first example we want to achieve basic packet delivery service that
> works under the worst possible conditions.
> After all the Internet was first designed to withstand a nuclear strike.
>
> In the second example we ask for much more. Essentially we ask the network
> to perform global balancing or global map-reduce on behalf of
> applications. Instead of each app doing its own.
>
> This level of network programmability is possible IFF there is a basic
> underlying connectivity because its based on distributed SDN control
> software.
> This is a bootstrap sequence.
>
> Hence the complementary aspect of traditional and software defined
> networking and the overlay models SDN models converge towards.
>
> Based on this basic reachability you can also apply sophisticate traffic
> engineering for certain flows on graphs, facilitate mobility and workflows
> etc.
> Additional driver is security and the ability to account for each and
> every packet. This is virtually impossible under the autonomous control
> models, but again without that foundation you can not build these next
> levels of functionality.
>
> Hope this makes sense - it's supposed to simplify network management as
> well - because sophisticated configuration need not be scattered into
> interface configuration - end points are moving between those. Instead,
> all SDN programable policies should be available in a similar to database
> programming mode vs manager-agents mode, for the complex and massive
> things at least.
>
> Sent from my iPhone 650 492 0794
>
> On Jan 15, 2013, at 9:27 AM, "[email-masked]"
> <[email-masked]> wrote:
>
> Thanks Sharon,  Looking at the examples, I seem to think the second one
> has a strong reach component to it, only the reach is not for the traffic
> that is carried but metadata about the traffic?
> Sitaraman
>> Happy to but don't want to bear on the list -
>> Can you take two simple examples and can extrapolate:
>>
>> One: get a ping across to multiple locations, with different gear from
>> different generations of hardware and different administrative domains
>> that have no reason to trust one another as an example ISPs from
>> conflicting nations or competing vendors.
>>
>> Two: globally balance a function instantiated using the same address in
>> multiple locations with global awareness in each location of the exact
>> health state load and affinity associated with each of the resources.
>>
>>
>>
>> On Jan 15, 2013, at 7:19, "[email-masked]"
>> <[email-masked]> wrote:
>>
>> Hi Sharon,
>> Would appreciate if you could elaborate on the extended network
>> functionality and the conflict between the reach and
>> functionality...Thanks
>> Sitaraman
>>> depends on what you try to achieve-
>>>
>>> if you try to extend network reach then back-comp interoperable control
>>> is
>>> key, therefore a "need to know basis" distribution (topo) makes that
>>> feasible.
>>>
>>> If you try to extended network functionality, your control distribution
>>> emphasis changes significantly, and you still have to consider the
>>> touch
>>> point of the control application with the wire - tcams, scope, aging,
>>> etc
>>>
>>> Since non of these reach & function needs are going away it looks like
>>> SDN
>>> overlays on IP can be used to sandbox the conflicting requirements. I
>>> haven't seen a hammer other then layers that can handle such different
>>> nails.
>>>
>>>
>>>
>>> On Jan 15, 2013, at 6:26 AM, "[email-masked]"
>>> <[email-masked]> wrote:
>>>
>>> Hi Sharon,
>>> Thanks for these valuable insights.
>>> In the preSDN networking world, due to practicality of evolution and
>>> backward compatibility needs there arose multiple ways of doing the
>>> same
>>> thing..i.e gather and use graph reachability information.
>>> SDN is our chance to begin with a clean slate, while we need not throw
>>> the interoperation with existing networks totally out the window, we
>>> must also be careful not to avoid falling into the trap of restricting
>>> the capabilities and flexibility due to its need, even at first as
>>> options in isolation, for SDN.
>>> What we could consider in IRTF is standardizing a single way to gather
>>> reachability information (in a capacitated graph, typically). Indeed as
>>> you point out very aptly, such reachability information can be of
>>> varying geographical spans and varying aggregation level spans and
>>> these
>>> can have causal connections. If I understand you correctly, an
>>> Aggregration pivot has implications on the geographic spans that need
>>> to
>>> considered, and such aggregation pivots serve to segment/split the
>>> geographic expanse (conceptually in the graph model of the network that
>>> is) that the control has to deal with.
>>> It appears then if only we have a control of a control that based on
>>> the
>>> specified aggregation pivots redistribute the division between
>>> distributed control and distribution of control that when combined with
>>> operations on Graph model with scalable algorithmic schemes as
>>> mentioned
>>> in GPS, then we will have a powerful means to exercise traffic control,
>>> shaping and delivery which are the fundamental aspects of any network.
>>> A source of complexity we may need to handle is to be able to allow for
>>> multiple instances of such distributed control and distribution of
>>> control working together.
>>> Such segmentation between distributed control and distribution of
>>> control also could yield to a scalable solution.
>>> Sitaraman
>>>
>>>
>>>>
>>>> These bring up interesting global-local distinctions.
>>>>
>>>> The scope of a flow definition is clearly local to the aggregation
>>>> point:
>>>> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection
>>>> ..depends.
>>>>
>>>> The context of handling a flow in a specific point clearly has global
>>>> user-app considerations.
>>>> Distributing control logic is therefore according to global context
>>>> mapping not aggregation topology. This is different then control
>>>> distribution considerations for packet forwarding.
>>>>
>>>> The touch point between control and forwarding is therefore a
>>>> practical
>>>> choice.
>>>> The control has to be both locally (scope & mechanics) and globally
>>>> (user-app) aware.
>>>>
>>>> Overlays work quite well in that sense, global awareness by
>>>> distributed
>>>> clustering,
>>>> local touch point splits, or merges encapsulates flows based on global
>>>> pipeline need.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Jan 14, 2013, at 17:49, "[email-masked]"
>>>> <[email-masked]> wrote:
>>>>
>>>> Hi,
>>>> Some thoughts.
>>>> 1. Does the separation of control plane from the forwarding
>>>> necessarily
>>>> mean the control now is to be centralized? It likely is not. Though
>>>> the
>>>> network device itself need not implment the control plane and can be
>>>> interacted via an OpenFlow interface, the control funcationality can
>>>> be
>>>> a separate distributed system.
>>>> 2. Model to represent Network
>>>>  Network and traffic flows are fundamentally flows in capacitated
>>>> graphs.  Could we look at using Stanford Graph Processing System
>>>> (GPS) for SDN based networks. The periodic communication amongst
>>>> nodes seem to naturally map to a traffic and information flow in a
>>>> network?
>>>>
>>>> 3. Model to repsresent capacities of network resources and logical
>>>> abstractions of physical resources.
>>>>  SDN dosent and probably should not change anything fundamental in the
>>>> traffic flow itself. This means that here SDN must look into reusing
>>>> existing models.  TMF models is a likely candidate.
>>>> 4. Model to represent faults.
>>>>  Same as above. New type of faults related to the decoupled (possibly
>>>> yet distributed) control plane to be harmonized with model for
>>>> existing faults. Again TMF is a source.
>>>> 5. Model to respresent Business aspects (Products, Orders such as time
>>>> to delivery commitments)
>>>>  Same as above and again TMF is a source for this model. The new SDN
>>>> network could leverage by being able to be invoked or referred to in
>>>> the existing TMF business model aspects. After all these are directly
>>>> related to revenue and Customer Experience Management.
>>>> 6. Is it distributed control, distribution of control or soemwhere in
>>>> between that is preferable. Distributed control can be a conceptual
>>>> centralized control which is implemented in a distribued manner.  Can
>>>> this nature be adaptively changed. Any aspects of learning in control
>>>> plane in SDN networks.
>>>> 7. Layers of control Ethernet Layer, MPLS layer, IP layer.
>>>> 8. Service Providers' bottom line is business and this means the TMF
>>>> FAB
>>>> Fulfilment, Assurance and Billing. SDN models must leverage the
>>>> existing
>>>> model as transparently as is practically feasibile.
>>>> Sitaraman
>>>>
>>>> Possibly of interest.
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "Eggert, Lars" <[email-masked]>
>>>>>> Subject: [irtf-discuss] New: Software-Defined Networking Research
>>>>>> Group
>>>>>> (SDNRG)
>>>>>> Date: January 14, 2013 10:24:57 GMT+01:00
>>>>>> To: "<[email-masked]>" <[email-masked]>,
>>>>>> "<[email-masked]>" <[email-masked]>
>>>>>> Cc: "[email-masked]" <[email-masked]>
>>>>>> Reply-To: "[email-masked]" <[email-masked]>
>>>>>>
>>>>>> A new IRTF research group on Software-Defined Networking has been
>>>>>> chartered:
>>>>>>
>>>>>> The Software-Defined Networking Research Group (SDNRG) investigates
>>>>>> SDN
>>>>>> from various perspectives with the goal of identifying the
>>>>>> approaches
>>>>>> that
>>>>>> can be defined, deployed and used in the near term as well
>>>>>> identifying
>>>>>> future research challenges. In particular, key areas of interest
>>>>>> include
>>>>>> solution scalability, abstractions, and programming languages and
>>>>>> paradigms
>>>>>> particularly useful in the context of SDN. In addition, it is an
>>>>>> explicit
>>>>>> goal of the SDNRG to provide a forum for researchers to investigate
>>>>>> key
>>>>>> and interesting problems in the Software-Defined Networking field.
>>>>>>
>>>>>> Charter and participation information can be found at
>>>>>> http://irtf.org/sdnrg
>>>>>>
>>>>>> Lars Eggert
>>>>>> IRTF Chair
>>>>>
>>>>> _______________________________________________
>>>>> openflow-discuss mailing list
>>>>> [email-masked]
>>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>>>>>
>>>>> --
>>>>> This message has been scanned for viruses and
>>>>> dangerous content by MailScanner, and is
>>>>> believed to be clean.
>>>>
>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by MailScanner, and is
>>>> believed to be clean.
>>>>
>>>> _______________________________________________
>>>> sdn mailing list
>>>> [email-masked]
>>>> https://www.irtf.org/mailman/listinfo/sdn
>>>>
>>>>
>>>> _______________________________________________
>>>> sdn mailing list
>>>> [email-masked]
>>>> https://www.irtf.org/mailman/listinfo/sdn
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by MailScanner, and is
>>>> believed to be clean.
>>>
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>>
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Sharon <[email-masked]>
Date: Sun, 20 Jan 2013 20:31:55 -0800

Most of what you say corresponds to the basic notion of layers.
In this case network virtualization SDN layer that the end points do not see.
Just like application software doesn't see the HyperVisor layer inserted between the OS and the machine in order to virtualize computers.

As for a language and programming model above the open flow "assembly" -

For many usage examples its more or less a matter of declarative Schema:
- The identities: location state and logical containers (big table)
- The policies catalogs of much smaller size user-defined tables 

For traffic engineering you probably need SDN layer control points presence in core junctions.
This is more tricky because the graph you want to handle is an overlay graph.
It's very hard to keep track of every physical underlying hop -
But the overlay graph can be measurement based ..

For such Overlay graphs Most likely a structured CLOS or Valiant topology can be used.
This can map to a logical Schema of intermediate points as well.

What I think you want to avoid is a situation where a trivial physical topology change or re-patching of ports triggering a massive recalculation of traveling salesman flows.
It's better if the network heals autonomously with fading side effects away from the "fault-line",
Followed by gradual reintroduction of programmed control points.

This is worth further examination.

On Jan 15, 2013, at 22:08, [email-masked] wrote:

Hi Sharon,

---

From: [email-masked]
Date: Mon, 21 Jan 2013 15:51:41 +0530 (IST)

Though you have raised a very important distinct aspect, storage schemes
needed for the problem, i will for now set that aspect aside for now.

 Layer transparency is indeed very useful. But we need to be careful to
distinguish between traffic, control,  application (and others?)
layering.  Visibility in and across layers in one category may actually
be needed to ensure transparency in others.

 I have a feeling when we talk of network design and optimization we may
risk mixing things up here. For the best architecture to evolve, network
design must (to the extent possible) assume the worst Protocol and
Control architecture and vice versa, must likely not assume the best...
What we were earlier discussing is more closer to Network Control and
Protocol design for SDN and layers above it. This must not assume or must
be minimally aware of the network design in itself which occurs on top of
the Network.
 Layering of various categories and the coordination of them (the split
points that you mentioned) has the potential to allievate some of the
massive recalculation...partly aided by the transparency afforded and not
needing a global re-optimization a sort of a "convexity" characteristic
to the problem, as the Optimization folks seem to call it for something
similar.
Sitaraman

> Just like application software doesn't see the HyperVisor layer inserted
> between the OS and the machine in order to virtualize computers.
>
> What I think you want to avoid is a situation where a trivial physical
> topology change or re-patching of ports triggering a massive recalculation
> of traveling salesman flows.