February 2010 - Nsi-wg - lists.ogf.org

Wednesday's NSI conference call
by Guy Roberts 16 Feb '10

16 Feb '10

Hi All, The following is call information for tomorrow -- same as always. 9 ET. 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 Agenda: Discuss the attached set of NSI definitions. 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

(no subject)
by Guy Roberts 15 Feb '10

15 Feb '10

Hi John, I have attempted to summarize the problem as you see it in the attached diagram. My understanding is that you want a network model that will support option 3 in the attached diagram. This will allow a port to be assigned to a link in a network without requiring a connection that forwards to a physical port on a switch to be present. Is this correct? 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

On-demand Infrastructure Services Provisioning workshop and BoF at OGF28
by Joan A. García-Espín 10 Feb '10

10 Feb '10

Dear all, I'm pleased to inform you about two events at OGF28 (both on Mon 15th) that may be of your interest (aligned to NSI activities): - Workshop "On-demand Infrastructure Services provisioning" (S. Figuerola, Y. Demchenko) http://www.ogf.org/gf/event_schedule/index.php?id=1968 - BoF "On-demand Infrastructure Services provisioning" (S. Figuerola, Y. Demchenko) http://www.ogf.org/gf/event_schedule/index.php?id=1961 I've been personally working with them and contributing to their activities in the ISoD 2009 workshop at TERENA (http://www.terena.org/activities/e2e/ws2/ ). Receive my apologises if you receive multiple copies of this email. Kind regards, -- Joan A. García-Espín 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

Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI
by Jeroen van der Ham 10 Feb '10

10 Feb '10

On 10/02/2010 00:55, Radek Krzywania wrote: > Hi Jeroen, > Is there any way to see the results of your simulations and the chapter you wrote on aggregation? I would like to take a closer look on that issue, as this issue is something I was investigating some time ago and could not find a strong reason to claim one to be better than the other. Sure. I'll pre-publish my thesis for this group: http://staff.science.uva.nl/~vdham/research/publications/thesis-jvdh.pdf The relevant section is part two of my thesis. The first chapter there is an overview of existing research regarding aggregating topologies, the second chapter describes my simulations and results. The thesis has been approved by the committee, my defense is in April. I will be sending out hardcopies in about two weeks, if you want one send me your postal address and I can send you one. Jeroen.

1 0

Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI
by Joan A. Garcia-Espin 10 Feb '10

10 Feb '10

Hi all, I'm also following the conversation and add one to Radek's request: is this info (or part of it) public Jeroen? I would be highly interested. Regards, -- Joan A. García-Espín CTX, i2CAT Foundation El 10/02/2010, a las 9:55, Radek Krzywania escribió: > Hi Jeroen, > Is there any way to see the results of your simulations and the > chapter you wrote on aggregation? I would like to take a closer look > on that issue, as this issue is something I was investigating some > time ago and could not find a strong reason to claim one to be > better than the other. > > Best regards > Radek > > ________________________________________________________________________ > Radoslaw Krzywania Network Research and > Development > Poznan Supercomputing and > radek.krzywania(a)man.poznan.pl Networking Center > +48 61 858 20 28 http://www.man.poznan.pl > ________________________________________________________________________ > >> -----Original Message----- >> From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On >> Behalf >> Of Jeroen van der Ham >> Sent: Tuesday, February 09, 2010 6:23 PM >> To: John MacAuley >> Cc: nsi-wg(a)ogf.org >> Subject: Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI >> >> On 09/02/2010 07:37, John MacAuley wrote: >>> 1. Aggregation and summarization. >> >> I've done some simulations, analysis and have written a chapter about >> this in my thesis. My results show that aggregating a domain to a >> single >> node performs very badly compared to an aggregation model where you >> advertise a full mesh between edge nodes. >> I would also argue that the advantages of simplifying the internal >> domain do not balance the disadvantages you have in false positives >> in >> inter-domain pathfinding. >> >> However, these simulations have only used a single layer. We're >> currently looking at pathfinding in multi-layer networks, and we're >> thinking about how to create aggregations for multiple layers. This >> is >> a >> hard problem. >> >> Given the fact that current domains are not that complicated, and we >> have a very open culture in regards to information exchange, I would >> suggest that we leave the problem of aggregation open for now and >> just >> use full topologies. >> >> Jeroen. >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/nsi-wg > > _______________________________________________ > nsi-wg mailing list > nsi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg

1 0

Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI
by John MacAuley 10 Feb '10

10 Feb '10

Jerry, Great slide package - you did a good job of describing the key concepts discussed on the last call. I think it is import we store these documents somewhere so people joining the list can access the most recent versions (and people like me who switch computers all the time can pull down copies). Last week at the GLIF there were a number of hallway conversations on the topic of topology. As with everything in the world people had differing opinions, but I think it was great since it did get me questioning about my position on the subject. I would like to make a couple of points for discussion: 1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional. 1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize. There are a couple of key ones we should consider for example: . Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network? . Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested? . Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find. Although I think it would be possible to describe and advertise these types of access control rules along with the internal topology for other path computation elements to utilize, they complexity of describing such data may be prohibitive. In addition, the controlling NRM would still need to evaluate any request path based on the provisioned policies and end user identity. Therefore, for simplicity I believe these routing decisions should be left up to the controlling NRM and not an external Path Computation Element. 2. Routing in both time and space. The specific point here is existing schedules/reservations are part of topology since we are routing in both space and time. I am not sure if this was explicitly stated anywhere, and from the discussions on the conference calls I definitely think people are considering spatial routing first, and the time aspect as part of the path reservation signaling. Obviously, evaluating the time aspect after a physical path has been computed is a valid solution, however, we may be able to derive more optimal solutions by incorporating existing schedules earlier in the process. Inclusion of schedules into the routing decision is how DRAC does performs path computation, but we have the distinct advantage of having all the topology for the domain and all the scheduled paths centrally located in our database. This allows for extremely fast and 100% accurate routing decisions. Obviously, distributing time-based topology is not feasible in a distributed control plane model due to the large dataset sizes, but with the summarized virtual node model we do have some opportunities for optimization due to the reduced scale of the problem. If we attach reservations to the UNI and E-NNI links reported via topology exchange for the virtual node, and use this additional information to perform path computation, we will have a high probability of reservation success the first time through if the summarized domain is fairly well connected internally. 3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-) John. > *From: *Jerry Sobieski <jerry(a)nordu.net <mailto:jerry@nordu.net>> > *Date: *February 2, 2010 2:24:10 PM EST > *To: *"nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg(a)ogf.org > <mailto:nsi-wg@ogf.org>> > *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI* > > Hi all- > > Relative to our brief discussion last week about topology and the NSI... > > We want the NSI to offer more power and options to the "user" - to > break out of the traditional carrier models for interacting with the > user. And I think our notions of Requesting aAgents and Providing > Agents does that nicely and in a very elegant and scalable fashion. > > However, we still have a lot of discussion about pathfinding - about > how the agents will go about decomposing a path request into sub-paths > for tree or chain model processing, or how we decide which NRMs are > responsible for a particular end point, etc. These all deal with > *topology*. There are quite a few notions we take for granted that > require some sort of topology model. For instance: a Service > Termination Point. Whatever we end up caling it, the semantics of an > STP is that it represents a point in the topology where a service > connection can terminate. We talk about capturing path information > for monitoring...that requires a notion of how the topology is > defined. There are lots of topologically based assumptions we need > to be more explicit about. > > So this set of slides tries to capture some thoughts of mine on how we > can pose a simple minimalist topological model sufficient for our NSI > purposes. I think it is consistent wth our thoughts and discussions. > And while it may bump into things that the NML WG is considering, I > doubt a) we have come up with anything conflicting, and b) we certanly > have not gone to the details of how to describe or distribute a > topology database - we just assume we have a TopoDB and that is > contains these basic constructs. > > Comments are welcome...Its only a draft for consideration... > Jerry > > While the NSI protocol itself does not impose a particular topology on > the transport plane or the agents that manage it, we do impose some > notions on the Connections we construct - e.g. that the NSAs will, as > a group, be able to construct and reserve a suitable path for the request. > _______________________________________________ > nsi-wg mailing list > nsi-wg(a)ogf.org <mailto:nsi-wg@ogf.org> > http://www.ogf.org/mailman/listinfo/nsi-wg

7 18

tomorrow's call
by Guy Roberts 10 Feb '10

10 Feb '10

The following is call information for tomorrow -- same as always. 9 ET. 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 Agenda - 1. Status update protocol document deliverable 2. Review Jerry's NSI topology submission: http://forge.gridforum.org/sf/go/doc15871?nav=1 3. DICE-IDC protocol submission as OGF informational document. 4. Sessions for OGF28 5. OGF28 registration reminder - advance registration closes 15 Feb 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

3rd Party connection requests
by Jerry Sobieski 09 Feb '10

09 Feb '10

I wish to pose two questions for discussion regarding Connection Service request handling: 1st: Can we reserve resources backwards? 2nd: How should third party requests be handled? Backward Reservations- This is simply doing a path finding process backwards - from destination to source. This does not (must not) change the direction of the connection that is established in the transport plane, it simply constructs the viable path tree from the destination towards the source. THis should still develop a valid connection path, but it may not be the same path selected by a forward pathfinding process... My recommendation: It should not matter whether a path is discovered from Source to Destination or vice versa. And it is up to the local domain as to decide how to decompose a connection request and perform the path finding/resource allocation within its domain. Any intermediate hops specified in a PO must be honored. 3rd Party Requests A "3rd Party Request" is a request receive by a local NSA that specifies end-points that are not located within the local NSA's domain. I.e. there is no basis for assuming that the [shortest/best] connection path will transit the local domain. So the question is: should the local NSA simply forward the request towards the Source (or Destination) ? or can the local NSA insert a local intermediate STP (a loose hop) in the path object, thus forcing the connection to transit the local domain? Since this has to do with how we handle a request - not particularly pathfinding per se, I think we need to think about this to decide if we need to make some firm declaration about this. One potentially questionable result of this issue is that an intermediate NSA who handles a request could insert a local hop into the Path Object, thus forcng the connection thru their domain. If this sounds ominous, it is. So we should consider what the desired action should be and how to be certain it is followed. Thoughts? Jerry

2 1

Path Object summary
by Jerry Sobieski 02 Feb '10

02 Feb '10

Here is my summary of our thoughts regarding a Path Object. 1. A Path Object consists of an ordered list of "Path Elements" that describe a tour through a topology. These elements are [initially] either a) an STP, or b) a "subpath" in the form of named Path Object. A Path Object does not carry any connection related information, just the stepping stones through the topology. 2. A Path Object is unidirectional. 2.5 At a minimum, a Path Object must contain two STPs: a beginning STP and a terminating STP. (Note for discussion: Can these be the same STP? i.e. can a path have zero hops? Is this even possible in a directed graph topology?) 3. A "Connection" object contains the set of constraints associated with a connection, including the path object, scheduled start and duration, authorization, and other technical specs (e.g. capacity, framing, BER, etc.) We asserted that a Connection is a uni-directional construct as well. 4. A "Service Instance" contains one or more Connections. This would allow for a bidirectional circuit to be established by bonding a connection with its reverse into a single service instance. This would also allow for constructs such as protection circuits. (Note: we need to discuss this further as I think a Svc Instance construct and a Connection construct may not be so different.) 5. We discussed breifly the necessity (or not) for a strict vs loose indicator bit associated with each element. This bit would indicate if this element is/must be strictly adjacent to the prior element in the topology. (I think this needs further discussion - does Issues for further discussion: What form does the name of a "named Object" take? I.e. How do we name STPs, or how do we name Connection Objects or Path Objects Instance Objects??? Any thing I missed? Jerry

1 0