Description |
Adaptation is between Ports, and requires the following objects:
* 2 Link instances
* 4 Port instances
* 2 Adaptation instances
* 8 relations between these instances
I propose a shortcut to define adaptation between Links, similar how
isSerialCompoundLink also relates Link objects, bypassing the more tedious Link
<--(isSink)-- Port --(isSource)--> Link relations.
This would only require the following objects:
* 2 Link instances
* 1 relation between these instances
This can be used in situations where a full topology description (with all ports
) is not required. Of course this is less detailed (e.g. it is not possible to
describe the type or adaptation, or the name of the Ports)
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 .
|
Adaptation is between Ports, and requires the following objects:
* 2 Link instances
* 4 Port instances
* 2 Adaptation instances
* 8 relations between these instances
I propose a shortcut to define adaptation between Links, similar how
isSerialCompoundLink also relates Link objects, bypassing the more tedious Link
<--(isSink)-- Port --(isSource)--> Link relations.
This would only require the following objects:
* 2 Link instances
* 1 relation between these instances
This can be used in situations where a full topology description (with all ports
) is not required. Of course this is less detailed (e.g. it is not possible to
describe the type or adaptation, or the name of the Ports)
NML:
Link --(hasChannel)--> 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 --(hasChannel)--> l1 - True
l0 --(hasChannel)--> l2-2 - True
l1 --(hasChannel)--> l2-2 - True
While the following statements are all False:
l0 --(hasChannel)--> l3 - False
l1 --(hasChannel)--> l3 - False
l2-2 --(hasChannel)--> 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="hasChannel">
<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:hasChannel ex:link:eth:NOR-AMS-0001 .
|
07/11/2012 8:15 PM EDT |
Freek Dijkstra |
Description |
Is the adaptation between links or between ports, or either? Is adaptation a
relation or a separate transport entity, like a link (which can have more
associated properies, such as type of adaptation, or type of protection/link
aggregation)
|
Adaptation is between Ports, and requires the following objects:
* 2 Link instances
* 4 Port instances
* 2 Adaptation instances
* 8 relations between these instances
I propose a shortcut to define adaptation between Links, similar how
isSerialCompoundLink also relates Link objects, bypassing the more tedious Link
<--(isSink)-- Port --(isSource)--> Link relations.
This would only require the following objects:
* 2 Link instances
* 1 relation between these instances
This can be used in situations where a full topology description (with all ports
) is not required. Of course this is less detailed (e.g. it is not possible to
describe the type or adaptation, or the name of the Ports)
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 .
|
05/10/2012 7:32 AM EDT |
Freek Dijkstra |