[Sdnp] High-Level Motivation (Re: one or two blank looks on int-serv reference during the bar bof)

Ping Pan ping at pingpan.org
Mon Aug 1 10:42:40 EDT 2011 

Hi,

You have raised a very critical question here. During IETF and over the
weekend, several have asked off-line about our motivation. Are we doing
RSVP, UNI, GENI, bandwidth broker etc.?

So allow me to explain our thinking and motivation at very high level here:

(1) Why?

Many of us have been a part of the Internet creation and deployment in the
past many years. It has become something more than we had dreamed for better
or for worse. While we were squeezing the last bit of inefficiency out of
routing, forwarding and policing, the new applications have emerged
and proliferated. While we were designing the interface between transport,
packet, broadband and wireless networks, the new services have been created
and deployed simply over the underlying networks. While we were optimizing
the use of bandwidth and processing on our hardware, the Moore's Law has
made all parts of the network less expensive each day. This is the way it
is!

The interface between application and network has been an interesting area:
We have seen the approach in closing the network and enforcing tighter
control over users within a walled garden (good luck!). We have also seen
the attempts in pushing the traditional network operation methodology into
applications (yuk!)

My belief is that we should open up the network, embrace
new applications and provide simpler and easier interface to the users. The
value of the network is in attracting more traffic, more users and more
applications, not in creating more middlemen.

Many have been saying that network should be a "dumb pipe". True and false.
It's true that, as far as users are concerned, any link between two network
endpoints should be predictable and reliable as a simple wire. At the same
time, the network needs to be pretty smart in making the interface dumb.

Today, we can create connections at any layer, at any rate, in any format,
with any property and in any granularity inside the network. Our motivation
here is in making the network connections visible and programmable to the
applications.

(2) Why us?

For a long time, Web and network technologies have been developed
in parallel. However, the recent demand in data centers requires the massive
web transaction and the heavy network transport taking place within a few
hundred feet. Web operation, driven by massive parallel processing and
massive content replication, demands simple and cheaper network support. To
date, no network port is faster enough, and no application-network operation
is efficient enough.

I believe that the network technology needs to scale up and accommodate the
demand from the applications. We need to make our network simpler, easier
and more efficient. (Yes, we say this every time when we start a new
project, the outcome is always contradicting. But, we try anyway! ;-))

We envision to create programmable network API's, by adapting both
networking and application techniques. We will leverage the existing
networking technologies, designed and defined in IETF, to create, monitor
and discover network resources, services and connections. And we will
leverage the scalable and secure message processing capability from Web (or
over port-80) for API's.

(3) Examples (be more specific)

Network programmability applies in many places, and we see a few
applications need to be solved real fast.

First, the VM network interface is VLAN. As such, any VM network-level
service manipulation need to be accomplished through the management at
VLAN-granularity.

For example, if VM applications require non-disruptive services, the service
operators may map the VM's to the network links with bandwidth, delay and
protection constraints, by utilizing MPLS and FRR to achieve network-wide
support.

Another example is in supporting enterprise VPN's. In this scenario, the
service operators may bundle the relevant VM's to the corresponding MPLS
VPN's. All the techniques defined in IETF can be readily used to support VM
mobility and service security here.

Another area we need to to look at is in the area of video/media services.
OTT video services will likely store the content on the data centers, and
utilize local CDN's for delivery (take a look at Netflix). The content may
be replicated from data center to data center, and CDN's may utilize
different distribute techniques. However, the service operators may map the
(logical) content to the actual distribution engines with service
guarantees. I know some of the work has been discussed in ALTO, so let's
work together there.

Service monitoring is another important aspect of the work. Each web service
is supported by many back-end applications, which may operated in different
locations. To have a robust service, the service operators need to have a
way to monitor and guarantee network-services to those services.

In summary, we envision SDN work to bridge the gap between the applications
and the network. In the future, we may address inter-networking concerns.
However, much of the networking-level work can be solved with a better OSS.
I'd prefer to solve the application-network interfacing issues first.


(4) Next Steps

I have an old-school when it comes to this: running code and rough
consensus!

In the coming weeks, we would like to collect more use cases, collaborate
with many, learn from each other. At the end, we should put together the
architecture, protocol design and hopefully some prototypes.

Hope this makes sense.

Best regards,

- Ping


On Wed, Jul 27, 2011 at 2:32 PM, Bitar, Nabil N
<nabil.n.bitar at verizon.com>wrote:

>
> I think during the meeting a good spectrum of use cases was discussed
> raging from data center type applications to the case of inter-provider
> connection setup or policy transfer.  It seems that there is a need to put
> down the use cases on paper and see what existing mechanisms can be used to
> address these use cases and why there is new work needed. Is it fresh new
> work or extensions to existing mechanisms?  What are the gaps  in what
> exists is being solved? It is not clear to me that there is one hammer that
> will be able to address all the use cases , and if needed, without
> recreating the wheel or adding complexities or deficiencies  That may be
> biased by the view I had walking into the meeting that there was tendency to
> focus on the interface between the application and the SDN controller  to
> request resources maybe subject to  constraints, to receive information,
> response to a request and/or notification  from the SDN controller. What the
> SDN controller does may capitalize on existing mechanisms which will be
> dependent on the use case and the nature of the application request.  While
> the interface can be generic  and extensible, the use case or application
> will drive what information is exchanged.
> I appreciate a clarification if all the the following still at play here or
> something was pruned out or too early to prune:
>
>    1. application -SDN controller interface. What is the function of that
>    interface is going to be application dependent. That goes for other
>    interfaces
>    2. SDN controller-SDN interface
>    3. SDN controller-SDN controller interface
>    4. Path computation (not necessarily TE ) for a tunnel or microflow
>    based on certain constraints.
>    5. flow mapping to a path, including flow classification and
>    configuration on every hop.
>
> Thanks,
> Nabil
> From: Thomas Nadeau <tnadeau at lucidvision.com>
> Date: Wed, 27 Jul 2011 11:29:20 -0400
> To: "Ong, Lyndon" <Lyong at Ciena.com>
> Cc: "sdnp at lucidvision.com" <sdnp at lucidvision.com>
>
> Subject: Re: [Sdnp] one or two blank looks on int-serv reference during
> the bar bof
>
>
>
>
>
> On Jul 27, 2011, at 11:15 AM, "Ong, Lyndon" <Lyong at Ciena.com> wrote:
>
> Hi Guys,****
>
> ** **
>
> Regarding (2), if we’re agnostic then this work seems to be more general,
> it could apply to OF-controlled networks, MPLS/GMPLS-controlled networks,
> PCE/non-PCE, etc.****
>
> ** **
>
> Regarding (3) not sure that this follows – in a lot of the control plane
> technologies there is a way to control the path.  Question, though, how much
> does an application need to know about the path?
>
>
> I think that depends on what the application is and what it's purpose is.
> It may be interested in network resources other than just links and paths.
> Also, as Danny mentioned in his use case yesterday there is a need for
> varying levels of granularity here.
>
> Tom
>
> ****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Lyndon****
>
> ** **
>
> BTW, the comparison to intserv reminds me that when I try to explain OF to
> people, they commonly ask why this is different from FORCES!****
>
> ** **
>
> <imageb58e9e.gif at b6446a3d.24d4497b>
>
> *From:* sdnp-bounces at lucidvision.com [mailto:sdnp-bounces at lucidvision.com<sdnp-bounces at lucidvision.com>]
> *On Behalf Of *Edward Crabbe
> *Sent:* Wednesday, July 27, 2011 7:23 AM
> *To:* Ping Pan
> *Cc:* <sdnp at lucidvision.com>sdnp at lucidvision.com
> *Subject:* Re: [Sdnp] one or two blank looks on int-serv reference during
> the bar bof****
>
> ** **
>
> ** **
>
> Our goal here is to solve a specific problem: map application flows (in
> whatever the form) into physical network tunnels.****
>
> ** **
>
> ** **
>
> three things here: ****
>
> ** **
>
> 1) so basically, you're saying you want a common language to  build a FEC,
> mapping a set of n-tuple matches (vlan, whatever) into a specific
> encapsulation?****
>
> ** **
>
> 2) are these tunnels pre-existing?  if so, fine, if not, we now have to set
> up the tunnel, at which point we're back to dealing with either OF type per
> hop state setup or an existing end to end signaling protocol (and  we're
> dealing with things at a per host, app level?  Thus the  int-serv reference
> ;-).  Perhaps the idea is to be agnostic regarding path setup method here?
> ****
>
> ** **
>
> 3) would this also imply that that definition of the characteristics,
> including path,  that the tunnel takes over the underlying infrastructure is
> in scope?****
>
> ** **
>
>  ****
>
> No need in limiting applications, and no need in making network smarter (or
> dumber). ;-)
> ****
>
> ** **
>
> Thanks!****
>
> ** **
>
> - Ping
>
> ****
>
> On Tue, Jul 26, 2011 at 7:28 PM, Edward Crabbe < <edc at google.com>
> edc at google.com> wrote:****
>
> for reference, was referring to:****
>
> ** **
>
> <http://tools.ietf.org/rfc/rfc2210.txt>
> http://tools.ietf.org/rfc/rfc2210.txt****
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________
> SDNP mailing list
> <SDNP at lucidvision.com>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
>
>
> _______________________________________________
> SDNP mailing list
> SDNP at lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lucidvision.com/pipermail/sdnp/attachments/20110801/6f66199a/attachment.htm>

More information about the SDNP mailing list