[Nml-wg] atributes of Services

[Jeroen van der Ham]

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.

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