Roman Łapacz wrote:
btw. I'm still thinking that we don't need nml:bidirectionalport in NML
:) We could use port with "bidirectional" relation.
The distinction between <nml:port type="bidirectional"> and
<nml:bidirectionalport> is only syntactic, so I presume you are
referring to not only change the syntax, but also the semantic. Meaning
that all the rules and relations that apply to nml:ports can be applied
to nml:bidirectional ports as well.
Actually, the problem is not so much with bidirectional ports, but with
bidirectional links.
I personally hope you are right. We identified some issues related to
identifying the direction (ingress or egress) for physical interfaces
that did both de-adaptation AND adaptation for ingress traffic (this is
uncommon, I only know of one practical example). For that reason, we
decided at the time to do everything unidirectional (so that identifying
directionality is trivial) and see if we can later come up with either
syntactic of semantic simplifications for bidirectional links.
I just took another look at the problem we had back than, and I start to
wonder if the problem is solved because we now use explicit links, and
we have some basic understanding how to handle multicast and broadcast
(as links with multiple end-points).
Let me describe the problem we had a few years ago. If you have time to
propose a solution, and it works with the following three examples,
that's a good indication for me that we can make it work, and I would
back up your proposal.
If you make a proposal, make sure to do it in the UML schema, since that
is leading.
1. A link between one network that described all links unidirectional
and another network that describes all links bidirectional.
2. A link with more than two end-points, such as a Ethernet LAN or VLAN
(this one is probably easy).
3. How to describe a physical interfaces that did both de-adaptation AND
adaptation for ingress traffic. The only example I know is an Ethernet
interface in a SONET switch. Here, the Ethernet traffic is first
de-adapted from the fiber layer (e.g. using 1000base-LR decoding), and
than, //at the same interface// adapted to the VC-4 layer (e.g. using
GFP-F encoding or the older LEX encoding). The questions are:
a) how to make the distinction between the link on the ingress and
egress side of an such an interface, and
b) the distinction between the adaptation stack on the ingress and
egress side of such an interface.
This is where abstraction comes in. Those de-adaptations and
adaptations are all functional network elements. They can be
engineered topologically just like other devices and preserve your
notions of port orientation etc. Granted, some are virtual elements
but the point remains - they can easily be represented
topologically. Right?
Use case 3 is rather complex, so I made a picture, see attached (it's
still complex, so I'm happy to explain in more detail if required). As
you can see, on the Ethernet layer, there is a direct link between port
C1 and D2 (thus NOT between C2 and D1 as is the case on the fiber
layer). Data coming in at C1 from either A1 or B1 is really different
from data coming in from D2. For use case 3a, how do the links and ports
look like when described on the Ethernet layer (without describing the
underlying fiber infrastructure). Would be possible to distinction to
describe the connections A1, B1 and C2? For use case 3b, how to describe
the links, ports and adaptation if only the fiber layer and adaptations
are described, but the Ethernet layer is not explicitly defined (but
should be inferred from the underlying infrastructure on the lower layer).
Is your diagram then a bidirectional diagram? It seems to me this
should really be a diagram of unidirectional links to avoid
asymetric and diverse connectivity issues.