[Nml-wg] Use case: a media converter (multi-layer)
John Vollbrecht
jrv at internet2.edu
Mon Aug 10 14:21:51 CDT 2009
This is very helpful --
It seems that the adaptation could also be described a modifying the
characteristic information between ethernet over copper and ethernet
over fiber. I am wondering if there is another way to do this, that
might be more interesting in a switched case.
Assume the device is a switch (emsw) which has an ethernet over
copper, an ethernet over fiber and a ethernet over SONET port. Then
there is an internal port "software-eth" which has no technology
specific information.
Then assume the switch connects the Eth/SONET to Eth/fiber - I
attempt to describe this in your terms below. I think this is what
you describe in approach 2 -- do you agree?
:emsw hasPort :emsw:fiber_in
:emsw hasPort :emsw:fiber_out
:emsw hasPort :emsw:utp_in
:emsw hasPort :emsw:utp_out
:emsw hasPort :emsw:SONET_eth_in
:emsw hasPort :emsw:SONET_eth_out
:emsw hasPort :emsw:internal_fiber_in
:emsw hasPort :emsw:internal_utp_in
:emsw hasPort :emsw:internat_SONET_in
Relation
tyoe deadaptation
source :emsw:fiber_in
sink :emsw:internal_fiber_in
Relation (switched)
tyoe adaptation
soucre :emsw:internal_fiber_in
sink :emsw:SONET_eth_out
Relation (switched)
tyoe deadaptation
soucre :emsw:SONET_eth_in
sink :emsw:internal_SONET_in
Relation
tyoe adaptation
soucre :emsw:internal_SONET_in
sink :emsw:SONET_eth_out
> Relation
> type deadaptation
> source :emc:fiber_in
> sink :emc:eth_fiber_in
> adaptation function urn:ieee:802.3-clause38
On Aug 10, 2009, at 1:15 PM, 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 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