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

Tue Feb 9 18:12:43 CST 2010

Excellent!  I like the proposed text and the ability to provide 
constraint based routing.  I assume there will be the ability to provide 
other constraints such as nodes to traverse, nodes to exclude, SLRG, etc?

John.

On 10-02-09 6:51 PM, Jerry Sobieski wrote:
> 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 at 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 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
>>>>        
>>> _______________________________________________
>>> nsi-wg mailing list
>>> 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/703733e2/attachment-0001.html 