| Description |
1) PortGroup and LinkGroup
A PortGroup is an unordered set of Ports
A LinkGroup is an unordered set of Links
2) hasPort / hasLink relation
<PortGroup G> --(hasPort)--> <Port P>
<LinkGroup H> --(hasLink)--> <Link L>
In XML, the hasPort and hasLink relations are implicit. E.g. the following XML
and RDF statements are equivalent:
<nml:PortGroup id="urn:ogf:network:example.net:2012:myportgroup">
<nml:Port idRed="urn:ogf:network:example.net:2012:myport"/>
</nml:PortGroup>
@prefix nml: <http://schemas.ogf.org/nml/base/2013/10/>; .
@prefix ex: <urn:ogf:network:example.net:2012:> .
ex:myportgroup a nml:PortGroup .
ex:myportgroup nml:hasPort ex:myport .
ex:myport a nml:Port .
3) isOutboundPort, isInboundPort and providesPort relations
<Network Object O> --(isOutboundPort)--> <PortGroup G>
has the meaning:
For all Port P, where: <PortGroup G> --(hasPort)--> <Port P>:
<Network Object O> --(isOutboundPort)--> <Port P>
The same applies to isInboundPort and providesPort relations:
<Network Object O> --(isInboundPort)--> <PortGroup P>
<Service S> --(providesPort)--> <PortGroup P>
4) hasLabelGroup relation
<PortGroup G> --(hasLabelGroup)--> <Label group V>
has the meaning:
For every label v ∈ V: ∃ Port P:
<PortGroup G> --(hasPort)--> <Port P>
<Port P> --(hasLabel)--> <Label v>
The same applies to LinkGroups:
<LinkGroup G> --(hasLabelGroup)--> <Label group V>
5) isSource and isSink relations
<PortGroup G> --(isSource)--> <LinkGroup H>
has the meaning:
There is a Label group V such that:
<PortGroup G> --(hasLabelGroup)--> <Label group V>
<LinkGroup H> --(hasLabelGroup)--> <Label group V>
and for every label v ∈ V: there is a Port P and a Link L:
<PortGroup G> --(hasPort)--> <Port P>
<LinkGroup H> --(hasLink)--> <Link L>
<Port P> --(hasLabel)--> <Label v>
<Link L> --(hasLabel)--> <Label v>
<Port P> --(isSource)--> <Link L>
This is the same as the following definition (which is a bit longer, but does
not use the Label group concept):
For every Port P, where: <PortGroup G> --(hasPort)--> <Port P>,
there is a Link L, such that:
<LinkGroup H> hasLink <Link L>
<Port P> --(hasLabel)--> <Label v>
<Link L> --(hasLabel)--> <Label v>
<Port P> --(isSource)--> <Link L>
furthermore, for every Link L, where: <LinkGroup H> --(hasLink)--> <Link L>,
there is a Port P, such that:
∀ Link L ∈ LinkGroup H: ∃ Port P ∈ PortGroup G:
<PortGroup G> --(hasPort)--> <Port P>:
<Port P> --(hasLabel)--> <Label v>
<Link L> --(hasLabel)--> <Label v>
<Port P> --(isSource)--> <Link L>
The same applies to the isSink relation.
6) Identification of Ports in a PortGroup by its properties
A Port can be identified by its own (URI) identifier.
If there is a NML property (or there are NML properties) that allow unique
identification of each Port within a PortGroup, then a Port may be identified by
this property (or these properties) and the URI of the PortGroup.
A prime example is a PortGroup that contain all channels at a given multiplexing
adaptation. For example, all VLANs at a specific Ethernet interface. In that
case, a specific Port can be identified by the combination of the PortGroup URN
and the VLAN label.
The syntax for identifying a Port in a PortGroup by its properties is not
defined in NML version 1.
7) Complex PortGroups
The only properties a Port currently has are the id, name, encoding and label.
With the definition in (6), in practise, only the label (and perhaps name) can
be used to uniquely identify a Port in a PortGroup.
However, it may be useful to define a PortGroup as all outbound ports of a
Topology, which -if they are all VLAN tagged Ports- may be identified by the
Node, the Port and VLAN. Similarly, a PortGroup may be defined that contains all
Ports of a complex adaptation stack, which may be defined by the combination of
wavelength and VLAN label. However, a node is not a property of a Port, and a
Port can only have one label type (the wavelength is a property of the
underlying WDM Port, not of the VLAN Port), so according to the definition in (6
) it is not possible to identify these Ports by their NML properties. Also, it
is often not possible to create relations between such a PortGroup to other
PortGroups or LinkGroups, due to limitations in the definitions of (4) and (5)
above. It is desirable to lift these limitations.
The syntax for identifying a Port in a PortGroup by multiple properties, or non-
Port properties is not defined in NML version 1.
The following relations define a PortGroup as explained in the second example:
<Port myLink> --(hasService)--> <Service wdm>
<Service wdm> --(providesPort)--> <PortGroup myWavelengths>
<PortGroup myWavelengths> --(hasService)--> <Service 802.1q>
<Service 802.1q> --(providesPort)--> <PortGroup myVLANs>
This requires that the following relation is allowed:
<PortGroup> --(hasService)--> <Service>
(Currently only <Port> --(hasService)--> <Service> is allowed)
It is proposed to allow this relation, but mark it as "EXPERIMENTAL", meaning
that it is NOT RECOMMENDED for use in production services.
|
1) PortGroup and LinkGroup
A PortGroup is an unordered set of Ports
A LinkGroup is an unordered set of Links
2) hasPort / hasLink relation
<PortGroup G> --(hasPort)--> <Port P>
<LinkGroup H> --(hasLink)--> <Link L>
In XML, the hasPort and hasLink relations are implicit. E.g. the following XML
and RDF statements are equivalent:
<nml:PortGroup id="urn:ogf:network:example.net:2012:myportgroup">
<nml:Port idRed="urn:ogf:network:example.net:2012:myport"/>
</nml:PortGroup>
@prefix nml: <http://schemas.ogf.org/nml/base/2013/10/>; .
@prefix ex: <urn:ogf:network:example.net:2012:> .
ex:myportgroup a nml:PortGroup .
ex:myportgroup nml:hasPort ex:myport .
ex:myport a nml:Port .
3) isOutboundPort, isInboundPort and providesPort relations
<Network Object O> --(isOutboundPort)--> <PortGroup G>
has the meaning:
For all Port P, where: <PortGroup G> --(hasPort)--> <Port P>:
<Network Object O> --(isOutboundPort)--> <Port P>
The same applies to isInboundPort and providesPort relations:
<Network Object O> --(isInboundPort)--> <PortGroup P>
<Service S> --(providesPort)--> <PortGroup P>
4) hasLabelGroup relation
<PortGroup G> --(hasLabelGroup)--> <Label group V>
has the meaning:
For every label v ∈ V: ∃ Port P:
<PortGroup G> --(hasPort)--> <Port P>
<Port P> --(hasLabel)--> <Label v>
The same applies to LinkGroups:
<LinkGroup G> --(hasLabelGroup)--> <Label group V>
5) isSource and isSink relations
<PortGroup G> --(isSource)--> <LinkGroup H>
has the meaning:
There is a Label group V such that:
<PortGroup G> --(hasLabelGroup)--> <Label group V>
<LinkGroup H> --(hasLabelGroup)--> <Label group V>
and for every label v ∈ V: there is a Port P and a Link L:
<PortGroup G> --(hasPort)--> <Port P>
<LinkGroup H> --(hasLink)--> <Link L>
<Port P> --(hasLabel)--> <Label v>
<Link L> --(hasLabel)--> <Label v>
<Port P> --(isSource)--> <Link L>
This is the same as the following definition (which is a bit longer, but does
not use the Label group concept):
For every Port P, where: <PortGroup G> --(hasPort)--> <Port P>,
there is a Link L, such that:
<LinkGroup H> hasLink <Link L>
<Port P> --(hasLabel)--> <Label v>
<Link L> --(hasLabel)--> <Label v>
<Port P> --(isSource)--> <Link L>
furthermore, for every Link L, where: <LinkGroup H> --(hasLink)--> <Link L>,
there is a Port P, such that:
∀ Link L ∈ LinkGroup H: ∃ Port P ∈ PortGroup G:
<PortGroup G> --(hasPort)--> <Port P>:
<Port P> --(hasLabel)--> <Label v>
<Link L> --(hasLabel)--> <Label v>
<Port P> --(isSource)--> <Link L>
The same applies to the isSink relation.
6) Identification of Ports in a PortGroup by its properties
A Port can be identified by its own (URI) identifier.
If there is a NML property (or there are NML properties) that allow unique
identification of each Port within a PortGroup, then a Port may be identified by
this property (or these properties) and the URI of the PortGroup.
A prime example is a PortGroup that contain all channels at a given multiplexing
adaptation. For example, all VLANs at a specific Ethernet interface. In that
case, a specific Port can be identified by the combination of the PortGroup URN
and the VLAN label.
The syntax for identifying a Port in a PortGroup by its properties is not
defined in NML version 1.
7) Complex PortGroups
The only properties a Port currently has are the id, name, encoding and label.
With the definition in (6), in practise, only the label (and perhaps name) can
be used to uniquely identify a Port in a PortGroup.
However, it may be useful for a user to define a PortGroup as all outbound ports
of a Topology, which -if they are all VLAN tagged Ports- may be identified by
the Node, the Port and VLAN. Similarly, a user may define a PortGroup that
contains all Ports of a complex adaptation stack, which may be defined by the
combination of wavelength and VLAN label. However, a node is not a property of a
Port, and a Port can only have one label type (the wavelength is a property of
the underlying WDM Port, not of the VLAN Port), so according to the definition
in (6) it is not possible to identify these Ports by their NML properties. Also,
it is often not possible to create relations between such a PortGroup to other
PortGroups or LinkGroups, due to limitations in the definitions of (4) and (5)
above. It is desirable to lift these limitations.
The syntax for identifying a Port in a PortGroup by multiple properties, or non-
Port properties is not defined in NML version 1.
The following relations define a PortGroup as explained in the second example:
<Port myLink> --(hasService)--> <Service wdm>
<Service wdm> --(providesPort)--> <PortGroup myWavelengths>
<PortGroup myWavelengths> --(hasService)--> <Service 802.1q>
<Service 802.1q> --(providesPort)--> <PortGroup myVLANs>
This requires that the following relation is allowed:
<PortGroup> --(hasService)--> <Service>
(Currently only <Port> --(hasService)--> <Service> is allowed)
It is proposed to allow this relation, but mark it as "EXPERIMENTAL", meaning
that it is NOT RECOMMENDED for use in production services.
|
07/13/2012 7:45 AM EDT |
Freek Dijkstra |
