Here is the use case of the cross connect (single layer). It really makes me think about my mantra: the model can be verbose, but the syntax compact. This is the (very verbose) model. As soon we finished that, we should look into compact (syntax) shortcuts for sure! Regards, Freek THREE EXAMPLE USE CASES Created 2009-07-30 by Freek Dijkstra Cross connect use case: photonic cross connect ============================================== Case: Describe a photonic cross connect, thus a MEMS device that works as an automated patch panel. Our example device is called "pxc", and has four bidirectional ports: port1, port2, port3 and port4. Currently port2 and port3 are crossed. This example will be represented by multiple instances of the UML classes. I will denote that as follows: <UML class name> <property 1> <property value> <property 2> <property value> Or -as a shortcut- <UML class name> <property 1> <property value> Let's first define the objects that describe the device itself, the cross connect service that it offers, its ports and the crossconnect: Node id urn:ogf:network:example.org:pxc SwitchingMatrixServer id urn:ogf:network:example.org:pxc:switch Port id urn:ogf:network:example.org:pxc:port1-ingress Port id urn:ogf:network:example.org:pxc:port1-egress Port id urn:ogf:network:example.org:pxc:port2-ingress Port id urn:ogf:network:example.org:pxc:port2-egress Port id urn:ogf:network:example.org:pxc:port3-ingress Port id urn:ogf:network:example.org:pxc:port3-egress Port id urn:ogf:network:example.org:pxc:port4-ingress Port id urn:ogf:network:example.org:pxc:port4-egress Link id urn:ogf:network:example.org:pxc:port2-port3 Link id urn:ogf:network:example.org:pxc:port3-port2 Now we have to relate these objects somehow. This is done with instances of the Relation class: First the relation between the device and the ports: Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port1-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port1-egress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port2-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port2-egress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port3-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port3-egress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port4-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port4-egress The relation between the device and the Switch matrix service: (note that the current schema does not list "hasService" and "hasPort" as relation. I will add it.) Relation type hasService from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:switch The relation between the switch matrix and the interface: Relation type hasPort from urn:ogf:network:example.org:pxc:switch to urn:ogf:network:example.org:pxc:port1-ingress Relation type hasPort from urn:ogf:network:example.org:pxc:switch to urn:ogf:network:example.org:pxc:port1-egress .... Relation type hasPort from urn:ogf:network:example.org:pxc:switch to urn:ogf:network:example.org:pxc:port4-egress The relation between the Link and its ports: Relation type source from urn:ogf:network:example.org:pxc:port2-port3 to urn:ogf:network:example.org:pxc:port2 Relation type sink from urn:ogf:network:example.org:pxc:port2-port3 to urn:ogf:network:example.org:pxc:port3 Relation type source from urn:ogf:network:example.org:pxc:port3-port2 to urn:ogf:network:example.org:pxc:port3 Relation type sink from urn:ogf:network:example.org:pxc:port3-port2 to urn:ogf:network:example.org:pxc:port2 And that's it. If we want to group the two unidirectional links to a bidirectional link: BidirectionalLink id urn:ogf:network:example.org:pxc:port2-port3-vv element urn:ogf:network:example.org:pxc:port2-port3 element urn:ogf:network:example.org:pxc:port3-port2 Adaptation use case 1: WSS ========================== (follows) Adaptation use case 2: tunable laser ==================================== (follows)
Freek Dijkstra wrote (in "Use case: cross connect (single layer)"):
Here is the use case of the cross connect (single layer).
Paola Grosso wrote:
- Transitivity of relation, such as if a device is at one Location, all its Ports are at the same location. Should transitivity specified in the model or implicit?
The problem I had is there there were 16 "hasPort" relations for 8 unidirectional ports: a hasPort relation between the Node and each port, and a hasPort relation between the SwitchMatrix Service and each port. In the call I wondered if this can be an implicit relation. I recently thought about this, and it seems we have 3 options: 1) No transitivity: You have to specify all 16 "hasPort" relation, as in the example I sent out previous week. 2) Transitivity from Node to Service: If there is a hasPort relation between a Node and a Port, and also a hasService between the same Node and a Service, then it is implied that there is also a hasPort relation between the Service and the Port, _provided that the Port is on the same layer as the Service_. This scenario was discussed in the call, and we added this condition to cope with Nodes with services on multiple layers. 3) Transitivity from Service to Node: If there is a hasPort relation between a Service and a Port, and also a hasService between a Node and the same Service, then it is implied that there is also a hasPort relation between the Node and the Port. This last scenario was not discussed, but I think it makes more sense: this way we would not need the additional condition that the Port is on the same layer as the Service. Less conditions = better. Regards, Freek
Freek Dijkstra wrote:
2) Transitivity from Node to Service: If there is a hasPort relation between a Node and a Port, and also a hasService between the same Node and a Service, then it is implied that there is also a hasPort relation between the Service and the Port, _provided that the Port is on the same layer as the Service_. This scenario was discussed in the call, and we added this condition to cope with Nodes with services on multiple layers.
This seems like a good idea to me. It also makes it a lot easier to map GMPLS descriptions to NML. In GMPLS the port contains all the information about the layer and the switching capability. You can then easily map that to a port on a layer and a service on a node.
3) Transitivity from Service to Node: If there is a hasPort relation between a Service and a Port, and also a hasService between a Node and the same Service, then it is implied that there is also a hasPort relation between the Node and the Port.
This last scenario was not discussed, but I think it makes more sense: this way we would not need the additional condition that the Port is on the same layer as the Service. Less conditions = better.
This makes sense, but then I have problems with the word "Service". A "Service" in my mind is a generic thing that can be provided by many providers, it is up to you to pick the service-provider you want. In this case we are talking about an action that is specific to this device, and will need a unique identifier. Then there cannot be two "Services" that are exactly the same. What we actually seem to be talking about is that we have a SwitchingMatrix in a device, which performs the Service of switching at a specific layer. Then a switchingmatrix is a unique component to a device, so it is fair to assume that any port attached to a SM is also part of the node. The way that switching is done is a Service, which should be equal between SMs on the same layer. Jeroen.
Jeroen van der Ham wrote:
This makes sense, but then I have problems with the word "Service".
A "Service" in my mind is a generic thing that can be provided by many providers, it is up to you to pick the service-provider you want. In this case we are talking about an action that is specific to this device, and will need a unique identifier. Then there cannot be two "Services" that are exactly the same.
Yes, we discussed this earlier. There are multiple meanings of the word "Service". I'm using the term "Service" as it is currently used in the latest NML schema, which is a "transport processing capability", e.g. a Switch Matrix. You're thinking about the other meaning of services (as in Service Provider). Regards, Freek
Freek, I like the idea of creating an explicit service call switchingMatrix (for circuits) or forwardingEngine (for packets). So as Jeroen says, as soon as an switchingMatrix/forwardingEngine is instantiated in a node, all of the ports in the switchingMatrix/forwardingEngine are inherited by the node. I wonder if we should not distinguish between switchingMatrix and forwardingEngine, these have unique properties, for example a forwarding engine will try and forward any incoming packet to its egress destination, but has the ability to drop packets, whereas a switchingMatrix can have blocking properties, so either everything or nothing is forwarded. The reason I like the idea of explicitly nominating services types is that it maps to reality which is always nice :) Guy -----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 07 August 2009 15:00 To: Freek Dijkstra Cc: Network Markup Language Working Group Subject: Re: [Nml-wg] Transitivity of hasPort Freek Dijkstra wrote:
2) Transitivity from Node to Service: If there is a hasPort relation between a Node and a Port, and also a hasService between the same Node and a Service, then it is implied that there is also a hasPort relation between the Service and the Port, _provided that the Port is on the same layer as the Service_. This scenario was discussed in the call, and we added this condition to cope with Nodes with services on multiple layers.
This seems like a good idea to me. It also makes it a lot easier to map GMPLS descriptions to NML. In GMPLS the port contains all the information about the layer and the switching capability. You can then easily map that to a port on a layer and a service on a node.
3) Transitivity from Service to Node: If there is a hasPort relation between a Service and a Port, and also a hasService between a Node and the same Service, then it is implied that there is also a hasPort relation between the Node and the Port.
This last scenario was not discussed, but I think it makes more sense: this way we would not need the additional condition that the Port is on the same layer as the Service. Less conditions = better.
This makes sense, but then I have problems with the word "Service". A "Service" in my mind is a generic thing that can be provided by many providers, it is up to you to pick the service-provider you want. In this case we are talking about an action that is specific to this device, and will need a unique identifier. Then there cannot be two "Services" that are exactly the same. What we actually seem to be talking about is that we have a SwitchingMatrix in a device, which performs the Service of switching at a specific layer. Then a switchingmatrix is a unique component to a device, so it is fair to assume that any port attached to a SM is also part of the node. The way that switching is done is a Service, which should be equal between SMs on the same layer. Jeroen. _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Guy Roberts wrote:
I like the idea of creating an explicit service call switchingMatrix (for circuits) or forwardingEngine (for packets).
I think we all agree on having an explicit service for switchMatrix. (If not, this is a good time to speak up).
[...] as soon as an switchingMatrix/forwardingEngine is instantiated in a node, all of the ports in the switchingMatrix/forwardingEngine are inherited by the node.
So, we both have a preference of option #3 in my first mail (Transitivity from Service to Node), not what we discussed in the call (Transitivity from Node Service). I think your suggestion to have a distinction between switchingMatrix and forwardingEngine may be good. I would say that both spawn from the same base class. If their properties are sufficiently different, it makes sense to make subclasses instead of just different attributes in the base class. If others agree, we can provisionally put these subclasses in the schema.
Things could get ugly if you try and model spanning tree forwarding rules! ... but fortunately I think (hope) this is not necessary.
I hope we don't need to model spanning tree. But I do think we will have to define packet switched networks: VLANs are a weird technology that I tend to model as packet Ethernet on top of VLAN circuits on top of packet Ethernet on top of something else (I think this is an ugly model, but don't see another way to model an Ethernet interface in a TDM switch; I'll save that discussion for another mail). Regards, Freek
On Aug 10, 2009, at 9:47 AM, Freek Dijkstra wrote:
Guy Roberts wrote:
I like the idea of creating an explicit service call switchingMatrix (for circuits) or forwardingEngine (for packets).
I think we all agree on having an explicit service for switchMatrix. (If not, this is a good time to speak up).
I agree
[...] as soon as an switchingMatrix/forwardingEngine is instantiated in a node, all of the ports in the switchingMatrix/forwardingEngine are inherited by the node.
So, we both have a preference of option #3 in my first mail (Transitivity from Service to Node), not what we discussed in the call (Transitivity from Node Service).
I have the same preference
I think your suggestion to have a distinction between switchingMatrix and forwardingEngine may be good. I would say that both spawn from the same base class. If their properties are sufficiently different, it makes sense to make subclasses instead of just different attributes in the base class. If others agree, we can provisionally put these subclasses in the schema.
Things could get ugly if you try and model spanning tree forwarding rules! ... but fortunately I think (hope) this is not necessary.
Why is modeling spanning tree hard? I would think that it would be possible to model the presence of spanning tree without knowing the topology of network.
I hope we don't need to model spanning tree. But I do think we will have to define packet switched networks: VLANs are a weird technology that I tend to model as packet Ethernet on top of VLAN circuits on top of packet Ethernet on top of something else (I think this is an ugly model, but don't see another way to model an Ethernet interface in a TDM switch; I'll save that discussion for another mail).
I think of Ethernet Links carrying VLANs, where VLANs are labels for each Link connection. Characteristic info is ethernet hdr and for VLAN one adds tag. When adapting to SONET one needs to decide whether the whole Link (with its VLANs) is adapted or if each VLAN is adapted individually. If one adapts the whole Link, then a Ethernet trunk exists at the ethernet layer and there is no dynamic adaptation at that layer. If one adapts at the VLAN layer then there is no link at the ethernet layer and pathfinding must be done on multiple layers. I think, but am not sure, that this is an advantage to the NDL approach to pathfinding that Freek described in pathfinding email today. This would be worth discussing,.
Regards, Freek
_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
John Vollbrecht wrote:
Things could get ugly if you try and model spanning tree forwarding rules! ... but fortunately I think (hope) this is not necessary.
Why is modeling spanning tree hard? I would think that it would be possible to model the presence of spanning tree without knowing the topology of network.
Not hard, ugly. I think it is too detailed to convey to neighbouring networks (I'm assuming the context of NML and NSI here which is interdomain messaging and modelling). The model is reasonable: you have to add the concept of a routing table. (That would model the MAC layer, not the _presence of_ a spanning tree; I'm not sure how to model that except with some boolean attribute). If you think it is useful, please propose a use case and/or extension to the current schema. Regards, Freek
I vote for option 3, it makes the most sense to me. Guy -----Original Message----- From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] Sent: 07 August 2009 14:05 To: Network Markup Language Working Group Subject: [Nml-wg] Transitivity of hasPort Freek Dijkstra wrote (in "Use case: cross connect (single layer)"):
Here is the use case of the cross connect (single layer).
Paola Grosso wrote:
- Transitivity of relation, such as if a device is at one Location, all its Ports are at the same location. Should transitivity specified in the model or implicit?
The problem I had is there there were 16 "hasPort" relations for 8 unidirectional ports: a hasPort relation between the Node and each port, and a hasPort relation between the SwitchMatrix Service and each port. In the call I wondered if this can be an implicit relation. I recently thought about this, and it seems we have 3 options: 1) No transitivity: You have to specify all 16 "hasPort" relation, as in the example I sent out previous week. 2) Transitivity from Node to Service: If there is a hasPort relation between a Node and a Port, and also a hasService between the same Node and a Service, then it is implied that there is also a hasPort relation between the Service and the Port, _provided that the Port is on the same layer as the Service_. This scenario was discussed in the call, and we added this condition to cope with Nodes with services on multiple layers. 3) Transitivity from Service to Node: If there is a hasPort relation between a Service and a Port, and also a hasService between a Node and the same Service, then it is implied that there is also a hasPort relation between the Node and the Port. This last scenario was not discussed, but I think it makes more sense: this way we would not need the additional condition that the Port is on the same layer as the Service. Less conditions = better. Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hi, Just to be clear on this, examples of the following proposals so that we are all sure that we understand each other. (I'm abbreviating "urn:ogf:network:example.org:" to # and default namespace is nml) I'm also adding a way to describe that something is on a specific layer using the "hasLayer" property. This is just an shorthand for whatever that we eventually decide will be the way to describe what layer an interface is on. Node id #pxc SwitchingMatrixServer id #pxc:switch Port id #pxc:port1-ingress Port id #pxc:port1-egress Freek Dijkstra wrote:
I recently thought about this, and it seems we have 3 options: 1) No transitivity: You have to specify all 16 "hasPort" relation, as in the example I sent out previous week.
#pxc hasService #pxc:switch #pxc hasPort #pxc:port1-ingress #pxc hasPort #pxc:port1-egress #pxc:switch hasPort #pxc:port1-ingress #pxc:switch hasPort #pxc:port1-egress #pxc:switch hasLayer foo #pxc:port1-ingress hasLayer foo #pxc:port1-egress hasLayer foo
2) Transitivity from Node to Service: If there is a hasPort relation between a Node and a Port, and also a hasService between the same Node and a Service, then it is implied that there is also a hasPort relation between the Service and the Port, _provided that the Port is on the same layer as the Service_. This scenario was discussed in the call, and we added this condition to cope with Nodes with services on multiple layers.
#pxc hasService #pxc:switch #pxc hasPort #pxc:port1-ingress #pxc hasPort #pxc:port1-egress #pxc:switch hasLayer foo #pxc:port1-ingress hasLayer foo #pxc:port1-egress hasLayer foo implies: #pxc:switch hasPort #pxc:port1-ingress #pxc:switch hasPort #pxc:port1-egress
3) Transitivity from Service to Node: If there is a hasPort relation between a Service and a Port, and also a hasService between a Node and the same Service, then it is implied that there is also a hasPort relation between the Node and the Port.
#pxc hasService #pxc:switch #pxc:switch hasPort #pxc:port1-ingress #pxc:switch hasPort #pxc:port1-egress #pxc:switch hasLayer foo implies: #pxc:port1-ingress hasLayer foo #pxc:port1-egress hasLayer foo #pxc hasPort #pxc:port1-ingress #pxc hasPort #pxc:port1-egress Jeroen.
participants (4)
-
Freek Dijkstra -
Guy Roberts -
Jeroen van der Ham -
John Vollbrecht