Hello John,
Great to see your active participation in the NSI-WG - I sure
that your experience in DRAC development will form a useful contribution to
group discussion.
I have followed up your suggestion and posted Jerry’s
contribution on NSI’s Grid Forge site, you can find a copy here (This is
the normal repository for contributions to the NSI working group):
I would also like to take the opportunity to point out the
issue tracker software that we are using to keep track of decisions made by the
group:
http://forge.gridforum.org/sf/tracker/do/listArtifacts/projects.nsi-wg/tracker.nsi_issues
Regards,
Guy
From:
John MacAuley [mailto:john.macauley@surfnet.nl]
Sent: 09 February 2010 15:37
To: nsi-wg@ogf.org; Jerry Sobieski
Subject: Re: [Nsi-wg] Fwd: Thoughts on a basic topology model for NSI
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@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