[Nsi-wg] Bidirectional Link (was Re: [AutoGole] Ports relations)

Fri Sep 27 09:53:07 EDT 2013

SOme other considerations on unidirectional vs bidirectional Connections 
and Topology:

1- Unidirectional topology is (IMO) just the atomic construct for an 
interface.   And as JvdH says, we should be able to construct more 
complex or capability specific topo components from these atomic elements.

2. Atomic Bidirectional links are problematic.   For path finders, these 
circuit paths are almost never actually occupying the same physical 
resources- these are typically paired up elements that have been 
packaged together for human convenience - not for automated agents.  For 
example: switches employ [only] unidirectional fabrics internally.   The 
fabric has a set of input ports and a separate following set of output 
ports.  The device switches circuits or frames or packets from any input 
port to a designated output port according to a Look Up Table (LUT).   
The design engineers simply relate an arbitrary input port on the fabric 
with an output port on the fabric, and then connect those two 
unidirectional ports to a duplex connectors on the faceplate and they 
call it a single interface with transmit and receive sides.   Even 
ethernet does this inside a switch, as do routers.
And other technologies - such as optical DWDM platforms - don't even 
hide this fact...the engineers do everything manually and 
unidirectionally in the transmit receive optics.    So if we really want 
to be able to avoid lots of technology specific hacks in the topology 
descriptions and path finders, we should adopt the unidirectional 
interface as an atomic element, and then make sure we have appropriate 
and generalized means of composing other topological service constructs 
from those atomics.

3. Bidirectional Connections with guarantees capacity/performance will 
pose scaling problems in the point to multipoint model.    In a mp 
connection model, the output capacity at any destination endpoint must 
be the sum of all input capacities of the other endpoints. This is fine 
if you have a single source (i.e. unidirectional) p2mp connection.   But 
in bidirectional mp connections you have multiple sources.   It becomes 
a mp2mp connection (!!)  (e.g. if 5 endpoints all want to be part of a 
bidirectional connection, then you have actually created a broadcast 
domain, a mp2mp tree - not a single source p2mp multicast tree.   And if 
each of those 5 endpoints want to transmit at 1 Gbps, then it is 
possible that all endpoints will get 5 Gbps of traffic delivered to 
them.)  If you do not maintain this summation rule, then you cannot 
guaranty the performance of the bidirectional Connection under all input 
conditions - and so it becomes a best effort class of service. (Its 
starting to sound more and more like conventional ethernet, eh?)   If 
you can only guarranty best effort for the mp2mp broadcast domain, then 
there is no real value to requesting a capacity specification in the 
first place.   Further, if you add an endpoint to a bidir mp2mp 
connection, you then need to modify all of the existing endpoints and 
their output segments if you wish to maintain performance guarantees, 
which becomes totally impractical as the number of endpoints increases 
or gets large (N^2 problem)

4.  Bidirectional Connections would be better served if we treated them 
as two unidirectional connections bound together by some specific 
service constraints constraints that path finders can chew on.  The 
notion that such circuits transit the "same ports" in both directions is 
flawed and inaccurate in almost all cases.     For instance, what 
specifically is our definition of a "bidirectional" NSI Connection?  It 
does not really occupy the same fibers or ports end to end, and it is 
often separated by a meter or [much] more distance as it transits 
different transport kit in the pops.   So what are the specific 
constraints we feed the path finders that differentiate a "valid" 
bidirectional Connection layout from an "invalid" Connection path 
layout?   And if we can define a set of standard constraints that govern 
the relation between forward and backward paths, do we have those 
attributes defined in the topology such that path finders can see them 
and use them?

I think bidirectional "Connections" (dba mp2mp "Broadcast Domains") are 
useful - even without capacity guarantees.  These are very practical and 
useful service constructs (IMO) and it would be good (and easy!) for NSI 
to support the reservation and provisioning of these.    We can extend 
the NSI-CS DestSTP semantics to include multiple end points.  These 
would build a single source tree for unidirectional Connections, with or 
without capacity guarantees. And the same Reservation() syntax and 
semantics can be used to build bidirectional mp2mp Connections - again 
with capacity (slow and likely to exhaust resources) or without capacity 
(the b.e. broadcast domain).    The protocol can be extended easily 
(IMO) to support both modes and maintain backward compatbility to 
current v2 implementation.

So, the question comes down to this:  Do we really need to differentiate 
Unidirectional and Bidirectional connection constructs?  Can we simplify 
to just unidirectional, then build two independent connections going 
each way?  (Its what happens internally anyway...)   What do we get from 
a "bidirectional Connection" that you do not get from two "unidirected 
Connections"? Its not sufficient to say we want bidir connections 
because thats what Ethernet does...a) Ethernet does not do this (see 
above), and b) this makes NSI technology specific rather than "service" 
oriented.  So what is the service requirement that dictates 
Bidirectional connections be differentiated from Unidirectional 
connections? (And how do we define that for PFs?) Would it not simplify 
NSI protocol and syntax if we could have only unidirectional connections 
and we compose more sophisticated services on top of those atomics ?  
For instance: "Given circuit A1:=A1>Z1, I would like a circuit A2:= 
Z2>A2 that is less than "R" radius from A1, AND the circuit A2 has an 
average latency equal to +/-5% average latency of A1.     Or just the 
opposite: I want a circuit A2:= A2>Z2 that is greater than "R" radius 
from this other circuit A1:=A1>Z1.  (The former example would construct 
a reverse path circuit A2 that is "close" to A1, the latter would 
construct a diverse circuit A2 that is "far away" from A1.)   My point 
is that these types of constraint based specifications allow a much 
richer set of functionality for the user, or for a service provider who 
wants to compose higher level service constructs  from the NSI base 
protocols.   These can scale globally so much easier because they do not 
rely on specific hardware features, traditional human factors, or 
antiquated service concepts.

...just some thoughts for discussion next week...:-)
J

On 9/27/13 6:21 AM, Henrik Thostrup Jensen wrote:
> On Wed, 25 Sep 2013, Jeroen van der Ham wrote:
>
>>> Hmm... that seems to be an unneeded artificial restriction.  I 
>>> should be able to build up my unidirectional topologies into other 
>>> network constructs based on my needs.  Saying you can only have 
>>> unidirectional topology is like saying you can paint as much art as 
>>> you want but only using black.
>
> Agreed 100%.
>
> While most things are unidirectional at the bottom (there are 
> exceptions like true ethers), some equipment can only be controlled 
> from a bidirectional point of view (say, most switches). They are by 
> all accounts bidirectional as that is what can be controlled.
>
>> As soon as we would add this construct everyone would just use NML to 
>> construct bidirectional topologies, and leaving out the 
>> unidirectional part. Then if the need ever arises to do asymmetrical, 
>> unidirectional, or disjoint return paths, then you can't because 
>> everyone is using bidirectional constructs.
>
> If everyone could just buy ready-made cars, no-one would assemble 
> their own cars or build weird 7-cylinder combustion engines, and very 
> few people would even know how a car worked.
>
>
>     Best regards, Henrik
>
>  Henrik Thostrup Jensen <htj at nordu.net>
>  Software Developer, NORDUnet
>
>
> _______________________________________________
> 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/20130927/aefbc546/attachment-0001.html>