[Nml-wg] atributes of Services

[Roman Łapacz]

W dniu 2012-10-01 15:45, Roman Łapacz pisze:
> 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.

No objections mean that option 2 is accepted so we can update the schema 
and close this issue?

Roman

>
> 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
>
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg