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

Tue Feb 9 23:35:55 CST 2010

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 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/20100210/337ec086/attachment-0001.html 