Conversation about ITU concepts with Ciena folks
Jeroen van der Ham, Guy Roberts and myself had a conversation with Lyndon Ong, George Newsome and Rajender Razdan of Ciena about ITU networking recommendations. This was extremely helpful, and I thank the Ciena folks very much for their time and help. The following notes are put together by Jeroen and myself - please feel free to add or correct or question. We spend the first part of the meeting going over slides (see attachnment below) describing NSI concepts in G.800 terms. It is worth noting that George described the evolution of the recommendations as G.805 describing connection oriented networks, G. 809 attempting to extent that to connectionless networks, and then G. 800 which combines both. He also commented that the way that G.800 came to be is that "G.805 was observed to be insufficient for describing packet-switched networks (especially ethernet). Updating a standard is hard, hence a new standard." So using G.800 concepts is what is done in the slides and in discussions we have had earlier on the mailing list. G.8080 unfortunately still uses G.805 terminology, and adds some more - but is in the process of being updated/reviewed. G.8080 is also called ASON. On slide 2 it was remarked that it uses the term Subnet. This really is an abbreviation of Subnetwork, which is okay. It is probably better to use the full word subnetwork to distinguish it from IP subnets. On slide 3 and slide 6 we found that the ITU uses Link responder and Subnetwork responder as terms for the agents. On slide 5 we had a long discussion on terminology. There is a distinction between a Layer Network and a Routing Area, having to do with whether you could see the Link end or not (not completely sure?) In general George says that he thinks of them as basically the same. On slide 5 there was a discussion on the difference between a SNPP (subnetwork point pool) and a port. A SNPP is an ASON concept that is essentially the same as a link port except that a port might have multiple SNPPs. The SNPP is what is used for routing. The ASON concepts are named slightly differently than G.800. Link ports in 800 are Subnetwork ports (SNP) in 8080. George says that in casual conversation both are called ports. More on slide 5 Subnetwork is what the ITU calls it, but usually Network is used anyway when talking about it. NSI will likely switch to use the term Network for the concept that G.800 calls subnetwork. The distinction between Port and Point in G.800 is not helpful and for most intended purposes you can just use Port (for what G.800 calls a Point). The Forwarding Port seems to be fine. Forwarding point is where segments from different resources connect. In G.8080 Segment also seems okay, and is used in G.8080 for the same concept as it is used for in NSI - otherwise known as link connection and subnetwork connection in G.800. AccessPort is okay. Note that G.800 makes a clear distinction between a network connection which goes across a network, and a client connection which goes between clients (where clients connect to network). We also talked about document on multiple layers. The doc is attached The first figure in the doc seemed a normal way of describing a link on one layer being implemented on a different layer. George wanted to understand the second figure better - it shows that a network connection at one layer (ethernet layer) may include segments from another layer (SONET layer), and that there may be no link at the ethernet layer between the ethernet subnetworks. George said this was an interesting problem and that he had proposed the concept of transitional links to between ports at different layers to describe this concept. I am not sure I understand this completely, but I believe the idea is that doing this allows topology from both layers to be considered in pathfinding. This needs more thinking - at least on my part. George sent a number of documents that describe transitional links and other concepts. I am in the process of reading these still. There were some concepts indicating that GMPLS was not as good at describing multi-layer capabilities as G.800 (and possibly NML). I don't really understand precisely why. Thanks very much to all who participated.
Hi John, I note a couple of interesting (and to me) new points from the documents provided by George Newsome. As I see it, there are broadly two ways of approaching pathfinding in multi-domain, multi-layer networks: Approach 1: AutoBAHN like - the layers are collapsed into a single abstracted layer and pathfinding is done on this layer. We then perform stitching on a set of possible paths. Approach 2: path finding is done on a complete multi-layer graph with full knowledge of layer adaptations. A much more limited (if any) stitching function is then required. I think this is more like the method proposed by Freek in his thesis. The multi-layer pathfinding proposal included in the documents from George Newsome is interesting, and in my view is close to the method used by AutoBAHN, namely the topology is fattened into a single layer which assumes the presence of adaptation in each node. Pathfinding is the done on this flattened topology. The problem not addressed by George Newsome is the issues covered in Victor Reijs's stitching work. The other document of note is the transitional link document. I think we need to be careful about adopting this concept since as far as I can see it has been created by ITU-T for a very specific purpose. They use it for transit between sub-layers as opposed to adaptation between layers. In their example a transitional link is used for all-optical conversion of wavelengths, where wavelengths are not real layers as there is no termination and adaptation function when converting between wavelengths. Guy -----Original Message----- From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: 02 September 2009 21:53 To: NSI WG Cc: Network Markup Language Working Group; Rajender Razdan; Lyndon Ong; George Newsome; Jeff Verrant; Daniel Getachew Subject: [Nsi-wg] Conversation about ITU concepts with Ciena folks Jeroen van der Ham, Guy Roberts and myself had a conversation with Lyndon Ong, George Newsome and Rajender Razdan of Ciena about ITU networking recommendations. This was extremely helpful, and I thank the Ciena folks very much for their time and help. The following notes are put together by Jeroen and myself - please feel free to add or correct or question. We spend the first part of the meeting going over slides (see attachnment below) describing NSI concepts in G.800 terms. It is worth noting that George described the evolution of the recommendations as G.805 describing connection oriented networks, G. 809 attempting to extent that to connectionless networks, and then G. 800 which combines both. He also commented that the way that G.800 came to be is that "G.805 was observed to be insufficient for describing packet-switched networks (especially ethernet). Updating a standard is hard, hence a new standard." So using G.800 concepts is what is done in the slides and in discussions we have had earlier on the mailing list. G.8080 unfortunately still uses G.805 terminology, and adds some more - but is in the process of being updated/reviewed. G.8080 is also called ASON.
Hello, I agree that George's multi-layer pathfinding seems very similar to the AutoBAHN approach. Freek in his thesis argues that this approach can work, but does not have a way to handle incompatibilities. Freek uses an example where there are two ways to map Ethernet onto SONET, and the source and destination use different mappings. A path through the network will have to do a remapping along the way, otherwise it can't work. I do not see how a collapsed topology can ever solve such a problem. Perhaps it can, but it will have to specifically supported by the stitching framework. Jeroen. Guy Roberts wrote:
Hi John,
I note a couple of interesting (and to me) new points from the documents provided by George Newsome. As I see it, there are broadly two ways of approaching pathfinding in multi-domain, multi-layer networks:
Approach 1: AutoBAHN like - the layers are collapsed into a single abstracted layer and pathfinding is done on this layer. We then perform stitching on a set of possible paths.
Approach 2: path finding is done on a complete multi-layer graph with full knowledge of layer adaptations. A much more limited (if any) stitching function is then required. I think this is more like the method proposed by Freek in his thesis.
The multi-layer pathfinding proposal included in the documents from George Newsome is interesting, and in my view is close to the method used by AutoBAHN, namely the topology is fattened into a single layer which assumes the presence of adaptation in each node. Pathfinding is the done on this flattened topology. The problem not addressed by George Newsome is the issues covered in Victor Reijs's stitching work.
The other document of note is the transitional link document. I think we need to be careful about adopting this concept since as far as I can see it has been created by ITU-T for a very specific purpose. They use it for transit between sub-layers as opposed to adaptation between layers. In their example a transitional link is used for all-optical conversion of wavelengths, where wavelengths are not real layers as there is no termination and adaptation function when converting between wavelengths.
Guy
-----Original Message----- From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: 02 September 2009 21:53 To: NSI WG Cc: Network Markup Language Working Group; Rajender Razdan; Lyndon Ong; George Newsome; Jeff Verrant; Daniel Getachew Subject: [Nsi-wg] Conversation about ITU concepts with Ciena folks
Jeroen van der Ham, Guy Roberts and myself had a conversation with Lyndon Ong, George Newsome and Rajender Razdan of Ciena about ITU networking recommendations. This was extremely helpful, and I thank the Ciena folks very much for their time and help.
The following notes are put together by Jeroen and myself - please feel free to add or correct or question.
We spend the first part of the meeting going over slides (see attachnment below) describing NSI concepts in G.800 terms. It is worth noting that George described the evolution of the recommendations as G.805 describing connection oriented networks, G. 809 attempting to extent that to connectionless networks, and then G. 800 which combines both. He also commented that the way that G.800 came to be is that "G.805 was observed to be insufficient for describing packet-switched networks (especially ethernet). Updating a standard is hard, hence a new standard." So using G.800 concepts is what is done in the slides and in discussions we have had earlier on the mailing list.
G.8080 unfortunately still uses G.805 terminology, and adds some more - but is in the process of being updated/reviewed. G.8080 is also called ASON.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hello Jeroen, It is important to mention that the SF does NOT determine the path to be tested by the Stitching Framework. It assumes a pathfinder process to finds a set of paths at layer 0; the SF will determine for each individual path if it can be supported by the specific range of interface settings of each peering domain. Freek's work is at multiple levels/processes and covers more than the SF (it includes the path finding process as defined in AutoBAHN: at layer 0 being connectivity at the lowest (physical) layer. So this '0' is not a misspelling; aka it is not layer 1. Have next week a demo of the SF with Freek, so we can also cover this issue. All the best, Victor Jeroen van der Ham wrote:
Hello,
I agree that George's multi-layer pathfinding seems very similar to the AutoBAHN approach.
Freek in his thesis argues that this approach can work, but does not have a way to handle incompatibilities. Freek uses an example where there are two ways to map Ethernet onto SONET, and the source and destination use different mappings. A path through the network will have to do a remapping along the way, otherwise it can't work.
I do not see how a collapsed topology can ever solve such a problem. Perhaps it can, but it will have to specifically supported by the stitching framework.
Jeroen.
Guy Roberts wrote:
Hi John,
I note a couple of interesting (and to me) new points from the documents provided by George Newsome. As I see it, there are broadly two ways of approaching pathfinding in multi-domain, multi-layer networks:
Approach 1: AutoBAHN like - the layers are collapsed into a single abstracted layer and pathfinding is done on this layer. We then perform stitching on a set of possible paths.
Approach 2: path finding is done on a complete multi-layer graph with full knowledge of layer adaptations. A much more limited (if any) stitching function is then required. I think this is more like the method proposed by Freek in his thesis.
The multi-layer pathfinding proposal included in the documents from George Newsome is interesting, and in my view is close to the method used by AutoBAHN, namely the topology is fattened into a single layer which assumes the presence of adaptation in each node. Pathfinding is the done on this flattened topology. The problem not addressed by George Newsome is the issues covered in Victor Reijs's stitching work.
The other document of note is the transitional link document. I think we need to be careful about adopting this concept since as far as I can see it has been created by ITU-T for a very specific purpose. They use it for transit between sub-layers as opposed to adaptation between layers. In their example a transitional link is used for all-optical conversion of wavelengths, where wavelengths are not real layers as there is no termination and adaptation function when converting between wavelengths.
Guy
-----Original Message----- From: John Vollbrecht [mailto:jrv@internet2.edu] Sent: 02 September 2009 21:53 To: NSI WG Cc: Network Markup Language Working Group; Rajender Razdan; Lyndon Ong; George Newsome; Jeff Verrant; Daniel Getachew Subject: [Nsi-wg] Conversation about ITU concepts with Ciena folks
Jeroen van der Ham, Guy Roberts and myself had a conversation with Lyndon Ong, George Newsome and Rajender Razdan of Ciena about ITU networking recommendations. This was extremely helpful, and I thank the Ciena folks very much for their time and help.
The following notes are put together by Jeroen and myself - please feel free to add or correct or question.
We spend the first part of the meeting going over slides (see attachnment below) describing NSI concepts in G.800 terms. It is worth noting that George described the evolution of the recommendations as G.805 describing connection oriented networks, G. 809 attempting to extent that to connectionless networks, and then G. 800 which combines both. He also commented that the way that G.800 came to be is that "G.805 was observed to be insufficient for describing packet-switched networks (especially ethernet). Updating a standard is hard, hence a new standard." So using G.800 concepts is what is done in the slides and in discussions we have had earlier on the mailing list.
G.8080 unfortunately still uses G.805 terminology, and adds some more - but is in the process of being updated/reviewed. G.8080 is also called ASON.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
-- The HEAnet National Networking Conference 2009 – 12&13 November Registration is now open: http://www.heanet.ie/conferences/2009/ 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/
Jeroen van der Ham wrote:
I agree that George's multi-layer pathfinding seems very similar to the AutoBAHN approach.
Freek in his thesis argues that this approach can work, but does not have a way to handle incompatibilities. Freek uses an example where there are two ways to map Ethernet onto SONET, and the source and destination use different mappings. A path through the network will have to do a remapping along the way, otherwise it can't work.
I do not see how a collapsed topology can ever solve such a problem. Perhaps it can, but it will have to specifically supported by the stitching framework.
The approach that must be taken for collapsing is: - have a path find agent find multiple paths - let the stitching framework try each path in order till a valid path is found. The consequence is that in rare situations no valid path may be found, even though one might be available. If these situations are sufficiently rare, the simplification that this approach brings may outweigh the disadvantage of false negatives. So I think this may be a viable approach, even though it is different than what I have pursued so far. This is not to say I have no concerns about topology collapsing and stitching approaches. I have two concerns about the stitching framework, and one about topology collapsing. For stitching, I like to make sure there is no implicit assumption of order in network layers, or worse, that the number of network layers is fixed (e.g. as in layer 1-7 in the OSI model), or that a layer may only occur once in an adaptation stack. - layers come and go. We got rid of the ATM layer, and some people try to get rid of the SONET layer(s). However, just the same, we add (sub)layers for Ethernet and OTN. - The order can not be fixed: it is getting common to see network tunnels, e.g. Ethernet over IP over Ethernet, or simply Ethernet over Ethernet (think Q-in-Q). My concern about layer collapsing is how it handles multiplexing and inverse multiplexing. A SONET circuit in the GLIF community may carry multiple Ethernet connections. At my work, we have an immediate problem that we must describe the relations between these connections -- if the SONET circuit goes does, so will the Ethernet circuits, and our software must know this relations or we will not inform the correct customers. Therefor, we need a network description that is able to describe this relation. I have doubts that this can still work for collapsed topologies. Regards, Freek
Some notes below - this is a good conversation. I also have questions about how stitching works when making requests that cross multi-layer networks. I have taken it as a good descriptive device, but I am trying to understand how it works as a path making element. On Sep 7, 2009, at 3:33 PM, Freek Dijkstra wrote:
Jeroen van der Ham wrote:
I agree that George's multi-layer pathfinding seems very similar to the AutoBAHN approach.
Freek in his thesis argues that this approach can work, but does not have a way to handle incompatibilities. Freek uses an example where there are two ways to map Ethernet onto SONET, and the source and destination use different mappings. A path through the network will have to do a remapping along the way, otherwise it can't work.
I do not see how a collapsed topology can ever solve such a problem. Perhaps it can, but it will have to specifically supported by the stitching framework.
The approach that must be taken for collapsing is: - have a path find agent find multiple paths - let the stitching framework try each path in order till a valid path is found.
The consequence is that in rare situations no valid path may be found, even though one might be available. How is it possible to try every path and not find a valid one, if a valid one exists?
If these situations are sufficiently rare, the simplification that this approach brings may outweigh the disadvantage of false negatives. So I think this may be a viable approach, even though it is different than what I have pursued so far.
This is not to say I have no concerns about topology collapsing and stitching approaches. I have two concerns about the stitching framework, and one about topology collapsing.
For stitching, I like to make sure there is no implicit assumption of order in network layers, or worse, that the number of network layers is fixed (e.g. as in layer 1-7 in the OSI model), or that a layer may only occur once in an adaptation stack.
I don't think this is a problem, but I leave that for Victor. I am not sure what an adaptation stack is. Is it something you see over a complete path? I don't think it happens in a single device does it?
- layers come and go. We got rid of the ATM layer, and some people try to get rid of the SONET layer(s). However, just the same, we add (sub)layers for Ethernet and OTN. - The order can not be fixed: it is getting common to see network tunnels, e.g. Ethernet over IP over Ethernet, or simply Ethernet over Ethernet (think Q-in-Q). I am wondering if layers are different if they are Q-in-Q or Ethernet over IP. Seems there needs to be an adaptation between these, but the client info stays the same. It seems to me that collapsing layers where the client info stays the same and only the characteristic info changes can be useful.
Where adaptations do not exist between specific layers it seems silly (at least to me) to flatten the topology. Where adaptations are not possible between layers - one cannot adapt a VLAN portion of a fiber, at least not without another adaptation (e.g. SONET) between them.
My concern about layer collapsing is how it handles multiplexing and inverse multiplexing. A SONET circuit in the GLIF community may carry multiple Ethernet connections. At my work, we have an immediate problem that we must describe the relations between these connections -- if the SONET circuit goes does, so will the Ethernet circuits, and our software must know this relations or we will not inform the correct customers. Therefor, we need a network description that is able to describe this relation. I have doubts that this can still work for collapsed topologies.
I think this is probably a valid concern. However I don't completely understand it. Is this the case where lower layers are carrying multiplexed upper layer connections and one needs to know which upper layer connections are being carried at the lower layer so that if it fails the upper layer can be notified? If so it seems that the lower layer is a Link which carries segments of the upper layer and if it goes down the upper layer link goes down. It is then the upper layer's job to notify its users that the link is down.
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hello all of you, John Vollbrecht wrote:
The approach that must be taken for collapsing is: - have a path find agent find multiple paths - let the stitching framework try each path in order till a valid path is found.
The consequence is that in rare situations no valid path may be found, even though one might be available.
How is it possible to try every path and not find a valid one, if a valid one exists?
Would be interested why indeed it would not find it. I am more concerned that a certain path is not found. If a path is found and the technology in principle is able to make a working path, the SF should also agree with that (otherwise there is something wrong with (the implementation of) SF.
If these situations are sufficiently rare, the simplification that this approach brings may outweigh the disadvantage of false negatives. So I think this may be a viable approach, even though it is different than what I have pursued so far.
I think this approach stays a valid approach. Always good to reduce to complexity (and I think we will need to do that when abstracting a topology for pathfinding).
This is not to say I have no concerns about topology collapsing and stitching approaches. I have two concerns about the stitching framework, and one about topology collapsing.
For stitching, I like to make sure there is no implicit assumption of order in network layers, or worse, that the number of network layers is fixed (e.g. as in layer 1-7 in the OSI model), or that a layer may only occur once in an adaptation stack.
I don't think this is a problem, but I leave that for Victor. I am not sure what an adaptation stack is. Is it something you see over a complete path? I don't think it happens in a single device does it?
The SF knows no layers, it knows the concept of 'Parameter'; at what layer this is, is not defined. Can be at any level as defined by the two parties that need to negotiate it (the two peering domains). So a Parameter can be 'Available time', 'AAI information', 'Policy for access', 'Connector', 'a secret human handshake', etc. <remember: beside defining the parameter name string, the two peering domains also need to agree on the meta data as defined in SF. This thus all allows new technology to negotiate parameters [like 'inband' wavelength choice in Adva equipment and other PON stuff] over the existing infrastructure> I normally don't use OSI layers, but I still use the layered concept (as I think that is the best part of the OSI model). All the best, Victor -- The HEAnet National Networking Conference 2009 – 12&13 November Registration is now open: http://www.heanet.ie/conferences/2009/ 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/
Victor Reijs wrote:
How is it possible to try every path and not find a valid one, if a valid one exists?
Would be interested why indeed it would not find it. I am more concerned that a certain path is not found. If a path is found and the technology in principle is able to make a working path, the SF should also agree with that (otherwise there is something wrong with (the implementation of) SF.
Would the whole combination of pathfinding with the SF find the path as given in Freek's scenario? The resulting path has a loop in it, so it will not be among the paths found by any pathfinding algorithm before the stitching begins. Jeroen.
Hello Jeroen, Jeroen van der Ham wrote:
Would the whole combination of pathfinding with the SF find the path as given in Freek's scenario?
I hope so!
The resulting path has a loop in it, so it will not be among the paths found by any pathfinding algorithm before the stitching begins.
I agree this domain type of loop can cause problems with normal pathfinding, but at the end it is just a linear path, regradless of the number of loops). So it would be a good test! All the best, Victor -- The HEAnet National Networking Conference 2009 – 12&13 November Registration is now open: http://www.heanet.ie/conferences/2009/ 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/
Hi folks- The discussion below makes me think we need to explicit about the difference between the "user data payload" and the "framing protocol". The former is the information that is to be transported [unmodified] from the source to the destination within a circuit, the latter is that information placed on a link in addition to or surrounding the user data that allows the user data to be recovered or routed. The User Data Payload should always be delivered at the egress point just as it was accepted at the ingress point. But the network is free to do whatever it has to within the network to transport it (e.g. segmentation and reassembly, transport protocol adaptations, etc.) I think this explicit terminology will allow us to be clear about what is the user data payload at any point in the circuit, and what is the outer layer of transport framing protocol. I would also define two other terms: "access" framing protocol, and the "transport" framing protocol. The former defines framing protocol that delivers the user data payload to the ingress point of a circuit (or how it is delivered at the egress point), where the latter defines the framing protocol(s) used within the network to transport the user data (and of course, the latter may be different along different segments of the circuit). These terms I think will help us be clear as we discuss things like tunneling and when we encapsulate ot de-encapsulate circuit segments and protocols. Jerry John Vollbrecht wrote:
Jeroen van der Ham wrote:
- layers come and go. We got rid of the ATM layer, and some people try to get rid of the SONET layer(s). However, just the same, we add (sub)layers for Ethernet and OTN. - The order can not be fixed: it is getting common to see network tunnels, e.g. Ethernet over IP over Ethernet, or simply Ethernet over Ethernet (think Q-in-Q). I am wondering if layers are different if they are Q-in-Q or Ethernet over IP. Seems there needs to be an adaptation between these, but the client info stays the same. It seems to me that collapsing layers where the client info stays the same and only the characteristic info changes can be useful.
Where adaptations do not exist between specific layers it seems silly (at least to me) to flatten the topology. Where adaptations are not possible between layers - one cannot adapt a VLAN portion of a fiber, at least not without another adaptation (e.g. SONEHi folks-T) between them. I would agree that an Ethernet frame carried Q-in-Q would need to be adapted somehow to the EoIP environment. The router does this but you need to tell it whether to encapsulate the whole inbound ethernet frame into IP packets, or to strip the inbound [outter] ethernet frame off, and simply forawrad the Q-in-Q frame over the IP link.
I think we should distinguish between the link layer protocol which is the protocol that actually carries data on a physical link, from what I call the "access" protocol - the protocol that is used to present data at the ingress or egress points of a circuit. (There maybe other terms used for these...these are what I use). The di
My concern about layer collapsing is how it handles multiplexing and inverse multiplexing. A SONET circuit in the GLIF community may carry multiple Ethernet connections. At my work, we have an immediate problem that we must describe the relations between these connections -- if the SONET circuit goes does, so will the Ethernet circuits, and our software must know this relations or we will not inform the correct customers. Therefor, we need a network description that is able to describe this relation. I have doubts that this can still work for collapsed topologies.
I think this is probably a valid concern. However I don't completely understand it. Is this the case where lower layers are carrying multiplexed upper layer connections and one needs to know which upper layer connections are being carried at the lower layer so that if it fails the upper layer can be notified?
If so it seems that the lower layer is a Link which carries segments of the upper layer and if it goes down the upper layer link goes down. It is then the upper layer's job to notify its users that the link is down.
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
------------------------------------------------------------------------
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Guy Roberts wrote:
The other document of note is the transitional link document. I think we need to be careful about adopting this concept since as far as I can see it has been created by ITU-T for a very specific purpose. They use it for transit between sub-layers as opposed to adaptation between layers. In their example a transitional link is used for all-optical conversion of wavelengths, where wavelengths are not real layers as there is no termination and adaptation function when converting between wavelengths.
That's not completely true. As far as I see it there are two kinds of Transitional Links. The example you are referring to are sub-layer transitional links, where the connection on a single layer is not terminated, and readapted, but only the "Characteristic Information" is transformed, in this case the wavelength. There is also the Layer Transitional Link. This link does go from a client layer to a server layer, without specifying all the details. It seems to be an abstraction of a normal link with an adaptation. I am not sure whether the distinction between sub-layer and layers is actually relevant to us. So far I'm inclined to think that it is not relevant. Jeroen.
Hi Jeroen, Thanks for pointing this out - I have misunderstood the definition/use of transitional links. But now I really have a problem seeing the point of NML using transitional links. Re-reading I wonder if this is perhaps a concept only required for George's path computation on a 'flattened multi-layer topology' idea? This is what he says about this: "2.4 Transitional Links The discussion above shows that use of the G.805 link as the topological entity between nodes in a routing graph is too restrictive. We need another term to describe the node – node relationship in the network graph. In graph theory the terms node and edge or vertex and arc are used, and there is value in adopting vertex and arc (or edge) to avoid confusion. Nodes frequently designate equipment. Inspection of the figure suggests that the links that are important when considering pruning are those links whose CI changes along the link (L1, L2 and L3). L1 and L3 convert CI from the client to the server (and back again) while L2 converts server CI to client at each end. If we include those links, we have a connected graph at the client CI. If we remove those links then we have the server topology left over. It seems that we are perhaps better off retaining the term link, because it has been use so long, and introducing the term transitional link for those links which change CI along the link. This should give us some strong hints when looking for appropriate link semantics." If path computation is the only proposed use for transitional links then I am not sure that we need to use the concept in NML, or are we proposing another use that I have missed? Guy -----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 04 September 2009 19:13 To: Guy Roberts Cc: John Vollbrecht; NSI WG; Network Markup Language Working Group Subject: Re: [Nml-wg] [Nsi-wg] Conversation about ITU concepts with Ciena folks Guy Roberts wrote:
The other document of note is the transitional link document. I think we need to be careful about adopting this concept since as far as I can see it has been created by ITU-T for a very specific purpose. They use it for transit between sub-layers as opposed to adaptation between layers. In their example a transitional link is used for all-optical conversion of wavelengths, where wavelengths are not real layers as there is no termination and adaptation function when converting between wavelengths.
That's not completely true. As far as I see it there are two kinds of Transitional Links. The example you are referring to are sub-layer transitional links, where the connection on a single layer is not terminated, and readapted, but only the "Characteristic Information" is transformed, in this case the wavelength. There is also the Layer Transitional Link. This link does go from a client layer to a server layer, without specifying all the details. It seems to be an abstraction of a normal link with an adaptation. I am not sure whether the distinction between sub-layer and layers is actually relevant to us. So far I'm inclined to think that it is not relevant. Jeroen.
Hello Guy, Guy Roberts wrote:
Thanks for pointing this out - I have misunderstood the definition/use of transitional links. But now I really have a problem seeing the point of NML using transitional links. Re-reading I wonder if this is perhaps a concept only required for George's path computation on a 'flattened multi-layer topology' idea? This is what he says about this:
I think that one of the NSI use-cases for the NML schema is that it should be able to provide a topology for pathfinding. One that is as abstract and simplified as possible, while still allowing for multi-layer pathfinding. I'm not sure wheter the Transitional Link is a good solution for this or not. We should try to pursue this idea further. Jeroen.
comment below On Sep 7, 2009, at 5:45 AM, Guy Roberts wrote:
Hi Jeroen,
Thanks for pointing this out - I have misunderstood the definition/ use of transitional links. But now I really have a problem seeing the point of NML using transitional links. Re-reading I wonder if this is perhaps a concept only required for George's path computation on a 'flattened multi-layer topology' idea? This is what he says about this:
"2.4 Transitional Links
The discussion above shows that use of the G.805 link as the topological entity between nodes in a routing graph is too restrictive. We need another term to describe the node – node relationship in the network graph. In graph theory the terms node and edge or vertex and arc are used, and there is value in adopting vertex and arc (or edge) to avoid confusion. Nodes frequently designate equipment.
Inspection of the figure suggests that the links that are important when considering pruning are those links whose CI changes along the link (L1, L2 and L3). L1 and L3 convert CI from the client to the server (and back again) while L2 converts server CI to client at each end. If we include those links, we have a connected graph at the client CI. If we remove those links then we have the server topology left over. It seems that we are perhaps better off retaining the term link, because it has been use so long, and introducing the term transitional link for those links which change CI along the link. This should give us some strong hints when looking for appropriate link semantics."
If path computation is the only proposed use for transitional links then I am not sure that we need to use the concept in NML, or are we proposing another use that I have missed?
I think that transitional link is a way of flattening topology where it is possible to do adaptations between layers. It requires that a device be represented at both layers and have a link between layers with a specific adaptation. When doing pathfinding using such links one must be sure adaptations and deadaptations match such that the client info is passed through. I think this concept is highly useful for describing a "routing area" over which pathfinding can be done. We should consider this relative to other methods of pathfinding which seem more difficult to use in practice. John
Guy
-----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 04 September 2009 19:13 To: Guy Roberts Cc: John Vollbrecht; NSI WG; Network Markup Language Working Group Subject: Re: [Nml-wg] [Nsi-wg] Conversation about ITU concepts with Ciena folks
Guy Roberts wrote:
The other document of note is the transitional link document. I think we need to be careful about adopting this concept since as far as I can see it has been created by ITU-T for a very specific purpose. They use it for transit between sub-layers as opposed to adaptation between layers. In their example a transitional link is used for all-optical conversion of wavelengths, where wavelengths are not real layers as there is no termination and adaptation function when converting between wavelengths.
That's not completely true. As far as I see it there are two kinds of Transitional Links. The example you are referring to are sub-layer transitional links, where the connection on a single layer is not terminated, and readapted, but only the "Characteristic Information" is transformed, in this case the wavelength.
There is also the Layer Transitional Link. This link does go from a client layer to a server layer, without specifying all the details. It seems to be an abstraction of a normal link with an adaptation.
I am not sure whether the distinction between sub-layer and layers is actually relevant to us. So far I'm inclined to think that it is not relevant.
Jeroen.
John Vollbrecht wrote:
comment below On Sep 7, 2009, at 5:45 AM, Guy Roberts wrote:
If path computation is the only proposed use for transitional links then I am not sure that we need to use the concept in NML, or are we proposing another use that I have missed?
I think that transitional link is a way of flattening topology where it is possible to do adaptations between layers. It requires that a device be represented at both layers and have a link between layers with a specific adaptation. When doing pathfinding using such links one must be sure adaptations and deadaptations match such that the client info is passed through.
I think this concept is highly useful for describing a "routing area" over which pathfinding can be done. We should consider this relative to other methods of pathfinding which seem more difficult to use in practice.
John
Hmmm...I guess I am confused. I thought transitional links *were* adaptation components of the topology (and vice versa). A selected path that transited/transitioned an adaptation componet had to configure that adaptation at provisioning time; I think though, whatever you call it or where ever it is in the topology, transitional links / adaptation components function differently in two different situations: a) Encapsulation, and b) stitching. The former, is a "vertical" transition where the upper layer protocol is tunneled in its entirety through the lower layer protocol (ala IP/Ethernet, or Ethernet/sonet (via GFP adaptation) ) and must have a matching decapsulation function at the egress, and the latter is more "horizontal" transition where the current transport protocol is stripped in its entirety leaving only the user data payload which is then placed in the next transport protocol for forwarding (the stitching adaptation does not require a matching function at its egress point - only whatever it needs for the next stage). Does this jive with the discussion and other papers on these concepts? Jerry
Jerry Sobieski wrote:
Hmmm...I guess I am confused. I thought transitional links *were* adaptation components of the topology (and vice versa). A selected path that transited/transitioned an adaptation componet had to configure that adaptation at provisioning time;
As far as I understand it Transitional Links were introduced to create an abstraction of the adaptation and links underneath it.
I think though, whatever you call it or where ever it is in the topology, transitional links / adaptation components function differently in two different situations: a) Encapsulation, and b) stitching. The former, is a "vertical" transition where the upper layer protocol is tunneled in its entirety through the lower layer protocol (ala IP/Ethernet, or Ethernet/sonet (via GFP adaptation) ) and must have a matching decapsulation function at the egress, and the latter is more "horizontal" transition where the current transport protocol is stripped in its entirety leaving only the user data payload which is then placed in the next transport protocol for forwarding (the stitching adaptation does not require a matching function at its egress point - only whatever it needs for the next stage). Does this jive with the discussion and other papers on these concepts?
If I understand correctly the distinction you make has already been proposed by Guy earlier: forwarding (your "vertical") and switching ("horizontal"). Jeroen.
On Sep 8, 2009, at 12:26 PM, Jerry Sobieski wrote:
John Vollbrecht wrote:
comment below On Sep 7, 2009, at 5:45 AM, Guy Roberts wrote:
If path computation is the only proposed use for transitional links then I am not sure that we need to use the concept in NML, or are we proposing another use that I have missed?
I think that transitional link is a way of flattening topology where it is possible to do adaptations between layers. It requires that a device be represented at both layers and have a link between layers with a specific adaptation. When doing pathfinding using such links one must be sure adaptations and deadaptations match such that the client info is passed through.
I think this concept is highly useful for describing a "routing area" over which pathfinding can be done. We should consider this relative to other methods of pathfinding which seem more difficult to use in practice.
John
Hmmm...I guess I am confused. I thought transitional links *were* adaptation components of the topology (and vice versa). A selected path that transited/transitioned an adaptation componet had to configure that adaptation at provisioning time; I think though, whatever you call it or where ever it is in the topology, transitional links / adaptation components function differently in two different situations: a) Encapsulation, and b) stitching. The former, is a "vertical" transition where the upper layer protocol is tunneled in its entirety through the lower layer protocol (ala IP/ Ethernet, or Ethernet/sonet (via GFP adaptation) ) and must have a matching decapsulation function at the egress, and the latter is more "horizontal" transition where the current transport protocol is stripped in its entirety leaving only the user data payload which is then placed in the next transport protocol for forwarding (the stitching adaptation does not require a matching function at its egress point - only whatever it needs for the next stage). Does this jive with the discussion and other papers on these concepts?
Probably we are both confused. Jeroen and I have had a long conversation about transitional links and I think he and I agree (at least temporarily) on how they might work between layers. I think your distinction between a case where client data is encapsulated in one form (e.g. VLAN) on one layer and in a different form on another (e.g. SONET). In one method the VLAN is encapsulated as ethernet in GFP and carried in SONET. In this case the encapsulation and decapsulation coming in and out of SONET need to match. In the second method the client data is encapsulated in VLAN, decapsulated between layers and re-encapsulated in SONET. When in leaves SONET it might go directly to a user, or might be encapsulated in a different layer. There does not need to be matching encapsulation and decapsulation, everything get converted back to basic Client Information then encapsulated in a different layer. Are these your distinctions or is it something else. If so - I don' t think it matches the papers, but it is a very interesting concept :) John
Jerry
Guy Roberts wrote:
As I see it, there are broadly two ways of approaching pathfinding in multi-domain, multi-layer networks:
Approach 1: AutoBAHN like - the layers are collapsed into a single abstracted layer and pathfinding is done on this layer. We then perform stitching on a set of possible paths.
Approach 2: path finding is done on a complete multi-layer graph with full knowledge of layer adaptations. A much more limited (if any) stitching function is then required. I think this is more like the method proposed by Freek in his thesis.
Guy, your analysis is spot on. Thank you for your insight. The notes on "Conversation about ITU concepts with Ciena folks" contained:
There were some concepts indicating that GMPLS was not as good at describing multi-layer capabilities as G.800 (and possibly NML). I don't really understand precisely why.
John Vollbrecht added (off-list):
I would love to have you or someone make a more specific/detailed critique of GMPLS. Is it just for layers that it has problems?
It is just the fact that GMPLS does not represent the relation between links on different layers explicitly. This give problems in either of these situations: - incompatible adaptation functions (e.g. GFP-F vs. LEX or Q-in-Q vs. PBB-TE) - multiplexing and inverse multiplexing Basically: it gives problems whenever the collapse as describe in approach #1 above leads to loss of information in the resulting graph (indeed, I proved that there are -rare- network topologies where any possible collapse must lead to loss of information.) Regards, Freek
participants (6)
-
Freek Dijkstra -
Guy Roberts -
Jeroen van der Ham -
Jerry Sobieski -
John Vollbrecht -
Victor Reijs