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

Tue Feb 9 14:47:48 CST 2010

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/0c57a8ea/attachment-0001.html 