| |
Action: |
Update
Description changed from 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.
to 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.
|
