[NSIS] NSIS Requirement: Independence of existing flow reservations anddefault routing

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

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