[Nml-wg] Use case: a media converter (multi-layer)
Freek Dijkstra
Freek.Dijkstra at sara.nl
Mon Aug 10 12:15:27 CDT 2009
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
More information about the nml-wg
mailing list