- Nsi-wg - lists.ogf.org

call tomorrow 9ET
by John Vollbrecht 01 Sep '09

01 Sep '09

We will have a call tomorrow morning. Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180 Proposed agenda 1. review slides from Joan 2. discuss motivation and context sections from Guy and Jerry I will try to send some notes/comments on motivation and context prior to call. Others might as well if they have time. 3. discuss meeting in Banff John

1 0

NSI Motivation and Context
by Jerry Sobieski 28 Aug '09

28 Aug '09

Hi all- Jeroen vdH and I put together a few points regarding the "conext" and "motivation" for NSI. Please review and comment... NSI Context 1. Emerging hybrid network services are being deployed in most NRENs. There is currently no consensus method for automated provisioning of these services, for asserting policy over the use of these services. Once provisioned, there also are no common processes for monitoring to insure service levels or to localize performance problems. These services are being developed without a comprehensive understanding of how these services will be accessed, applied, or provisioned - particularly as more dynamic, automated, global, and virtualized requirements are emerging. 2. There is a growing portfolio of globally distributed [science] applications that need predictable and quantifiable network services. These growing data-centric science work flows require a more integrated approach that matches network performance to the acquisition, transport, computation, storage, and visualization/analysis of the particular science processes. The global nature of these science activities means that these network services will necessarilly extend across many networks and a myriad of transport technologies to link collaborating colleagues and facilities. A common model for realizing these services on a global basis has not yet emerged despite ongoing work on control planes for provisioning them. 3. Hand crafted hybrid services for the current early adopters are slow and manpower intensive. The development of automated systems that allow collaborating research teams to craft application specific cyber-infrastructure environments is hobbled by the cacophony of locally developed interfaces, services models, and technologies. 4. There exists a multitude of industry standards and recommendations that attempt to address many of the technical issues associated with multi-domain, multi-layer, dynamic path computation and provisioning, but these are often confusing or contradictory, and assume traditional industry service models that limit their usefulness in the increasingly federated and virtualized global R&E networking and telecommunications environment. 5. Broad and ubiquitous adoption (or at least availability) of connection oriented services is a key objective without which maturation of hybrid services will be difficult. And adoption will be driven by the ease and simplicity with which a) the non-expert cyber-infrastructure user is able to access and leverage these services, and b) the network service provider(s) can adapt their environments to meet a common global services model. NSI Motivators: 1. A simplified architecture for requesting specific and deterministic services from the network is necessary to drive adoption. The NSI, however, should view the "Connection" as just one possible service for which a formally defined interface should be defined. The NSI should anticipate the introduction of other network services and should therefore be extensible to support a variety of such services. 2. Due to the increasing scope and complexity of co-scheduled global cyber-infrastructure, automated agents will be necessary and responsible for specifying and negotiating a complex array of resources - in particular: network resources. The NSI should facilitate such automated service interactions/transactions. 3. As the ability to provision connection oriented services becomes a more ubiquitous user capability, the traditionally separate roles of "user' and "network" will merge as application specific cyber-environments evolve into global private networks, and in turn offer specialized network (and other CI) services to niche communities. An NSI archtitecture that can support both federated services as well as virtualized services is necessary. 4. A scalable solution for global service provisioning must recognize local (domain specific) requirments or situations. An NSI must be able to inter-work with such local solutions yet provide a service with global reachability.

1 0

NSI motivation/context
by Guy Roberts 27 Aug '09

27 Aug '09

Below is a re-worked motivation/context Guy Network Service Interface Motivation and Context In recent years adoption of control plane protocols have allowed network operators to support fast automated creation of connection-oriented circuits within their networks. These services are being rolled out in research and education networks to support the demanding connectivity requirements of big science projects such as grids. With increasing international cooperation, the demand for international circuits is also rising requiring inter-operator co-ordination of these services. Existing providers implement a wide range of technologies (Ethernet, SDH, OTN etc) to deliver connection oriented services. These connections are built using a variety of control or management planes (MPLS, GMPLS, TMN etc). Current operational practices typically require cross-network connections to be created by each network separately and the interconnect point to be mutually agreed by manual negotiation between operators. This process of add-hoc manual creation has proven to be slow and expensive and acts as an inhibitor to service uptake. While it is possible for all providers to cooperate and run a common control plane (such as GMPLS) the process of agreement between providers and the timescales required to implement this common control plane is likely to be prohibitive. For this reason, an application-to-provider network service interface is proposed by the NSI-WG. This should be implemented in a way that allows operators to exchange connection requests while retaining their existing network technology and their exiting control plane. The interface aims to be able to be rapidly deployed compared to, for example, wide scale deployment of GMPLS eNNI. The solution should also be readily scalable and support web service based to support network virtualization in grid network service environments. NSI The Network Service Interface (NSI) standard defines an interface that will allow a connection oriented service that spans multiple networks to be requested. The requestor may be either another network operator or an application such as grid middleware. 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, in each network, of a Network Service Agent (NSA) which is capable of controlling a set of network resources - for transmission equipment this might 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: 1. Between an application layer (for example grid middleware) and an operator service plane layer. 2. 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 ------------------------------------------------------------------------------------------------------------------

1 0

call Wed 9 ET
by John Vollbrecht 26 Aug '09

26 Aug '09

This is a reminder that we will have a call Wed Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180 tentative agenda Layer names -- suggestions -- change Data Plane to Transport Plane as in ASON, change Control Plane as used in NSI so far to Service Plane, define Control Plane as signalling actual connections, define management plane. I am not sure if there is also an AAA plane and/or a Policy plane NS agent relationships -- Joan, Tomohiro Context section Layers and adaptation -- see diagram I sent out last week suggestions for changes or additions? I have contacted some folks from Ciena who may be able to help with G. 800 and ASON. I will update you on that.

3 3

Conf call minutes for today's NSI call
by Guy Roberts 26 Aug '09

26 Aug '09

Hello All, The minutes for today's NSI conference call are available here http://forge.gridforum.org/sf/go/doc15751?nav=1 Guy ------------------------------------------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------------------------------------------

1 0

standards context for NSI
by Guy Roberts 26 Aug '09

26 Aug '09

Hi All, To help me keep track of standards related to NSI I have created as document summarizing these. I have put a copy on gridforge: http://forge.gridforum.org/sf/go/doc15749?nav=1 Any comments are welcome, in particular security and web service standards are not clear to me. Guy ------------------------------------------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------------------------------------------

2 1

Network Service Agent interaction/relationships
by Joan A. Garcia-Espin 26 Aug '09

26 Aug '09

Dear all, Attached you will find a slide-set describing some basic NSA interaction models, as it has been commented on the last call conferences. Please feel free to comment on them. All the best, -- Joan A. Garcia-Espin Network Technologies Cluster (CTX) i2CAT Foundation C/ Gran Capità 2-4, office 203, Nexus I building 08034 Barcelona, Catalonia (Spain) T: +34 93 553 2518 F: +34 93 553 2520

1 0

revised slides
by John Vollbrecht 26 Aug '09

26 Aug '09

A couple revisions on slides I sent earlier thanks to Jeroen- John

1 0

text for NSI context
by Guy Roberts 26 Aug '09

26 Aug '09

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: 1. Between an application layer (for example grid middleware) to operator service plane layer. 2. 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 ------------------------------------------------------------------------------------------------------------------

3 3

revised slides for NSI/ G.800/8080 naming
by John Vollbrecht 25 Aug '09

25 Aug '09

attached is a revised PPT of concepts and names for NSI. It includes ASON (G.8080) names in the comparison table. It uses the terms service plane and transport plane (which were not in earlier version, but could have been control plane and data plane in earlier version)

1 0