Hi Gigi - I agree in general, but propose the following:

I suggest that we need to roll this up into a "semantic" for the NSI - i.e. PathFinding is not fundamentally part of the NSI scope so if we want to make sure this capability is allowed, then we need to state it in a way that is relevant to the NSI Connection Request.   Essentially say what is must be performed in a certain way, everything else being free to interpretation...

So, IMO we need to make a declaration of the follow sort as part of NSI:

-    A Connection Request *must* provide at a minimum an "ingress STP" and an "egress STP" in a Path Object.
-    A Connection Request *may* provide intermediate STPs in the Path Object that the connection must transit. The connection must transit these STPs in the order in which they appear in the Path Object.
- A Provider Agent must construct a connection path that honors the "framing" format for each intermediate STP. The Provider Agent is free to select any transport mechanism, technology, or path between STPs that otherwise meet the constraints of the Connection Request.

In my mind, the STP will point to topology information that explicitly determins the native "framing" of the STP.   And by specifying this STP as a ingress or egress point, the requester is able to specify the exact framing that should be used to accept input PDUs, or to present egress PDUs.

The point here is that we want to make it explicit how the user data payload is defined at the ingress STP and the egress STP. And each intermediate hop would be treated similarly. For example, if the user specifies ethernet STP at ingress, then that connection should expect to see ethernet frames at the ingress. If the egress point is a VLAN, then an adaptation must be performed to encapsultate the PDU in a tagged VLAN frame. A concatenation operation that attempts to terminate a SONET/SDH framed transport path at en ethernet STP should not succeed.   How we define the STP should imply the appropriate framing. (However, there may be some virtualizations that may confound this mechanism.)

But this would allow PathFinders to concatenate connections, adapt connections, to encapsulate connections...whatever, as long as the end points are framed in a specific manner.

I move that we put the preceeding statements into the NSI Connection Service semantics section.

Comments? thoughts?
Jerry

gkedward@ncsu.edu wrote:

HI John,

I agree with all three of your points you stated below. I particularly
agree with handling complex intra domain paths only with the local NRMs
and outside the scope of interdomain paths. However, I do think that the
adaptation services should be advertised by each domain, so that the
inter-domain path computation engine may sometimes choose a path running
through a domain that comes in at (like your example) Ethernet and then
leaving the same domain via SONET to cross the ocean (for example). In
this case adaptation does take place only inside the domain via the local
NRM but the inter domain path had to be aware of that service to
successfully choose the interdomain path.

thanks,
Gigi

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 <mailto:jerry@nordu.net>>
*Date: *February 2, 2010 2:24:10 PM EST
*To: *"nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>" <nsi-wg@ogf.org
<mailto: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 <mailto:nsi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg