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@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg
  