[Nml-wg] atributes of Services

[Roman Łapacz]

W dniu 2012-10-01 13:26, Jeroen van der Ham pisze:
> I'm for option 2 as well. It only adds a single new relationship. It also makes it very clear what you would get if you would request something.

Agree. Simple and consistent.

Roman


>
> Jeroen.
>
>
> On 28 Sep 2012, at 17:22, Freek Dijkstra <freek.dijkstra at sara.nl> wrote:
>
>> Hi,
>>
>> I'm reviewing the NML document a few times in detail, adding notes what
>> examples are useful.
>>
>> One thing I can't seem to do is distinguish between the Ports that can
>> be configured by an AdaptationService and the Ports are are already
>> configured.
>>
>> The providesPort relation seem to aim the ports that are already
>> configured, akin to providesLink for the SwitchingService.
>>
>>
>> Current situation
>> =================
>>
>> Here are the current attributes and relations for SwitchingService:
>>
>> - associate with static component:
>>   Node|Topology --(hasService)--> SwitchingService
>> - associate (between) which (ports a) link CAN be created:
>>   SwitchingService --(hasOutboundPort)--> Port|PortGroup
>>   SwitchingService --(hasInboundPort)--> Port|PortGroup
>> - associate which links are already configured:
>>   SwitchingService --(providesLink)--> Link|LinkGroup
>>
>> Here are the current attributes and relations for AdaptationService:
>>
>> - associate with static component:
>>   Port --(hasService)--> AdaptationService
>> - associate which (client layer) ports CAN be created:
>>   AdaptationService --adaptationfunction--> URI (*)
>>   N/A
>> - associate which ports are already configured:
>>   AdaptationService --(providesPort)--> Port|PortGroup
>>
>> (* The adaptationfunction attribute can be used to determine client
>> layer encoding, but not the available labels)
>>
>>
>> Here are three (3) proposals to rectify this omission and subsequently
>> align the SwitchingService and AdaptationService definitions:
>>
>>
>> Proposal 1: encoding and hasLabelGroup
>> ======================================
>>
>> For SwitchingService (same as current situation):
>>
>> - associate with static component:
>>   Node|Topology --(hasService)--> SwitchingService
>> - associate (between) which (ports a) link CAN be created:
>>   SwitchingService --(hasOutboundPort)--> Port|PortGroup
>>   SwitchingService --(hasInboundPort)--> Port|PortGroup
>> - associate which links are already configured:
>>   SwitchingService --(providesLink)--> Link|LinkGroup
>>
>> For AdaptationService (add attribute and relation):
>>
>> - associate with static component:
>>   Port --(hasService)--> AdaptationService
>> - associate which (client layer) ports CAN be created:
>>   AdaptationService --encoding--> URI
>>   AdaptationService --hasLabelGroup--> LabelGroup
>> - associate which ports are already configured:
>>   AdaptationService --(providesPort)--> Port|PortGroup
>>
>>
>> Proposal 2: canProvidePort
>> ==========================
>>
>> For SwitchingService (same as current situation):
>>
>> - associate with static component:
>>   Node|Topology --(hasService)--> SwitchingService
>> - associate (between) which (ports a) link CAN be created:
>>   SwitchingService --(hasOutboundPort)--> Port|PortGroup
>>   SwitchingService --(hasInboundPort)--> Port|PortGroup
>> - associate which links are already configured:
>>   SwitchingService --(providesLink)--> Link|LinkGroup
>>
>> For AdaptationService (add canProve):
>>
>> - associate with static component:
>>   Port --(hasService)--> AdaptationService
>> - associate which (client layer) ports CAN be created:
>>   AdaptationService --canProvidePort--> Port|PortGroup
>> - associate which ports are already configured:
>>   AdaptationService --(providesPort)--> Port|PortGroup
>>
>>
>> Proposal 2: canProvidePort
>> ==========================
>>
>> For SwitchingService (same as current situation):
>>
>> - associate with static component:
>>   Node|Topology --(hasService)--> SwitchingService
>> - associate (between) which (ports a) link CAN be created:
>>   SwitchingService --(hasOutboundPort)--> Port|PortGroup
>>   SwitchingService --(hasInboundPort)--> Port|PortGroup
>> - associate which links are already configured:
>>   SwitchingService --(providesLink)--> Link|LinkGroup
>>
>> For AdaptationService (add canProvidePort):
>>
>> - associate with static component:
>>   Port --(hasService)--> AdaptationService
>> - associate which (client layer) ports CAN be created:
>>   AdaptationService --canProvidePort--> Port|PortGroup
>> - associate which ports are already configured:
>>   AdaptationService --(providesPort)--> Port|PortGroup
>>
>>
>> Proposal 3: Behave like a SwitchingService
>> ==========================================
>>
>> For SwitchingService (has[In|Out]boundPort is replaced with
>> canConnect[Sink|Source]Port):
>>
>> - associate with static component:
>>   Node|Topology --(hasService)--> SwitchingService
>> - associate (between) which (ports a) link CAN be created:
>>   SwitchingService --(canConnectSinkPort)--> Port|PortGroup
>>   SwitchingService --(canConnectSourcePort)--> Port|PortGroup
>> - associate which links are already configured:
>>   SwitchingService --(providesLink)--> Link|LinkGroup
>>
>> For AdaptationService (it now is provided by a Node or Topology):
>>
>> - associate with static component:
>>   Node|Topology --(hasService)--> AdaptationService
>>   AdaptationService --(hasServerSinkPort)--> Port
>>   AdaptationService --(hasServerSourcePort)--> Port
>> - associate which client AND server layer ports CAN be created:
>>   AdaptationService --(canConnectClientSinkPort)--> Port|PortGroup
>>   AdaptationService --(canConnectClientSourcePort)--> Port|PortGroup
>> - associate which ports are already configured:
>>   AdaptationService --(providesClientSinkPort)--> Port|PortGroup
>>   AdaptationService --(providesClientSourcePort)--> Port|PortGroup
>>
>> The advantage of the later configuration is that is allows bidirectional
>> adaptations services (no more distinction between AdaptationService and
>> DeAdaptationService).
>>
>> With only minor modifications it is also possible to support inverse
>> multiplexing adaptation. I did not add this, because I'm not a big fan
>> (it adds more complexity, which can be provided with the more simple
>> experimental isParallelCompoundLink relation.)
>>
>> My opinion
>> ==========
>>
>> I would say proposal #2 is cleanest.
>>
>> What do you think?
>>
>> Freek
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg