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