[Nsi-wg] text for NSI context

[Jerry Sobieski]

Hi John (and everyone)-

I can't let this one slip by:-)   -> GMPLS *IS* multi-layer.   Thats the 
whole "Multi-protocol" part of GMPLS.    In the GMPLS standards, they 
explicitly broke out "path computation" and defined a Path Computation 
Element that would provide EROs - it was then left to the implementor to 
develop the algorithms for doing so.  If they chose to do adaptation 
between layers, or to focus on one or just a few layers, that was their 
choice.  But it wasn't a limitation in the GMPLS standards.  GMPLS-OSPF 
and GMPLS -RSVP very definately support multi-layer networks.   

Where GMPLS is not so strong is in *multi-domain* networks.   OSPF does 
not scale well to large (global) networks, but it would work fine for 
small networks - technically.   But there are other issues to crop up 
(black box topology) that is *not* GMPLS conformant that cause things to 
need additional thinking.   These other issues, many of which are 
multi-domain issues, are what IMO drive the need for OGF-NSI.

But in general, we should not start our document out this way- dissing 
one particular standard no matter what its dis-ability.  We are not 
defining the OGF-NSI to fix GMPLS, we are trying to provide a common 
solution to some issues that no provisioning systems or networks address 
in a consistent manner:  The interface between the user/agent that is 
requesting/needs a [circuit] service, and the network agents that can 
provide it.   

I do think we should be careful however to reference prior work in this 
area in order to show that we don't idly making up new standards.    
There has been much work done in the past to define "User-Network 
Interfaces" and "Network-Network Interfaces" and I-NNIs, and E-NNIs, etc 
that have discussed many of the same issues we have in this group.   We 
need to state how NSI fits in the context of these standards... Why an 
OGF-NSI recommendation is required that is not satisfied by these other 
industry standards/recommendations.   (This reference need not be in the 
intro or a context statement, but in the detailed document we should 
reference these other standards.)

I think the "context" is trying to go in a good direction, to make a 
good point - that some aspects of the dynamic provisioning process are 
not clearly or consistently defined or adopted among interoperating 
networks...and that *does* need to change for myriad stated reasons.   I 
would suggest we tilt this statement in this way, rather than trying to 
make a statement that we do OGF-NSI because GMPLS is broken...

Jerry



John Vollbrecht wrote:
> I  think this is a good start.  I think it needs to focus at first on 
> the difference between network centric and grid centric approaches and 
> that NS is aiming to accomodate both.  I will work on some words for 
> this to try to help in the next week or so.
>
> John
>
> On Aug 19, 2009, at 9:29 AM, Guy Roberts wrote:
>
>> Context to NSI
>>
>> In recent years adoption of control plane protocols such as GMPLS 
>> have allowed network operators to support fast automated creation of 
>> connection-oriented circuits within their networks.  As these 
>> services are rolled out in research and education networks to support 
>> the demanding connectivity requirements of projects such as grids, 
>> demand for inter-operator co-ordination of these services is 
>> increasing.   Existing protocols such as GMPLS are inherently single 
>> layer in nature and do not readily interoperate between networks of 
>> heterogeneous technology.  The Network Service Interface (NSI) 
>> standard defines an interface that will allow an arbiter such as grid 
>> middleware to request a connection oriented service that spans 
>> multiple networks.  This network service setup requires 
>> configuration, monitoring and orchestration of network resources 
>> across each network under particular agreements and policies.
>>
>> The Network Service Interface assumes the existence of a Network 
>> Service Agent (NSA) which is capable of controlling a set of network 
>> resources – for transmission equipment this could typically be a 
>> network management system operating in accordance with TMN 
>> principles. The NSA is able to authorize, reserve, schedule, 
>> instantiate, monitor, teardown, negotiate, and log its resources and 
>> the connections which are created from the resources.  The Network 
>> Service Interface is then defined as being the interface between a 
>> Requestor Agent (for example grid middleware) and the NSA.
>>
>> To support reservation of resources across multiple operators, the 
>> NSI interface must support the following messaging services:
>> Topology exchange service
>> Path computation service
>> Signalling service
>> Authorization and Authentication service
>>
>> While the NSI definition does not mandate any standards for 
>> implementation of these services within a network operator domain, a 
>> standardised exchange of information over the NSI interface is 
>> required. So for example domain internal path computation may be 
>> performed by the operators preferred method (such as PCE), however 
>> the results of this computation should be exchanged is standardised 
>> in NSI.
>>
>> The NSI interface is intended to be implemented either:
>> Between an application layer (for example grid middleware) to 
>> operator service plane layer.
>> Between operator service plane layers.
>>
>>
>> ------------------------------------------------------------------------------------------------------------------ 
>>
>> Guy  Roberts,  Ph.D
>>
>> Network Engineering & Planning
>> DANTE - www.dante.net
>> Tel: +44 (0)1223 371 316
>> City House, 126-130 Hills Road
>> Cambridge, CB2 1PQ, UK
>> ------------------------------------------------------------------------------------------------------------------ 
>>
>>
>>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20090826/20abd2bd/attachment-0001.html