Hello, I've gone through the available notes of the meetings at OGF 23, and I've compiled a UML diagram of what I think we have agreed on: http://forge.ogf.org/sf/sfmain/do/downloadAttachment/projects.nml-wg/wiki/De... I've also updated the Deliverable_2 part of the wiki to reflect what we have decided at OGF 23. The diagram is not complete, I'm not 100% sure what we have decided what kind of domains there would be. But at least this shows where to place it, and what we have so far agreed upon. Jeroen.
Today, we had a fruitful interim meeting in Berlin, discussing the NML schema. We progressed quite a bit further, mostly deciding on named, adding adaptation and cross connects. 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. Tasks ----- We will use a subversion repository with docbook. Martin re-re-request the status of this request. Base namespace is http://ogf.org/schema/network/base/20080802/ or http://ogf.org/schema/network/topology/base/20080802/ We use http: instead of urn:ogf.org: since the URL could contain more information about the schema Deliverable 2 ------------- Contents - Overview/Introduction - Schema Picture - Element Descriptions - Relation to NM-WG schema Extensions of current schema ---------------------------- network elements: - cross connects - broadcast segments (subnet, multicast network, unidirectional link, bidirectional link) - adaptations grouping: - topology: unordered set of nodes (and edges interfaces? or is that derived) - path: ordered set of edges? But how to describe a multilayer path? implicit? - domain: unordered set of nodes, interfaces, links. type? Capability/time-information Regards, Freek
Aaron Brown wrote:
We progressed quite a bit further, mostly deciding on named, adding adaptation and cross connects.
What are the semantics of the adaptation element?
As for the semantics -- it is a combination of the adaptation and termination function as defined in G.805. But in the discussion we mostly used a bit less formal terms, something along the lines of "an upper (layer) port is 'implemented by' a lower (layer) port". We didn't extensively discussed the semantic definitions, but rather used a few examples to verify if our class interrelations are correct. Basically, an adaptation is a class, which is connected to 1..* client layer ports and 1..* server layer ports. Furthermore, each port can be the client layer port of 0..2 adaptations and the server layer port of 0..2 adaptations. But in particular the 0..2 is open for discussion. (If you are interested, ask, but I need pictures to explain why it is 0..2 instead of 0..1 and how we can limit this to 0..1 at the cost of defining more ports). Regards, Freek
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_ * _..._ # 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_ * _..._
* A _Node_ MUST have a _hasPort_ relation with one or more _Ports_. Could we not have an unconnected node? e.g. describing all the hosts in a domain, one might have had its NICs removed, but you still want to account for its existence. * A _Node_ MAY have a _implementedBy_ relation with one or more _Nodes_. Might a node be "implementedBy" a complex topology? E.g. a POP or similar. So you could have a node that is "implementedBy" a network (or whatever it's being called nowadays). A _Port_ is related to zero or one _Node_, and also has a relation with zero, one or two (uni-directional) _Links_. Where does an unconnected port exist? * 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_. Does this mean that a port might be a sink for two unidirectional links? If so, under what circumstances could it occur that a port could be a sink for more than one link, but not more than two? A _Unidirectional Link_ SHOULD have a _capacity_ attribute which describes the capacity of the link in bytes per second. Not bits 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. Would it make sense to make a cross-connect a subclass of link? Seems strange to me to mix 'type' attribute differentiation with object-oriented definitions. As an actually defined schema instead of an ontology, it might make sense to simply define much of these different classes as simply 'type' attributes of the objects. This might apply to
This is a great writeup, thanks :-) Jeroen van der Ham wrote: the 'domain' object as well. Cheers, Aaron
Aaron Brown wrote:
* A _Node_ MUST have a _hasPort_ relation with one or more _Ports_.
Could we not have an unconnected node?
I concur, and would change it to zero or more Ports.
* A _Node_ MAY have a _implementedBy_ relation with one or more _Nodes_.
Might a node be "implementedBy" a complex topology? E.g. a POP or similar. So you could have a node that is "implementedBy" a network (or whatever it's being called nowadays).
A _Port_ is related to zero or one _Node_, and also has a relation with zero, one or two (uni-directional) _Links_. Where does an unconnected port exist?
* 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_.
Does this mean that a port might be a sink for two unidirectional links? If so, under what circumstances could it occur that a port could be a sink for more than one link, but not more than two?
A _Unidirectional Link_ SHOULD have a _capacity_ attribute which describes the capacity of the link in bytes per second.
Not bits per second?
GMPLS defines it in Bytes per second, and I don't see a good reason to deviate (although I also wondered why on earth they picked this strange convention). To me it's much more important to be very clear what this attribute means. For example, the actual transmission rate of 1 Gbit/s Ethernet is 1.25*10^9 Baud, which due to the 10b/8b encoding correlates to 1.00*10^9 bit/s data rate. In this case, I'd say that the capacity of the physical layer link is (1.25*10^9)/8 byte/s and the capacity of the Ethernet layer link is (1.00*10^9)/8 byte/s.
A Unidirectional Link MUST have an attribute _type_ which is either _Link_ or _Crossconnect_.
Would it make sense to make a cross-connect a subclass of link?
That is what we had at first. I think we changed because we sometimes want to explicitly say something really is a link, not a cross connect. If a cross connect is a subclass of a link, you can not do so. We briefly played with the notion of having a abstract class called "relation", of which both link, cross-connect and adaptation are subclasses.
When the type is Link, the source and sink MUST be of different devices.
This is incorrect -- you may connect two ends of a fiber to the same device. Why anyone would want to do that is a different matter, but it is possible. The underlying idea is correct though. Regards, Freek
Hi Freek, All,
Would it make sense to make a cross-connect a subclass of link?
That is what we had at first. I think we changed because we sometimes want to explicitly say something really is a link, not a cross connect. If a cross connect is a subclass of a link, you can not do so.
We briefly played with the notion of having a abstract class called "relation", of which both link, cross-connect and adaptation are subclasses.
I don't think that we were considering "link" to be a subclass of "relation". I believe that we were considering that what you're referring to as "adaptation" is sometimes a simple relation (a Layer 3 interface atop a Layer 2 interface) and sometimes an active "Service/Function". My perspective is that a cross-connect is a role/type of "link", that a an active adaptation is a "Function/Service" of type adaptation and that a L3 port atop an L2 port is a "relation". best, martin
Freek Dijkstra wrote:
MUST be of different devices.
This is incorrect -- you may connect two ends of a fiber to the same device. Why anyone would want to do that is a different matter, but it is possible. The underlying idea is correct though.
My mistake, for Link we indeed decided that it was possible to have a loopback link. However, for Crossconnect we did agree that it must be in the same device.
Hi Freek,
GMPLS defines it in Bytes per second, and I don't see a good reason to deviate (although I also wondered why on earth they picked this strange convention).
Regarding bits vs bytes: The original definitions of the RSVP TSPEC/RSPEC objects [1] used floats to represent rates and the use of IEEE single-precision floating point seems to have carried over to GMPLS. Now floats are used in both the RSVP messages as well as the OSPF TE LSAs. :-) No reason for choosing bytes vs bits is given in RFC 2212, but I would assume it is to allow for a larger range of bandwidth values to be represented as accurately as possible when using 32-bit floats since precision decreases as the exponent increases. [1] see RFC 2210, RFC 2212, and RFC 2215 (circa 09/1997)
To me it's much more important to be very clear what this attribute means. For example, the actual transmission rate of 1 Gbit/s Ethernet is 1.25*10^9 Baud, which due to the 10b/8b encoding correlates to 1.00*10^9 bit/s data rate.
In this case, I'd say that the capacity of the physical layer link is (1.25*10^9)/8 byte/s and the capacity of the Ethernet layer link is (1.00*10^9)/8 byte/s.
Similarly, in the case of DWDM systems, the physical layer on the TRIB side for 10GigE might be ((1.00*10^10)*66/64) bits/s but higher on the LINE side if g.709 FEC is being used...(which according to some descriptions of g.709 makes the line rate ~11.095 Gbps for a 10GigE w/ g.709 overhead and FEC [2]). I can understand it being useful to know which portions of the path may or may not have FEC capabilities, but it is a lot of detail to try and capture.. As an example, on the DRAGON network we have 10GigE waves across our core, some of which have FEC (using transponders) and some that don't (because they are alien waves coming from DWDM XFPs passing through our optical core). To further the example, there is an "enhanced" FEC (EFEC) mode supported by one of the commonly used g.709 chips used by many vendors [3] -- how it works exactly and whether or not the overhead is different, who knows? On our 10G transponders, we have the option to either disable FEC, enable SFEC or enable EFEC, so of course we use EFEC everywhere. ;-) [2] http://www.innocor.com/pdf_files/g709_tutorial.pdf [3] http://link.aip.org/link/?OPEGAR/42/3456/1
This is incorrect -- you may connect two ends of a fiber to the same device. Why anyone would want to do that is a different matter, but it is possible. The underlying idea is correct though.
Such a thing can be very useful for debugging and testing circuits -- we often put copper CAT5 cables between two Ethernet ports to loop traffic around a portion of the network, such that each port is set to untagged but associated with a different VLAN. We typically do not put a single piece of fiber between the Rx/Tx of a single transceiver though, but some people routinely do this for testing purposes, especially if you are just blasting packets down the line to see if they come back to you...(e.g. you are using ixia/spirent boxes which don't care about arp or you configure fake arp entries to force packets to go out a particular NIC). -Chris
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
-- Chris Tracy Mid-Atlantic Crossroads (MAX) Office phone: 301.314.6655 GPG key: 0xB3B9C93D
John Vollbrecht commented on physical links:
To me the physical link is the basic element. Virtual or logical links may exist but are built by "relations" with physical links.
When I think about network I often also reason in this way. However, I suggest not to _enforce_ that virtual links are built by relations with physical links, but only _allow_ it. For example, it should be possible to describe all links in the GLIF community (http://www.glif.is/publications/maps/). Remember that these links are *not* direct physical links. Most of them are OC-192 circuits provided by large networks such as T-Systems and Global Crossing. I do not want to _enforce_ people to first describe those underlying physical networks, although I most certainly like to _enable_ people to do so. Chris Tracy responded to my comment about link "capacity":
In this case, I'd say that the capacity of the physical layer link is (1.25*10^9)/8 byte/s and the capacity of the Ethernet layer link is (1.00*10^9)/8 byte/s.
Similarly, in the case of DWDM systems, the physical layer on the TRIB side for 10GigE might be ((1.00*10^10)*66/64) bits/s but higher on the LINE side if g.709 FEC is being used...(which according to some descriptions of g.709 makes the line rate ~11.095 Gbps for a 10GigE w/ g.709 overhead and FEC [2]). I can understand it being useful to know which portions of the path may or may not have FEC capabilities, but it is a lot of detail to try and capture..
Agreed, it is a lot of detail, and I certainly don't advocate that we force people to publish these details. I just say that we should be explicit what capacity we are referring to (payload only or with encoding/headers -- think IP MTU 1480 bytes = Ethernet MTU = 1500 bytes). The capacity I'm talking about would include the headers, not only the payload. (to describe the capacity of the payload, you must first define the payload as a channel (= logical link) inside this link, and then specify the capacity of that channel as property of that channel. As for this specific case, I don't see a compelling use case (yet) to describe FEC, but I would advocate a technology-independent model which allows one to describe this as two different sublayers, with two different link capacities (with a GFP-based adaptation between the two sublayers). Regards, Freek
Aaron Brown wrote:
* A _Node_ MUST have a _hasPort_ relation with one or more _Ports_.
Could we not have an unconnected node?
I concur, and would change it to zero or more Ports.
* A _Node_ MAY have a _implementedBy_ relation with one or more _Nodes_.
Might a node be "implementedBy" a complex topology? E.g. a POP or similar. So you could have a node that is "implementedBy" a network (or whatever it's being called nowadays).
A _Port_ is related to zero or one _Node_, and also has a relation with zero, one or two (uni-directional) _Links_. Where does an unconnected port exist?
* 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_.
Does this mean that a port might be a sink for two unidirectional links? If so, under what circumstances could it occur that a port could be a sink for more than one link, but not more than two?
A _Unidirectional Link_ SHOULD have a _capacity_ attribute which describes the capacity of the link in bytes per second.
Not bits per second?
GMPLS defines it in Bytes per second, and I don't see a good reason to deviate (although I also wondered why on earth they picked this strange convention). To me it's much more important to be very clear what this attribute means. For example, the actual transmission rate of 1 Gbit/s Ethernet is 1.25*10^9 Baud, which due to the 10b/8b encoding correlates to 1.00*10^9 bit/s data rate. In this case, I'd say that the capacity of the physical layer link is (1.25*10^9)/8 byte/s and the capacity of the Ethernet layer link is (1.00*10^9)/8 byte/s.
A Unidirectional Link MUST have an attribute _type_ which is either _Link_ or _Crossconnect_.
Would it make sense to make a cross-connect a subclass of link?
That is what we had at first. I think we changed because we sometimes want to explicitly say something really is a link, not a cross connect. If a cross connect is a subclass of a link, you can not do so. We briefly played with the notion of having a abstract class called "relation", of which both link, cross-connect and adaptation are subclasses.
When the type is Link, the source and sink MUST be of different devices.
This is incorrect -- you may connect two ends of a fiber to the same device. Why anyone would want to do that is a different matter, but it is possible. The underlying idea is correct though. Regards, Freek
Freek Dijkstra wrote:
A _Unidirectional Link_ SHOULD have a _capacity_ attribute which describes the capacity of the link in bytes per second.
Not bits per second?
GMPLS defines it in Bytes per second, and I don't see a good reason to deviate (although I also wondered why on earth they picked this strange convention).
Would it be better to have a units field to describe the units that this field is in? I'm just wary of people getting confused and entering the more common bps instead of Bps. Technically, it would violate spec, but it wouldn't be immediately obvious that something is wrong.
Would it make sense to make a cross-connect a subclass of link?
That is what we had at first. I think we changed because we sometimes want to explicitly say something really is a link, not a cross connect. If a cross connect is a subclass of a link, you can not do so.
We briefly played with the notion of having a abstract class called "relation", of which both link, cross-connect and adaptation are subclasses.
This probably opens up a bigger question of what is a "real" link? Cheers, Aaron
Aaron Brown wrote:
Freek Dijkstra wrote:
GMPLS defines [the capacity] in Bytes per second
Would it be better to have a units field to describe the units that this field is in? I'm just wary of people getting confused and entering the more common bps instead of Bps.
Good point. If you think there is a change for confusion, I'd rather like to specify bit/s instead of adding units (since that IMHO only yields unnecessary complexity of the spec)
we sometimes want to explicitly say something really is a link, not a cross connect.
This probably opens up a bigger question of what is a "real" link?
Not sure if we have to answer that. I just can imagine I want to tell my neighbours about my external links, while stressing that I'm talking about links, not cross connects. In those case, it is useful to somehow distinguish. Regards, Freek
Aaron Brown wrote:
A _Port_ is related to zero or one _Node_, and also has a relation with zero, one or two (uni-directional) _Links_. Where does an unconnected port exist?
When we define an inter-domain link we typically define a connection to an unconnected port and point to the other domain for more information about that interface. But I guess this is also a remnant of us preferring to use a relation between interfaces, instead of a link object in between. So I guess we could also require that an interface is connected to a node. What does the rest think?
* 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_. Does this mean that a port might be a sink for two unidirectional links? If so, under what circumstances could it occur that a port could be a sink for more than one link, but not more than two?
A Port typically has two uni-directional links to another device, and two uni-directional crossconnects (crossconnects are also links). So then it has two source relations and two sink relations. Freek also brought up an example where a SONET switch with an Ethernet interface. If you just look at the Ethernet Layer, this would appear as a Port with links ("actual link links") to two devices. Jeroen.
Jeroen van der Ham wrote:
So I guess we could also require that an interface is connected to a node.
What does the rest think?
I'm slightly inclined not to enforce that relation. Thus, it is allowed to define ports without its node. The use case I have in mind is a topology (aka graph aka network aka domain) with ports, without explicit nodes. The obvious downside is that we allow too much, we still end up with incompatible software, because each software tool only support a subset of what can be described. Regards, Freek
Jeroen van der Ham wrote:
* 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_.
Does this mean that a port might be a sink for two unidirectional links? If so, under what circumstances could it occur that a port could be a sink for more than one link, but not more than two?
A Port typically has two uni-directional links to another device, and two uni-directional crossconnects (crossconnects are also links). So then it has two source relations and two sink relations.
Is a cross-connect a subclass of link?
Freek also brought up an example where a SONET switch with an Ethernet interface. If you just look at the Ethernet Layer, this would appear as a Port with links ("actual link links") to two devices.
What two devices does it have an actual link to? Maybe i'm being dense? Cheers, Aaron
Hey Aaron,
A Port typically has two uni-directional links to another device, and two uni-directional crossconnects (crossconnects are also links). So then it has two source relations and two sink relations.
Is a cross-connect a subclass of link?
These are open issues. I assume that you're asking for Freek and Jeroen's opinion here, or maybe the output of the discussion. In my opinion, cross-connect is a specific type of link. Whether that is manifested as a subclass depends on whether their are structural differences in their descriptions that cause them to require different objects rather than different roles of the same object.
Freek also brought up an example where a SONET switch with an Ethernet interface. If you just look at the Ethernet Layer, this would appear as a Port with links ("actual link links") to two devices.
What two devices does it have an actual link to? Maybe i'm being dense?
I might be being dense as well, but I think this case refers to a port connecting on the internal side to a cross-connect (or the backplane) and a regular link on the outside. best, martin
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 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@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
John Vollbrecht wrote:
So what exactly is an adaptation.
See also my mail yesterday. Loosly, adaptation is the encapsulation of one data layer into another data layer. A de-adaptation is the extraction of data from that lower layer (which also terminates the lower layer path). Formally (G.800):
The adaptation source function is a labelling and encoding entity that takes one or more client communications passing through its client facing input port(s), and combines them into instances of adapted information. The adaptation source function also adds sufficient labelling in order to distinguish each client communication from all others within the scope of the access point to which the adaptation source is bound. The instances of adapted information are passed through the server facing port.
For example, and OTN port might convert things to SONET, Ethernet, and other line protocols. Is this adaptation?
Yes, if "things" is a higher layer than SONET or Ethernet.
Also, what is it that keeps there to be only two adaptations?
There is at most one adaptation per data source: that data is adapted into one or more server layer channels using ONE adaptation function. However, our ports are bidirectional, and thus have two sources and two sinks. Therefore, a port can have at most two adaptations. The same applies for links and cross connects: since there are two sources and two sinks per port, there can be two links and/or two cross connects at most. (Typically, one link and one cross connect, but I know of situations with two links) It is still open for discussion if this is the best approach. Thinking of it now, I am almost inclined to define unidirectional ports, though I think that is too verbose for most topology descriptions.
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.
I'd say 1:*, since one (virtual) node is -I think- typically implemented by a physical node. The converse, a set of nodes behaving like a virtual node is handled by the topology concept (formerly known as Graph, formerly know as Network) Regards, Freek
Freek Dijkstra wrote:
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.
I'd say 1:*, since one (virtual) node is -I think- typically implemented by a physical node.
The converse, a set of nodes behaving like a virtual node is handled by the topology concept (formerly known as Graph, formerly know as Network)
I know that Xen and VirtualPC also support a virtual machine that is actually implemented on multiple physical machines. Although Topology could handle that concept, I think that that is not entirely appropriate in this case. Jeroen.
On Jun 25, 2008, at 6:59 AM, Freek Dijkstra wrote:
John Vollbrecht wrote:
So what exactly is an adaptation.
See also my mail yesterday.
Loosly, adaptation is the encapsulation of one data layer into another data layer.
A de-adaptation is the extraction of data from that lower layer (which also terminates the lower layer path).
Formally (G.800):
The adaptation source function is a labelling and encoding entity that takes one or more client communications passing through its client facing input port(s), and combines them into instances of adapted information. The adaptation source function also adds sufficient labelling in order to distinguish each client communication from all others within the scope of the access point to which the adaptation source is bound. The instances of adapted information are passed through the server facing port.
For example, and OTN port might convert things to SONET, Ethernet, and other line protocols. Is this adaptation?
Yes, if "things" is a higher layer than SONET or Ethernet.
I think that I understand what you are saying - that a link has a single stream on it and that single stream can be adapted to some other layer. However, in multiplexed networks like DCN a link can carry many streams and each stream can be adapted differently. In fact, in an ete circuit there may be several links and each link may do a different adaptation. How does the topology describe something like this? John
John Vollbrecht wrote:
For example, and OTN port might convert things to SONET, Ethernet, and other line protocols. Is this adaptation?
Yes, if "things" is a higher layer than SONET or Ethernet.
I think that I understand what you are saying - that a link has a single stream on it and that single stream can be adapted to some other layer. However, in multiplexed networks like DCN a link can carry many streams and each stream can be adapted differently. In fact, in an ete circuit there may be several links and each link may do a different adaptation. How does the topology describe something like this?
Good question. If we talk about a "link" we actually mean a logical link, or a channel (G.805 talks about "a transport entity across a link"). Thus a fiber with different wavelenghts would be described as a link at the fiber layer, and multiple links at the WDM layer. Either only the fiber link is in the database, and the other links are "derived" from the combination of adaptation, link and de-adaptation, or they are all present in the database. The relation between these links would be an adaptation relation between the ports on each layer. In this particular case, the relation would be a multiplexing adaptation function, which is an adaptation with multiple channels on the higher layer and one on the lower layer. Each port on the WDM layer has a "client" relation with the adaptation instance. The (single) port on the fiber layer has a "server" relation with the adaptation instance. It is possible that the WDM layer ports could in turn have "server" relation with other adaptation instance, each different. Perhaps wavelength 1 carries multiple STS timeslots, while wavelength carriers Ethernet. Let me know if you like me express this example in instances of classes in the current NML schema. Regards, Freek
On Jun 25, 2008, at 11:21 AM, Freek Dijkstra wrote:
John Vollbrecht wrote:
For example, and OTN port might convert things to SONET, Ethernet, and other line protocols. Is this adaptation?
Yes, if "things" is a higher layer than SONET or Ethernet. I think that I understand what you are saying - that a link has a single stream on it and that single stream can be adapted to some other layer. However, in multiplexed networks like DCN a link can carry many streams and each stream can be adapted differently. In fact, in an ete circuit there may be several links and each link may do a different adaptation. How does the topology describe something like this?
Good question.
If we talk about a "link" we actually mean a logical link, or a channel (G.805 talks about "a transport entity across a link").
Thus a fiber with different wavelenghts would be described as a link at the fiber layer, and multiple links at the WDM layer.
Either only the fiber link is in the database, and the other links are "derived" from the combination of adaptation, link and de- adaptation, or they are all present in the database.
The relation between these links would be an adaptation relation between the ports on each layer. In this particular case, the relation would be a multiplexing adaptation function, which is an adaptation with multiple channels on the higher layer and one on the lower layer.
Each port on the WDM layer has a "client" relation with the adaptation instance. The (single) port on the fiber layer has a "server" relation with the adaptation instance.
It is possible that the WDM layer ports could in turn have "server" relation with other adaptation instance, each different. Perhaps wavelength 1 carries multiple STS timeslots, while wavelength carriers Ethernet.
Let me know if you like me express this example in instances of classes in the current NML schema.
before expressing this perhaps a little more exploration of the concepts. From what you say, I assume that a logical link between two ports would be what in DCN I call a path segment. A path segment has uses some resource on a physical link. in this case, each logical link then can have an adaptation. This is ok - but -- where is a physical link described? how do I know how a physical link can be subdivided into dynamic logical links? how do I create an ete circuit that is a concatenation of logical links. How do I name the ete circuit and treat it as an entity that is time variant? These are what seems to me to be needed for DCN, to both create reservations and circuits, and to monitor the reservations and circuits. John
Regards, Freek
John Vollbrecht, Senior Network Engineer Internet2 office +1-734-352-4960 | mobile +1-734-395-7890
John Vollbrecht wrote:
how do I know how a physical link can be subdivided into dynamic logical links? how do I create an ete circuit that is a concatenation of logical links. How do I name the ete circuit and treat it as an entity that is time variant?
So far, we mostly looked at how to describe the state of a network. One of the next things still on the agenda is how to describe how (and perhaps by whom) this state can be changed. Naming is also not yet agreed upon. As always: input (either in the form of requirements or proposals) is welcome. Regards, Freek
Hi John, This is a great set of questions and get right at the heart of the problem.
From what you say, I assume that a logical link between two ports would be what in DCN I call a path segment. A path segment has uses some resource on a physical link. in this case, each logical link then can have an adaptation. This is ok - but --
where is a physical link described? how do I know how a physical link can be subdivided into dynamic logical links? how do I create an ete circuit that is a concatenation of logical links. How do I name the ete circuit and treat it as an entity that is time variant?
The physical link is described as another link (indicating that it is physical) and enumerating its characteristics. Next, we'd need to describe the relationship between this physical link and the logical links atop it. In our model (where "our" is the topology schema folks in perfSONAR @ Internet2) we have an element called "relation". As I think I mentioned, this is one sense of the "adaptation" concept from the NDL. At any rate, we must represent the case you're highlighting.
These are what seems to me to be needed for DCN, to both create reservations and circuits, and to monitor the reservations and circuits.
Absolutely. Hopefully, this begins to address it. best, martin
Martin -- Thanks for the note. Just to be clear, I assume your response means that answering the questions about how to describe DCN, along the lines you suggest, is part of the work plan for the NML group. Is that right or is there some group action required to make it part of the group's deliverables? John On Jun 26, 2008, at 7:03 AM, Martin Swany wrote:
Hi John,
This is a great set of questions and get right at the heart of the problem.
From what you say, I assume that a logical link between two ports would be what in DCN I call a path segment. A path segment has uses some resource on a physical link. in this case, each logical link then can have an adaptation. This is ok - but --
where is a physical link described? how do I know how a physical link can be subdivided into dynamic logical links? how do I create an ete circuit that is a concatenation of logical links. How do I name the ete circuit and treat it as an entity that is time variant?
The physical link is described as another link (indicating that it is physical) and enumerating its characteristics. Next, we'd need to describe the relationship between this physical link and the logical links atop it. In our model (where "our" is the topology schema folks in perfSONAR @ Internet2) we have an element called "relation". As I think I mentioned, this is one sense of the "adaptation" concept from the NDL. At any rate, we must represent the case you're highlighting.
These are what seems to me to be needed for DCN, to both create reservations and circuits, and to monitor the reservations and circuits.
Absolutely. Hopefully, this begins to address it.
best, martin
John Vollbrecht, Senior Network Engineer Internet2 office +1-734-352-4960 | mobile +1-734-395-7890
Hi John,
Just to be clear, I assume your response means that answering the questions about how to describe DCN, along the lines you suggest, is part of the work plan for the NML group. Is that right or is there some group action required to make it part of the group's deliverables?
I think that it's definitely part of an adequate solution for NML in my mind. I'm pretty sure that we're all on the same page there. best, martin
Martin -This seems a good discussion - thanks. -- based on the fact that describing DCN is part of what NML should be able to do, I expand on your ideas below. It seems to me that one possible result is that we generate a "view" of the schema for DCN. This view would include only the aspects of DCN that are important for creating dynamic networks - e.g. networks, nodes, ports and links in the form we use right now. One specific is that for static connections between dynamic nodes, it is good to describe the statically configured devices for monitoring and debugging purposes, but these static devices are not needed when doing pathfinding or reservations. More below. On Jun 26, 2008, at 7:03 AM, Martin Swany wrote:
Hi John,
This is a great set of questions and get right at the heart of the problem.
From what you say, I assume that a logical link between two ports would be what in DCN I call a path segment. A path segment has uses some resource on a physical link. in this case, each logical link then can have an adaptation. This is ok - but --
where is a physical link described? how do I know how a physical link can be subdivided into dynamic logical links? how do I create an ete circuit that is a concatenation of logical links. How do I name the ete circuit and treat it as an entity that is time variant?
The physical link is described as another link (indicating that it is physical) and enumerating its characteristics.
To me the physical link is the basic element. Virtual or logical links may exist but are built by "relations" with physical links. Is this wrong.
Next, we'd need to describe the relationship between this physical link and the logical links atop it. In our model (where "our" is the topology schema folks in perfSONAR @ Internet2) we have an element called "relation". As I think I mentioned, this is one sense of the "adaptation" concept from the NDL. At any rate, we must represent the case you're highlighting. I think adaptation is also a G.805 term, and is perhaps a specific type of relation.
I think the implication of what you suggest is that there needs to be a switch between links on a node. Then there needs to be a way to specify which pieces of a link switch to which pieces of a different link. Do you agree? I think each link segment may be "adapted" in a way that deals with that stream so that it can be switched at a different level (or format - is switching between SONET and Ethernet swithcing levels or just formats?) Also, I don't think there is a name for a concatenated sequence of link segments (or whatever you call them). Perhaps there is some concept that I don't know.
These are what seems to me to be needed for DCN, to both create reservations and circuits, and to monitor the reservations and circuits.
Absolutely. Hopefully, this begins to address it.
best, martin
John Vollbrecht, Senior Network Engineer Internet2 office +1-734-352-4960 | mobile +1-734-395-7890
participants (7)
-
Aaron Brown -
Chris Tracy -
Freek Dijkstra -
Freek Dijkstra -
Jeroen van der Ham -
John Vollbrecht -
Martin Swany