Hi all, OGF was very useful, at least to me, and a LOT of papers notes were scribbled scribbled in discussions after the session. I took the liberty of recreating an electronic copy of a few of these pictures. You will find them attached. Slide 1: Node Virtualization ---------------------------- During the session, we had a discussion about physical versus virtual nodes. Later, it turned out we had to distinguish two different concepts: a) partitioning of devices into multiple logical devices. Typically, control of each logical part will be given to another party. b) abstraction of multiple device and expose it as one single device (for example, Raptor switches and multi-chassis routers do this). In the picture, the green boxes are physical devices -- real hardware, a chassis. The blue boxes in the physical devices represent logical partitionings, referred to as "virtual nodes". Note: We first used the terms "nodes" for logical nodes and "device" for physical devices. Later we agreed that "node" and "device" should be interchangeable, and we should refer to "physical nodes" and "virtual nodes" (or "physical device" and "virtual device"). The parent concept is called "node". A group of nodes (either virtual nodes or physical nodes) can be exposed as an abstracted thing that behaves as if it was a device (with interfaces, capabilities, etc.). This is a "network", or "graph", since it must behave as a connected graph (thus there is a implicit assumption that data can be transported between any two interfaces of the same graph/network. Slides 2+3: Node Relations -------------------------- This slide gives the relationship between node and network, and between virtual and physical nodes. Each node has an attributed "implemented". If this is undefined, it is a physical device. If it is set, it means that this is a virtual node, which is a partition of the referred instance. Note: this schema only gives the relations between classes (one to many, many to one). In this example, the "implemented" attributed is a many to one attribute; the others are one to many. To convert this to a relational database, it is much more convenient to use many to one than one to many attributes. I suggest we follow that practice in the final schema. Slides 3 is a variant of slides 2. In here, virtual node and physical node are subclasses of the base node class. This is useful if one of them has attributes that the other does not. I put location in there, but that may be a bad example. The network/graph abstraction has interfaces, just like regular nodes. These can be inferred (derived) from the original nodes in the network. Therefor, this is not an attribute, but a function that calculate the edge interfaces of the network. Of course, in (XML or RDF) messages, this relation is explicit -- it just is implied in a database (to avoid internal inconsistencies). Slide 4: Networks ----------------- There are two concepts of the term "network". Martin Swany noted that in the IP world, the word "network" has a very well defined meaning, the "link local" network between routers. The definition which was proposed in the session by Pascale Primet was that of a connected graph. This is what is meant by "network" when people talk about e.g. the "Internet2 network" or "the SURFnet network". John Vollbrecht proposed to use the term "multi-point link" for a IP-terminology "network", and use the term "network" for the graph-like "network". This image attempts to show the two terms in a single picture. While the definition was agreed upon, the term was not. We may use "G-Network" (for graph-like network) and "I-Network" (for IP-term network) until we decide on this. Slide 5+6+7: G.805 Functional Elements -----------==------------------------- We had a discussion on the terms "link", "path" and "connection". In particular, it should be noted that a path on a lower layer is a link on a higher layer. For example, an IP "link" may in fact cross a while DWDM network, or Ethernet network. G.805 defines exactly this. This slide re-iterates the terminology of G.805. Slide 6 relates this to "our" terminology: - link = G.805 link connection - path = G.805 network connection - circuit = G.805 trail A trail is a terminated network connections (thus with error correction, retransmission, etc.). John Vollbrecht likes the distinction between these two terms, but there was no consensus for that. Slide 7 is a picture I added to explain G.805 for those really interested (including subnetworks and multiplexing adaptation). Ask me if you are interested. Groups ------ (not in the slide pictures) We agreed that we should keep the concept of group, and that path and domain, and perhaps also network are specific types of groups. Function/Service ---------------- Martin Swany argued that adaptations and cross connects are functions or services in a node. This was not extensively discussed in the group itself, but in general the idea was met in favour. Note: it is not clearly defined yet what a service or function is. For example, if it is a transport function between ports, this includes adaptations, cross connects and link connections. An alternative is to reserve the term only for operations within a node (thus excluding link connections). Regards, Freek Dijkstra