RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing

["Schneider, Marco" <schneider@tri.sbc.com>]

Georgios,

In my mind this requirement has do with the layering relationship between
QOS Signaling and Routing. In a hard-state solution once the QOS path is
created it does not unchange. The signaling protocol uses input from the
routing protocol to create this path. The path created is static. In an RSVP
style solution without route pinning we have a reactive distributed
algorithm that takes the default routing path as its input. While it should
be possible to do this style of path that is dynamically determined by the
default destination based routing, it must also be possible to build the
path once based upon an initial set of inputs.

Marco


> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: Wednesday, May 29, 2002 7:52 AM
> To: Schneider, Marco; 'nsis@ietf.org'
> Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow
> reserv ations and default routing
> 
> 
> Hi Marco
> 
> I am not sure, but it, at least seems to me, that this 
> requirement is more associated to routing than to 
> QoS signaling. Is this true?
> 
> Best regards,
> Georgios
> 
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: dinsdag 28 mei 2002 22:18
> To: 'nsis@ietf.org'
> Cc: 'sven.van_den_bosch@alcatel.be'
> Subject: [NSIS] NSIS Requirement: Independence of existing flow
> reservations and default routing
> 
> 
> Hi All,
> 
> One of the Open issues mentioned in the current requirements 
> draft is Route
> Pinning (item 47). In the following I discuss a very strong 
> motivation for
> the ability to do route pinning if a soft state solution is 
> used for NSIS. I
> have tried to express this as a requirement upon NSIS rather than the
> mechanism (route pinning being the obvious one) by which this 
> requirement
> may be achieved.
> 
> Requirement: NSIS must directly support the ability to insulate a flow
> reservation from changes in the default routing behaviour 
> except in those
> cases where said changes result from loss of resources (layer 3 hops,
> capacity etc.) along the existing flow reservation path.
> 
> For instance, utilizing traffic engineering in a layer 2 
> network (e.g. MPLS
> or ATM) we may provision additional links or change the 
> resources associated
> with existing links. Additionally failures in the network may 
> cause changes.
> Such changes must not affect existing layer 3 reservation 
> paths with the
> exception of those cases where the existing reservation path no longer
> exists or no longer has capacity to support the flow reservation.
> 
> As a simple example consider a network with two routers A and 
> B and assume
> that the shortest path from A to B is two hops. Based upon 
> NSIS signaling,
> as directed by default routing based upon number of hops, a 
> reservation path
> is setup from A to B along a path of two hops, where both hops have a
> capacity of 10 and the reservation uses a capacity of 6. Now 
> let us assume
> that a direct link with capacity 5 is provisioned between A 
> and B resulting
> in a new and direct default route of 1 hop. If NSIS uses a soft state
> solution without route pinning then the existing flow 
> reservation will be
> redirected along the new link, which cannot support it. Thus 
> the existing
> flow reservation is lost due a change in the network unrelated to its
> current path. In fact thousands of reservations may have been 
> routed along
> the original path and would now be disrupted. Such protocol 
> behaviour is not
> acceptable.
> 
> Best Regards,
> Marco
>  
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis