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