[Nml-wg] atributes of Services

[Freek Dijkstra]

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