[Nml-wg] More UML....

John Vollbrecht jrv at internet2.edu
Tue Jun 24 13:24:21 CDT 2008


Some comments and questions below --  I hope these are helpful --


On Jun 24, 2008, at 9:52 AM, Jeroen van der Ham wrote:

> 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).
>
So what exactly is an adaptation.  For example, and OTN port might  
convert things to SONET, Ethernet, and other line protocols.  Is this  
adaptation?
When I create multiple circuits over a link, some may take the next  
segment in the same protocol, some may be adapted? to a different  
protocol.

Also, what is it that keeps there to be only 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

I think a fundamental element might be a circuit  - a portion of  
resources along a path.  If this is not basic to general topology it  
is basic to DCN.  I think it is also basic to being able to measure  
and monitor circuit networks.

>
>
> ## 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_.
The way we have been using links assumes there could be many links to  
a port.  e.g. groups of VLANS that are directed to different  
endpoints (through intermediate static switches for example)

>
> To adapt traffic to and from different layers, an _Adaptation_ is  
> used. One Port can have relations with up to two Adaptations in total.
are adaptations only to layers?  how about OTN to SONET -- is that  
layers?  Perhaps -- but what layers are they?

>
>
>
> ### 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 ##

We discussed at OGF that Links have resouces that can be allocated to  
circuits (or whatever we call the ete connections between users).   
The type of resource to be allocated and the increments should be  
included.
>
> 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
I think we need a name for a network - as in interdomain networks.   
networks share external connections with other networks.
> * 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_
> * _..._<NML-schema.pdf># 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
There are two concepts of path.  One is what I think you mean here -  
a sequence of nodes and links between end points.  The other is what  
gets allocated when one creates a "circuit"  over a path.  the  
circuit includes a subset of the resources on the path, and also  
include time.

> * 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. -->
as noted above, I think we need a network concept so we can express  
the differences between ENNI, NNI and UNI links - for example.

>
> ### 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_
> * _...________________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nml-wg

John Vollbrecht, Senior Network Engineer
Internet2
office +1-734-352-4960 | mobile +1-734-395-7890





More information about the nml-wg mailing list