W dniu 2012-05-10 14:53, Aaron Brown pisze:

On May 10, 2012, at 7:41 AM, Freek Dijkstra wrote:

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" />

Should this be <nml:Link> and not <nml:Port> ?


If not, I'm apparently missing something obvious. If so, I'm fine with the proposal.

providesLink may not be obvious for people who will want to use NML that it is  adaptation. Of course a detailed documentation of it may solve the problem but on the other hand such things should be intuitive. Maybe still using nml:Service element,  only with type attribute and no additional info, would be better?

Roman


Cheers,
Aaron

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

Internet2 Spring Member Meeting
April 22-25, 2012 - Arlington, Virginia
http://events.internet2.edu/2012/spring-mm/



_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg