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>

Date: February 2, 2010 2:24:10 PM EST

To: "nsi-wg@ogf.org" <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
http://www.ogf.org/mailman/listinfo/nsi-wg