[Sdnp] updated SDN problem statement draft
Pankaj Shroff
shroffg at gmail.com
Wed Mar 14 15:01:04 EDT 2012
One suggestion is that perhaps it is valuable to consider the existence of
such a "platform", "layer", "API" or "controller" in the context of
specific vertical applications/services. For example if you take a specific
service like Content Delivery or Video Streaming over CDNs, where service
provider owns the underlying networking infrastructure, does it make sense
to have a "service controller" and then what are the "protocols or APIs" it
could/ would/ should exercise in order to orchestrate the underlying
elements - whether they are Proxy Server Selection functions (service
layer), ALTO servers (SDN layer), Routers (network layer) or Optical
transport switches (OTN, ROADM, DWDM, etc.) (Transport layer)? Maybe? Maybe
not?
Not necessarily advocating the control/ orchestration of all these elements
in every session setup - but just offering a service oriented use case to
work off of.
Perhaps there are sufficient use cases like this that could benefit and the
SDNP layer could be broad enough to cover those set of "interesting"
services.
Pankaj
On Wed, Mar 14, 2012 at 2:50 PM, Ping Pan <ping at pingpan.org> wrote:
> Wrong list to ask the question.
>
>
> On Wed, Mar 14, 2012 at 11:41 AM, Tina TSOU <Tina.Tsou.Zouting at huawei.com>wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Mar 14, 2012, at 6:27 AM, "Ping Pan" <ping at pingpan.org> wrote:
>>
>> On Wed, Mar 14, 2012 at 5:23 AM, Scott Brim <scott.brim at gmail.com>wrote:
>>
>>> On Tue, Mar 13, 2012 at 11:48, David Meyer <dmm at 1-4-5.net> wrote:
>>> > Thanks Ping. Search for dmm> in-line.
>>>
>>> > Software Defined Network (SDN) is an overlay architecture that
>>> > presents the underlying transport network to the applications and
>>> > services for monitoring, and provisioning at abstraction level.
>>> >
>>> >
>>> > dmm> Is it true that SDN an overlay architecture, or is this SDN
>>> > dmm> something different than what is being termed SDN in the
>>> > dmm> industry? If so maybe we should use a different term?
>>>
>>> From a distance I'm still wondering about this group's "SDN" and other
>>> "SDNs". This definition doesn't sound like an overlay architecture,
>>> rather it sounds like element management.
>>>
>>
>> Yeah, I hear you. Let's forget about ONF SDN, IETF SDN and other
>> flavors of SDN's and names. Let's just focus on its original concept that
>> first advocated by Scott Shenker and others - we may have misinterpreted it
>> quite a bit. However, over the past many months, we keep asking: what is
>> it? why us? how does it really work at engineering level? what business
>> will it serve?
>>
>> For a long time, we have been trying to go through all the material,
>> products and use cases that we can get our hands on, and met many who are
>> working in this area. There are a couple of enlighten moments, especially,
>> when I saw the campus deployment in Indiana University. Through the use of
>> routers plus OpenFlow-enabled OEM boxes, the virtual NOC can control and
>> allocate bandwidth to different users. The users can run a
>> totally independent network off servers, and run some very simple
>> applications. The total cost of ownership is tiny, the management of the
>> virtual NOC is getting crazy, but the potential it presents is
>> amazing. (The guy was telling me that the excitement, the craziness and
>> the unknowns are very much like when we were doing NFSnet :-))
>>
>> This "virtual" network is presenting itself with a real engineering
>> challenge to overcome. User registration is a problem. The existing
>> provisioning methodology is way too trivial via OpenFlow, on the other
>> hand, the box itself is dirt cheap. The basic network management,
>> including coordinating network alarms to the virtual users/applications, is
>> not in place. Redundancy and protection - what are they? ;-) Yes, the
>> north-bound API's do not exist in any standard form....
>>
>> Doesn't SOP do this job?
>>
>>
>> We can call whatever the name we want, but I think this is an area that
>> IETF can address and contribute.
>>
>> Regards,
>>
>> Ping
>>
>>
>
> _______________________________________________
> SDNP mailing list
> SDNP at lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp
>
>
--
Pankaj Shroff
shroffG at Gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lucidvision.com/pipermail/sdnp/attachments/20120314/ebb9665a/attachment.htm>
More information about the SDNP
mailing list