Sorry this is a bit long - but I propose we do two things: 1) The
ERO path be defined as a single [forward] path consisting of one STP
reference per hop. 2) each network indicates in their topology
description the duplex STP pairings to be used for reverse path
construction for bi-directional services.
Detail/discussion below.
please read and comment.
Thanks!
Jerry
On 9/7/12 7:37 AM, Jeroen van der Ham
wrote:
Hi,
On 7 Sep 2012, at 12:16, Jerry Sobieski <jerry@nordu.net> wrote:
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.
No, the question should be the reverse, why would you ever want to have a reservation request with two different topology IDs in it?
Yes I Agree. So what we have in the proposed triple form - _even with a single topology id _- is the ability to specify forward and reverse transit points that are widely geographicaly separated. There is no significant constraints imposed by a single topology. So while I agree with you that we do not want any particular hop to have widely geographically diverse forward and reverse paths, _/a single topology ID does not accomplish this./_
I'm not trying impose geographical restrictions, I'm trying to add logical restrictions. STPs with the same Topology ID should go to the same NSA. This makes the whole behavior a lot more predictable.
Yup - by definition: STPs with the same topology ID belong to the
same NSA. This is always the case in NSI. But in specifying a
path, we do not always want the forward and reverse components to
transit the same path elements. We could, for instance, request
that the forward path transit one network, but the reverse path
transit a different network. This is perfectly legal and useful.
But it can't be done if you cannot specify a different topology Id
for the forward and reverse STPs. I.e. there is no inherent
reason the forward and reverse hops must transit a single
particular network or even traverse the same number of explicit
hops.
Thus, the proposed triple (topology, source port, sink port )
constrains the source and sink to be in the same network - This does
not solve any problem, thus is places arbitrary and unnecessary
restrictions on path specification. We don't put unnecessary or
arbitrary constraints into the standard.
The more important question is: Do we actually need to
specify a reverse path at all? I suggest not.
I recommend that we specify the forward path only in the ERO. Each
hop would be: ( topology Id, port Id, tv1, tv2,... ). i.e. a STP
Type/value reference. If a service request is asking for a
uni-directional connection, then there is no need for reverse path
ERO elements at all. If a service request is asking for a
"bi-directional" circuit, then we let the Provider Agent construct
the reverse path according to duplex pairing attributes defined in
their topology. Thus, again, there is no need for a reverse ERO
element. (Indeed, we can't actually identify the forward transit
STP until the forward path segment is confirmed and we can get the
"as-built" STP back.)
If a "bi-directional connection request" has to do something special
to build a bidirectional connection, i.e. not just build two
uni-directional connections, then we need to define
explicitly what a "reverse" path is meant to be.
Otherwise, it is just another unidirectional connection. And if so,
there is no need to have a special primitive that does two
uni-directional connections in one request - we just perform two
requests and simplify the protocol.
If, however, a user wants a connection that has both a forward
channel and a back channel, and the back channel transits ports that
are "tightly coupled" in some specific manner with the transit ports
in the forward path, then we really need a "bi-directional
connection service" - it is not just two uni-directional
connections. For example: If you want the reverse path to
transit a particular receive port because it is associated with a
particular transmit port on the forward path, then you need to
specify what that "association" is - specifically. Its not
implicit or self evident in anything we have adopted to date.
The WG has not been able to provide a rigorous and concise
definition of what a "bi-directional" Connection instance means.
We all know it when we see it :-)...but we have nothing specific
that can be adopted as either part of the NSI CS standard, nor even
as part of a best practice or service definition. Thus, we are all
over the place on how the ERO should look. From experience, we
know such connections are generally made up of two adjacent - but
separate - uni-directional data flows going in opposite directions -
but this is not a formal specification and often not actually the
case in the WAN or even the metro space. We have a notion of a
"forward" and "reverse" data path - but what *SPECIFIC*
characteristics do they exhibit relative to one another? What do
we need defined within the topology database to enable a path finder
to identify the topological objects that constitute a "reverse path"
relative to some "forward path" ???
Here is my off-the-cuff definition of a "bi-directional" connection
instance:
-- It has a "forward path" defined by an ordered set of 2 or more
STPs as specified in the path object (or ERO). The data flows along
this forward path from the first STP ( ERO[0] ) to the last STP (
ERO[n] ).
-- It has a "reverse path" defined by a set of STPs identified as
"duplex" with the STPs in the forward path.
-- The reverse path flows data in the opposite direction of the
forward path (assuming the reverse path STPs are ordered in the same
order as their corresponding forward path STPs.)
-- Duplex STPs are indicated in the topology. (This relation may
be any relation that provides the same semantic meaning.)
-- The forward and reverse paths have equal capacity (This is not
strictly necessary, but simplifies things.)
-- The forward and reverse paths are linked. I.e. there is a
formal service-specific relationship between the forward and reverse
connections. together, they are/can-be treated as a single service
instance.
The advantage of these "bi-directional" characteristics is that the
forward and reverse paths could be constructed by a RA
independently. I.e. an RA could reserve a unidirectional
connection, query its path, find the duplex STPs in the topology,
reverse their order, and request a 2nd uni-directional connection.
These two connections taken together would be technically equivalent
to a single bidirectional connection - except that the two
uni-directional connections would be seen as two separate service
instances rather than one.
If we adopt this definition for v2.0, then our ERO elements can be
single STPs defining the forward path - very simple. A network
service provider will define their network topology to be
uni-directional STPs (NML Port objects, and will indicate the Port's
duplex twin in the database.
Note: perhaps the NML folks can concur with this, or pose an
alternative relation defining the duplex pairs?) For example:
Aruba a nml:Topology ;
nml:version
"2011112901"
;
nml:hasOutboundPort
Aruba:ams-ge1out ;
nml:hasInboundPort
Aruba:ams-ge1in .
Aruba:ams-ge1out a nml:PortGroup ;
My proposal is to have the local network provide the appropriate
forward/reverse pair mapping in their topology description.
Bi-directional connection requests would then use that mapping for
path construction. How we specify the mapping syntactically in the
NML topology can be flexible...but it must be simple and consistent.