November 2009 - Nsi-wg - lists.ogf.org

NSA functional components v2.3
by Chin Guok 02 Dec '09

02 Dec '09

Hi all, I've revised the document based on our last discussion. Please feel free to comment and make edits. Please also keep in mind that the contents of this document should only serve as supporting text for the NSI architecture document and is not meant to detail the NSA architecture (which would be a separate document). Thanks. - Chin

2 1

Slides for discussion
by John Vollbrecht 30 Nov '09

30 Nov '09

Attached is revised set of slides based on last weeks call conversation and including new discussion of transport resource and Broker/wholesaler <=> authorization policy I would appreciate comments and suggestions. John

1 0

SC09 - NSI protocol minutes
by Inder Monga 30 Nov '09

30 Nov '09

Hi All, A group of around 15 of us from met for an interim meeting at the SC 2009 show to discuss and kickstart the NSI protocol discussions. The following are the summarized decisions from the meeting. This note will be followed by a doodle poll to decide on the date and time for the first con call. Summary of decisions 1. NSI protocol specification will be divided into two standard documents a. NSI protocol messaging specification The scope of this standards specification will be to define the messages and interaction between requester and provider agents that will be the NSI interface. The specification would also indicate the structure of the messages, define the norm for specifying technology specific parameters and the state machine to manage lots of simultaneous interactions. The messages will be defined at a high-level and the detailed protocol encodings will be part of the next specification. The set of features that will be part of NSI 1.0 will be discussed within the group and included as part of this specification. b. NSI protocol implementation specification The scope of this standards specification is to specify the exact on-the-wire protocol to implement the messages and interaction defined in the above standards document. The current expectation is that the NSI protocol group would work on web services based implementation specification of this protocol. It is quite feasible for a community to define an RSVP based implementation of the above protocol or another implementation specification at the time in future. 2. The current set of editors are: Evangelos Chaniotakis, Tomohiro Kudoh, Radek Krzywania and Matthew Lemay. 3. The following steps are planned between now and the next OGF meeting: a. Information exchange: Research project like G-lambda, OSCARS, IDC, Phosphorus/Harmony present their current message set. Doodle poll for the meeting in 3rd week of december to follow b. NSI 1.0 Feature set: Jerry and Inder to suggest a first pass set of features to be included in NSI 1.0 . c. The group of editors take this updated set of information and create a draft specification for the NSI group to review by late January 2010. d. Setup regular conference calls in January to discuss the document and open issues, leading towards the first draft specification by the March OGF. Thanks, Inder

1 0

Issues for NSI/NML coordination
by John Vollbrecht 30 Nov '09

30 Nov '09

Hello all- I have been working on description of transport plane for NSI. I think what is coming out of this makes the coordination simpler in some ways and also raises a problem to be resolved. 1) NSI is basically a resource reservation and instantiation protocol. The resource it deals with is connections between ports. A connectionin NSI map to a links in NML quite nicely. So this is the part that is simpler- there is no need to distinguish between networks and links as NSI has been doing. 2) Resources controlled by an NS provider agent are a set of ports between which it can provide transport connection. This can be represented by a group in NML. The group of NML resources is a combination of nodes and links. The problem is that the NSI resource may a terminate with a link or a node. If it terminates with a node, the node has a port. If it terminates with at link, links currently have no port. This is the problem - NSI resource [NML group] has ports on the edge while NML does not define port links, and link may be last topological element in the group. To resolve this problem NSI could call end points something other than ports, or NML could define links as having ports. I am not sure which way is better. Having ports be specific to nodes makes it possible to describe switching and termination capabilities for the port, which don't exist on links. Having ports exist on links seems to correspond to the G.800 and ASON view where nodes and links have ports and where ports connect to each other is a point. This also makes the names on the edge the same for both NML and NSI which might be desirable. Comments or suggestions? John

1 0

Issues for NSI/NML coordination
by John Vollbrecht 30 Nov '09

30 Nov '09

Hello all- I have been working on description of transport plane for NSI. I think what is coming out of this makes the coordination simpler in some ways and also raises a problem to be resolved. 1) NSI is basically a resource reservation and instantiation protocol. The resource it deals with is connections between ports. A connectionin NSI map to a links in NML quite nicely. So this is the part that is simpler- there is no need to distinguish between networks and links as NSI has been doing. 2) Resources controlled by an NS provider agent are a set of ports between which it can provide transport connection. This can be represented by a group in NML. The group of NML resources is a combination of nodes and links. The problem is that the NSI resource may a terminate with a link or a node. If it terminates with a node, the node has a port. If it terminates with at link, links currently have no port. This is the problem - NSI resource [NML group] has ports on the edge while NML does not define port links, and link may be last topological element in the group. To resolve this problem NSI could call end points something other than ports, or NML could define links as having ports. I am not sure which way is better. Having ports be specific to nodes makes it possible to describe switching and termination capabilities for the port, which don't exist on links. Having ports exist on links seems to correspond to the G.800 and ASON view where nodes and links have ports and where ports connect to each other is a point. This also makes the names on the edge the same for both NML and NSI which might be desirable. Comments or suggestions? John

1 0

conf call minutes
by Guy Roberts 27 Nov '09

27 Nov '09

Hi All, Here are the minutes for Wednesday's conf call: http://forge.gridforum.org/sf/go/doc15823?nav=1 Our next call will be Wednesday 2nd December at the usual time, call details to be posted. 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

NSI slides
by John Vollbrecht 25 Nov '09

25 Nov '09

This is something we can talk about tomorrow-- John

1 0

call tomorrow
by John Vollbrecht 24 Nov '09

24 Nov '09

There will be a call tomorrow at 9 ET - I am thinking this may be a short call. We should review meeting at SC and talk next steps. Please send any work in progress to discuss. I hope to have something to share later today. --- call info Call infoCall: +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 John

1 0

Location for protocol meeting tomorrow
by Inder Monga 17 Nov '09

17 Nov '09

Hi All, We will have the protocol meeting tomorrow (Tuesday, Nov 17th) at the Lawrence Berkeley National Lab booth (# 723). I have reserved a table there where we can talk. Unfortunately, phone connection will not be possible there for remote participants, though I will try fire up skype. I could not book the whisper room as it was busy. Hope to see you all there! Thanks, Inder

1 1

Protocol Message Path descriptions
by John Vollbrecht 16 Nov '09

16 Nov '09

This is a quick note to discuss path descriptions that might be received by a Provider Agent P1 when making a request. 1) simple path [A ->Z] A and Z are ports on the network known to (or findable by) P1 2) Multi-hop path [A -> B -> C -> Q ->Z] A, B, C, Q and Z are ports on the network know to (or findable by) P1 3) Strict -hop path [A -> B -> C -> D -> Z] A, B, C, D, and Z are ports on the network known to (or findable by) P1 Comment - I am not sure there is a difference between 2 and 3. I started thinking 2 was loose hop, 3 was strict hop. Now I think they are the same as far as the requestor is concerned. 4) Mid-chain path [A *-> B* -> C -> Z] A *-> B* -> C is outside the request but is included as part of the chain being requested There may be other path descriptions for requests. When responding to a request 1) simple path [ A<->Z] 2) multi-hop path [A <-> B <-> C <-> D <->Z] 3) Mid chain path [A*-> B *-> C <-> D <-> Z] Finally, the times that one uses a path 1) request instantiation of a path that has been reserved 2) request timed [phase 1] scheduling of resource 3) request commited [phase 2] scheduling of resource I don't know if there is a time for introducing this at the meeting Tuesday, but I submit this for possible discussion. John

1 0