Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI
Jerry, Great slide package - you did a good job of describing the key concepts discussed on the last call. I think it is import we store these documents somewhere so people joining the list can access the most recent versions (and people like me who switch computers all the time can pull down copies). Last week at the GLIF there were a number of hallway conversations on the topic of topology. As with everything in the world people had differing opinions, but I think it was great since it did get me questioning about my position on the subject. I would like to make a couple of points for discussion: 1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional. 1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize. There are a couple of key ones we should consider for example: . Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network? . Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested? . Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find. Although I think it would be possible to describe and advertise these types of access control rules along with the internal topology for other path computation elements to utilize, they complexity of describing such data may be prohibitive. In addition, the controlling NRM would still need to evaluate any request path based on the provisioned policies and end user identity. Therefore, for simplicity I believe these routing decisions should be left up to the controlling NRM and not an external Path Computation Element. 2. Routing in both time and space. The specific point here is existing schedules/reservations are part of topology since we are routing in both space and time. I am not sure if this was explicitly stated anywhere, and from the discussions on the conference calls I definitely think people are considering spatial routing first, and the time aspect as part of the path reservation signaling. Obviously, evaluating the time aspect after a physical path has been computed is a valid solution, however, we may be able to derive more optimal solutions by incorporating existing schedules earlier in the process. Inclusion of schedules into the routing decision is how DRAC does performs path computation, but we have the distinct advantage of having all the topology for the domain and all the scheduled paths centrally located in our database. This allows for extremely fast and 100% accurate routing decisions. Obviously, distributing time-based topology is not feasible in a distributed control plane model due to the large dataset sizes, but with the summarized virtual node model we do have some opportunities for optimization due to the reduced scale of the problem. If we attach reservations to the UNI and E-NNI links reported via topology exchange for the virtual node, and use this additional information to perform path computation, we will have a high probability of reservation success the first time through if the summarized domain is fairly well connected internally. 3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-) John.
*From: *Jerry Sobieski <jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Hello John, Great to see your active participation in the NSI-WG - I sure that your experience in DRAC development will form a useful contribution to group discussion. I have followed up your suggestion and posted Jerry's contribution on NSI's Grid Forge site, you can find a copy here (This is the normal repository for contributions to the NSI working group): http://forge.gridforum.org/sf/docman/do/listDocuments/projects.nsi-wg/docman... I would also like to take the opportunity to point out the issue tracker software that we are using to keep track of decisions made by the group: http://forge.gridforum.org/sf/tracker/do/listArtifacts/projects.nsi-wg/track... Regards, Guy From: John MacAuley [mailto:john.macauley@surfnet.nl] Sent: 09 February 2010 15:37 To: nsi-wg@ogf.org; Jerry Sobieski Subject: Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI Jerry, Great slide package - you did a good job of describing the key concepts discussed on the last call. I think it is import we store these documents somewhere so people joining the list can access the most recent versions (and people like me who switch computers all the time can pull down copies). Last week at the GLIF there were a number of hallway conversations on the topic of topology. As with everything in the world people had differing opinions, but I think it was great since it did get me questioning about my position on the subject. I would like to make a couple of points for discussion: 1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional. 1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize. There are a couple of key ones we should consider for example: * Adaptation decision - at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network? * Inter-layer routing decisions - When should a new lower layer service be created to meet the additional demand of the higher layer services requested? * Policy based routing - although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find. Although I think it would be possible to describe and advertise these types of access control rules along with the internal topology for other path computation elements to utilize, they complexity of describing such data may be prohibitive. In addition, the controlling NRM would still need to evaluate any request path based on the provisioned policies and end user identity. Therefore, for simplicity I believe these routing decisions should be left up to the controlling NRM and not an external Path Computation Element. 2. Routing in both time and space. The specific point here is existing schedules/reservations are part of topology since we are routing in both space and time. I am not sure if this was explicitly stated anywhere, and from the discussions on the conference calls I definitely think people are considering spatial routing first, and the time aspect as part of the path reservation signaling. Obviously, evaluating the time aspect after a physical path has been computed is a valid solution, however, we may be able to derive more optimal solutions by incorporating existing schedules earlier in the process. Inclusion of schedules into the routing decision is how DRAC does performs path computation, but we have the distinct advantage of having all the topology for the domain and all the scheduled paths centrally located in our database. This allows for extremely fast and 100% accurate routing decisions. Obviously, distributing time-based topology is not feasible in a distributed control plane model due to the large dataset sizes, but with the summarized virtual node model we do have some opportunities for optimization due to the reduced scale of the problem. If we attach reservations to the UNI and E-NNI links reported via topology exchange for the virtual node, and use this additional information to perform path computation, we will have a high probability of reservation success the first time through if the summarized domain is fairly well connected internally. 3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-) John. From: Jerry Sobieski <jerry@nordu.net<mailto:jerry@nordu.net>> Date: February 2, 2010 2:24:10 PM EST To: "nsi-wg@ogf.org<mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org<mailto:nsi-wg@ogf.org>> Subject: [Nsi-wg] Thoughts on a basic topology model for NSI Hi all- Relative to our brief discussion last week about topology and the NSI... We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion. However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about. So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs. Comments are welcome...Its only a draft for consideration... Jerry While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org<mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
On 09/02/2010 07:37, John MacAuley wrote:
1. Aggregation and summarization.
I've done some simulations, analysis and have written a chapter about this in my thesis. My results show that aggregating a domain to a single node performs very badly compared to an aggregation model where you advertise a full mesh between edge nodes. I would also argue that the advantages of simplifying the internal domain do not balance the disadvantages you have in false positives in inter-domain pathfinding. However, these simulations have only used a single layer. We're currently looking at pathfinding in multi-layer networks, and we're thinking about how to create aggregations for multiple layers. This is a hard problem. Given the fact that current domains are not that complicated, and we have a very open culture in regards to information exchange, I would suggest that we leave the problem of aggregation open for now and just use full topologies. Jeroen.
Jeroen, I agree with the statement that the signal node model would perform more poorly for optimal path computation, but would the computation of the summarized meshed links not be a costly on an on-going basis? These meshed links would need to be updated anytime there is a reservation added to the network that could impact the availability of the existing precomputed links. I this model are you providing the summarized bandwidth available between nodes? This would be an extremely costly calculation summing all potential bandwidth. Do you have description of the mechanism used to compute the meshed topology? I wouldn't mind understanding in more detail if possible. Thank you, John. also suffer from being "potentially possible" topology, in that On 10-02-09 12:23 PM, Jeroen van der Ham wrote:
On 09/02/2010 07:37, John MacAuley wrote:
1. Aggregation and summarization.
I've done some simulations, analysis and have written a chapter about this in my thesis. My results show that aggregating a domain to a single node performs very badly compared to an aggregation model where you advertise a full mesh between edge nodes. I would also argue that the advantages of simplifying the internal domain do not balance the disadvantages you have in false positives in inter-domain pathfinding.
However, these simulations have only used a single layer. We're currently looking at pathfinding in multi-layer networks, and we're thinking about how to create aggregations for multiple layers. This is a hard problem.
Given the fact that current domains are not that complicated, and we have a very open culture in regards to information exchange, I would suggest that we leave the problem of aggregation open for now and just use full topologies.
Jeroen.
On 09/02/2010 15:42, John MacAuley wrote:
Jeroen,
I agree with the statement that the signal node model would perform more poorly for optimal path computation, but would the computation of the summarized meshed links not be a costly on an on-going basis? These meshed links would need to be updated anytime there is a reservation added to the network that could impact the availability of the existing precomputed links. I this model are you providing the summarized bandwidth available between nodes? This would be an extremely costly calculation summing all potential bandwidth.
Yes, there will be a cost in maintaining an up-to-date topology. Again, reflecting on the current situation, the time between reservation is measured in days, not miliseconds, so this is not really an issue right now. Then again, if you're doing a single node aggregation, you will be getting a lot more false-positives, which means that the clients will have to do recalculations. I am not sure how the amount of calcalations in the two situations balance out. I think that it will fall negatively towards the single node aggregation, because each client has to discover false positives himself. In the full mesh situation it's calculated once and then shared with everyone.
Do you have description of the mechanism used to compute the meshed topology? I wouldn't mind understanding in more detail if possible.
I think there are several mechanisms to do that. The one I used is very simple: for each border node we do a Dijkstra's towards all the other border nodes. If there is a path available, then we add a link in the full mesh topology. I don't do anything fancy with the metric, it's set to 1 on every link. Jeroen.
Hey Jeroen, Your algorithm does not calculate available capacity, then; it's just reachability. That's not too expensive, but it's also not as useful. :) On Feb 9, 2010, at 4:00 PM, Jeroen van der Ham wrote:
On 09/02/2010 15:42, John MacAuley wrote:
Jeroen,
I agree with the statement that the signal node model would perform more poorly for optimal path computation, but would the computation of the summarized meshed links not be a costly on an on-going basis? These meshed links would need to be updated anytime there is a reservation added to the network that could impact the availability of the existing precomputed links. I this model are you providing the summarized bandwidth available between nodes? This would be an extremely costly calculation summing all potential bandwidth.
Yes, there will be a cost in maintaining an up-to-date topology. Again, reflecting on the current situation, the time between reservation is measured in days, not miliseconds, so this is not really an issue right now.
Then again, if you're doing a single node aggregation, you will be getting a lot more false-positives, which means that the clients will have to do recalculations. I am not sure how the amount of calcalations in the two situations balance out. I think that it will fall negatively towards the single node aggregation, because each client has to discover false positives himself. In the full mesh situation it's calculated once and then shared with everyone.
Do you have description of the mechanism used to compute the meshed topology? I wouldn't mind understanding in more detail if possible.
I think there are several mechanisms to do that. The one I used is very simple: for each border node we do a Dijkstra's towards all the other border nodes. If there is a path available, then we add a link in the full mesh topology. I don't do anything fancy with the metric, it's set to 1 on every link.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
On 09/02/2010 16:02, Evangelos Chaniotakis wrote:
Hey Jeroen,
Your algorithm does not calculate available capacity, then; it's just reachability. That's not too expensive, but it's also not as useful. :)
Again, if you have to do this in the complete graph, you're not going to win much by breaking this up in smaller problems. Jeroen.
An additional interesting problem to investigate with the meshed mechanism is the ability to model diversity in the links. Whenever DRAC is asked to perform diverse routing for protected circuits it does both node diverse and SRLG diverse routing. The mesh model would hide this, but you might be able to come up with a ingenious way to handle it. John. On 10-02-09 7:11 PM, Jeroen van der Ham wrote:
On 09/02/2010 16:02, Evangelos Chaniotakis wrote:
Hey Jeroen,
Your algorithm does not calculate available capacity, then; it's just reachability. That's not too expensive, but it's also not as useful. :)
Again, if you have to do this in the complete graph, you're not going to win much by breaking this up in smaller problems.
Jeroen.
These guys did some research into that. Their paper is about the design of networks, but I think the metric also applies to pathfinding with existing networks as well. Designing Connection Oriented Networks for Multi-Domain Path Resilience (http://dx.doi.org/10.1007/s10922-009-9155-z) There probably is a lot more research into that. Not to sound like a broken record, but this research is just being published again shows that it is an open problem that is still being worked on. Jeroen. On 09/02/2010 16:20, John MacAuley wrote:
An additional interesting problem to investigate with the meshed mechanism is the ability to model diversity in the links. Whenever DRAC is asked to perform diverse routing for protected circuits it does both node diverse and SRLG diverse routing. The mesh model would hide this, but you might be able to come up with a ingenious way to handle it.
John.
On 10-02-09 7:11 PM, Jeroen van der Ham wrote:
On 09/02/2010 16:02, Evangelos Chaniotakis wrote:
Hey Jeroen,
Your algorithm does not calculate available capacity, then; it's just reachability. That's not too expensive, but it's also not as useful. :)
Again, if you have to do this in the complete graph, you're not going to win much by breaking this up in smaller problems.
Jeroen.
Yeah, I used to work alongside these guys :) Their approach seems to model the blocking probability so that pathfinders can take that into account. I think that's a valuable concept, actually. On Feb 9, 2010, at 4:32 PM, Jeroen van der Ham wrote:
These guys did some research into that. Their paper is about the design of networks, but I think the metric also applies to pathfinding with existing networks as well.
Designing Connection Oriented Networks for Multi-Domain Path Resilience (http://dx.doi.org/10.1007/s10922-009-9155-z)
There probably is a lot more research into that.
Not to sound like a broken record, but this research is just being published again shows that it is an open problem that is still being worked on.
Jeroen.
On 09/02/2010 16:20, John MacAuley wrote:
An additional interesting problem to investigate with the meshed mechanism is the ability to model diversity in the links. Whenever DRAC is asked to perform diverse routing for protected circuits it does both node diverse and SRLG diverse routing. The mesh model would hide this, but you might be able to come up with a ingenious way to handle it.
John.
On 10-02-09 7:11 PM, Jeroen van der Ham wrote:
On 09/02/2010 16:02, Evangelos Chaniotakis wrote:
Hey Jeroen,
Your algorithm does not calculate available capacity, then; it's just reachability. That's not too expensive, but it's also not as useful. :)
Again, if you have to do this in the complete graph, you're not going to win much by breaking this up in smaller problems.
Jeroen.
There you go - the exact problem :-) On 10-02-09 7:32 PM, Jeroen van der Ham wrote:
These guys did some research into that. Their paper is about the design of networks, but I think the metric also applies to pathfinding with existing networks as well.
Designing Connection Oriented Networks for Multi-Domain Path Resilience (http://dx.doi.org/10.1007/s10922-009-9155-z)
There probably is a lot more research into that.
Not to sound like a broken record, but this research is just being published again shows that it is an open problem that is still being worked on.
Jeroen.
On 09/02/2010 16:20, John MacAuley wrote:
An additional interesting problem to investigate with the meshed mechanism is the ability to model diversity in the links. Whenever DRAC is asked to perform diverse routing for protected circuits it does both node diverse and SRLG diverse routing. The mesh model would hide this, but you might be able to come up with a ingenious way to handle it.
John.
On 10-02-09 7:11 PM, Jeroen van der Ham wrote:
On 09/02/2010 16:02, Evangelos Chaniotakis wrote:
Hey Jeroen,
Your algorithm does not calculate available capacity, then; it's just reachability. That's not too expensive, but it's also not as useful. :)
Again, if you have to do this in the complete graph, you're not going to win much by breaking this up in smaller problems.
Jeroen.
Hi Jeroen, Is there any way to see the results of your simulations and the chapter you wrote on aggregation? I would like to take a closer look on that issue, as this issue is something I was investigating some time ago and could not find a strong reason to claim one to be better than the other. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Jeroen van der Ham Sent: Tuesday, February 09, 2010 6:23 PM To: John MacAuley Cc: nsi-wg@ogf.org Subject: Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI
On 09/02/2010 07:37, John MacAuley wrote:
1. Aggregation and summarization.
I've done some simulations, analysis and have written a chapter about this in my thesis. My results show that aggregating a domain to a single node performs very badly compared to an aggregation model where you advertise a full mesh between edge nodes. I would also argue that the advantages of simplifying the internal domain do not balance the disadvantages you have in false positives in inter-domain pathfinding.
However, these simulations have only used a single layer. We're currently looking at pathfinding in multi-layer networks, and we're thinking about how to create aggregations for multiple layers. This is a hard problem.
Given the fact that current domains are not that complicated, and we have a very open culture in regards to information exchange, I would suggest that we leave the problem of aggregation open for now and just use full topologies.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Comments in line: John MacAuley wrote:
1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional.
1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize.
For future reference, summarization does not always mean complete summarization. I.e. a network could advertise an abstract topology that is just simpified - not just a single node, or even just edge nodes.... An "abstracted" topology need only provide valid topology information - not necessarilly congruent or even summarized topology. For instance, a network could advertise a much more complex internal topology than it actually has...how would a neigbor know that its BS? :-) This is an issue for the DToX group... There are a number of advantages to summarization - the most notable is the potential reduction in topology that gets distributed, but there is also a cost: reducing topology information makes it more difficult to find optimal paths (or even just a "better" set of paths). So I don't think NSI should make recommendation on topology summarization - but hopefully our minimal topology model will allow it. As Jeroen alludes - hiding topology can be costly. (But so can exposing it:-) I suggest our topo model should be able to support whatever topology a domain /chooses/ to expose - and leave for another day/another working group the consideration of what topology should best be distributed and how.
. Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network?
. Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested?
. Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find. I suggest that these are *all* constraints that can be considered generally rather than making special cases for inter-layer adaptation, special scheduling corner cases, special authorization requirements, on an on... If pathfinding has to consider special conditions for any
Again, while there is some good discussion that could be had on this topic, this is really a topology distribution conversation. Different domains will use different heuristics to make that decision. What we need to do is to make sure that once the decision is made, that the NSI will be able to implement it and inter-operate with it. I.e. how a network decides when its necessary to build an express link is not our decision, but when they do, we should be able to construct that connection with NSI, and have a model that allows that connection to then become part of the topology db and thereby utilized for future path finding. I think we are good on this point. The one thing NSI should (IMO) stipulate is that the ingres and egress framing will be as requested by the Connection Request. I.e. if the ingress STP is an ethernet access framing, and the output STP is say SDH framing (a trib), then adaptation is necessary -its not a tunnel. However, if the request specified ethernet STPs on both ingress and egress, then the pathfinder could a) provision a flat ethernet connection, b) adapt the payload to sonet framing and then adapt it back to ethernet before reaching the egress, or c) build a sonet tunnel that encapsulates the ethernet framing and that pops out before reaching the egress STP. These are sublty different approaches. The real question is how complex does the topology need to be? and what does this do to the computational complexity of the pathfinder algorithm? I think the only thing we need from this issue is to make sure the minimal topological model can represent functional nodes like "adaption"...which it can (IMO). link, then it needs to do so for every link... it doesn't buy you anything to make some links subject to special processing - you then have to check every link to see if special processing condition applies. It is my assertion that the measure and value of our minimal topology model will be the ability for it to support these issues *without* specialized handling. If we choose to optimize some aspect later, thats ok as long as the model itself is not broken by doing so. One optimization that doesn't break the model is the constraint prioritization: one constraint may prune the search space faster than another. This is something that is general, and can be applied to any/all constraints without breaking the generality of a constraint based search for pathfinding. One thing we decided we needed to consider was how we implement a "modify" semantic for connections. Just to digress a bit into the topology discussion, distributing all topology to all networks is probably going to be a scaling issue in both complexity and security, and even our R&E networks are big enough to pose that scaling issue. So a local PathFinder is not going to make a very good decision about some far away network link allocation. So, IMO, we need to view topology distribution and pathfinding in a more localized manner. Possibly using a mix of local link state to make local path decisions but based upon reachability presented though something akin to an AS path vector for choosing exit points to next hop domains. And let downstream pathfinders perform downstream Pathfinding/allocation. This doesn't prevent or preclude domains from dumping all their topo infromation to their neighbors, but having a model that allows both methods would probably be a best fit - and small communities like R&E might share more complete topo info, while larger networks might keep more details localized and just advertise reachability to neighbors...
3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-)
I assert that not "swiss cheesing" a Sonet/sdh layer is not a compelling argument for an architectural decision today (:-) First, I think with VCAT and LCAS this issue is not so big a resource problem anymore. Second, old symetric models for sonet/sdh circuits supporting voice services are not typical of present day connection requirements for data circuits. Data circuits in general exhibit asymetric loading, and TCP flows tend strongly toward asymetric loads. Third, there is no apriori requirement that a connection be symetric pathwise or capacitywise. There may be some assumptions by TCP that RTT is symetric, but that hasn't been a reliable assumption for years. And there is a truck load of flow control algorithms in the literature that could and have been adapted for IP traffic over big fat [possibly asymetric] pipes. And fourth, if we expect to support multipoint services in future versions, the notion of unidirection path objects and connections provides a much better basis for assembling components of a multipoint connnection where bidirectionality means something significantly different. So while I believe you that real networks may have been historically concerned about the sonet groomng/garbage collection, I don't believe this is a significant concern in present/emerging networks. Thanks for the comments John. Interesting thoughts. Jerry
John.
*From: *Jerry Sobieski <jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Oh Jerry I see you are a progressive thinker. I assume my arguement of "bidirectional symmetric bandwidth is the way God intended" will not work with you then? I can't argue with your points. VCAT was designed to help carriers with the swiss cheesing problem, as well as permit growth of existing connections, but I get a warm sense of comfort when an equivalent number of timeslots are provisioned on each of the transmit/receive pairs at layer 1. So just for my clarification - this working group is only dealing with the protocols used to exchange topology and signal the reservation? John. On 10-02-09 3:47 PM, Jerry Sobieski wrote:
Comments in line:
John MacAuley wrote:
1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional.
1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize.
For future reference, summarization does not always mean complete summarization. I.e. a network could advertise an abstract topology that is just simpified - not just a single node, or even just edge nodes.... An "abstracted" topology need only provide valid topology information - not necessarilly congruent or even summarized topology. For instance, a network could advertise a much more complex internal topology than it actually has...how would a neigbor know that its BS? :-) This is an issue for the DToX group...
There are a number of advantages to summarization - the most notable is the potential reduction in topology that gets distributed, but there is also a cost: reducing topology information makes it more difficult to find optimal paths (or even just a "better" set of paths). So I don't think NSI should make recommendation on topology summarization - but hopefully our minimal topology model will allow it. As Jeroen alludes - hiding topology can be costly. (But so can exposing it:-) I suggest our topo model should be able to support whatever topology a domain /chooses/ to expose - and leave for another day/another working group the consideration of what topology should best be distributed and how.
. Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network?
. Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested?
Again, while there is some good discussion that could be had on this topic, this is really a topology distribution conversation. Different domains will use different heuristics to make that decision. What we need to do is to make sure that once the decision is made, that the NSI will be able to implement it and inter-operate with it. I.e. how a network decides when its necessary to build an express link is not our decision, but when they do, we should be able to construct that connection with NSI, and have a model that allows that connection to then become part of the topology db and thereby utilized for future path finding. I think we are good on this point.
The one thing NSI should (IMO) stipulate is that the ingres and egress framing will be as requested by the Connection Request. I.e. if the ingress STP is an ethernet access framing, and the output STP is say SDH framing (a trib), then adaptation is necessary -its not a tunnel. However, if the request specified ethernet STPs on both ingress and egress, then the pathfinder could a) provision a flat ethernet connection, b) adapt the payload to sonet framing and then adapt it back to ethernet before reaching the egress, or c) build a sonet tunnel that encapsulates the ethernet framing and that pops out before reaching the egress STP. These are sublty different approaches. The real question is how complex does the topology need to be? and what does this do to the computational complexity of the pathfinder algorithm? I think the only thing we need from this issue is to make sure the minimal topological model can represent functional nodes like "adaption"...which it can (IMO).
. Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find. I suggest that these are *all* constraints that can be considered generally rather than making special cases for inter-layer adaptation, special scheduling corner cases, special authorization requirements, on an on... If pathfinding has to consider special conditions for any link, then it needs to do so for every link... it doesn't buy you anything to make some links subject to special processing - you then have to check every link to see if special processing condition applies. It is my assertion that the measure and value of our minimal topology model will be the ability for it to support these issues *without* specialized handling. If we choose to optimize some aspect later, thats ok as long as the model itself is not broken by doing so. One optimization that doesn't break the model is the constraint prioritization: one constraint may prune the search space faster than another. This is something that is general, and can be applied to any/all constraints without breaking the generality of a constraint based search for pathfinding.
One thing we decided we needed to consider was how we implement a "modify" semantic for connections.
Just to digress a bit into the topology discussion, distributing all topology to all networks is probably going to be a scaling issue in both complexity and security, and even our R&E networks are big enough to pose that scaling issue. So a local PathFinder is not going to make a very good decision about some far away network link allocation. So, IMO, we need to view topology distribution and pathfinding in a more localized manner. Possibly using a mix of local link state to make local path decisions but based upon reachability presented though something akin to an AS path vector for choosing exit points to next hop domains. And let downstream pathfinders perform downstream Pathfinding/allocation. This doesn't prevent or preclude domains from dumping all their topo infromation to their neighbors, but having a model that allows both methods would probably be a best fit - and small communities like R&E might share more complete topo info, while larger networks might keep more details localized and just advertise reachability to neighbors...
3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-)
I assert that not "swiss cheesing" a Sonet/sdh layer is not a compelling argument for an architectural decision today (:-) First, I think with VCAT and LCAS this issue is not so big a resource problem anymore. Second, old symetric models for sonet/sdh circuits supporting voice services are not typical of present day connection requirements for data circuits. Data circuits in general exhibit asymetric loading, and TCP flows tend strongly toward asymetric loads. Third, there is no apriori requirement that a connection be symetric pathwise or capacitywise. There may be some assumptions by TCP that RTT is symetric, but that hasn't been a reliable assumption for years. And there is a truck load of flow control algorithms in the literature that could and have been adapted for IP traffic over big fat [possibly asymetric] pipes. And fourth, if we expect to support multipoint services in future versions, the notion of unidirection path objects and connections provides a much better basis for assembling components of a multipoint connnection where bidirectionality means something significantly different.
So while I believe you that real networks may have been historically concerned about the sonet groomng/garbage collection, I don't believe this is a significant concern in present/emerging networks.
Thanks for the comments John. Interesting thoughts. Jerry
John.
*From: *Jerry Sobieski <jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Hah! :-) Along with swiss cheese problem, you also end up with idle reverse bandwidth provisioned but sitting unused and blocking other circuits...but the user is paying for it so hey whats not to like? :-) I didn't mean to sound too strident in refuting the bidirectional circuit practice John. I know it has been a common and standard practice in nearly every network for many years. Sorry if it seemed a bit dismissive. We don't want to preclude a symetric bidirectional circuit, just make sure that we aren't forced into them as the standard service instance. For the upcoming document we decided that we'd accept unidirectional connections as the basic "coin of the relm" and address more sophisticated groupings, routing, and provisioning issues in the next version. We do indeed want to explore the issues of diverse routing, SRLGs, Point-to-mulitPoint and MP to MP path computing, decomposition, and manipulation - but we just didn't have time to address those issues by OGF. Actually, this group is *not* supposed to be dealing with topology exchange or even provisioning...those are process we recognize and consider, but NSI doesn't make a specification regarding them. NSI only deals with the RA-PA relationship - i.e. the semantic functionality necessary to establish trust and field service requests. We have decided that one service that NSI will need to include is the Connection Service, and this was important enough that we felt it necessary to define the functional semantics for that NSI service as well. So we are developing the functional semantics necessary provide such a service in a fashion that lends itself to both WS and lowlevel protocol implementations. Hope this helps Jerry John MacAuley wrote:
Oh Jerry I see you are a progressive thinker. I assume my arguement of "bidirectional symmetric bandwidth is the way God intended" will not work with you then? I can't argue with your points. VCAT was designed to help carriers with the swiss cheesing problem, as well as permit growth of existing connections, but I get a warm sense of comfort when an equivalent number of timeslots are provisioned on each of the transmit/receive pairs at layer 1.
So just for my clarification - this working group is only dealing with the protocols used to exchange topology and signal the reservation?
John.
On 10-02-09 3:47 PM, Jerry Sobieski wrote:
Comments in line:
John MacAuley wrote:
1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional.
1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize.
For future reference, summarization does not always mean complete summarization. I.e. a network could advertise an abstract topology that is just simpified - not just a single node, or even just edge nodes.... An "abstracted" topology need only provide valid topology information - not necessarilly congruent or even summarized topology. For instance, a network could advertise a much more complex internal topology than it actually has...how would a neigbor know that its BS? :-) This is an issue for the DToX group...
There are a number of advantages to summarization - the most notable is the potential reduction in topology that gets distributed, but there is also a cost: reducing topology information makes it more difficult to find optimal paths (or even just a "better" set of paths). So I don't think NSI should make recommendation on topology summarization - but hopefully our minimal topology model will allow it. As Jeroen alludes - hiding topology can be costly. (But so can exposing it:-) I suggest our topo model should be able to support whatever topology a domain /chooses/ to expose - and leave for another day/another working group the consideration of what topology should best be distributed and how.
. Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network?
. Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested?
Again, while there is some good discussion that could be had on this topic, this is really a topology distribution conversation. Different domains will use different heuristics to make that decision. What we need to do is to make sure that once the decision is made, that the NSI will be able to implement it and inter-operate with it. I.e. how a network decides when its necessary to build an express link is not our decision, but when they do, we should be able to construct that connection with NSI, and have a model that allows that connection to then become part of the topology db and thereby utilized for future path finding. I think we are good on this point.
The one thing NSI should (IMO) stipulate is that the ingres and egress framing will be as requested by the Connection Request. I.e. if the ingress STP is an ethernet access framing, and the output STP is say SDH framing (a trib), then adaptation is necessary -its not a tunnel. However, if the request specified ethernet STPs on both ingress and egress, then the pathfinder could a) provision a flat ethernet connection, b) adapt the payload to sonet framing and then adapt it back to ethernet before reaching the egress, or c) build a sonet tunnel that encapsulates the ethernet framing and that pops out before reaching the egress STP. These are sublty different approaches. The real question is how complex does the topology need to be? and what does this do to the computational complexity of the pathfinder algorithm? I think the only thing we need from this issue is to make sure the minimal topological model can represent functional nodes like "adaption"...which it can (IMO).
. Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find. I suggest that these are *all* constraints that can be considered generally rather than making special cases for inter-layer adaptation, special scheduling corner cases, special authorization requirements, on an on... If pathfinding has to consider special conditions for any link, then it needs to do so for every link... it doesn't buy you anything to make some links subject to special processing - you then have to check every link to see if special processing condition applies. It is my assertion that the measure and value of our minimal topology model will be the ability for it to support these issues *without* specialized handling. If we choose to optimize some aspect later, thats ok as long as the model itself is not broken by doing so. One optimization that doesn't break the model is the constraint prioritization: one constraint may prune the search space faster than another. This is something that is general, and can be applied to any/all constraints without breaking the generality of a constraint based search for pathfinding.
One thing we decided we needed to consider was how we implement a "modify" semantic for connections.
Just to digress a bit into the topology discussion, distributing all topology to all networks is probably going to be a scaling issue in both complexity and security, and even our R&E networks are big enough to pose that scaling issue. So a local PathFinder is not going to make a very good decision about some far away network link allocation. So, IMO, we need to view topology distribution and pathfinding in a more localized manner. Possibly using a mix of local link state to make local path decisions but based upon reachability presented though something akin to an AS path vector for choosing exit points to next hop domains. And let downstream pathfinders perform downstream Pathfinding/allocation. This doesn't prevent or preclude domains from dumping all their topo infromation to their neighbors, but having a model that allows both methods would probably be a best fit - and small communities like R&E might share more complete topo info, while larger networks might keep more details localized and just advertise reachability to neighbors...
3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-)
I assert that not "swiss cheesing" a Sonet/sdh layer is not a compelling argument for an architectural decision today (:-) First, I think with VCAT and LCAS this issue is not so big a resource problem anymore. Second, old symetric models for sonet/sdh circuits supporting voice services are not typical of present day connection requirements for data circuits. Data circuits in general exhibit asymetric loading, and TCP flows tend strongly toward asymetric loads. Third, there is no apriori requirement that a connection be symetric pathwise or capacitywise. There may be some assumptions by TCP that RTT is symetric, but that hasn't been a reliable assumption for years. And there is a truck load of flow control algorithms in the literature that could and have been adapted for IP traffic over big fat [possibly asymetric] pipes. And fourth, if we expect to support multipoint services in future versions, the notion of unidirection path objects and connections provides a much better basis for assembling components of a multipoint connnection where bidirectionality means something significantly different.
So while I believe you that real networks may have been historically concerned about the sonet groomng/garbage collection, I don't believe this is a significant concern in present/emerging networks.
Thanks for the comments John. Interesting thoughts. Jerry
John.
*From: *Jerry Sobieski <jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Thank you Jerry, it does clear it up. Also, I did not think you dismissive at all. I posed an extremely weak argument based on a desire to save myself work, and being new to the group, wanted to see the dynamics in action :-) On 10-02-10 12:35 AM, Jerry Sobieski wrote:
Hah! :-) Along with swiss cheese problem, you also end up with idle reverse bandwidth provisioned but sitting unused and blocking other circuits...but the user is paying for it so hey whats not to like? :-)
I didn't mean to sound too strident in refuting the bidirectional circuit practice John. I know it has been a common and standard practice in nearly every network for many years. Sorry if it seemed a bit dismissive. We don't want to preclude a symetric bidirectional circuit, just make sure that we aren't forced into them as the standard service instance. For the upcoming document we decided that we'd accept unidirectional connections as the basic "coin of the relm" and address more sophisticated groupings, routing, and provisioning issues in the next version. We do indeed want to explore the issues of diverse routing, SRLGs, Point-to-mulitPoint and MP to MP path computing, decomposition, and manipulation - but we just didn't have time to address those issues by OGF.
Actually, this group is *not* supposed to be dealing with topology exchange or even provisioning...those are process we recognize and consider, but NSI doesn't make a specification regarding them. NSI only deals with the RA-PA relationship - i.e. the semantic functionality necessary to establish trust and field service requests. We have decided that one service that NSI will need to include is the Connection Service, and this was important enough that we felt it necessary to define the functional semantics for that NSI service as well. So we are developing the functional semantics necessary provide such a service in a fashion that lends itself to both WS and lowlevel protocol implementations.
Hope this helps Jerry
John MacAuley wrote:
Oh Jerry I see you are a progressive thinker. I assume my arguement of "bidirectional symmetric bandwidth is the way God intended" will not work with you then? I can't argue with your points. VCAT was designed to help carriers with the swiss cheesing problem, as well as permit growth of existing connections, but I get a warm sense of comfort when an equivalent number of timeslots are provisioned on each of the transmit/receive pairs at layer 1.
So just for my clarification - this working group is only dealing with the protocols used to exchange topology and signal the reservation?
John.
On 10-02-09 3:47 PM, Jerry Sobieski wrote:
Comments in line:
John MacAuley wrote:
1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional.
1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize.
For future reference, summarization does not always mean complete summarization. I.e. a network could advertise an abstract topology that is just simpified - not just a single node, or even just edge nodes.... An "abstracted" topology need only provide valid topology information - not necessarilly congruent or even summarized topology. For instance, a network could advertise a much more complex internal topology than it actually has...how would a neigbor know that its BS? :-) This is an issue for the DToX group...
There are a number of advantages to summarization - the most notable is the potential reduction in topology that gets distributed, but there is also a cost: reducing topology information makes it more difficult to find optimal paths (or even just a "better" set of paths). So I don't think NSI should make recommendation on topology summarization - but hopefully our minimal topology model will allow it. As Jeroen alludes - hiding topology can be costly. (But so can exposing it:-) I suggest our topo model should be able to support whatever topology a domain /chooses/ to expose - and leave for another day/another working group the consideration of what topology should best be distributed and how.
. Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network?
. Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested?
Again, while there is some good discussion that could be had on this topic, this is really a topology distribution conversation. Different domains will use different heuristics to make that decision. What we need to do is to make sure that once the decision is made, that the NSI will be able to implement it and inter-operate with it. I.e. how a network decides when its necessary to build an express link is not our decision, but when they do, we should be able to construct that connection with NSI, and have a model that allows that connection to then become part of the topology db and thereby utilized for future path finding. I think we are good on this point.
The one thing NSI should (IMO) stipulate is that the ingres and egress framing will be as requested by the Connection Request. I.e. if the ingress STP is an ethernet access framing, and the output STP is say SDH framing (a trib), then adaptation is necessary -its not a tunnel. However, if the request specified ethernet STPs on both ingress and egress, then the pathfinder could a) provision a flat ethernet connection, b) adapt the payload to sonet framing and then adapt it back to ethernet before reaching the egress, or c) build a sonet tunnel that encapsulates the ethernet framing and that pops out before reaching the egress STP. These are sublty different approaches. The real question is how complex does the topology need to be? and what does this do to the computational complexity of the pathfinder algorithm? I think the only thing we need from this issue is to make sure the minimal topological model can represent functional nodes like "adaption"...which it can (IMO).
. Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find. I suggest that these are *all* constraints that can be considered generally rather than making special cases for inter-layer adaptation, special scheduling corner cases, special authorization requirements, on an on... If pathfinding has to consider special conditions for any link, then it needs to do so for every link... it doesn't buy you anything to make some links subject to special processing - you then have to check every link to see if special processing condition applies. It is my assertion that the measure and value of our minimal topology model will be the ability for it to support these issues *without* specialized handling. If we choose to optimize some aspect later, thats ok as long as the model itself is not broken by doing so. One optimization that doesn't break the model is the constraint prioritization: one constraint may prune the search space faster than another. This is something that is general, and can be applied to any/all constraints without breaking the generality of a constraint based search for pathfinding.
One thing we decided we needed to consider was how we implement a "modify" semantic for connections.
Just to digress a bit into the topology discussion, distributing all topology to all networks is probably going to be a scaling issue in both complexity and security, and even our R&E networks are big enough to pose that scaling issue. So a local PathFinder is not going to make a very good decision about some far away network link allocation. So, IMO, we need to view topology distribution and pathfinding in a more localized manner. Possibly using a mix of local link state to make local path decisions but based upon reachability presented though something akin to an AS path vector for choosing exit points to next hop domains. And let downstream pathfinders perform downstream Pathfinding/allocation. This doesn't prevent or preclude domains from dumping all their topo infromation to their neighbors, but having a model that allows both methods would probably be a best fit - and small communities like R&E might share more complete topo info, while larger networks might keep more details localized and just advertise reachability to neighbors...
3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-)
I assert that not "swiss cheesing" a Sonet/sdh layer is not a compelling argument for an architectural decision today (:-) First, I think with VCAT and LCAS this issue is not so big a resource problem anymore. Second, old symetric models for sonet/sdh circuits supporting voice services are not typical of present day connection requirements for data circuits. Data circuits in general exhibit asymetric loading, and TCP flows tend strongly toward asymetric loads. Third, there is no apriori requirement that a connection be symetric pathwise or capacitywise. There may be some assumptions by TCP that RTT is symetric, but that hasn't been a reliable assumption for years. And there is a truck load of flow control algorithms in the literature that could and have been adapted for IP traffic over big fat [possibly asymetric] pipes. And fourth, if we expect to support multipoint services in future versions, the notion of unidirection path objects and connections provides a much better basis for assembling components of a multipoint connnection where bidirectionality means something significantly different.
So while I believe you that real networks may have been historically concerned about the sonet groomng/garbage collection, I don't believe this is a significant concern in present/emerging networks.
Thanks for the comments John. Interesting thoughts. Jerry
John.
*From: *Jerry Sobieski <jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
HI John, I agree with all three of your points you stated below. I particularly agree with handling complex intra domain paths only with the local NRMs and outside the scope of interdomain paths. However, I do think that the adaptation services should be advertised by each domain, so that the inter-domain path computation engine may sometimes choose a path running through a domain that comes in at (like your example) Ethernet and then leaving the same domain via SONET to cross the ocean (for example). In this case adaptation does take place only inside the domain via the local NRM but the inter domain path had to be aware of that service to successfully choose the interdomain path. thanks, Gigi
Jerry,
Great slide package - you did a good job of describing the key concepts discussed on the last call. I think it is import we store these documents somewhere so people joining the list can access the most recent versions (and people like me who switch computers all the time can pull down copies).
Last week at the GLIF there were a number of hallway conversations on the topic of topology. As with everything in the world people had differing opinions, but I think it was great since it did get me questioning about my position on the subject. I would like to make a couple of points for discussion:
1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional.
1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize. There are a couple of key ones we should consider for example:
. Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network?
. Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested?
. Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find.
Although I think it would be possible to describe and advertise these types of access control rules along with the internal topology for other path computation elements to utilize, they complexity of describing such data may be prohibitive. In addition, the controlling NRM would still need to evaluate any request path based on the provisioned policies and end user identity. Therefore, for simplicity I believe these routing decisions should be left up to the controlling NRM and not an external Path Computation Element.
2. Routing in both time and space. The specific point here is existing schedules/reservations are part of topology since we are routing in both space and time. I am not sure if this was explicitly stated anywhere, and from the discussions on the conference calls I definitely think people are considering spatial routing first, and the time aspect as part of the path reservation signaling. Obviously, evaluating the time aspect after a physical path has been computed is a valid solution, however, we may be able to derive more optimal solutions by incorporating existing schedules earlier in the process.
Inclusion of schedules into the routing decision is how DRAC does performs path computation, but we have the distinct advantage of having all the topology for the domain and all the scheduled paths centrally located in our database. This allows for extremely fast and 100% accurate routing decisions. Obviously, distributing time-based topology is not feasible in a distributed control plane model due to the large dataset sizes, but with the summarized virtual node model we do have some opportunities for optimization due to the reduced scale of the problem. If we attach reservations to the UNI and E-NNI links reported via topology exchange for the virtual node, and use this additional information to perform path computation, we will have a high probability of reservation success the first time through if the summarized domain is fairly well connected internally.
3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-)
John.
*From: *Jerry Sobieski <jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi Gigi - I agree in general, but propose the following: I suggest that we need to roll this up into a "semantic" for the NSI - i.e. PathFinding is not fundamentally part of the NSI scope so if we want to make sure this capability is allowed, then we need to state it in a way that is relevant to the NSI Connection Request. Essentially say what is must be performed in a certain way, everything else being free to interpretation... So, IMO we need to make a declaration of the follow sort as part of NSI: - A Connection Request *must* provide at a minimum an "ingress STP" and an "egress STP" in a Path Object. - A Connection Request *may* provide intermediate STPs in the Path Object that the connection must transit. The connection must transit these STPs in the order in which they appear in the Path Object. - A Provider Agent must construct a connection path that honors the "framing" format for each intermediate STP. The Provider Agent is free to select any transport mechanism, technology, or path between STPs that otherwise meet the constraints of the Connection Request. In my mind, the STP will point to topology information that explicitly determins the native "framing" of the STP. And by specifying this STP as a ingress or egress point, the requester is able to specify the exact framing that should be used to accept input PDUs, or to present egress PDUs. The point here is that we want to make it explicit how the user data payload is defined at the ingress STP and the egress STP. And each intermediate hop would be treated similarly. For example, if the user specifies ethernet STP at ingress, then that connection should expect to see ethernet frames at the ingress. If the egress point is a VLAN, then an adaptation must be performed to encapsultate the PDU in a tagged VLAN frame. A concatenation operation that attempts to terminate a SONET/SDH framed transport path at en ethernet STP should not succeed. How we define the STP should imply the appropriate framing. (However, there may be some virtualizations that may confound this mechanism.) But this would allow PathFinders to concatenate connections, adapt connections, to encapsulate connections...whatever, as long as the end points are framed in a specific manner. I move that we put the preceeding statements into the NSI Connection Service semantics section. Comments? thoughts? Jerry gkedward@ncsu.edu wrote:
HI John,
I agree with all three of your points you stated below. I particularly agree with handling complex intra domain paths only with the local NRMs and outside the scope of interdomain paths. However, I do think that the adaptation services should be advertised by each domain, so that the inter-domain path computation engine may sometimes choose a path running through a domain that comes in at (like your example) Ethernet and then leaving the same domain via SONET to cross the ocean (for example). In this case adaptation does take place only inside the domain via the local NRM but the inter domain path had to be aware of that service to successfully choose the interdomain path.
thanks, Gigi
Jerry,
Great slide package - you did a good job of describing the key concepts discussed on the last call. I think it is import we store these documents somewhere so people joining the list can access the most recent versions (and people like me who switch computers all the time can pull down copies).
Last week at the GLIF there were a number of hallway conversations on the topic of topology. As with everything in the world people had differing opinions, but I think it was great since it did get me questioning about my position on the subject. I would like to make a couple of points for discussion:
1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional.
1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize. There are a couple of key ones we should consider for example:
. Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network?
. Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested?
. Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find.
Although I think it would be possible to describe and advertise these types of access control rules along with the internal topology for other path computation elements to utilize, they complexity of describing such data may be prohibitive. In addition, the controlling NRM would still need to evaluate any request path based on the provisioned policies and end user identity. Therefore, for simplicity I believe these routing decisions should be left up to the controlling NRM and not an external Path Computation Element.
2. Routing in both time and space. The specific point here is existing schedules/reservations are part of topology since we are routing in both space and time. I am not sure if this was explicitly stated anywhere, and from the discussions on the conference calls I definitely think people are considering spatial routing first, and the time aspect as part of the path reservation signaling. Obviously, evaluating the time aspect after a physical path has been computed is a valid solution, however, we may be able to derive more optimal solutions by incorporating existing schedules earlier in the process.
Inclusion of schedules into the routing decision is how DRAC does performs path computation, but we have the distinct advantage of having all the topology for the domain and all the scheduled paths centrally located in our database. This allows for extremely fast and 100% accurate routing decisions. Obviously, distributing time-based topology is not feasible in a distributed control plane model due to the large dataset sizes, but with the summarized virtual node model we do have some opportunities for optimization due to the reduced scale of the problem. If we attach reservations to the UNI and E-NNI links reported via topology exchange for the virtual node, and use this additional information to perform path computation, we will have a high probability of reservation success the first time through if the summarized domain is fairly well connected internally.
3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-)
John.
*From: *Jerry Sobieski <jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Excellent! I like the proposed text and the ability to provide constraint based routing. I assume there will be the ability to provide other constraints such as nodes to traverse, nodes to exclude, SLRG, etc? John. On 10-02-09 6:51 PM, Jerry Sobieski wrote:
Hi Gigi - I agree in general, but propose the following:
I suggest that we need to roll this up into a "semantic" for the NSI - i.e. PathFinding is not fundamentally part of the NSI scope so if we want to make sure this capability is allowed, then we need to state it in a way that is relevant to the NSI Connection Request. Essentially say what is must be performed in a certain way, everything else being free to interpretation...
So, IMO we need to make a declaration of the follow sort as part of NSI:
- A Connection Request *must* provide at a minimum an "ingress STP" and an "egress STP" in a Path Object. - A Connection Request *may* provide intermediate STPs in the Path Object that the connection must transit. The connection must transit these STPs in the order in which they appear in the Path Object. - A Provider Agent must construct a connection path that honors the "framing" format for each intermediate STP. The Provider Agent is free to select any transport mechanism, technology, or path between STPs that otherwise meet the constraints of the Connection Request.
In my mind, the STP will point to topology information that explicitly determins the native "framing" of the STP. And by specifying this STP as a ingress or egress point, the requester is able to specify the exact framing that should be used to accept input PDUs, or to present egress PDUs.
The point here is that we want to make it explicit how the user data payload is defined at the ingress STP and the egress STP. And each intermediate hop would be treated similarly. For example, if the user specifies ethernet STP at ingress, then that connection should expect to see ethernet frames at the ingress. If the egress point is a VLAN, then an adaptation must be performed to encapsultate the PDU in a tagged VLAN frame. A concatenation operation that attempts to terminate a SONET/SDH framed transport path at en ethernet STP should not succeed. How we define the STP should imply the appropriate framing. (However, there may be some virtualizations that may confound this mechanism.)
But this would allow PathFinders to concatenate connections, adapt connections, to encapsulate connections...whatever, as long as the end points are framed in a specific manner.
I move that we put the preceeding statements into the NSI Connection Service semantics section.
Comments? thoughts? Jerry
gkedward@ncsu.edu wrote:
HI John,
I agree with all three of your points you stated below. I particularly agree with handling complex intra domain paths only with the local NRMs and outside the scope of interdomain paths. However, I do think that the adaptation services should be advertised by each domain, so that the inter-domain path computation engine may sometimes choose a path running through a domain that comes in at (like your example) Ethernet and then leaving the same domain via SONET to cross the ocean (for example). In this case adaptation does take place only inside the domain via the local NRM but the inter domain path had to be aware of that service to successfully choose the interdomain path.
thanks, Gigi
Jerry,
Great slide package - you did a good job of describing the key concepts discussed on the last call. I think it is import we store these documents somewhere so people joining the list can access the most recent versions (and people like me who switch computers all the time can pull down copies).
Last week at the GLIF there were a number of hallway conversations on the topic of topology. As with everything in the world people had differing opinions, but I think it was great since it did get me questioning about my position on the subject. I would like to make a couple of points for discussion:
1. Aggregation and summarization. 2. Routing in both space and time. 3. Unidirectional versus bidirectional.
1. Aggregation and summarization. There are a few advantages to abstracting a domain into a single virtual node beyond the first point made with respect to security. First of all, it simplifies the inter-domain topology picture since only edge links (UNI and E-NNI ports) are advertised external to the domain. It also permits internal routing decisions to be made exclusively by the NRM for that domain, without having to expose complex routing policies externally for PCE to utilize. There are a couple of key ones we should consider for example:
. Adaptation decision -- at what point in the network should a higher layer payload (Ethernet) be wrapped into a lower layer service (STS) for transport across the network?
. Inter-layer routing decisions -- When should a new lower layer service be created to meet the additional demand of the higher layer services requested?
. Policy based routing -- although adaptation and inter-layer routing could be considered policy based decisions, with this point I am referring to policies applied to path computation that could guide a route through the network. These attributes should be considered different than the standard constraint based routing attributes of link cost and shared risk link group values. For example, certain internal routes may be exclusively reserved for a particular class of service or class of user. My example here was always routing Inder's requests over the longest route and dirtiest fiber you could find.
Although I think it would be possible to describe and advertise these types of access control rules along with the internal topology for other path computation elements to utilize, they complexity of describing such data may be prohibitive. In addition, the controlling NRM would still need to evaluate any request path based on the provisioned policies and end user identity. Therefore, for simplicity I believe these routing decisions should be left up to the controlling NRM and not an external Path Computation Element.
2. Routing in both time and space. The specific point here is existing schedules/reservations are part of topology since we are routing in both space and time. I am not sure if this was explicitly stated anywhere, and from the discussions on the conference calls I definitely think people are considering spatial routing first, and the time aspect as part of the path reservation signaling. Obviously, evaluating the time aspect after a physical path has been computed is a valid solution, however, we may be able to derive more optimal solutions by incorporating existing schedules earlier in the process.
Inclusion of schedules into the routing decision is how DRAC does performs path computation, but we have the distinct advantage of having all the topology for the domain and all the scheduled paths centrally located in our database. This allows for extremely fast and 100% accurate routing decisions. Obviously, distributing time-based topology is not feasible in a distributed control plane model due to the large dataset sizes, but with the summarized virtual node model we do have some opportunities for optimization due to the reduced scale of the problem. If we attach reservations to the UNI and E-NNI links reported via topology exchange for the virtual node, and use this additional information to perform path computation, we will have a high probability of reservation success the first time through if the summarized domain is fairly well connected internally.
3. Unidirectional versus Bidirectional. Although I totally understand that a unidirectional service is a basic building block, there are a number of problems going with this model in a layer 1 network. Over time is can result in the undesirable side effect of Swiss cheesing timeslots on layer 1 links. If this is truly to be considered a functional solution in a highly dynamic network we need to make sure this does not become an issue. Secondly, in a layer 1 network bidirectional provisioning is an atomic operation reserving equivalent timeslots on transmit/receive pairs. This can cut the time of provisioning two equivalent unidirectional circuits in half. Lastly, it makes my life a lot easier :-)
John.
*From: *Jerry Sobieski<jerry@nordu.net <mailto:jerry@nordu.net>> *Date: *February 2, 2010 2:24:10 PM EST *To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>"<nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>> *Subject: **[Nsi-wg] Thoughts on a basic topology model for NSI*
Hi all-
Relative to our brief discussion last week about topology and the NSI...
We want the NSI to offer more power and options to the "user" - to break out of the traditional carrier models for interacting with the user. And I think our notions of Requesting aAgents and Providing Agents does that nicely and in a very elegant and scalable fashion.
However, we still have a lot of discussion about pathfinding - about how the agents will go about decomposing a path request into sub-paths for tree or chain model processing, or how we decide which NRMs are responsible for a particular end point, etc. These all deal with *topology*. There are quite a few notions we take for granted that require some sort of topology model. For instance: a Service Termination Point. Whatever we end up caling it, the semantics of an STP is that it represents a point in the topology where a service connection can terminate. We talk about capturing path information for monitoring...that requires a notion of how the topology is defined. There are lots of topologically based assumptions we need to be more explicit about.
So this set of slides tries to capture some thoughts of mine on how we can pose a simple minimalist topological model sufficient for our NSI purposes. I think it is consistent wth our thoughts and discussions. And while it may bump into things that the NML WG is considering, I doubt a) we have come up with anything conflicting, and b) we certanly have not gone to the details of how to describe or distribute a topology database - we just assume we have a TopoDB and that is contains these basic constructs.
Comments are welcome...Its only a draft for consideration... Jerry
While the NSI protocol itself does not impose a particular topology on the transport plane or the agents that manage it, we do impose some notions on the Connections we construct - e.g. that the NSAs will, as a group, be able to construct and reserve a suitable path for the request.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (7)
-
Evangelos Chaniotakis -
gkedward＠ncsu.edu -
Guy Roberts -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley -
Radek Krzywania