[Nsi-wg] uml proposal for STPs path object specifications...
Jerry Sobieski
jerry at nordu.net
Thu Sep 6 17:56:33 EDT 2012
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 at uva.nl]
> Sent: 06 September 2012 10:47
> To: Guy Roberts
> Cc: nsi-wg at 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 at 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 at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120906/dad6d76b/attachment.html>
More information about the nsi-wg
mailing list