[Nml-wg] Use case: broadcast network (single layer)

Roman Lapacz romradz at man.poznan.pl
Mon Aug 10 09:50:00 CDT 2009


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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nml-wg
>   



More information about the nml-wg mailing list