[Nml-wg] More UML....
Jeroen van der Ham
vdham at uva.nl
Tue Jun 24 08:52:27 CDT 2008
Freek Dijkstra wrote:
> Here is a quick list on tasks, content outline of deliverable 2 and
> items which are still open for discussion. Jeroen will shortly mail an
> updated version of his schema.
Attached.
I've been thinking about the cardinality of the relations to Adaptation
while tidying up the schema. I came to the conclusion that a Port can
have up to two server and client relationships with Adaptations in
total. (so it can only have relations to two Adaptations).
Another point that I was thinking about: what is the cardinality of the
implementedBy relation? I think it might be *-*, but I'm not sure.
Below is a first stab at describing the schema, input is very welcome,
if not encouraged!
Jeroen.
# NML Topology Schema #
The NML Topology schema describes elements and their relations that together
form computer networks. This schema is kept intentionally simple, it
will later be extended with a multi-layer schema.
## Network Element ##
A _Network Element_ is an abstract type, the basic elements inherit from it.
The URI for the schema will be
"http://ogf.org/schema/network/base/20080208/".
Instantiated elements MUST have an _id_ attribute, which MUST be a
unique URI.
The network elements that we describe in this schema are:
* Node
* Port
* Unidirectional Link
* Group
* Service
## Node ##
A _Node_ is a machine that is connected to the network, another term
used for it is _Device_.
A Node does not have to be a physical machine, it may be a virtual
machine implemented by another machine. In this case, the
_implementedBy_ relation can be used to describe this.
<!-- We first used a Virtual and Physical subclasses. For simplicity
reasons we decided not to use them. Another advantage is that the schema
can now describe an arbitrary long chain of implementedBy's. -->
A Node is connected to the network by its ports. A Node must have a
_hasPort_ relation with one or more Ports.
The location of a node in the physical world can be described using the
_locatedAt_ relationship to a _Location_. The actual location is then
described using properties of the Location object.
### Relations of Node ###
* A _Node_ MUST have a _hasPort_ relation with one or more _Ports_.
* A _Node_ MAY have a _locatedAt_ relation with one _Location_
* A _Node_ MAY have a _implementedBy_ relation with one or more _Nodes_.
## Port ##
A _Port_ connects a _Node_ to the rest of the network, another term used
for Port is _Interface_.
A _Port_ is related to zero or one _Node_, and also has a relation with
zero, one or two (uni-directional) _Links_.
To adapt traffic to and from different layers, an _Adaptation_ is used.
One Port can have relations with up to two Adaptations in total.
### Relations of Port ###
* A _Port_ MAY have a _hasPort_ relation with one _Node_.
* A _Port_ MAY have up to two _server_ and _client_ relations with
_Adaptations_.
* A _Port_ MAY have a _client_ relation with up to two _Adaptations_.
* A _Port_ MAY have a _source_ relation with up to two _Unidirectional
Links_.
* A _Port_ MAY have a _sink_ relation with up to two _Unidirectional Links_.
## Unidirectional Link ##
As the name states, a _Unidirectional Link_ is a unidirectional link, it
provides connectivity from one _Port_ to another. These ports are
identified using the _source_ and _sink_ relationships.
A _Unidirectional Link_ SHOULD have a _capacity_ attribute which
describes the capacity of the link in bytes per second.
A Unidirectional Link MUST have an attribute _type_ which is either
_Link_ or _Crossconnect_. When the type is Link, the source and sink
MUST be of different devices. When the type is Crossconnect, the source
and sink MUST be of the same device.
### Relations of Unidirectional Link ###
* A _Unidirectional Link_ MAY have a _source_ relation with one _Port_.
* A _Unidirectional Link_ MAY have a _sink_ relation with one _Port_.
## Group ##
To describe collections of network elements, there is a group element.
Any element defined above can be part of a group, including another group.
We also define a set of special groups:
* Link
* Path
* Topology
* Domain
### Link ###
A _Link_ is a special group, it is a group of two _Unidirectional
Links_, which together form a bidirectional link between two ports.
### Topology ###
A _Topology_ is a group of network elements with the restriction that
this group must be connected.
<!-- At first this was called a Network, then Graph Network. Finally the
term Topology was suggested to avoid the confusion surrounding the term
Network. -->
### Path ###
A _Path_ is an ordered collection of network elements.
### Domain ###
A _Domain_ is an unordered collection of network elements. The _type_
attribute can be used to define what kind of Domain is meant.
The value of the type attribute is unrestricted, but several predefined
values and their meaning are given below:
* _User_
* _Linking_
* _..._
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NML-schema.pdf
Type: application/pdf
Size: 44385 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20080624/ac0cb2c4/attachment-0001.pdf
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: schema.md
Url: http://www.ogf.org/pipermail/nml-wg/attachments/20080624/ac0cb2c4/attachment-0001.pl
More information about the nml-wg
mailing list