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

Tue Feb 9 09:37:10 CST 2010

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 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/1847b833/attachment.html 