Use case: a media converter (multi-layer)
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
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
Freek Dijkstra wrote:
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.
I strongly suggest not to invent urn's like this, even if this is just an example. This will be archived on the web and can always be found later. We do not know at all whether IEEE, ANSI or the ITU have URN namespaces like this. Or even if they do, that they want to identify their technologies like this. In absence of a better identifier I suggest using a URL to the standard. Or the group that wrote the standard if none is available. I agree that this is incredibly annoying, and that we'll probably have to maintain a list with identifiers for technologies. But we can't just make stuff up while referring to other standards organisations. So: 802.3ab: http://grouper.ieee.org/groups/802/3/ab/index.html eia-568-a: http://standardsdocuments.tiaonline.org/tia-eia-568.htm 802.3-2008: http://standards.ieee.org/getieee802/802.3.html etc. Jeroen.
Jeroen van der Ham wrote:
In absence of a better identifier I suggest using a URL to the standard. Or the group that wrote the standard if none is available. I agree that this is incredibly annoying, and that we'll probably have to maintain a list with identifiers for technologies. But we can't just make stuff up while referring to other standards organisations.
So: 802.3ab: http://grouper.ieee.org/groups/802/3/ab/index.html eia-568-a: http://standardsdocuments.tiaonline.org/tia-eia-568.htm 802.3-2008: http://standards.ieee.org/getieee802/802.3.html etc.
This actually raises an important point, that was also identified during an NSI call today: how do we make sure that different networks will use the same identifiers for technologies and adaptations? IMO, we can't go the GMPLS way and define what identifiers can be used. This would mean that we would have to standardize a list of identifiers, and keep it up to date as new standards evolve. We also can't directly use the identifiers of GMPLs, because we use different model. And unfortunately, there does not seem be to be a simple way of determining identifiers for technologies and adaptations. Even the URLs above took me some time to find and are somewhat arbitrary. Does anyone have an idea on how we could solve this? Jeroen.
Jeroen van der Ham wrote:
Jeroen van der Ham wrote:
In absence of a better identifier I suggest using a URL to the standard. Or the group that wrote the standard if none is available. I agree that this is incredibly annoying, and that we'll probably have to maintain a list with identifiers for technologies. But we can't just make stuff up while referring to other standards organisations.
This actually raises an important point, that was also identified during an NSI call today: how do we make sure that different networks will use the same identifiers for technologies and adaptations?
IMO, we can't go the GMPLS way and define what identifiers can be used. This would mean that we would have to standardize a list of identifiers, and keep it up to date as new standards evolve.
We also can't directly use the identifiers of GMPLS, because we use different model.
And unfortunately, there does not seem be to be a simple way of determining identifiers for technologies and adaptations. Even the URLs above took me some time to find and are somewhat arbitrary.
Does anyone have an idea on how we could solve this?
[Freek steps on his soap box] Let me ask: what are we trying to solve exactly, and why do you dismiss the enumeration approach of GMPLS? In my view, we want to create a model that is strongly forward compatible. That means that NO SOFTWARE SHOULD BE UPDATED IF A NEW TECHNOLOGY COMES ALONG. After all, we are explicitly dealing with multi-domain, and we can not expect our neighbour to upgrade their software if our network moves to some fancy new technology. Let me rub in the fact that nearly everyone things IPv4 has reached its limit, and IPv6 is the accepted predecessor. Still, it has OVER 10 YEARS and still MOST ISPs have NOT updated their software. And that is easy compared that what we are doing (after all, what router does not support IPv6 these days) CCAMP dealt with this by modelling everything as a list of parameters in GMPLS. Every technology gets a number. That's it. In my view, the best approach is that software is able to dynamically load new technologies, and to make it possible to do the same reasoning as it did before. In fact, enumeration does work that way. Let's assume you see a Switching Type of value 38. Now, you know this is not defined at http://www.iana.org/assignments/gmpls-sig-parameters. However, you DO know that it is a switching matrix at some unknown new layer, and you still can reason about it. Problem solved, right? So why do I still agree with Jeroen that enumeration is not the way to go? Well, we deal with research networks, experimental networks, so I will take it even a step further: NO NML EXTENSION SHOULD BE NEEDED IF A NEW TECHNOLOGY COMES ALONG. So, indeed, NO standardization action by defining a new number. No IANA. So If network X want to use PBB though it is not defined, they should be able to make their own PBB technology definition, and if network Y wants to use MPLS-TP, they can create their own technology definition. This is the same as that X defines parameter 27 and network Y defines parameter 38 for PBB and MPLS-TP respectively. The problem arises when network Z comes along and defines their own definition of PBB. In GMPLS terms, what if they would define parameter 19 for PBB? In my view three things need to happen: - Software must be able to understand new technology definitions. Much like a new number comes along in GMPLS. - These definitions should be dynamically loaded (pull/push/...) by software. (In NDL, this is done by pointing to a URL with a technology schema). - Whoever defines these schemas should be able to define equivalence relations between technology definitions. The last point is important: everyone can just make a definition, and start using it. The word will spread, and other people will start using that technology definition. If multiple people define the same technology, one can define an equivalence relation and thus resolve the just created incompatibility. The hard part is how to define equivalence when different sublayers are used. For example, if X defines one Ethernet layer, while Y defines 4 layers (MAC layer, C-VLAN layer, B-VLAN layer and I-SID layer). This is hard, but not undoable. In fact, even when we do require a standardization action, I claim that WE MUST DEFINE EQUIVALENCE RELATIONS FOR ADAPTATIONS Imagine we have a world with Ethernet over fiber. Everyone describes that as two layers: Ethernet layer and fiber layer. Now some smart guy (O.E. DeLange if not for my mix up in chronology) comes along and introduces two wavelengths on the same fiber. So now we have three layers: Ethernet over a wavelength over a fiber. Surely we do not want to update all software to deal with this change, but instead tell them that "Ethernet over fiber" is really equivalent to "Ethernet over a wavelength over a fiber" This is not new, Figure 13 in G.805 deals with this (I don't think this is repeated in G.800). Now it is up to us to define a syntax how to deal with this. [Freek leaves his soap box] Now, I intentionally took my views to an extreme, I do appreciate your rebuttal. Looking forward to it, Freek
Jeroen van der Ham wrote:
[...] we use [a] different model [than GMPLS].
You dismiss the GMPLS approach rather quickly. To play the devil's advocate: the GMPLS group was the first to point me to G.800, which we now triumph so much. So their model is not that different. Surely you are referring to the fact that GMPLS does define the line encoding ("LSP Encoding Type") -the layer of the link in NDL- and "Switching Types" -the layer of the switch matrix in NDL-, but does not describe HOW that data may be adapted from one to the other layer. You are right though that originally, GMPLS did not describe adaptations explicitly (since they never assumed incompatibilities there). However, they certainly did consider this. A draft of RFC 5339 said:
the advertisement of the internal adaptation capability of hybrid nodes is required.
I just discovered that in the final RFC this has changed to:
The advertisement of the adjustment capacities is required, as it provides critical information when performing multi-region path computation.
Where "adjustment capacities" is defined as:
The term "adjustment capacity" refers to the property of a hybrid node to interconnect different switching capabilities it provides through its external interfaces [RFC5212]. This information allows path computation to select an end-to-end multi-region path that includes links of different switching capabilities that are joined by LSRs that can adapt the signal between the links.
They are trying to add the adaptation information to GMPLS. See also: RFC 5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-mln-extensions (the last one is fresh -- it was updated 3 days ago). Regards, Freek
Freek - I have some questions about the On Aug 10, 2009, at 1:15 PM, Freek Dijkstra wrote:
Hi,
. . .
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.
. . .
This defines a new attribute, atLayer, which might be defined as a Relation type if the Layer class is a subclass of Network Object.
I am not clear on the definition of a layer. Is everything that has a different characteristic information a different layer? I have been thinking that a layer was where technologies differed in a way that the user information could not be multiplexed directly on links from one layer to another. For example, ethernet would be a single layer, where segments at the layer carry ethernet coded with different characteristic information. SONET could carry ethernet segments by encoding them using GFP. However once GFP encoding is done then the segments at the SONET layer are carried in VCGs or sets of channels. ethernet frames (coded in GFP) can be carried with other segments, and the layer (in my view) supports SONET links which carry STS1 channels, while the ethernet layer supports Ethernet links which carry VLANs. In some ways these are similar concepts, but the concept of being able to create and concatenate segments of a particular client type seems to me to be the important concept for dynamic connection concepts of NSI. What is your view? John
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
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@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Attempt number three. Now with the *correct* pdf. sorry :( Jeroen van der Ham wrote:
Now with PDF.
------------------------------------------------------------------------
_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hi, I just got a call from Guy Roberts asking about some details about my "Ethernet media converter" example. Apparently, I did not use the G.800 terminology corretly, so I updated the example. In addition, I added a PDF showing a graphical representation of all descriptions (and a picture of an actual Ethernet media converter). Changes: - use "adaptation source" instead of "adaptation" - use "adaptation sink" instead of "deadaptation" - use "from" instead of "source", as is now in the schema - use "to" instead of "sink", as is now in the schema - make it clear that the URN of technologies are just made up Regards, Freek Hi, 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 uri_for_IEEE_802.3ab uri_for_IEEE_802.3ab name 1000base-T uri_for_IEEE_802.3ab client layer uri_for_Ethernet_layer uri_for_IEEE_802.3ab server layer uri_for_TIA_EIA_568 Adaptation Function id uri_for_1000base-LX uri_for_1000base-LX name 1000base-LX uri_for_1000base-LX client layer uri_for_Ethernet_layer uri_for_1000base-LX server layer uri_for_SM_fibre where uri_for_Ethernet_layer, uri_for_TIA_EIA_568 and uri_for_SM_fibre are layers -- I think we should define a "Layer" class for this. client layer and server layer are attributes of the Adaptation Function class. The "EMC" converter has 2 physical interfaces. Each physical interfaces has Ports on two layers, and both ingress and egress Ports. So 2 x 2 = 4 Ports per physical interface, for a total of 8 Ports: Node id :emc Port id :emc:fiber_in Port id :emc:fiber_out Port id :emc:eth_fiber_in Port id :emc:eth_fiber_out Port id :emc:utp_in Port id :emc:utp_out Port id :emc:eth_utp_in Port id :emc:eth_utp_out The identifiers in this example start with ":", e.g. ":emc:utp_in". In reality, the identifiers will start with "urn:ogf:network:", e.g. "urn:ogf:network:example.net:emc:utp_in", but that is too long for lines in an e-mail. These instances have the following properties: :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 :emc:fiber_in atLayer uri_for_SM_fibre :emc:fiber_out atLayer uri_for_SM_fibre :emc:eth_fiber_in atLayer uri_for_Ethernet_layer :emc:eth_fiber_out atLayer uri_for_Ethernet_layer :emc:utp_in atLayer uri_for_TIA_EIA_568 :emc:utp_out atLayer uri_for_TIA_EIA_568 :emc:eth_utp_in atLayer uri_for_Ethernet_layer :emc:eth_utp_out atLayer uri_for_Ethernet_layer These Ports are internally interconnected as follows: Relation type adaptation-sink from :emc:fiber_in to :emc:eth_fiber_in adaptation function uri_for_1000base-LX Relation type adaptation-source from :emc:eth_fiber_out to :emc:fiber_out adaptation function uri_for_1000base-LX Relation type adaptation-sink from :emc:utp_in to :emc:eth_utp_in adaptation function uri_for_IEEE_802.3ab Relation type adaptation-source from :emc:eth_utp_out to :emc:utp_out adaptation function uri_for_IEEE_802.3ab Relation type cross connect from :emc:eth_fiber_in to :emc:eth_utp_out Relation type cross connect from :emc:eth_utp_in to :emc:eth_fiber_out Two remarks: - I needed to define an additional attribute for the adaptation and adaptation-sink relation. This is currently not possible in the schema. I propose we create two subclasses of Relation, Adaptation and adaptation-sink, 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 adaptation-sink from :emc:fiber_in to :emc:eth_fiber_in adaptation function uri_for_1000base-LX Relation type adaptation-source from :emc:eth_fiber_out to :emc:fiber_out adaptation function uri_for_1000base-LX Relation type adaptation-sink from :emc:utp_in to :emc:eth_utp_in adaptation function uri_for_IEEE_802.3ab Relation type adaptation-source from :emc:eth_utp_out to :emc:utp_out adaptation function uri_for_IEEE_802.3ab Relation type source from :emc:eth_fiber_in to :emc:eth_fiber_to_utp Relation type sink from :emc:eth_fiber_to_utp to :emc:eth_utp_out Relation type source from :emc:eth_utp_in to :emc:eth_utp_to_fiber Relation type sink from :emc:eth_utp_to_fiber to :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 adaptation-sink from :emc:fiber_in to :emc:eth_fiber_to_utp adaptation function uri_for_1000base-LX Relation type adaptation-source from :emc:eth_utp_to_fiber to :emc:fiber_out adaptation function uri_for_1000base-LX Relation type adaptation-sink from :emc:utp_in to :emc:eth_utp_to_fiber adaptation function uri_for_IEEE_802.3ab Relation type adaptation-source from :emc:eth_fiber_to_utp to :emc:utp_out adaptation function uri_for_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). Regards, Freek
participants (3)
-
Freek Dijkstra -
Jeroen van der Ham -
John Vollbrecht