Hi all, Yet another single layer use case (sorry to procrastinate on the multi layer use case, I want to make sure that single layer is tackled before diving in the hard stuff). Let's start with a single bidirectional link (= 2 unidirectional links) between two nodes: ----------> Node A Node B <---------- Each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in The relations here are: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in a_out source Link A-B b_in sink Link A-B b_out source Link B-A a_in sink Link B-A So far, so good. Since we want to model Ethernet, I think we should be able to model broadcast networks. Imagine an old-fashioned LAN: Node A Node B | | --+-----+-------------+---+-- | | Node C Node D Again, each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in Node C hasPort c_out and c_in Node D hasPort d_out and d_in Of course each *_out is the egress port, with each *_in is the ingress port. Now how do I describe this LAN? (A) As a single link, or (B) as multiple links? Let's first try (A) as a single link: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source MyFirstLAN b_out source MyFirstLAN c_out source MyFirstLAN d_out source MyFirstLAN a_in sink MyFirstLAN b_in sink MyFirstLAN c_in sink MyFirstLAN d_in sink MyFirstLAN But is this correct? Semantically, this would imply that if a_out is sending data, it is also received by a_in. Let's also try to describe this (B) as multiple links: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source LAN_A b_in sink LAN_A c_in sink LAN_A d_in sink LAN_A b_out source LAN_B a_in sink LAN_B c_in sink LAN_B d_in sink LAN_B c_out source LAN_C a_in sink LAN_C b_in sink LAN_C d_in sink LAN_C d_out source LAN_D a_in sink LAN_D b_in sink LAN_D c_in sink LAN_D MyFirstLAN elements {LAN_A, LAN_B, LAN_C, LAN_D} This later description is closer to the concept of Unidirectional Link as is currently in the schema. The schema further allows grouping to a (Bidirectional) Link. That's what I added on the last line. What are your preferences? I see problems with both concepts. Regards, Freek
Freek, I like option B. It is more complicated, but looks more accurate to me. I propose to rename LAN_A as forwarding_rule_A and so on. MyFirstLAN elements { forwarding_rule_A, forwarding_rule_B, forwarding_rule_C, forwarding_rule_C } The other option would be to add a rule to your option A which states that forwarding to yourself is not allowed. Things could get ugly if you try and model spanning tree forwarding rules! ... but fortunately I think (hope) this is not necessary. I realize option B is more complicated than option A, but for NSI I don't see a lot of demand for LANs, so better to be accurate if somewhat more cumbersome. Guy -----Original Message----- From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] Sent: 07 August 2009 15:16 To: Network Markup Language Working Group Subject: [Nml-wg] Use case: broadcast network (single layer) Hi all, Yet another single layer use case (sorry to procrastinate on the multi layer use case, I want to make sure that single layer is tackled before diving in the hard stuff). Let's start with a single bidirectional link (= 2 unidirectional links) between two nodes: ----------> Node A Node B <---------- Each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in The relations here are: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in a_out source Link A-B b_in sink Link A-B b_out source Link B-A a_in sink Link B-A So far, so good. Since we want to model Ethernet, I think we should be able to model broadcast networks. Imagine an old-fashioned LAN: Node A Node B | | --+-----+-------------+---+-- | | Node C Node D Again, each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in Node C hasPort c_out and c_in Node D hasPort d_out and d_in Of course each *_out is the egress port, with each *_in is the ingress port. Now how do I describe this LAN? (A) As a single link, or (B) as multiple links? Let's first try (A) as a single link: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source MyFirstLAN b_out source MyFirstLAN c_out source MyFirstLAN d_out source MyFirstLAN a_in sink MyFirstLAN b_in sink MyFirstLAN c_in sink MyFirstLAN d_in sink MyFirstLAN But is this correct? Semantically, this would imply that if a_out is sending data, it is also received by a_in. Let's also try to describe this (B) as multiple links: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source LAN_A b_in sink LAN_A c_in sink LAN_A d_in sink LAN_A b_out source LAN_B a_in sink LAN_B c_in sink LAN_B d_in sink LAN_B c_out source LAN_C a_in sink LAN_C b_in sink LAN_C d_in sink LAN_C d_out source LAN_D a_in sink LAN_D b_in sink LAN_D c_in sink LAN_D MyFirstLAN elements {LAN_A, LAN_B, LAN_C, LAN_D} This later description is closer to the concept of Unidirectional Link as is currently in the schema. The schema further allows grouping to a (Bidirectional) Link. That's what I added on the last line. What are your preferences? I see problems with both concepts. Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Freek, This issue is actually described quite well in G.800 by distinguishing between destination forwarding and channel forwarding: "Destination forwarding: Symbols presented at an ingress forwarding port are selectively forwarded to zero or more egress forwarding ports. The forwarding function requires control information to identify the output port(s) to which a communication is destined. This control information is carried by the symbol being forwarded (commonly in the form of a destination address). The resulting network behaviour is traditionally known as "connectionless". Channel forwarding: All symbols on all ingress forwarding ports are forwarded to all egress forwarding ports. No additional control information is required with the symbol. When there is a single ingress forwarding port the forwarding relationship is equivalent to a subnetwork connection in [ITU-T G.805]." -----Original Message----- From: Guy Roberts Sent: 10 August 2009 15:34 To: 'Freek Dijkstra' Subject: RE: [Nml-wg] Use case: broadcast network (single layer) Freek, My point here is that G.800 is trying to come up with a generic object that describes both unidirectional TDM circuits and the packet forwarding world. In this case G.800 uses a single concept of Link for both, perhaps this is ok, but I need to think about this some more to be confident that they can be generalized to be the same thing. I guess the answer is that in a label switched environment they are the same thing (LSPs are static), but not in a connectionless environment because forwarding tables are dynamic? Guy -----Original Message----- From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] Sent: 10 August 2009 15:22 To: Network Markup Language Working Group Subject: Re: [Nml-wg] Use case: broadcast network (single layer) Guy Roberts wrote:
I propose to rename LAN_A as forwarding_rule_A and so on.
LAN_A in my example was a Link. Are you saying that all Links are forwarding relations? Though we don't have a concept of "forwarding relation", I'm intrigued here. Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hi, if we want to have granular description I prefer second approach. The only concern I would have is that it needs more elements to use and thus is more complicated (but I think it's not a problem as the information based on the schema will be shared and parsed automatically by applications). regards, Roman Freek Dijkstra wrote:
Hi all,
Yet another single layer use case (sorry to procrastinate on the multi layer use case, I want to make sure that single layer is tackled before diving in the hard stuff).
Let's start with a single bidirectional link (= 2 unidirectional links) between two nodes:
----------> Node A Node B <----------
Each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in
The relations here are: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in a_out source Link A-B b_in sink Link A-B b_out source Link B-A a_in sink Link B-A
So far, so good.
Since we want to model Ethernet, I think we should be able to model broadcast networks. Imagine an old-fashioned LAN:
Node A Node B | | --+-----+-------------+---+-- | | Node C Node D
Again, each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in Node C hasPort c_out and c_in Node D hasPort d_out and d_in
Of course each *_out is the egress port, with each *_in is the ingress port.
Now how do I describe this LAN? (A) As a single link, or (B) as multiple links?
Let's first try (A) as a single link:
Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source MyFirstLAN b_out source MyFirstLAN c_out source MyFirstLAN d_out source MyFirstLAN a_in sink MyFirstLAN b_in sink MyFirstLAN c_in sink MyFirstLAN d_in sink MyFirstLAN
But is this correct? Semantically, this would imply that if a_out is sending data, it is also received by a_in.
Let's also try to describe this (B) as multiple links:
Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source LAN_A b_in sink LAN_A c_in sink LAN_A d_in sink LAN_A b_out source LAN_B a_in sink LAN_B c_in sink LAN_B d_in sink LAN_B c_out source LAN_C a_in sink LAN_C b_in sink LAN_C d_in sink LAN_C d_out source LAN_D a_in sink LAN_D b_in sink LAN_D c_in sink LAN_D MyFirstLAN elements {LAN_A, LAN_B, LAN_C, LAN_D}
This later description is closer to the concept of Unidirectional Link as is currently in the schema. The schema further allows grouping to a (Bidirectional) Link. That's what I added on the last line.
What are your preferences?
I see problems with both concepts.
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
participants (3)
-
Freek Dijkstra -
Guy Roberts -
Roman Lapacz