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

Starting Assumptions for GNI API
by Gigi Karmous-Edwards 20 Aug '09

20 Aug '09

All, Here is a starting point for the list of assumptions for the NSI API. I put these together for our GNI work in the GLIF GNI task force. (please add/delete/modify them as necessary ) Initially the GNI is only implementing three basic calls: 1) CreateReservation 2) CancelReservation 3) ListReservations With these calls we agreed to the following assumptions: 1) Users/NSA should have information regarding the endpoints, such as the type of technology at the interface, and exact location (URI) - this information should be available as either part of the request or the NSA can look it up based on a URI. 2) The NSI API can be used by a client that is an end user/application requesting a multidomain lightpath from an NSA or it can be used by another (“ingress”) NSA making a specific request to a single NRM for a partial path as part of a multidomain lightpath. 3) In some cases the user has a pre-defined chosen route or a preferred next-hop, therefore the API should have feilds available for these two cases. 4) If the technology used at the two endpoints differ, then the NRM/NSA servicing the request is responsible for including technology adaptation. - The API does not explicitly request technology adaptation, it is inferred. 5) It is assumed that the parameters will follow the NML working group language. 6) The API will not be used to exchange topology information. This is all I have at this point, I am sure the list should be longer. Kind regards, Gigi

2 1

Conf call minutes for 19th Aug
by Guy Roberts 20 Aug '09

20 Aug '09

The minutes for the last conf call are available here: http://forge.gridforum.org/sf/go/doc15747?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

Re: [Nsi-wg] route selecting (path finding)
by Jerry Sobieski 19 Aug '09

19 Aug '09

Hi all- First: Looking at Tomohiro's diagram I am reminded of the PNNI routing protocol where every network element was a member of a group. Each NE had a routing entity and spoke to its neighbor(s). The routing agents would dynamically elect a "group node" that would speak for the entire group. That Group Node would learn by flooding within its group which of its sub-nodes had connections to external groups and what those groups' Group Nodes were. And the local GN would establish an adjacentcy with its neigboring GN and exchange only summarized routing topology (no intra-group topology.) The diagrams with NSAs and Coordinators looks exactly like the diagrams they used in the PNNI standards ( but the names have been changed to protect the innocent:-) IMO, the PNNI hierarchichal approach to routing is *very* powerful and addresses many of the scalability issues associated with link state protocols - which are the optimal means for Path Computation. I suggest that - *if* the group believes the NSI-WG must consider routing/path comput protocols, that PNNI is something that should be looked at more closely. Second: Why do we (the "NSI" WG) care about path computing algorithms? IMO, in this regard there are two interface definitions required: #1) The delegated chain model single domain connection request, and 2) a topology request. If the user wants to pursue a tree model service establishment process and do their own PC, they can do it with a #2 followed by a series of one or more #1s. And *how* they chose the #1s is up to them - not part of the NSI. ...Now back to my regularly scheduled proposal deadline.... Jerry Radek Krzywania wrote: > Hi Tomohiro, > According to your slides, it seems that pathfinder finds all/multiple > inter-domain paths at once. If I am wrong, you may ignore the rest of this > email ;) If I am right, and pathfinder is about to result in more than one > path, then my experience is that this is quite difficult to implement. The > issues are as follows: > - you need to define how many paths will be returned (e.g. why 5, not 6 or > 100), otherwise you will find all of them, which may be thousands. > - Algorithms for graph searching allows you to find one path (e.g. Dijkstra) > or all paths (some graphs searching algorithm). There are some k-Dijkstra > algorithms but they relay on some constraints which we may not accept. > - if you found first path, what are the constraints for the second one? > Avoid all links from the first path, don't use one of the link on the path > (then which one should be avoided), etc. Guessing which links should be > avoided for n-th search is IMHO not the most optimal way of doing that. You > can always remove the most crowded links, but still, you don't know why the > previous (e.g. 1st) path will be refused, so you have no guarantee the next > one (e.g. 2nd) will be optimal in this particular case. > > Searching multiple path makes the pathfinding process more complex and > includes some decision mechanisms. Thus I have a question if we are going to > get into it. In AutoBAHN we did it simple - we use Dijkstra to find a sigle > path. If it fails for some reason, we know where (e.g. insufficient > bandwidth on link x or domain y refused the reservation). We temporary > remove x or y from topology and run Dijkstra once again. So we have > alternative path, which is expected to be still optimal (according to > current network condition on x and y). AutoBAHN interface for pathfinder > allows to get multiple path, just in case. But this feature is not used in > practice due to implementation complexity. > > Best regards > Radek > > -----Original Message----- > From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of > Tomohiro Kudoh > Sent: Wednesday, August 19, 2009 1:44 PM > To: NSI WG > Subject: [Nsi-wg] route selecting (path finding) > > Hi all, > > Attached slide shows my view of route selectiong (path finding) wrt NSI. > > I am sorry but I must leave today's call at around 10am EDT. > > Tomohiro > > _______________________________________________ > nsi-wg mailing list > nsi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg > >

1 0

Re: [Nsi-wg] route selecting (path finding)
by Tomohiro Kudoh 19 Aug '09

19 Aug '09

Hi Radek, In the slide, the coordinator NSA finds a path, according to the topology and availability information. It can find all the/multiple paths at once, or it can use Dijkstra. The algorithm the coordinator NSA uses is an implementation issue. In my diagram, static information (topology and capability) are described in the topology description, and may be obtained through Information Service, and availability information is gathered by queries to leaf NSAs. But I agree there can be other models. One thing what I think we should consider is that if a domain is operated by a commercial operator, the operator may not disclose all the availability information. Kind regards, Tomohiro On Wed, 19 Aug 2009 14:03:25 +0200 "Radek Krzywania" <radek.krzywania(a)man.poznan.pl> wrote: > Hi Tomohiro, > According to your slides, it seems that pathfinder finds all/multiple > inter-domain paths at once. If I am wrong, you may ignore the rest of this > email ;) If I am right, and pathfinder is about to result in more than one > path, then my experience is that this is quite difficult to implement. The > issues are as follows: > - you need to define how many paths will be returned (e.g. why 5, not 6 or > 100), otherwise you will find all of them, which may be thousands. > - Algorithms for graph searching allows you to find one path (e.g. Dijkstra) > or all paths (some graphs searching algorithm). There are some k-Dijkstra > algorithms but they relay on some constraints which we may not accept. > - if you found first path, what are the constraints for the second one? > Avoid all links from the first path, don't use one of the link on the path > (then which one should be avoided), etc. Guessing which links should be > avoided for n-th search is IMHO not the most optimal way of doing that. You > can always remove the most crowded links, but still, you don't know why the > previous (e.g. 1st) path will be refused, so you have no guarantee the next > one (e.g. 2nd) will be optimal in this particular case. > > Searching multiple path makes the pathfinding process more complex and > includes some decision mechanisms. Thus I have a question if we are going to > get into it. In AutoBAHN we did it simple - we use Dijkstra to find a sigle > path. If it fails for some reason, we know where (e.g. insufficient > bandwidth on link x or domain y refused the reservation). We temporary > remove x or y from topology and run Dijkstra once again. So we have > alternative path, which is expected to be still optimal (according to > current network condition on x and y). AutoBAHN interface for pathfinder > allows to get multiple path, just in case. But this feature is not used in > practice due to implementation complexity. > > Best regards > Radek > > -----Original Message----- > From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of > Tomohiro Kudoh > Sent: Wednesday, August 19, 2009 1:44 PM > To: NSI WG > Subject: [Nsi-wg] route selecting (path finding) > > Hi all, > > Attached slide shows my view of route selectiong (path finding) wrt NSI. > > I am sorry but I must leave today's call at around 10am EDT. > > Tomohiro >

1 0

NSI and G.800
by John Vollbrecht 19 Aug '09

19 Aug '09

Attached is a ppt that shows NSI concepts in G.800 terms. There are some questions in my mind about naming. There is a table showing NSI, G.800 and NML naming as I think they exist.

2 1

route selecting (path finding)
by Tomohiro Kudoh 19 Aug '09

19 Aug '09

Hi all, Attached slide shows my view of route selectiong (path finding) wrt NSI. I am sorry but I must leave today's call at around 10am EDT. Tomohiro

2 1

call wed 9am ET
by John Vollbrecht 17 Aug '09

17 Aug '09

we wil have a call wed at 9am ET 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 - Guy -- context - John, Guy, Jeroen - G.800 and NSI - Joan, Tomohiro, (Radek) on communcation between NS agents (control plane or service plane) - Chin and others on DOE architecture I will try to send out some diagrams showing G.800 naming and figures to replace pics in strawman doc. I hope also to be able to send out some comments on the DOE architecture (which is quite nice) I may send out a proposed outline for the doc for discussion - depends on how much time I have John

1 0

DOE Multi-Layer Architecture Document
by Chin Guok 17 Aug '09

17 Aug '09

Hi all, I've attached the DOE architecture document that I referenced in the last call (on Aug 12). Please do not redistribute this document outside of the NSI WG. Comments are welcomed. Thanks! - Chin

1 0

notes from call 8/12
by John Vollbrecht 12 Aug '09

12 Aug '09

On the call were Jeroen, Tomohiro, Joan, Chin, Freek, Guy, Gigi and myself. Discussion 1. Joan describe work he is doing with describing NS agent interfaces. He is working on slide set and will hopefully be able to present it next week or the week after. Some discussion - discussed the difference between dataplane which can be modeled by G.800 and the control plane. Tomohiro said that we should have a third plane that describes coordination between NS agents differently than coordination of dataplane [I may have this wrong - Tomohiro might want to comment}. - Chin talked about architecture document being worked on for DOE that describes a service plane, and as I understand it the service plane describes all interactions with NS agents. Interactions between agents is (I think) always with web services. Chin will see if it is possible to share this doc with the NSI wg. - there was some discussion of how Lookup Service and Path Computation capabilities fit into this. These seem like Information service similar to DNS or BGP for IP. - This is a subject to be discussed further in the group - by email and on calls. 2. Guy is working on a context section for document and will have a draft for next week 3. We discussed G.800 and NML and NSI. Consensus was that G.800 was a good way to describe NSI type networks. Concepts of G.800 map nicely to NSI concepts. Guy suggests that we consider using G.800 naming for NSI. I am not sure that works completely, but would be good if it could. One issue is that G. 800 concept of subnetwork is NSI concept of network. There may be other issues. We should consider this. We discussed how G.800 and NML interact. Seems that G.800 describes concepts that are included in NML schema. This is mostly done, NML group is working on details of schema now. Once schema is done then it is represented in a language. Discussed the difference between NML and GMPLS description of adaptations. My take is that GMPLS defines specific adaptations in detail, while NML wants to have abstract adaptations with capabilities assigned to each instance. Gigi raised the question of whether G.800 had been implemented by any vendors or providers. Jeroen agreed to ask the same question on Friday on the NML call. I am wondering the same for GMPLS. - We will have a call next week - Wed at 9ET. please add, correct or comment on notes - John

1 0

Re: [Nsi-wg] action items from call today
by Radek Krzywania 12 Aug '09

12 Aug '09

Hi, I've updated the PF examples with Data Plane and Control Plane names (yes, it took me some time :( ). I can prepare a more textual description with cases to make them more clear, if you wish to. Best regards Radek -- ____________________________________________ Radoslaw Krzywania radek.krzywania(a)man.poznan.pl +48 61 858 20 28 Network Research and Development Department Poznan Supercomputing and Networking Center ____________________________________________ > -----Original Message----- > From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf > Of Radek Krzywania > Sent: Tuesday, June 23, 2009 12:34 PM > To: 'John Vollbrecht'; 'NSI WG' > Subject: Re: [Nsi-wg] action items from call today > > Hi all, > In the attachment you will find PF examples. I've used term PCE as Path > Computation Element, which is standardized somewhere, but naming is > open. > It's not full list of cases, as there may be many permutations, but I > guess it may give an overview. The main issue is that the path provided > by PCE in the first domain, MAY or MAY NOT include details if each > domain along reservation path. Thus reservation process MAY include > some negotiations elements, where each domain will do local path > finding and provide a detailed path (or will just calculate it, and > keep hidden against other domains). > If a requested connection does not start in the user home domain (where > request was submitted), two scenarios are possible: > - domain will be responsible to manage the reservation, thus it will > not do local domain path computation, only the global one to define > reservation source domain. > - domain will delegate this responsibility to first domain on > reservation source path (may be more complicated in fact) > > Best regards > Radek > > -- > ____________________________________________ > Radoslaw Krzywania > radek.krzywania(a)man.poznan.pl > +48 61 858 20 28 > > Network Research and Development Department Poznan Supercomputing and > Networking Center ____________________________________________ > > > -----Original Message----- > > From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On > Behalf > > Of John Vollbrecht > > Sent: Wednesday, June 17, 2009 6:10 PM > > To: NSI WG > > Subject: [Nsi-wg] action items from call today > > > > The following are action items we agreed on today > > > > 1) Radek will send a set of use cases for pathfinding in different > > modes - distributed, central, separate requestor, -- > > 2) Joan may add additional use cases > > 3) John will do pictures for the use cases > > 4) Guy will include use cases in his UML diagrams > > 4) Guy consult with Tomohiro and Sebastien and others about diagrams > > 5) Joan will attempt to describe a request messages that includes > > anycast to start and have specific edgepoints in end result > > > > Did I miss anything? > > > > John > > > > _______________________________________________ > > nsi-wg mailing list > > nsi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/nsi-wg

1 0