[Nml-wg] Use case: a media converter (multi-layer)
Jeroen van der Ham
vdham at uva.nl
Thu Aug 13 15:11:36 CDT 2009
Hi,
I've made some pictures using the G.800 diagrammatic convention. I've
only drawn the approaches in one direction, I'll leave the other one as
an exercise to the reader ;)
I have an OmniGraffle stencil available on request.
Jeroen.
Freek Dijkstra wrote:
> Hi,
>
> (I promised this weeks ago, so here it goes. I do feel sorry if you just
> returned form holiday to find your NML mailbox flooded by Jeroen, John,
> Guy and yours truly).
>
> Imagine an Ethernet media converter. (That is a very simple device with
> two ports: one fiber port, one copper port. It effectively converts
> between Ethernet over copper to Ethernet over UTP and vice versa.)
>
> Our converter is called EMC, and coverts between 1000base-T (copper) and
> 1000base-X (fibre).
>
> For the sake of simplicity, I will ignore that it is not really Ethernet
> over fibre, but Ethernet over a given wavelength over a given encoding
> over a fibre. (Nitpicks will be delighted to know it's 770-860 nm for
> 1000base-SX, 1270-1355nm for 1000base-LX, and 1550nm for 1000base-ZX/LH,
> and all use a 8b/10b encoding. Rejoice.)
>
> First, I assume that the following technology definitions have already
> been defined:
>
> Adaptation Function id urn:ieee:802.3ab
> urn:ieee:802.3ab name 1000base-T
> urn:ieee:802.3ab client layer urn:ieee:802.3-2005
> urn:ieee:802.3ab server layer urn:ansi:eia-568-a
>
> Adaptation Function id urn:ieee:802.3-clause38
> urn:ieee:802.3-clause38 name 1000base-LX
> urn:ieee:802.3-clause38 client layer urn:ieee:802.3-2005
> urn:ieee:802.3-clause38 server layer urn:itu:fiber-8micron
>
> where urn:ieee:802.3-2005, urn:ansi:eia-568-a and urn:itu:fiber-8micron
> are layers -- I think we should define a class for this too.
> client layer and server layer are attributes of the Adaptation Function
> class.
>
>
> The "EMC" converter has 2 bidirectional interface, each on two layers. A
> NML Port is unidirectional on a single layer, so this Node has 8 Ports:
>
> Node id :emc
> :emc hasPort :emc:fiber_in
> :emc hasPort :emc:fiber_out
> :emc hasPort :emc:eth_fiber_in
> :emc hasPort :emc:eth_fiber_out
> :emc hasPort :emc:utp_in
> :emc hasPort :emc:utp_out
> :emc hasPort :emc:eth_utp_in
> :emc hasPort :emc:eth_utp_out
>
> (note: the actual identifiers will start with "urn:ogf:network:", e.g.
> "urn:ogf:network:example.net:emc", but that is too long, so I write ":emc")
>
> These Ports are internally interconnected as follows:
>
> Relation
> type deadaptation
> source :emc:fiber_in
> sink :emc:eth_fiber_in
> adaptation function urn:ieee:802.3-clause38
>
> Relation
> type adaptation
> source :emc:eth_fiber_out
> sink :emc:fiber_out
> adaptation function urn:ieee:802.3-clause38
>
> Relation
> type deadaptation
> source :emc:utp_in
> sink :emc:eth_utp_in
> adaptation function urn:ieee:802.3ab
>
> Relation
> type adaptation
> source :emc:eth_utp_out
> sink :emc:utp_out
> adaptation function urn:ieee:802.3ab
>
> Relation
> type cross connect
> source :emc:eth_fiber_in
> sink :emc:eth_utp_out
>
> Relation
> type cross connect
> source :emc:eth_utp_in
> sink :emc:eth_fiber_out
>
> Two remarks:
> - I needed to define an additional attribute for the adaptation and
> deadaptation relation. This is currently not possible in the schema. I
> propose we create two subclasses of Relation, Adaptation and
> Deadaptation, with attribute "adaptation function". The alternative is
> to stick the attribute in the Relation class. However, that would mean
> all relation carry this attribute, even the "implemented by" relation.
>
> - I did define a "cross connect" relation above. This is not necessary.
> Bellow are two alternatives. The second approach is longer and defines a
> Link. The third approach is shorter.
>
>
>
> ALTERNATIVE: Approach 2, with Link instance
>
> (The description of a switch will be similar to this one, only with a
> SwitchMatrix Service instead of a Link)
>
> Node id :emc
> :emc hasPort :emc:fiber_in
> :emc hasPort :emc:fiber_out
> :emc hasPort :emc:eth_fiber_in
> :emc hasPort :emc:eth_fiber_out
> :emc hasPort :emc:utp_in
> :emc hasPort :emc:utp_out
> :emc hasPort :emc:eth_utp_in
> :emc hasPort :emc:eth_utp_out
> Link id :emc:eth_fiber_to_utp
> Link if :emc:eth_utp_to_fiber
>
> Relation
> type deadaptation
> source :emc:fiber_in
> sink :emc:eth_fiber_in
> adaptation function urn:ieee:802.3-clause38
>
> Relation
> type adaptation
> source :emc:eth_fiber_out
> sink :emc:fiber_out
> adaptation function urn:ieee:802.3-clause38
>
> Relation
> type deadaptation
> source :emc:utp_in
> sink :emc:eth_utp_in
> adaptation function urn:ieee:802.3ab
>
> Relation
> type adaptation
> source :emc:eth_utp_out
> sink :emc:utp_out
> adaptation function urn:ieee:802.3ab
>
> Relation
> type source
> source :emc:eth_fiber_in
> sink :emc:eth_fiber_to_utp
>
> Relation
> type sink
> source :emc:eth_fiber_to_utp
> sink :emc:eth_utp_out
>
> Relation
> type source
> source :emc:eth_utp_in
> sink :emc:eth_utp_to_fiber
>
> Relation
> type sink
> source :emc:eth_utp_to_fiber
> sink :emc:eth_fiber_out
>
>
>
> ALTERNATIVE: Approach 3, compact description
>
> (in here, two ethernet Ports are merged into one)
>
> Node id :emc
> :emc hasPort :emc:fiber_in
> :emc hasPort :emc:fiber_out
> :emc hasPort :emc:utp_in
> :emc hasPort :emc:utp_out
> :emc hasPort :emc:eth_fiber_to_utp
> :emc hasPort :emc:eth_utp_to_fiber
>
> Relation
> type deadaptation
> source :emc:fiber_in
> sink :emc:eth_fiber_to_utp
> adaptation function urn:ieee:802.3-clause38
>
> Relation
> type adaptation
> source :emc:eth_utp_to_fiber
> sink :emc:fiber_out
> adaptation function urn:ieee:802.3-clause38
>
> Relation
> type deadaptation
> source :emc:utp_in
> sink :emc:eth_utp_to_fiber
> adaptation function urn:ieee:802.3ab
>
> Relation
> type adaptation
> source :emc:eth_fiber_to_utp
> sink :emc:utp_out
> adaptation function urn:ieee:802.3ab
>
>
>
>
> I don't think there is a "correct" alternative -- all are equivalent
> from a functional point of view. However, we can decide to strive for a
> uniform approach, like approach 2 (since that will look most like other
> Node descriptions).
>
> Finally, I have not explicitly defined the layer for each interface,
> because it was already apparent from the (de)adaptations. For a single
> layer Node, this information can not be derived (is not transitive). So
> there is may be necessary to make this explicit.
>
> If we make all the implicit properties explicit, approach 1 will look like:
>
> Node id :emc
> Port id :emc:fiber_in
> :emc hasPort :emc:fiber_in
> :emc:fiber_in atLayer urn:itu:fiber-8micron
> Port id :emc:fiber_out
> :emc hasPort :emc:fiber_out
> :emc:fiber_out atLayer urn:itu:fiber-8micron
> Port id :emc:eth_fiber_in
> :emc hasPort :emc:eth_fiber_in
> :emc:eth_fiber_in atLayer urn:ieee:802.3-2005
> Port id :emc:eth_fiber_out
> :emc hasPort :emc:eth_fiber_out
> :emc:eth_fiber_out atLayer urn:ieee:802.3-2005
> Port id :emc:utp_in
> :emc hasPort :emc:utp_in
> :emc:utp_in atLayer urn:ansi:eia-568-a
> Port id :emc:utp_out
> :emc hasPort :emc:utp_out
> :emc:utp_out atLayer urn:ansi:eia-568-a
> Port id :emc:eth_utp_in
> :emc hasPort :emc:eth_utp_in
> :emc:eth_utp_in atLayer urn:ieee:802.3-2005
> Port id :emc:eth_utp_out
> :emc hasPort :emc:eth_utp_out
> :emc:eth_utp_out atLayer urn:ieee:802.3-2005
>
> This defines a new attribute, atLayer, which might be defined as a
> Relation type if the Layer class is a subclass of Network Object.
>
> 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