August 2009 - nml-wg - lists.ogf.org

Use case: a media converter (multi-layer)
by Freek Dijkstra 14 Aug '09

14 Aug '09

Hi, (I promised this weeks ago, so here it goes. I do feel sorry if you just returned form holiday to find your NML mailbox flooded by Jeroen, John, Guy and yours truly). Imagine an Ethernet media converter. (That is a very simple device with two ports: one fiber port, one copper port. It effectively converts between Ethernet over copper to Ethernet over UTP and vice versa.) Our converter is called EMC, and coverts between 1000base-T (copper) and 1000base-X (fibre). For the sake of simplicity, I will ignore that it is not really Ethernet over fibre, but Ethernet over a given wavelength over a given encoding over a fibre. (Nitpicks will be delighted to know it's 770-860 nm for 1000base-SX, 1270-1355nm for 1000base-LX, and 1550nm for 1000base-ZX/LH, and all use a 8b/10b encoding. Rejoice.) First, I assume that the following technology definitions have already been defined: Adaptation Function id urn:ieee:802.3ab urn:ieee:802.3ab name 1000base-T urn:ieee:802.3ab client layer urn:ieee:802.3-2005 urn:ieee:802.3ab server layer urn:ansi:eia-568-a Adaptation Function id urn:ieee:802.3-clause38 urn:ieee:802.3-clause38 name 1000base-LX urn:ieee:802.3-clause38 client layer urn:ieee:802.3-2005 urn:ieee:802.3-clause38 server layer urn:itu:fiber-8micron where urn:ieee:802.3-2005, urn:ansi:eia-568-a and urn:itu:fiber-8micron are layers -- I think we should define a class for this too. client layer and server layer are attributes of the Adaptation Function class. The "EMC" converter has 2 bidirectional interface, each on two layers. A NML Port is unidirectional on a single layer, so this Node has 8 Ports: Node id :emc :emc hasPort :emc:fiber_in :emc hasPort :emc:fiber_out :emc hasPort :emc:eth_fiber_in :emc hasPort :emc:eth_fiber_out :emc hasPort :emc:utp_in :emc hasPort :emc:utp_out :emc hasPort :emc:eth_utp_in :emc hasPort :emc:eth_utp_out (note: the actual identifiers will start with "urn:ogf:network:", e.g. "urn:ogf:network:example.net:emc", but that is too long, so I write ":emc") These Ports are internally interconnected as follows: Relation type deadaptation source :emc:fiber_in sink :emc:eth_fiber_in adaptation function urn:ieee:802.3-clause38 Relation type adaptation source :emc:eth_fiber_out sink :emc:fiber_out adaptation function urn:ieee:802.3-clause38 Relation type deadaptation source :emc:utp_in sink :emc:eth_utp_in adaptation function urn:ieee:802.3ab Relation type adaptation source :emc:eth_utp_out sink :emc:utp_out adaptation function urn:ieee:802.3ab Relation type cross connect source :emc:eth_fiber_in sink :emc:eth_utp_out Relation type cross connect source :emc:eth_utp_in sink :emc:eth_fiber_out Two remarks: - I needed to define an additional attribute for the adaptation and deadaptation relation. This is currently not possible in the schema. I propose we create two subclasses of Relation, Adaptation and Deadaptation, with attribute "adaptation function". The alternative is to stick the attribute in the Relation class. However, that would mean all relation carry this attribute, even the "implemented by" relation. - I did define a "cross connect" relation above. This is not necessary. Bellow are two alternatives. The second approach is longer and defines a Link. The third approach is shorter. ALTERNATIVE: Approach 2, with Link instance (The description of a switch will be similar to this one, only with a SwitchMatrix Service instead of a Link) Node id :emc :emc hasPort :emc:fiber_in :emc hasPort :emc:fiber_out :emc hasPort :emc:eth_fiber_in :emc hasPort :emc:eth_fiber_out :emc hasPort :emc:utp_in :emc hasPort :emc:utp_out :emc hasPort :emc:eth_utp_in :emc hasPort :emc:eth_utp_out Link id :emc:eth_fiber_to_utp Link if :emc:eth_utp_to_fiber Relation type deadaptation source :emc:fiber_in sink :emc:eth_fiber_in adaptation function urn:ieee:802.3-clause38 Relation type adaptation source :emc:eth_fiber_out sink :emc:fiber_out adaptation function urn:ieee:802.3-clause38 Relation type deadaptation source :emc:utp_in sink :emc:eth_utp_in adaptation function urn:ieee:802.3ab Relation type adaptation source :emc:eth_utp_out sink :emc:utp_out adaptation function urn:ieee:802.3ab Relation type source source :emc:eth_fiber_in sink :emc:eth_fiber_to_utp Relation type sink source :emc:eth_fiber_to_utp sink :emc:eth_utp_out Relation type source source :emc:eth_utp_in sink :emc:eth_utp_to_fiber Relation type sink source :emc:eth_utp_to_fiber sink :emc:eth_fiber_out ALTERNATIVE: Approach 3, compact description (in here, two ethernet Ports are merged into one) Node id :emc :emc hasPort :emc:fiber_in :emc hasPort :emc:fiber_out :emc hasPort :emc:utp_in :emc hasPort :emc:utp_out :emc hasPort :emc:eth_fiber_to_utp :emc hasPort :emc:eth_utp_to_fiber Relation type deadaptation source :emc:fiber_in sink :emc:eth_fiber_to_utp adaptation function urn:ieee:802.3-clause38 Relation type adaptation source :emc:eth_utp_to_fiber sink :emc:fiber_out adaptation function urn:ieee:802.3-clause38 Relation type deadaptation source :emc:utp_in sink :emc:eth_utp_to_fiber adaptation function urn:ieee:802.3ab Relation type adaptation source :emc:eth_fiber_to_utp sink :emc:utp_out adaptation function urn:ieee:802.3ab I don't think there is a "correct" alternative -- all are equivalent from a functional point of view. However, we can decide to strive for a uniform approach, like approach 2 (since that will look most like other Node descriptions). Finally, I have not explicitly defined the layer for each interface, because it was already apparent from the (de)adaptations. For a single layer Node, this information can not be derived (is not transitive). So there is may be necessary to make this explicit. If we make all the implicit properties explicit, approach 1 will look like: Node id :emc Port id :emc:fiber_in :emc hasPort :emc:fiber_in :emc:fiber_in atLayer urn:itu:fiber-8micron Port id :emc:fiber_out :emc hasPort :emc:fiber_out :emc:fiber_out atLayer urn:itu:fiber-8micron Port id :emc:eth_fiber_in :emc hasPort :emc:eth_fiber_in :emc:eth_fiber_in atLayer urn:ieee:802.3-2005 Port id :emc:eth_fiber_out :emc hasPort :emc:eth_fiber_out :emc:eth_fiber_out atLayer urn:ieee:802.3-2005 Port id :emc:utp_in :emc hasPort :emc:utp_in :emc:utp_in atLayer urn:ansi:eia-568-a Port id :emc:utp_out :emc hasPort :emc:utp_out :emc:utp_out atLayer urn:ansi:eia-568-a Port id :emc:eth_utp_in :emc hasPort :emc:eth_utp_in :emc:eth_utp_in atLayer urn:ieee:802.3-2005 Port id :emc:eth_utp_out :emc hasPort :emc:eth_utp_out :emc:eth_utp_out atLayer urn:ieee:802.3-2005 This defines a new attribute, atLayer, which might be defined as a Relation type if the Layer class is a subclass of Network Object. Regards, Freek

3 10

Agenda for conference call Aug 14th
by Jeroen van der Ham 14 Aug '09

14 Aug '09

Hello, Here's a quick agenda for today's conference call: - Status update of the schema document (Martin) - Status update on the urn:og:network request (Freek) - Status update on TMF membership (Guy) - Status update on the ITU-T relation (Freek?/Guy?) - Discussion of the examples sent to the mailinglist by Freek In the first place I want to discuss the examples and the terminology used for them by Freek. Second, we can also discuss G.800 diagrams - Identifying technologies I realize that this is a lot, and perhaps we can move some of it to the next call and/or the mailinglist. Jeroen.

1 0

Conference call
by Freek Dijkstra 11 Aug '09

11 Aug '09

At the previous call we decided to have the next call today: Starting Time: Thu Jul 30, 2009 at 10:00 AM, US/Eastern Duration: 1:00 To join both the web and audio conference (recommended), click here: https://edial.internet2.edu/call/0186145 If you only want to participate in the audio conference, you may dial in with the following numbers: Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0186145 Jeroen and Chin reported that they are not able to attend. There have been two items on the task list (from Jeroen's mail July 10): > Most important points: > - Next teleconference is on July 30th at the same time (16:00 european, > 10:00 eastern). > - Martin will submit his work on defining the schema in text before the > next teleconference. > - Freek will prepare some use-cases and examples on cross-connects and > adaptations, so that we can get a sense of how the schema works. I should be reprimanded for not have this ready earlier. I have a half-baked attempt of a use case on my computer right now, and will sent it later. I already did notice I'm missing the concept of There are a few other items to discuss: - John Vollbrecht has recently looked in detail to G.800 for the NSI (I am mostly familiar with G.805, a predecessort). If John attends I'm curious to hear his opinion. - Recently I have been approached by another standardisation body that did some work on our topic (they have a UML representation to describe network topology and looked at hypergraphs). While academic institutes are welcome to join for free, their standards are not available for free. How do others feel about this? I did look at the OGF guidelines, but it is not explicit. - Paola Grosso did a few (very) minor changes to deliverable #1 based on comments (I promised this over a month ago, finally, she did - THANKS!). I like to sent it to the OGF editor. Are people familiar with the procedure (I'm not entirely). - Should be try to get urn:ogf: delegated from IANA and urn:ogf:network delegated from the OGF? Is that a task for us to do? Regards, Freek Dijkstra

5 8

Use case: cross connect (single layer)
by Freek Dijkstra 10 Aug '09

10 Aug '09

Here is the use case of the cross connect (single layer). It really makes me think about my mantra: the model can be verbose, but the syntax compact. This is the (very verbose) model. As soon we finished that, we should look into compact (syntax) shortcuts for sure! Regards, Freek THREE EXAMPLE USE CASES Created 2009-07-30 by Freek Dijkstra Cross connect use case: photonic cross connect ============================================== Case: Describe a photonic cross connect, thus a MEMS device that works as an automated patch panel. Our example device is called "pxc", and has four bidirectional ports: port1, port2, port3 and port4. Currently port2 and port3 are crossed. This example will be represented by multiple instances of the UML classes. I will denote that as follows: <UML class name> <property 1> <property value> <property 2> <property value> Or -as a shortcut- <UML class name> <property 1> <property value> Let's first define the objects that describe the device itself, the cross connect service that it offers, its ports and the crossconnect: Node id urn:ogf:network:example.org:pxc SwitchingMatrixServer id urn:ogf:network:example.org:pxc:switch Port id urn:ogf:network:example.org:pxc:port1-ingress Port id urn:ogf:network:example.org:pxc:port1-egress Port id urn:ogf:network:example.org:pxc:port2-ingress Port id urn:ogf:network:example.org:pxc:port2-egress Port id urn:ogf:network:example.org:pxc:port3-ingress Port id urn:ogf:network:example.org:pxc:port3-egress Port id urn:ogf:network:example.org:pxc:port4-ingress Port id urn:ogf:network:example.org:pxc:port4-egress Link id urn:ogf:network:example.org:pxc:port2-port3 Link id urn:ogf:network:example.org:pxc:port3-port2 Now we have to relate these objects somehow. This is done with instances of the Relation class: First the relation between the device and the ports: Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port1-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port1-egress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port2-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port2-egress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port3-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port3-egress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port4-ingress Relation type hasPort from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:port4-egress The relation between the device and the Switch matrix service: (note that the current schema does not list "hasService" and "hasPort" as relation. I will add it.) Relation type hasService from urn:ogf:network:example.org:pxc to urn:ogf:network:example.org:pxc:switch The relation between the switch matrix and the interface: Relation type hasPort from urn:ogf:network:example.org:pxc:switch to urn:ogf:network:example.org:pxc:port1-ingress Relation type hasPort from urn:ogf:network:example.org:pxc:switch to urn:ogf:network:example.org:pxc:port1-egress .... Relation type hasPort from urn:ogf:network:example.org:pxc:switch to urn:ogf:network:example.org:pxc:port4-egress The relation between the Link and its ports: Relation type source from urn:ogf:network:example.org:pxc:port2-port3 to urn:ogf:network:example.org:pxc:port2 Relation type sink from urn:ogf:network:example.org:pxc:port2-port3 to urn:ogf:network:example.org:pxc:port3 Relation type source from urn:ogf:network:example.org:pxc:port3-port2 to urn:ogf:network:example.org:pxc:port3 Relation type sink from urn:ogf:network:example.org:pxc:port3-port2 to urn:ogf:network:example.org:pxc:port2 And that's it. If we want to group the two unidirectional links to a bidirectional link: BidirectionalLink id urn:ogf:network:example.org:pxc:port2-port3-vv element urn:ogf:network:example.org:pxc:port2-port3 element urn:ogf:network:example.org:pxc:port3-port2 Adaptation use case 1: WSS ========================== (follows) Adaptation use case 2: tunable laser ==================================== (follows)

4 9

"optional" call Wed 8/12 at 9 ET
by John Vollbrecht 10 Aug '09

10 Aug '09

We will have an optional call for discussing items in progress wed. A week from tomorrow we will have a regular call. Both will use the same call info Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180 Tentative agenda -- discuss relationships between NS agents - Joan, Tomohiro, Guy, John discuss context for NSI -- Guy and others discuss NML/ G.800 for NSI other? John

1 1

Use case: broadcast network (single layer)
by Freek Dijkstra 10 Aug '09

10 Aug '09

Hi all, Yet another single layer use case (sorry to procrastinate on the multi layer use case, I want to make sure that single layer is tackled before diving in the hard stuff). Let's start with a single bidirectional link (= 2 unidirectional links) between two nodes: ----------> Node A Node B <---------- Each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in The relations here are: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in a_out source Link A-B b_in sink Link A-B b_out source Link B-A a_in sink Link B-A So far, so good. Since we want to model Ethernet, I think we should be able to model broadcast networks. Imagine an old-fashioned LAN: Node A Node B | | --+-----+-------------+---+-- | | Node C Node D Again, each Node here has two (unidirectional!) interfaces: Node A hasPort a_out and a_in Node B hasPort b_out and b_in Node C hasPort c_out and c_in Node D hasPort d_out and d_in Of course each *_out is the egress port, with each *_in is the ingress port. Now how do I describe this LAN? (A) As a single link, or (B) as multiple links? Let's first try (A) as a single link: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source MyFirstLAN b_out source MyFirstLAN c_out source MyFirstLAN d_out source MyFirstLAN a_in sink MyFirstLAN b_in sink MyFirstLAN c_in sink MyFirstLAN d_in sink MyFirstLAN But is this correct? Semantically, this would imply that if a_out is sending data, it is also received by a_in. Let's also try to describe this (B) as multiple links: Node A hasPort a_out Node A hasPort a_in Node B hasPort b_out Node B hasPort b_in Node C hasPort c_out Node C hasPort c_in Node D hasPort d_out Node D hasPort d_in a_out source LAN_A b_in sink LAN_A c_in sink LAN_A d_in sink LAN_A b_out source LAN_B a_in sink LAN_B c_in sink LAN_B d_in sink LAN_B c_out source LAN_C a_in sink LAN_C b_in sink LAN_C d_in sink LAN_C d_out source LAN_D a_in sink LAN_D b_in sink LAN_D c_in sink LAN_D MyFirstLAN elements {LAN_A, LAN_B, LAN_C, LAN_D} This later description is closer to the concept of Unidirectional Link as is currently in the schema. The schema further allows grouping to a (Bidirectional) Link. That's what I added on the last line. What are your preferences? I see problems with both concepts. Regards, Freek

3 4

aggregation
by Guy Roberts 10 Aug '09

10 Aug '09

Hi Freek, I have spotted the following clause in G.800 on 'recursive partitioning'. This is an important concept an allows for what has been described in the NSI-WG as 'aggregation'. i.e the aggregation of a domain or a group of nodes (subnetwork in G.800 terms) down to a node. This is an important concept for NSI so I would like to see this incorporated into NML. >From G.800: 6.4.1 Partitioning of a topological component When addressing the partitioning of topological components, both the topological and resource aspects of the components must be considered. A subnetwork may be recursively partitioned to a degree such that the resultant subnetwork is considered to be in a single (spatial) location, and therefore further partitioning does not result in the ability to add any more precision to the location information. At this level of partitioning, the subnetwork is considered to be a node. Note that a node is not necessarily the limit of recursive partitioning, of a subnetwork. Further, depending on the network implementation, it may not be possible to partition a subnetwork to the level of a node. For example, if a subnetwork belongs to a different administration and the policy of that administration is not to allow other administrations to see internal structure, or where the subnetwork is supported by a server layer that uses destination-based forwarding as described in clause 6.5.2. Guy ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

1 0

Re: [Nml-wg] pathfinding, SF and G.80x
by Freek Dijkstra 10 Aug '09

10 Aug '09

Victor Reijs wrote to the NSI list: > I think [G.800] is a good standard to look into, indeed. As I and others > are looking at the Stitching Framework, it will be interesting to see > how this standard maps the SF [Stitching Framework]. > Luckily the ideas are quite similar (it is a unified approach and there > is a close 1 to 1 mapping of some the relevant definitions, but there > will be some difference of course and we need see how to map these). [...] > By the way the Stitching Framework is in G.800 speak: about finding out > what LI (Layer Information) makes sure that the Layer processor function > can function at an interdomain level ('interdomain' is not defined in > G.800 I think, so it is perhaps a specific abstracted 'layer relationship'). Victor, When looking at explicit multi-layer network descriptions, I have the impression that most approaches start with G.800 as the base model (or a very similar model) and then extend it in one of these two ways: - Extend the base model by adding addition properties to the model to cope with technology constraints. This is the approach taken by NDL, and Stitching Framework. - Extend the base model by making subclasses for each technology (WDM, TDM, Ethernet, IP). This is the approach taken by cNIS, GMPLS, and UNIS. The advantage of the first approach is that is is truly technology independent, which makes it very suitable for inter-domain path finding (as the algorithm does not need addition for technology specific, which is a problem if new technologies are introduced). The disadvantage of the first approach is that it is hard to model characteristics which are only suitable for a single technology. (Think about signal degradation, memory buffers, packet size, which are hard to model in a technology independent enough that it applies equally well to -let's say- wireless, TDM and Ethernet.) The advantage of the second approach is that these technology quirks can be modeled in a better way using technology-specific extensions. This makes this approach very suitable for monitoring or intra-domain path finding. The decision which approach to use will be on the agenda in the upcoming time for NML. I personally hope that it is possible to create some hybrid form, which takes the best of both approaches by describing all extensions, no matter how hard, in a generic way. I guess the stitching framework is a set in that direction, but personally I am not convinced that this really works for ALL extensions. I would be thrilled to be proven otherwise. Regards, Freek

2 1

[Fwd: Re: [Nsi-wg] G.805/G.800 applied to NSI]
by Jeroen van der Ham 05 Aug '09

05 Aug '09

Hello, I agree that G.800 is a very valuable input towards describing computer networks. However, reading through the document and the G.800 standard, I'm somewhat confused about the difference between Points and Ports. Also, I'm not entirely convinced that the authors of the G.800 are really sure on this either. Unfortunately, there is no real definition in the G.800 standard describing the relation between the Point and Port. The only thing that comes close is in the diagramatic conventions: A Point is defined as two Ports connected by a Link, all within a Subnetwork. Then they make a distinction between Access Point, Forwarding Point, Forwarding End Point and Link Point, wich are all conveniently denoted by the same symbol. What confuses me is Figure 8. According to their own diagramatic conventions, they are showing Points within Subnetworks. I assume that this is an error and that they meant to use open circles there, thus Ports. However, later on in Table 1 on Page 19 the authors seem to define that all relations are between Points, for example Adaptation is between Forwarding Points, not Ports. And to make it even more confusing there's this paragraph on page 13: > An "access relationship" transport entity is created when a > forwarding function is configured in a layer network. The ingress > access ports and egress access ports of the forwarding relationship > are identified together with any policy related to these ports. An > access relationship cannot be partitioned. The access relationship > may be established either before or after the termination is bound to > an adaptation, i.e., it may be bounded by access ports or access > points or a combination. This seems to imply you can somehow mix Points and Ports. The definition of a Link Point seems to be pretty clear, there are two paragraphs describing that: The definition of Access Group: > An access group is a group of co-located termination functions. It is > bounded by a link port that contains the individual FwEPts and the > set of individual access ports of each of the termination functions. > When the link port is bound to a subnetwork or link, it forms a link > point. And the following page contains: > The internal structure of this [transport] plane can be further > described by partitioning the largest subnetwork into smaller > subnetworks (points of flexibility) and the links that interconnect > them. The binding between a link and a subnetwork results in a link > point. (This is not directly between Port and Point, but Links are defined to be between two Ports.) Reading this, I believe that a Link Point consists of two Ports, i.e. the connector on the cable and the physical port on the device. However, I'm completely in the dark about the meanings of Forwarding (End) Points and Access Points. Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 48290531) is spam: Spam: https://mailfilter.uva.nl/b.php?i=48290531&m=b77f397351ea&c=s Not spam: https://mailfilter.uva.nl/b.php?i=48290531&m=b77f397351ea&c=n Forget vote: https://mailfilter.uva.nl/b.php?i=48290531&m=b77f397351ea&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS

1 0

Issues from NSI
by Jeroen van der Ham 05 Aug '09

05 Aug '09

Hello, The NSI had a call today and some issues came up that are important for NML. - John Vollbrecht brought up that the ITU-T G.800 standard provides a better way of describing networks than G.805. I think it is important that the NML studies the G.800 document and consider it as important input to our base model. In discussing the G.800 document in the NSI group some issues came up regarding their definitions of Points and Ports. I'll forward that to the NML list as well. - Regarding the use of the ITU-T G.800 document, it was suggested that we set up a formal relationship to the authors and WG/SG of the G.800 and G.805. Does anyone have a point of contact at the ITU-T so that we can try to arrange this? - The NSI requests that the model and syntax of NML can describe capabilities, so possible cross-connects and adaptations. I'm not completely sure whether that is a formal goal of NML, but I think we already have something with our current definition of Service. Jeroen.

1 0