- Nsi-wg - lists.ogf.org

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

Path Object information/function
by Jerry Sobieski 29 Jan '10

29 Jan '10

Here are some thoughts on what a "Path Object" (PO) should contain and/or be able to do...please read thru and think about this and let me know your thoughts. Jerry - A Path Object is an ordered list of service transit points (STPs) through which a connection passes. - A Path Object must have at least two STPs: The ingress STP, and the egress STP. - A Path Object should allow a path to be described using "sub-paths" (i.e. other Path Objects) or pointers/tags that reference other Path Objects. - A Path Object is direction sensitive. I.e. The path is always interpreted as beginning at the first STP (the head of the list), and proceeding towards the last STP (the tail) in the list. There is no implication that a path object is reversable (or bidirectional). - A "fully specified" path identifies the complete set of STPs - in order - that a connection transits from ingress to egress. - A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path - A partially specified path may contain STPs that are, individually, only partially specified. For example, a path may contain a STP indicating a specific switching element to be transitted, without specifying the specific port or VLAN id to be used. This could also be generalized to indicate something as general as an particular network to be transitted. Alternatively, the path element may specify a "label set", i.e. a set of labels or STPs that can are acceptable within the context of that STP. THis may be useful for conveying valid VLAN IDs or Wavelengths that may be available to path selection functions downstream or for end-to-end tagging information. Path objects can be used in several ways: First, would be to specify constraints on a *proposed* path - i.e. must transit this switch, but port selection has full freedom. Or must transit this previously defned path. The path objects need wild card masks to indicate these constraints. Second use is to define a connect "as built", i.e. after the cnnection is full specified and/or in service, a fully specified detailed Path Object would capture the entire detailed path - end-to-end but perhaps not fully exposed. BNF format: <Path_Object> := <Path_Object_Header> <Path_List> <Path_List> := <STP> ( <Path_Object> | <STP> ) + | <Path_Object>+ Path elements can be STPs or Path Objects. STPs represent topology locations, these will likely be something such as: <domain_identifier><pointID> or <dom><node><port><label><...>. These will likely be alphanumeric strings, possibly parsable, or they may be binary structures... Likewise with Path Objects - these will likely be something like <domain><objectID>. The key concept however is that the Path Object contains two types of elements: service termination points that refer to points in the topology, and a path object tag that refer to another strucutre outside the current path object. So each elemnt of the path list must have a type code to say what type of path element it is, and then a string to uniquely dentify that object within a local context, and a length that says how long the object tag is.

5 16

Re: [Nsi-wg] Path Object information/function
by Jeroen van der Ham 27 Jan '10

27 Jan '10

Hi, I've had an exchange of emails with Jerry off the list, to see if I understood him correctly. I'm replying back to the list, because we had some interesting ideas. On 25/01/2010 18:46, Jerry Sobieski wrote: > Jeroen van der Ham wrote: >> Let me try to summarise what you just said, so that I understand. If >> that's the case, perhaps we can send this to the list, and I can >> respond to it ;) >> >> - You assume that hops in Path objects will always be checked before >> they are actually implemented. > I had assumed that would be the case. However, the "check" is a function > of how the agent uses the PO. The provisioning process will need to > (should) always do some level of check as it configures the switches, or > it must trust that the PO is accurate (is it trustworthy?) Crossreferencing to some comments John brought up: I think there should be a Connection object, of which the Path object is a part. The Connection object should be checked, and once that's done, the Path object should be implemented. At some point there has to be a translation between what is in the Path object and what actually will be implemented in the data plane. That is where the check should be, and not in each of the hops. >> - You propose to implement the strict hop by saying that everything is >> a loose hop unless specified otherwise. > Yes. We should consider this more - I only came up with it this > morning:-) Would this be sufficient? There is a possibility that we > could also define STPs that represent a group or domain. Specifying such > a hop would say "transit any more specific STP in this region/domain". > You could define a [group] STP that represents a whole transit network > and then declare that STP (hop) to be "required" (must transit) in the PO. I thjink there should be a flag for each hope defining whether it's strict or loose. I would not use a "default unless specified otherwise" in this case. > "adjacent" means: For a node A and a node B, there exists a single link > that directly connects A and B with no intervening nodes. I think this is a pretty sensible definition, perhaps only with the addition "... no intervening nodes which must be provisioned/configured." > In my world (:-), I contend we build [user] "connections" over a > topology of "nodes" and "links". At any layer, the topology is the lower > layer infrastructure over which we construct the high layer connection. > I differentiate between a "connection" and a "link". The latter being an > object in the topology database, the former being an object that is > constructed over the topology for a higher layer entity. A "connection" > is just a user conduit until that connection is inserted into the > topology database and becomes a link that Path Finding can use to > allocate other user connections. Yes. > There are two basic operations to build a connection: concatenation, and > encapsulation. /Concatenation /is the process of linking two connections > such that the egress PDU of one is fed directly into the ingress PDU of > another at some switching point. Concatenation can really only be done > when the egress and ingress framing are identical. If not identical, > then an "adaptation" function must be mapped into the connection to > convert the egress framing/PDU to the ingress framing/PDU. (Think of > what GFP does). /Encapsulation /is the process of moving the entire > transport frame (PDU *and* framing information) transparently from the > ingress point of a connection to the egress point. Encapsulation is > often called tunneling. I think that we use the term Adaptation for Encapsulation, but otherwise I agree. Jeroen.

1 0

Call info for tomorrow
by John Vollbrecht 26 Jan '10

26 Jan '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 - Discuss path description and converation on list I will try to get a description of NSI view of transport plane by tomorrow, but I may not make it. It is close but not I am not quite ready to share it. John

1 0

Call tomorrow
by John Vollbrecht 21 Jan '10

21 Jan '10

I attach a document that describes NSI in WS terms. I would like to discuss it tomorrow on the call. I am thinking perhaps we should stick to WS terminology and concepts for the first draft at least in order to make progress. I have taken the terminology from reading WS doc. It turns out to be slightly different than what we were using before, mostly in emphasis. In particular, the distinction between agent and actor is a little fuzzier, with the interface being between requestor agent that wants the service for its owner and provider agent that supplies the service. Actors come in only when discussing complex interactions between entities in particular infrastructure implementations. I think this is helpful also in thinking about service plane and what it is, though this doc does not deal with that. John

2 1

call information for tomorrow
by John Vollbrecht 19 Jan '10

19 Jan '10

The following is call information for tomorrow -- same as always. 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 actors agents, service plane and transport plane. Discuss OGF plans See doc that I sent out earlier for first part of discussion I am not people will have time to digest the doc, so we may go thru it quickly to prepare for discussion next week. John

1 0

Next call Jan 20
by John Vollbrecht 12 Jan '10

12 Jan '10

We will not have a call tomorrow - I am working on some description of Actors, Agents and client/server. I will send some description in the next day or so and then would be happy to get input and feedback. I am also relooking at GMPLS terminology for transport plane concepts to try to be as consistent with it as reasonable. We will have a call next week at 9 ET. I will send out call info ahead of time. John

1 0

vote on naming for Agents types
by Guy Roberts 22 Dec '09

22 Dec '09

Hi All, On the latest NSI conference call we have been pondering a suitable name for the two instances of an Agent that resides on either end of a Network Service Interface. Up to now the term 'Requestor Agent' has been used to identify the agent that originates the connection request, and 'Provider Agent' for the agent that processes (reserves, provisions etc) the request. Objections have been raised to this terminology based on the desire to break away from the old use of 'provider' as used in ISP. We would like to hold a ballot in the NSI group for preferred name. The following names have been suggested, please respond with an email to me with the number of your preferred choice. 1. Requestor Agent, Provider Agent 2. Requestor Agent, Service Agent 3. Requestor Agent, Granter Agent 4. Requestor Agent, Implementer Agent Regards, 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 ------------------------------------------------------------------------------------------------------------------

9 8