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. 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). Regards, Freek
