[Nsi-wg] text for NSI context

Wed Aug 26 07:35:10 CDT 2009

Hi Jerry,

These are good points, I agree that the multi-layer limitations of GMPLS are due to current implementations rather than being inherent to GMPLS, so this needs to be clear.

In my opinion a well written standard will start by clearly stating the motivation for the standard - this should then acknowledge existing standards/implementations and why these are not capable of achieving these goals.

The trick here (as you point out) is to identify the unique selling points of NSI - these are not entirely clear to me.   One way of presenting this could be to view NSI as a 'service plane' (to use Chin's definition) interface that supports a new concept of service plane path computation.  This service plane overlays (and requires) a  lower path computation layer which can be implemented as either a control plane (eg GMPLS) or as a management plane (eg TMN).  i.e. the unique selling point is that we allow operators to keep their existing domain internal management and we are creating a new layer (service plane) which supports multi-domain path request.

Guy

From: Jerry Sobieski [mailto:jerry at nordu.net]
Sent: 26 August 2009 12:57
To: John Vollbrecht
Cc: Guy Roberts; 'NSI WG'
Subject: Re: [Nsi-wg] text for NSI context

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<http://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<mailto:nsi-wg at ogf.org>
http://www.ogf.org/mailman/listinfo/nsi-wg

________________________________

_______________________________________________

nsi-wg mailing list

nsi-wg at ogf.org<mailto: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/6508f7e3/attachment.html 