Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization

From: David Meyer <[email-masked]>
Date: Fri, 25 Jan 2013 10:24:11 -0800

[not sure which lists you were trying to post to, so I added [email-masked]]

I'll just note here as a general comment that part of the success (and
really, beauty) of the IP architecture is its inherent simplicity. If
SDN becomes a dumping ground for *gratuitous* complexity (as we are
currently seeing in many venues) then it will fail.

--dmm

On Fri, Jan 25, 2013 at 10:08 AM,  <[email-masked]> wrote:
> We had Vint Cerf himself visit and talk to us today evening.
> Amongst others, he highlighted to us Openflow and SDN allowing routing
> based on  content in addition to headers.
>  My immediate reaction was question that this being an antithesis to
> standardization.....then Vint mentioned an example about routing based on
> charactersitics of the data and routers selectively choosing to listen
> (per my understanding of what Vint said, not certain i got it entirely.)
>  Could we say that the conventional protocols are more leaning towards
> syntactic standardization (Bits in header fields have tightly defined
> ranges and constructs).
>  Has Semantic standardization, pattern matching been done before at
> IETF/IRTF?
> Any relationship to Ontologies?
>  ARe the implications to correctness, convergence, routing loops and such
> of algorithms in this context been formally studied?
>  Would it make sense to start halfway and have two header components, one
> decided by the protocol and the other header components contents decided
> by the application itself (this will form a special part of the data).
> yet this part of the data being in a well defined restricted area of the
> data..is this beginning to look like optical network framing where frame
> at one layer is data for the other? Combine this with NMS based routing,
> (decoupled control of SDN) SDN is beginning to get a lot of the
> charactersitics of Optical then?
> Sitaraman
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> openflow-discuss mailing list
> [email-masked]
> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss

---

From: [email-masked]
Date: Sat, 26 Jan 2013 00:02:49 +0530 (IST)

I believe in one thing...
simplicity must always occur as a result of addressing and hiding
complexity, there is no free lunch as they say, simplicity in itself
without someone somewhere identifying, addressing and hiding for the
clients, the complexity...well simply will have true little true value
addition is what i feel...simplicity is for the users complexity is for
the designers....the more the complexity is identified and addressed, the
more the world will enjoy simplicity as a result....
Sitaraman

---

From: Sharon <[email-masked]>
Date: Fri, 25 Jan 2013 11:34:06 -0800

Right, but designers (there's lots) could use a few simple ground rules.

Flows - have always been a part of switch-router designs,
time to open them up for programming, in itself not a trivial task -
as can be seen from the various bug queries in this list.

Overlays - well, at least you know they don't break basic connectivity,
rather they use it and interject additional logic in well defined edge points.

Global awareness - that's the most tricky part, it could use a simple
definition and a resilient structure of how it's used and how it works.
"Controller" isn't such a definition.

On Jan 25, 2013, at 10:32, [email-masked] wrote:

_______________________________________________
sdn mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/sdn

---

From: [email-masked]
Date: Sat, 26 Jan 2013 08:41:51 +0530 (IST)

Agreed,
 By programmable flows, if i  understand correctly what you are referring
to is applications programmable flows (else flows have always been
programmed...). This pushes complexity up into the application layer,
which challenges if identified and adrressed could result in powerful
paradigms in networking and its operations (self -*?) IRTF could address
these...
   What are flow decisions applications would like to make an OSS system
specould be one eager candidate for the same (maybe work with TMF on
it...)s?
 Overlays can be good and bad, good for backward compatibility, scaling,
bad for the certain rigidity it brings to the architecture...yes,
overlays in one aspect (control) could lead to a homogenization in the
other (flows) and possible vice versa.
   Related to global awareness, Vint gave a couple of examples yesterday,
dealing with context awareness...in making speech recongintion
tractable, and wearable computers....This is a powerful concept
indeed...and application controlled flows allows precisely this, to
bring context awareness into routing decisions...it is like the
applications are walking around wearing routers on their heads!
Wearable routers for applications!
   I wonder if defintion should come before conceptualization or the other
way around...maybe  it should be overlayed, when and at what point....?
Sitaraman

> Right, but designers (there's lots) could use a few simplec grorund rules.
>
> Flows  have always been a part of switch-router designs,
> Overlays - well, at least youi know they don't break basic connectivity,

---

From: [email-masked]
Date: Sat, 26 Jan 2013 11:13:21 +0530 (IST)

On the content based routing...we could look at standardizing things like
for example, content fields where data or downloads are requested or
scheduled.

OSS applications can go more real time and perform traffic engineering
based on this by rerouting, reallocaiton of resources. Vint was mentioning
to us yesterday that it is not so much the amount of data requested but
the temporal nature of the same. This means of temporal nature of requests
could also be standardized for benefit (scheduled interchange of data in
organizations, relatively long on demand downloads...) Would you consider
this as a reasonable benefit for an application that warrants study of the
possible complexities involved.
 Another aspect that was discussed was charging based on the rate not the
absolute bandwidth used.  Facilities such as the above will allow service
providers a means to provide subscirbers automated optimizations to
schedule non urgent requests at lean times to a) reduce the cost to
customers, b)optimize their own use of network to increase customer base.
Would this warrant identifying, addressing and study of the complexities
involved as opposed to being "gratuitous"

Sitaraman

---

From: [email-masked]
Date: Wed, 30 Jan 2013 14:32:52 +0530 (IST)

What SDN buys us, due to its ability fo mess with forwarding directly at
the applicaiton layer is to bring in the possibility of Context Awareness 
of application data for tweaking forwarding decisions.
Fundamentally one difference between connection oriented  and
connectionless is the preemptibility of the paths. Here again, MPLS-TE's
LSP set up and hold priority kinds of reaches out to each other. LSPs are
connection oriented while giving connectionless like preremiptibiliy to
these LSPs.
With SDN with its application controlled routing would allow is, 
therefore, we could consider "Context Aware Premebility" which could be a
mix of Connectionless and Connection oriented nature.
I see some literature (one of them by John Strassner, i recolect some time
ago there was a long thread of discussion on Context Awareness involving
John too) on relating Context Awareness to Ontologies too...
We could look at IRTF on defining such application controlled dynamic
preemptibility configuration while cross technology expression of this
capability using Policies perhaps or Policy independent Interfaces is
something we could consider at jointly with TMF.
Sitaraman

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 30 Jan 2013 16:10:12 +0000

Sitarman,

I'm confused/bugged by the statement 'Fundamentally one difference between connection oriented and connectionless is the preemptibility of the paths'

I wonder if we are mixing (or redefining?) two concepts I thought I knew.
  1) The concept of connection versus connection-less. An example is the difference between TCP and UDP, which is more about protocols at the edge than things in the middle.
  2) The concept of dedicated versus statistical (shared) bandwidth.  An example is the difference between CBR and UBR or between a leased tdm circuit and an Internet route.  These are more about things in the middle like routing or who gets to use the tx port when.

SDN seems likely to be about managing the middle for the benefit of stuff at the edge so I assume you are thinking more about the middle.  Perhaps I should read your statement 'Fundamentally one difference between <dedicated and statistical paths> is the preemptibility of the paths'?

Regards,

Stuart

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 30, 2013 3:03 AM
To: [email-masked]
Cc: David Meyer; [email-masked] [email-masked]; SDN IRTF list
Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization

What SDN buys us, due to its ability fo mess with forwarding directly at the applicaiton layer is to bring in the possibility of Context Awareness of application data for tweaking forwarding decisions.
Fundamentally one difference between connection oriented  and connectionless is the preemptibility of the paths. Here again, MPLS-TE's LSP set up and hold priority kinds of reaches out to each other. LSPs are connection oriented while giving connectionless like preremiptibiliy to these LSPs.
With SDN with its application controlled routing would allow is, therefore, we could consider "Context Aware Premebility" which could be a mix of Connectionless and Connection oriented nature.
I see some literature (one of them by John Strassner, i recolect some time ago there was a long thread of discussion on Context Awareness involving John too) on relating Context Awareness to Ontologies too...
We could look at IRTF on defining such application controlled dynamic preemptibility configuration while cross technology expression of this capability using Policies perhaps or Policy independent Interfaces is something we could consider at jointly with TMF.
Sitaraman

> On the content based routing...we could look at standardizing things
> like for example, content fields where data or downloads are requested
> or scheduled.
>
> based on this by rerouting, reallocaiton of resources. Vint was
> mentioning to us yesterday that it is not so much the amount of data
> requested but the temporal nature of the same. This means of temporal
> nature of requests could also be standardized for benefit (scheduled
> interchange of data in organizations, relatively long on demand
> downloads...) Would you consider this as a reasonable benefit for an
> application that warrants study of the possible complexities involved.
>  Another aspect that was discussed was charging based on the rate not
> the absolute bandwidth used.  Facilities such as the above will allow
> service providers a means to provide subscirbers automated
> optimizations to schedule non urgent requests at lean times to a)
> reduce the cost to customers, b)optimize their own use of network to increase customer base.
> Would this warrant identifying, addressing and study of the
> complexities involved as opposed to being "gratuitous"
>
> Sitaraman
>
>
>> I'll just note here as a general comment that part of the success
>> (and really, beauty) of the IP architecture is its inherent
>> simplicity. If SDN becomes a dumping ground for *gratuitous*
>> complexity (as we are currently seeing in many venues) then it will fail.
>>
>> --dmm
>>
>>
>>> Amongst others, he highlighted to us Openflow and SDN allowing
>>> routing based on  content in addition to headers.
>>> standardization.....then Vint mentioned an example about routing
>>> based on charactersitics of the data and routers selectively
>>> choosing to listen (per my understanding of what Vint said, not
>>> certain i got it
>>> entirely.)
>>>  Could we say that the conventional protocols are more leaning
>>> towards syntactic standardization (Bits in header fields have
>>> tightly defined ranges and constructs).
>>>  ARe the implications to correctness, convergence, routing loops and
>>> such of algorithms in this context been formally studied?
>>>  Would it make sense to start halfway and have two header
>>> components, one decided by the protocol and the other header
>>> components contents decided by the application itself (this will
>>> form a special part of the data).
>>> yet this part of the data being in a well defined restricted area of
>>> the data..is this beginning to look like optical network framing
>>> where frame at one layer is data for the other? Combine this with
>>> NMS based routing, (decoupled control of SDN) SDN is beginning to
>>> get a lot of the charactersitics of Optical then?
>>> Sitaraman
>>>
>>>
>>> --

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 30 Jan 2013 16:22:19 +0000

Hi folks,

(including icnrg)

"content" (for example name based routing) is a topic in Information-Centric Networking (ICN). I agree it's an interesting application for SDN.

One interesting question might be what kind of SDN abstraction would be required to better support this -- as it is a bit different compared to flow-based communication.

Best regards,
Dirk

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> STUART VENTERS
> Sent: Mittwoch, 30. Januar 2013 17:10
> Cc: SDN IRTF list
> I'm confused/bugged by the statement 'Fundamentally one difference
> between connection oriented and connectionless is the preemptibility of the
> paths'
> 
>   1) The concept of connection versus connection-less. An example is the
> difference between TCP and UDP, which is more about protocols at the edge
> than things in the middle.
>   2) The concept of dedicated versus statistical (shared) bandwidth.  An
> example is the difference between CBR and UBR or between a leased tdm
> circuit and an Internet route.  These are more about things in the middle like
> routing or who gets to use the tx port when.
> 
> SDN seems likely to be about managing the middle for the benefit of stuff at
> the edge so I assume you are thinking more about the middle.  Perhaps I
> should read your statement 'Fundamentally one difference between
> <dedicated and statistical paths> is the preemptibility of the paths'?
> 
> 
> Regards,
> 
> Stuart
> 
> 
> 
> What SDN buys us, due to its ability fo mess with forwarding directly at the
> applicaiton layer is to bring in the possibility of Context Awareness of
> application data for tweaking forwarding decisions.
> connectionless is the preemptibility of the paths. Here again, MPLS-TE's LSP
> set up and hold priority kinds of reaches out to each other. LSPs are
> connection oriented while giving connectionless like preremiptibiliy to these
> LSPs.
> With SDN with its application controlled routing would allow is, therefore, we
> could consider "Context Aware Premebility" which could be a mix of
> Connectionless and Connection oriented nature.
> >>> 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: [email-masked]
Date: Wed, 30 Jan 2013 21:54:16 +0530 (IST)

Hi Stuart,
Indeed, you make a valid point here, thanks for bringing this out. Please
give me some time..i need to clarify my thoughts more...thanks again
Sitaraman
>  Sitarman,
>
> I'm confused/bugged by the statement 'Fundamentally one difference between
> connection oriented and connectionless is the preemptibility of the paths'
>
> difference between TCP and UDP, which is more about protocols at the
> edge than things in the middle.
> circuit and an Internet route.  These are more about things in the
> middle like routing or who gets to use the tx port when.
>
> SDN seems likely to be about managing the middle for the benefit of stuff
> at the edge so I assume you are thinking more about the middle.  Perhaps I
> [email-masked]

---

From: Pedro Martínez Juliá <[email-masked]>
Date: Wed, 30 Jan 2013 17:33:53 +0100

> Hi folks,

Hi,

> (including icnrg)
>
> "content" (for example name based routing) is a topic in
> Information-Centric Networking (ICN). I agree it's an interesting
> application for SDN.
>
> One interesting question might be what kind of SDN abstraction would be
> required to better support this -- as it is a bit different compared to
> flow-based communication.
>

The typical ICN data-plane function can be modeled as a (m)any-to-one flow, a 
flow with multiple possible sources and one sink. The SDN controller should be 
able to manage the "(m)any" concept to decide/determine the flow source and 
thus construct the flow between one specific information/content source and 
the client that asks for it.

On the other hand, to provide the caching function, a SDN should include the 
concept of data stores. Thus, a controller may set an element to introduce or 
get a flow-unit (packet/message) to/from such its store.

> Dirk

Regards,
Pedro

-- 
Pedro Martinez-Julia
Department of Communication and Information Engineering
Faculty of Computer Science
University of Murcia
Email: [email-masked]
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

---

From: Scott Brim <[email-masked]>
Date: Wed, 30 Jan 2013 17:07:44 +0000

>get a flow-unit (packet/message) to/from such its store.

But the ICN data plane is intentionally connectionless and highly dynamic
with respect to sources.  You want none of the planned configuration of
SDN forwarding.

---

From: Pedro Martínez Juliá <[email-masked]>
Date: Wed, 30 Jan 2013 18:17:42 +0100

> with respect to sources.  You want none of the planned configuration of

Flows are different than connections. I get your point about high dynamics but 
you will have a flow as soon as a ICN "source" is sending data to a ICN 
"sink". The key question is in determining which source can and will respond 
to the content requests and SDN controllers *should* be able to do it.

Regards,
Pedro

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 30 Jan 2013 16:31:11 +0000

Dirk, all,

for an idea of possibly mapping ICN over SDN, please see D. Syrivelis, G. Parisis, D. Trossen, P. Flegkas, V. Sourlas, T. Korakis, L. Tassiulas, Pursuing a Software-Defined Information-Centric Network, EWSDN 2012, IEEE, Darmstad Germany

The idea here is to NOT map content relations onto SDN since the scaling problems are potentially severe (I assert that the dimension of the 'information space' is significantly larger than that of communication relations in the network). Hence, the paper takes a different approach and promises scalability along the dimension of communication relations in the network.

Best,

Dirk
On 30 Jan 2013, at 16:22, Dirk Kutscher wrote:

> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 30 Jan 2013 17:24:22 +0000

> Flows are different than connections. I get your point about high dynamics but you will have a flow as soon as a ICN "source" is sending data to a ICN "sink". The key question is in determining which source can and will respond to the content requests and SDN controllers *should* be able to do it.

That's well put and I agree. See the provided paper reference in my email before. It includes a paragraph that outlines what a 'flow' here is in order to work well (i.e., scale) in SDN.

Dirk

---

From: [email-masked]
Date: Wed, 30 Jan 2013 23:13:57 +0530 (IST)

Hi Stuart,
   Like George Orwells more equal animals, i guess we can say some are
more connection oriented amongst connection oriented beasts.... When i
said connection oriented earlier, i had SDH type circuits in mind.
Indeed as you say,  TCP is an example of a connection that rides on a
connectionless layer underneath.
   I tend to think it has less to do with middle or edge, i.e less to do
with location in the typical telecommunication network topology or even
functionality (core or edge). For, you do have connectionless IP
running in the core (middle) that drives the LSP formation (connection)
in the middle. Similarly you have the control protocol for
connectionless IP - MPBGP driving a VPN "Connection" in the edge. If
you have Carrier Ethernet MAC in MAC you have connectionless in core
and with PBB-TE you have connection with the same technology -
Ethernet.
   When i say connection, i simply meant to indicate the charactersitic
that the application using this connection simply puts its data on one
end with the assurance it comes out at the other end of the
connectio(the path). I agree that i must explicitly add  "At the layer
at which the connection works"...for. like TCP, the connection can ride
over a connectionless layer underneath. (The terminology "Layer"
admittedly being used a bit loosely here than it should be, as it is
used to specify Layer Rates).
  By Preemptibility, i meant to indicate the preemptibility of this
charactersitic itself. When you say shared bandwidth, in the case of
TCP/IP, you are talking of sharing of the data pipes that go a couple of
layers below. Thats not what i intended to come across as saying, i was
more intending to say preempting of the connection itself, and this is
important.... at the layer the connection is established.
  Connections thus far in networks are established before hand, upfront,
in Optical an NMS does it and in IP the control plane does it. Then, the
application simply uses the connection. An applcation can choose to use
a connection or use another, it has no control beyond that.
  What i was wondering was if SDN paradigm could be exploited to provide
preemptibility of the connection, determined by the applicaiton context.
This may be done entirely by the application itself, or, perhaps more
likely, this is a use case scenario for an NMS(again centralized as
opposed to a distributed, in-router protocol) interfacing on behalf of
the applications with the controller.
  This means, that application context can drive preemption of connections
which to me appears like it could offer more
powerful/flexible/intelligent routing schemes that currently done.
 It appears to me, that SDN provides a means to exploit data or even
networking parameter context (bw used)visibility when made available to
management modules, to perform more intelligent routing that takes the
context and perhaps even go as far as  semantics of data into
congnizance. Perhaps what we could do to address the very real
scalability concern here is defining semantic patterns, ontological
representations and interfaces that would allow quick communcation of the
same to the NMS,  which would in turn interface with controller to do the
inteliigent routing, or reorg of network.
  Therefore i would say again that one fundamental difference between
connection and connectionless (as it exits now) is the preemptibility of
paths (i will now add however, at the "layer" at which the connection is
established...for connections it is trivial, two well defined end points
constituting the path, while for connectionless it is not).
  Does this sound more resonable?
Sitaraman

---

From: [email-masked]
Date: Thu, 31 Jan 2013 07:47:17 +0530 (IST)

Hi Stefano,
 Yes indeed, i agree with this approach of exploiting the decoupling of
the control as is provided by SDN to make routing aware of the contexts
that can be carried by the content.
 Two things.  The terminology NBI appears to me a vestige of legacy.  With
SDN, i would say the lines between devices, NMS, EMS and OSS begins to
blur. Decoupling and centralization of control in terms of topology, 
leads to a flatness in the interface semantics needed for operation. This
is like impulse response and time-frequency domain relation. The more
distributed the control domain is, the more hiearchical the semantics
that need to transferred for network operations and in this context the
NBI terminology makes sense. The converse is also true, the more
centralized the control becomes (centralized conceptually that is)the
more homogeneous the information semantics becomes.  I tend to think the
"Northbound"
terminology could be a tad misleading suggestive.
 This also means that we need no longer look at IP packet headers to
support Semantic routing.
 This is for the hardware folks there, would it be feasible to incorporate
exchange of meta rules, that the NRS, or even the OSS can come up with
that is then conveyed to Openflow which abstracts away the information
and just directs the forwarding to inspect a given area and route
accordingly. The hardware neednt do the abstraction itself, which could
be too much to ask, but the latter functionality, if given an "address"
in the packet the address being able to point to any area including data,
and a rule to match the contents of the same to determine
forwarding....the forwarding can then take place based on this rule?
Sitaraman
> Il 30/01/2013 18:17, Pedro MartÃ­nez JuliÃ¡ ha scritto:
>> Flows are different than connections. I get your point about high
>> dynamics but you will have a flow as soon as a ICN "source" is sending
>> data to a ICN "sink". The key question is in determining which source
>> can and will respond to the content requests and SDN controllers
>> *should* be able to do it.
>
> Hi all,
>
> FYI we have been working on ICN support with SDN/OpenFlow and recently
> submitted the paper
>
> Information Centric Networking over SDN and OpenFlow: Architectural
> Aspects and Experiments on the OFELIA Testbed
>
> available at http://arxiv.org/abs/1301.5933
>
> regards,
> Stefano
>
>>
>> Regards,
>> Pedro
>>
>
>
> --
> *******************************************************************
> Stefano Salsano
> Dipartimento Ingegneria Elettronica
> Universita' di Roma "Tor Vergata"
> Via del Politecnico, 1 - 00133 Roma - ITALY
>
> http://netgroup.uniroma2.it/Stefano_Salsano/
>
> E-mail  : [email-masked]
> Cell.   : +39 320 4307310
> Office  : (Tel.) +39 06 72597770  (Fax.) +39 06 72597435
> *******************************************************************
>
> --