|
|
|
|
|
Freek Dijkstra: 07/11/2012 8:22 PM EDT
|
| |
Comment: |
I changed the name of the proposed relation to "hasChannel".
I'm still very much in favour of allowing this, as it really allows a lot shorter topology descriptions.
The reason why this probably isn't mainstream is because network operators are customed to think as a network of "a bunch of nodes with connections
between them" rather than "a bunch of links with forwarding adjacencies between them".
A few people made it clear to me that "this was a really neat idea, but for now we're not going to get rid of Ports"
Hence, I will accept a "experimental" status for this relation, although I still very much like it to be defined by the NML-WG, so those that like to
implement it can at least use a common name/identifier for this relation.
Please comment if this "experimental" relation should be in the base draft or separately in another document.
|
| |
Action: |
Update
|
|
|
Freek Dijkstra: 07/11/2012 8:15 PM EDT
|
| |
Action: |
Update
Description changed from 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 .
to 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 .
Title changed from Adaptation between links to hasChannel relation
|
|
|
Jason Zurawski: 05/10/2012 8:19 AM EDT
|
| |
Comment: |
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?
|
| |
Action: |
Update
|
|
|
Freek Dijkstra: 05/10/2012 7:34 AM EDT
|
| |
Comment: |
Note: this is more extensive adaptation description between Ports is described in artf6514.
|
| |
Action: |
Update
|
|
|
Freek Dijkstra: 05/10/2012 7:32 AM EDT
|
| |
Action: |
Update
Status changed from Need proposal to Under discussion
|
|
|
Freek Dijkstra: 05/10/2012 7:32 AM EDT
|
| |
Action: |
Update
Description changed from 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)
to 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 .
Title changed from Define adaptation to Adaptation between links
|
|
|
Freek Dijkstra: 03/28/2012 10:33 AM EDT
|
| |
Action: |
Update
Status changed from Under discussion to Need proposal
|
|
|
|
|
|
