I do not believe it is appropriate or useful to distribute the "topology ID" across both the source and sink localids.   This forces both source and sink to be part of the same network topology...why?   What value is this?  This does not force any relation to exist between the source and sink ports besides being part of the same topology file - so what is the use case or value of it?   We should specify each STP 2-tuple independently.

For example: a common topologyid does NOT force the source and sink to be part of a conventional duplex port pair:
( topology="Bonaire", port="B1in"   )  := <switch="NYC", port="ge-0-3in", vlan="1780">
( topology="Bonaire", port="B1out" )  := <switch="CPH", port="ge-0-3out", vlan="27">

Even though a SourceSTP contains ( topology="Bonaire", source="B1out", sink="B1in") there is no relationship otherwise between these two STPs.  In this example, the source and sink are on different continents!   Thus the common topology id is an arbitrary and unnecessary requirement imposed upon the source and sink.  The protocol does not need this form.

Regarding the Source and Sink STPs...

If we want the source and sink to have some specific relationship, e.g be part of a duplex pair, then we need to specify those characteristic features in the topology database -e.g. a "duplex" attribute on one Port that identifies another Port as the duplex pair and vice versa.  This is something that needs to be advertiseable, not fudged somehow.     Having specified in the topology that two uni-directional ports are a duplex pair, we can request a bi-directional reservation that creates "bi-directional" connections from the "duplex" pairings. 

If we want to specify the forward and reverse paths explicitly, we should not require them to have the same number of transit points or otherwise constrain the path they take or their characteristics (e.g. capacity or administrative topology).  Thus, if we want to specify forward and reverse paths explicitly, we simply issue two separate uni-directional connection requests.    If we wish to force the forward and reverse paths to relate to each other in some broadly useful specific way (e.g. a duplex reverse path of equal capacity), then we should not give the requester the ability to specify both paths - it is unnecessary and it may not be correct...i.e. the path finder should ignore the user's specified reverse path and just build the reverse path that befits the defined relation to the users specified forward path.   Thus all we need is a single forward path specification.  

I suggest we define a single directed path object.  This object will always serve as the forward path object.      A bi-directional service will use it also to build a reverse path using an explicitly identified topological "duplex" pairing attribute obtained from each element of the forward path. 

SO I propose the following:

proposal #1:  The Path object describes a single "forward" path.  Each transit STP acts as a sink for the prior segment and a source for the subsequent segment.  The STP elements of the path object may be uni-directional or bi-directional.  Each transit element of the path object consists of a STP Reference - <topology><port><tv1>..<tvn>

For uni-directional connections each element of the ERO will be interpretted as follows:
   a) if the ERO STP is a unidirectional Port, the pathfinder uses that uni port as the start of the next forward path segment and as the terminus of the preceding forward path segment. 
    b) if the ERO STP is a bidirectional Port, the pathfinder uses the "sourcePort" associated with the STP to identify a uni-directional Port to be used as the start of the next (towards the Z end) forward path segment.  This same uni-directed Port will be used as the terminus of the previous (towards the A end) forward path segment.

For bi-directional connections, each element of the ERO will be interpretted as follows:
    a) if the ERO STP is a bidirectional Port, the pathfinder uses the sourcePort attribute of the STP to identify a uni port to be used as the start of the next (towards the Z end) forward path segment and as the terminus of the previous (towards the A end) forward segment.  The pathfinder will use the sinkPort associated with the bidirectional STP as the start of the upstream (towards the A end) reverse path segment, and as the terminus of the downstream (from the Z end) reverse path segment.
    b) if the ERO STP is a unidirectional Port, the pathfinder uses that uni port as the start of the next forward path segment and as the terminus of the preceding forward path segment.  The PF looks for a "duplex" attribute of the ERO STP to point to a paired uni port that will act as the transit point for the two duplex reverse segments.  If an ERO STP does not specify a duplex port, an error is generated.

proposal #2:  I suggest we do away with the SourceSTP and DestSTP in the wsdl Reservation Request message.  We instead use the ERO object to contain all transit points: ERO(0) will always be the SourceSTP, and ERO(n) is the DestSTP.   This will allow the code to treat all segments the same - not have to treat the first and last segments specially in order to handle the SourceSTP and DestSTP objects.

THoughts?

Jerry

On 9/6/12 1:09 PM, Guy Roberts wrote:
Jeroen,

Your assumptions about my UML diagram are correct, but as I did not like my proposal very much, so I have sent 3 variations to the list for discussion.  

In response to your question about the 'ERO problem', I think even with bidirectional STPs we can get an unambiguous result from path computation if we use SDPs in ERO as follows:  path is an ordered list of: AendSTP ((STPa, STPb), (STPc, STPd) ... ) ZendSTP  where (STPa, STPb) is an SDP.    Consequently for bidirectional connections I don't really see a case for uni-directional STPs, particularly since nml has a bidirectionalPort object it seems like a waste to re-produce this in NSI.  So I propose that we use unidirectional STPs for unidirectional connections and bidirectional STPs for bidirectional connections.

Regarding the LabelId = <type><value> tuple, I am wondering how we identify which types are allowed.  I would like to allow the option of for example <type> = nmleth:vlans so we allow the user to add the nml namespace here.. .any thoughts?

Guy

-----Original Message-----
From: Jeroen van der Ham [mailto:vdham@uva.nl] 
Sent: 06 September 2012 10:47
To: Guy Roberts
Cc: nsi-wg@ogf.org
Subject: Re: [Nsi-wg] uml proposal for STPs

Hi,

Let me try to see if I understand this correctly:
- The StpType identifiers refer to unidirectional ports in the topology.
- The PathType can be used to request a bidirectional reservation and then you need to use four different StpTypes, with pairs describing the two unidirectional connections

I think there is problem with the current ERO definition, because it doesn't define which part of the unidirectional connection it refers to. 

A solution would be to make them a tuple, with the first element defining an ERO for the path from AendSrcSTP to ZendSinkSTP, and the second element an ERO for ZendSrcSTP and ZendSinkSTP.
This is kind of messy, because if you use multiple EROs for the multiple connections you end up with (A,B'), (B,A') (with A,B the EROs for one direction and A',B' for the other).
Perhaps we should use two separate ERO lists?

Guy mentioned during the call that you may want to add a restriction that the path for both direction traverse the same cables, or you may want to explicitly request diverse paths. I think this should be possible to request without specifying EROs. Should we add path-attributes to the request to make that possible?

Jeroen.



On 5 Sep 2012, at 17:18, Guy Roberts <Guy.Roberts@dante.net> wrote:


Here is a possible unidirectional STP shown in UML format:
 
<image001.png>
 
_____________________________________________________________________
Guy Roberts PhD
Senior Transport Network Architect
DANTE
Cambridge, UK
+44 1223 371316
 
DANTE is the project co-ordinator and operator of GÉANT, the 
high-speed pan-European research and education network that is 
transforming the way researchers collaborate.
Learn more at: www.geant.net
Like us on: www.facebook.com/GEANTnetwork Follow us at: 
www.twitter.com/GEANTnews
 
DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN.
_____________________________________________________________________
 
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg



_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg