[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