[Nsi-wg] Fwd: Thoughts on a basic topology model for NSI

Tue Feb 9 17:59:43 CST 2010

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 at nordu.net <mailto:jerry at nordu.net>>
>>> *Date: *February 2, 2010 2:24:10 PM EST
>>> *To: *"nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>" <nsi-wg at ogf.org 
>>> <mailto:nsi-wg at 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 at ogf.org <mailto:nsi-wg at ogf.org>
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100209/e7bdbcb7/attachment-0001.html 