June 2008 - nml-wg - lists.ogf.org

DCN glossary
by John Vollbrecht 10 Jul '08

10 Jul '08

Attached is a DCN glossary which is part of DCN architecture and DCN reservation documents. Of particular note are some terms we use that don't seem to be in the NML schema (perhaps I am wrong?) path - a connection between a source and destination. A path is a sequence of hops. source - starting point of path - as defined by direction of signalling destination - end point of path- as defined by direction of signalling hop - a network element - [domain or node or port or link] path segment - subset of a path consisting of two or more hops circuit - a connection between tow endpoints that can be used to transmit data between them I note that in the glossary some information is assumed, in at least some of the definitions. In particular, a path (perhaps a DCN path) must include time/duration and resource. That is, a Link may carry multiple paths at a given time, and may carry different paths sequentially. I am wondering if this or something like it can be incorporated (or is incorporated) in NML. John John Vollbrecht, Senior Network Engineer Internet2 office +1-734-352-4960 | mobile +1-734-395-7890

7 13

Next face to face meetings: your availability required
by Paola Grosso 27 Jun '08

27 Jun '08

Hi all The meeting in Berlin has proved very useful. We are thinking of repeating the experience, and meet again in person in the coming months, if there are enough people interested/available. Can you let Martin and me know if you are planning to go, and would be willing to participate to NML-WG discussion during/around: --> The Summer ‘08 ESCC/Internet2 Joint Techs Workshop In Lincoln, Nebraska starting Sunday afternoon, July 20 and ending Thursday, July 24. --> 72nd IETF Meeting Dublin, Irelad July 27 - August 1 --> 8th Annual Global LambdaGrid Workshop Seattle, WA Ocober1 - 2 For OGF24 in Singapore (September 15-19). There will be **no** official NML-WG meeting. But we were contemplating an outreach session. I need a volunteer planning to be in Singapore to give a presentation on the group, and the latest schema. Let us know. Paola and Martin

1 0

More UML....
by Jeroen van der Ham 26 Jun '08

26 Jun '08

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/D…> 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.

7 28

Re: [Nml-wg] More UML....
by Freek Dijkstra 25 Jun '08

25 Jun '08

Jeroen van der Ham wrote: > [...] 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. Indeed. By the way: I once described a patchpanel as different "devices" and fixed fibers on the backend were described as "cross connects", thus between different "devices". I'm not sure how I would describe it nowadays -- possibly as ports with a link on each side, without a cross connect. Regards, Freek

1 0

NML-WG Meeting @ GN2 Technical Workshops Berlin
by Anand Patil 09 Jun '08

09 Jun '08

Hi, As agreed at Barcelona, a meeting room has been arranged for NML-WG during the 6th GÉANT2 Technical Workshop at Berlin. Name of session: NML Working Group meeting Date: Monday 23 June 2008 Time: Whole day (Four 90 minute sessions with breaks: 0900-1030, 1100-1300, 1400-1530, 1600-1730) Anyone wishing to attend should register at http://dyn.dfn.de/geant2reg/ As this was a last minute, it is not listed on the workshop registration. Please register for 'PS Dev' session and in the comments indicate that you will be attending the NML-WG session. There are no charges for registration or attending the meeting. The logistics info is at: http://dyn.dfn.de/geant2info/ Due to block bookings by the organisers the online booking system of the hotel may show that it is fully booked, but to my knowledge it is available. One needs to follow the instructions on the page (http://dyn.dfn.de/geant2info/) and quote the correct code. Please let the co-chairs know if you plan to attend. thanks & regards, - anand. -- ______________________________________________________________________ Anand Patil Head of Systems DANTE - www.dante.net Tel: +44 (0) 1223 371 300 Fax: +44 (0) 1223 371 371 PGP Key ID: 0xEF3D37CF 126-130 Hills Road, City House, Cambridge CB2 1PQ. UK _____________________________________________________________________

1 0

OGF 23 discussions: pictures
by Freek Dijkstra 09 Jun '08

09 Jun '08

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

2 1

domains and the Stitching Framework (SF) version 2
by Victor Reijs 03 Jun '08

03 Jun '08

Hello all of you, A few changes to the pdf file (learnt some more UML). I also added the IDC domain names in the below text. So I am looking at the classes of domains which might be important when working on Stitching (which is trying to connect different domains together by checking if they are or can be made compatible). This work has been done as part of AutoBAHN (GN2 JRA3 activity). The document that describes this Stitching Framework (SF) is here: http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_… This is already an 'old' document (1 year) and was also presented at GLIF in Japan (2006): http://www.glif.is/meetings/2006/controlplane/reijs-jra3.pdf <remember this is all before I knew UML, so it is not using that right UML terminology!> I talked with Freek and we discussed the domains that could be important for NML and I proposed to make an overview of the 'domains' (classes and objects in UML language) which are handy (but not always essential!) in the SF. The SF is just one view of reality (a use case), so there might be less classes (more objects) or more classes (less objects) when looking at all use cases of domains. At least the ones I discuss were in some way handy when talking about stitching (the ones with a * at the end look to be important for path finding and stitching). The below list comes from the above GEANT2 document (section 2.2.1) and I tried to UML-ize it (but I am really a novice on UML!). <I am still not 100% confident when to use classes, objects, attributes or values in UML, I am working on that> I tried to check the terminology used within AutoBAHN and IDC (but I did was not able to fully cover this). It also is written from the view of Bandwidth on Demand (circuits), but it can just as well work in packet switched networks, application environment and/or political levels;-) So anywhere compatibility is needed.. Remember I might use IDC and AutoBAHN as examples, but they might not have implemented it!!! I also did not check it with NMWG doc. 'Hierarchy of Characteristics', which is I assume: http://www-didc.lbl.gov/NMWG/docs/draft-ggf-nmwg-hierarchy-02.pdf ? The domain classes that play a some role in the use case, which uses the SF, are : • Termination domain This domain is where the possible path begins or ends. At least two Termination domains must exist in each path. A Termination domain can be a single workstation or a full-blown network (with demand for multiple paths). The Termination domain is not managed by the service (like AutoBAHN/IDC). It has only one 'side' (egress at start of the path and ingress at end of the path). • User domain* [AutoBAHN: UserAccessPoint?] [IDC: End-User] A User domain is a kind of the Termination domain and it is where the actual User’s system/network resides. • Linking domain* [AutoBAHN: External?] A Linking domain has known interfaces/protocols/processes and is one of the domains that make up the possible path between two Termination domains. If a proposed path (LIDP: Loose Inter-Domain Path) is possible all Linking domains together will form the actual path (SIDP: Strict Inter-Domain Path) (like AutoBAHN or IDC). A linking domain has two 'sides' (ingress and egress) • Home domain The Home domain is the domain that will accept the BoD request from a User. The Home domain does not have to be an actual Linking domain in the path; the Home domain is just the domain where the User sends his/her BoD request. So the Home domain acts as a proxy to the service and determines the Source Domain). • Source domain* [AutoBAHN: HomeDomain?] [IDC: Source/Endpoint] This is the first Linking domain that is part of the possible path. It might starts the investigation if a the BoD request can be made. • Destination domain* [AutoBAHN: LastDomain?] [IDC: Destination/Endpoint] This is the last Linking domain that is part of the possible path. It might do the path finding and feasibility evaluation of the proposed path based on all information gathered from the Linking and Termination domains. • Technology domain Linking domains can use a certain technology (such as pure optical circuits, SDH, SONET, Ethernet, etc.) in its switching/routing core. A Technology domain can allow ports to have a different technology then the Core (so adaptation taking place in the actual interface): e.g. an SDH Technology domain can have Ethernet ports. • Administrative domain [IDC: Domain] Networks fall under the strategic, tactic and operational responsibility of an entity e.g. NREN, operator, etc. Such an entity is called an Administrative domain. (Remember sometimes these three responsibilities can be done by three parties) • Provisioning domain A Provisioning domain is a Linking domain, which is defined by its provisioning methodology instead its technology. E.g. some NRENs (Administrative domain) aggregate their networks into one Provisioning domain. An example is HEAnet with its native Ethernet and an L2 MPLS VLL networks (two different Technology domains), but these two use the same NorthBound interface to form one Provisioning domain (using one tool: BLUEnet tool). Other objects of Provisioning domains are networks that use certain types of control plane or common management tool (aka north bound interface); like GMPLS, UCLP, DRAC, human NOC • Neighbouring domain A Neighbouring domain is a Linking/Termination domain that is physically connected (layer 0) to an adjacent Linking domain for the path. Neighboring domain is a Peering domain at layer 0. The proposed path (LIDP) is build of multiple Neighbouring domains. • Peering domain A Peering domain is the next domain where a certain protocol layer is terminated. This does not have to be the Neighbouring domain. For example two IP workstations interconnected with Ethernet network, the Peering domain of the IP layer are at the two workstations (User domains) which are not the directly connected Neighbouring domain. • Aggregated domain One can groom/group Administrative/Technology/Provisioning domains together over a large community and if that community acts as a single entity then we call this an Aggregated domain. UCLP is e.g. defined over many organisations, so it can be seen as a single Aggregated domain. This can also be used for groomed/grouped together networks for Premium IP (PIP) or (G)MPLS. An Aggregated domain could be a Termination or a Linking domain. Hope this helps in the discussion. I am planning to be by phone at the Tuesday meeting of OGF-NML. All the best, Victor -- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/

2 1

subscribe
by John Vollbrecht 02 Jun '08

02 Jun '08

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

1 0

Slides
by Freek Dijkstra 02 Jun '08

02 Jun '08

Given that the gridforge is down, I uploaded my slides to my own website: http://www.science.uva.nl/~fdijkstr/presentations/20080602NetworkModelling.… http://www.science.uva.nl/~fdijkstr/presentations/20080602DomainModels.pdf Regards, Freek Dijkstra

1 0