[Nml-wg] Adaptation between Links

[Jason Zurawski]

Hi Freek;

I could see the shortcut notation being made available through an 
extension (e.g. nml-lazy), but too many options will confuse things.  If 
there was the ability to capture the 16 object interaction in 3 objects, 
why would you ever waste time encoding it as such?

Thanks;

-jason

On 5/10/12 7:41 AM, thus spake Freek Dijkstra:
> I've just created a new artifact,
> https://forge.ogf.org/sf/go/artf6507
>
> Here is the full proposal.
>
>
> Adaptation is between Ports, and requires the following objects:
> * 2 Link instances
> * 4 Port instances
> * 2 Adaptation instances
> * 8 relations between these instances
> (see https://forge.ogf.org/sf/go/artf6514 for details)
>
> While the above is great to describe a topology in detail, it is
> sometimes useful to describe less detail.
>
> I propose a shortcut to define adaptation between Links:
>    Link --(providesLink)-->  Link
>
> This would only require the following objects:
> * 2 Link instances
> * 1 relation between these instances
>
> This is similar how isSerialCompoundLink also relates Link objects,
> bypassing the more tedious Link<--(isSink)-- Port --(isSource)-->  Link
> relations.
>
> Of course this is less detailed (e.g. it is not possible to describe the
> type or adaptation, or the name of the Ports). It's intended use is a
> situations where a full topology description (with all ports) is not
> required or not desirable.
>
> NML:
>
>    Link --(providesLink)-->  Link
>
> The subject (Link on the left) is on the server layer. The link of the
> right (the object) is one the client layer, and
> source and sinks of both Links MUST be related with an equal adaptation
> stack. In other words, both Links MUST span the
> same distance.
>
> For example, in the following ASCII-art, the following statements are True:
>    l0 --(providesLink)-->  l1     - True
>    l0 --(providesLink)-->  l2-2   - True
>    l1 --(providesLink)-->  l2-2   - True
> While the following statements are all False:
>    l0 --(providesLink)-->  l3     - False
>    l1 --(providesLink)-->  l3     - False
>    l2-2 --(providesLink)-->  l3   - False
>
>                              l3
>    O ----------------------------------------------->  O
>    |                                                  |
>    _                                                  _
>    V                                                  V
>    |      l2-1              l2-2             l2-3     |
>    O ------------->  O ------------->  O ------------->  O
>                     |                |
>                     _                _
>                     V                V
>                     |       l1       |
>                     O ------------->  O
>                     |                |
>                     _                _
>                     V                V
>                     |       l0       |
>                     O ------------->  O
>
>  From these requirements follows that the subject is always a terminated
> network connection (thus not a segment of a
> larger link connections), while the object is never a serial compound link.
>
> XML example:
>
>    <nml:Link
> id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm">
>      <nml:name>1530nm wave between NOR and AMS</nml:name>
>      <nml:Relation type="providesLink">
>        <nml:Port
> idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" />
>      </nml:Relation>
>    </nml:Service>
>
> RDF example:
>
>    @prefix nml:<http://example.ogf.org/schemas/nml/>; .
>    @prefix nmlrel:<http://example.ogf.org/schemas/nml-relation/>; .
>    @prefix ex:<urn:ogf:network:example.net:2012>  .
>
>    ex:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm a nml:Link ;
>      nml:name "1530nm wave between NOR and AMS" ;
>      nmlrel:providesLink ex:link:eth:NOR-AMS-0001 .
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg