We had a longer discussion if NML should define services? It was quickly clear to us that there are clearly two interpretations of the word "service": 1. Service as a network transport function. For example, an adaptation and network connection are transport processing functions. In the ITU, a lower layer is called a service layer which provide a network function to a (higher) client layer. 2. Service as a control plane daemon. For example a topology exchange service or a provisioning service. Regarding a control plane service: ---------------------------------- Should NML define services? No, but we should facilitate the tying of a service to the network description Template for generic service. We should look at OGSA. GLUE. Evangelos volunteers to propose a template definition. Guak: service may operate on a network Regarding a data transport function: ------------------------------------ Martin argued that Adaptation is just a subclass of Service. I gave his idea some thought over the weekend, and it seems to me that the high level proposal is to define a "service" as a dynamic transport function. That could both imply a cross connect as well as a dynamic adaptation. While I am now convinced that this high level idea is good (good suggestion, Martin!), I do not know how to make this into the schema yet. I am not convinced that Martin's schema proposal (made Adaptation a subclass of Service) is the right way forward. Mostly, I think Service is about *dynamic* (thus changable) trasport functions. A service is thus mostly about describing a *capability* ("it is possible to make this cross connect or this adaptation") and not about the *configuration* ("this-and-that adaptation is currently in place"). NDL only defined cross connects as part of the switching matrix (which contained information about capabilities). However, it did define adaptations, even dynamic adaptations outside of the switch matrix. I am very interested to hear about schemas that did this differently. Here are 3 different adaptations: * Fixed wavelenght over a fibre. This is what happens in most GBICs, and we should be able to describe this as a static feature -- devices often have no knowledge about the characteristics of the GBIC (e.g. is it 50 or 100 GHz spacing?) * Configurable wavelenght over a fibre. This is what happens in a tunable laser. The adaptation remains in place, but some of its properties (here: the label) changes. * VLAN channel over an Ethernet interface. This is a completely dynamic adaptation, which may completely be removed in software (if the Ethernet interface is switched from tagged to untagged). Should all these be represented with the same schema (database entries), or should we distinguish between static and dynamic adaptations. If so, how? Regards, Freek Dijkstra
Hi Freek,
We had a longer discussion if NML should define services?
It was quickly clear to us that there are clearly two interpretations of the word "service":
I think there are many interpretations of Service. This is also related to my other comment about the multi-layer topology in the other thread. I think we should include an abstract Service in the base and that this Service can be extended in the various layer-specific schemata. This would allow the use of the Service element to describe all the use cases that you mentioned. As you mentioned, the reason to do this in the base is so that we can have a generic way to relate services to the network objects (or classes) that provide them. This is not the same as the specific services defined in GLUE or but it allows them to be incorporated into our model. best, martin
Hi Martin,
I think there are many interpretations of Service. This is also related to my other comment about the multi-layer topology in the other thread.
I think we should include an abstract Service in the base and that this Service can be extended in the various layer-specific schemata. This would allow the use of the Service element to describe all the use cases that you mentioned.
Could you elaborate? To me, the three use case I mentioned (Fixed wavelenght over a fibre, tunable laser and VLAN) have rather different properties. In NDL we specified with this with a bunch of classes (Layer, Adaptation, StaticInterface, ConfigrableInterface, PotentialInterface and InstantiatedMuxInterface plus a bunch of relations), and the three use cases had different relations and class instances. I'm glad to write out all details and sent it to the list, but I hope that your ideas may lead to less subclasses of Ports. Just as starters, which of the three use case is to be represented as a "service" (in my mind only #3 and perhaps #2 are; #1 is -to me- a topology feature, not a capability feature, and not a service), and do you like to subclass "Adaptation" from "Service", or do you like to remove the "Adaptation" class altogether from the base schema (which is what I read in the above, but somehow doubt that that is your intention). So I am VERY interested to work on your ideas, but they are yet not clear to me. So pretty please, could you make a stance at the question of Jeroen:
Could you write a proposal for this perhaps including a new version of the schema diagram? I would like to understand your proposal better.
Thanks, Freek
participants (2)
-
Freek Dijkstra -
Martin Swany