Subject: [NSIS] QoS NSLP: rerouting issues

From: Andrew McDonald <[email-masked]>
Date: Wed, 18 Jan 2006 10:13:33 +0000

Hi all,

I did a review of the rerouting aspects of the QoS NSLP, and came across 
some potential problems. (NB: some of these also relate to the "GIST 
Refresh Mechanism eventually breaks upstream pathonCrossover Router" 
thread).

A summary of the issues is below, followed by proposed updates to the draft.

- There isn't currently a mechanism for a node to tell its upstream peer 
that it thinks its upstream route has changed (this concept is 
referenced in the GIST draft, but didn't exist in the QoS NSLP). This 
requires an additional notification code, and some rules for propagating 
such a message upstream.

- There is possibly an issue where the old path continues to send 
refreshes after a route change. Some extra text is needed to avoid 
oscillating between the old/new paths (i.e. need to look at SIIs),
which should also ensure that it will fall back to the old path if
rerouting back to the old path really does occur (e.g. fall back if
continue to get refreshes after some time, though you do have to be
careful about this).

- Another issue is that of making sure that a TEAR down the old path
doesn't go too far (and tear down reservations at nodes that should 
still exist because they are on the common path). The solution is that 
the TEAR shouldn't be sent until you've received an end-to-end ack of 
the RESERVE on the new path. Earlier versions of the draft also had a 
mechanism to do with counting backwards (RSN-1) for the TEAR to sort out 
problems where a route change wasn't really a route change (but, e.g., a 
change in the interfaces between the same two nodes). This got removed 
(the need for it looked like it had gone away), but I think it is still 
needed (though restricted to a particular use).

I also came some editorial issues in the rerouting text. In my proposed 
updates, I've created a new section in section 5 on processing related 
to rerouting. This includes the changes described above, and also 
includes some normative text from 3.2.10 (which is meant to be an 
informative section).

Proposed updates:

##### section 3.2.10 #####

.sh 3 "Rerouting"

QoS NSLP needs to adapt to route changes in the data path.  This
assumes the capability to detect rerouting events, perform QoS
reservation on the new path and optionally tear down reservations on
the old path.

Rerouting detection can be performed at three levels.  First, routing
modules may detect route changes through their interaction with
routing protocols.  Certain QNEs or GIST implementations may interact
with local routing module to receive quick notification of route
changes.  This is largely implementation-specific and outside of the
scope of NSIS.  Second, route changes may be detected at the GIST
layer.  GIST is able to provide information on such events over the
API.  This is outside the scope of the QoS NSLP specification.  Third,
rerouting may be detected at the NSLP layer.  A QoS NSLP node is able
to detect changes in its QoS NSLP peers by keeping track of a Source
Identification Information (SII) handle that provides information
similar in nature to the RSVP_HOP object described in RFC 2205
[RFC2205].  When a RESERVE message with an existing SESSION_ID and a
different SII is received, the QNE knows its upstream or downstream
peer has changed, for sender- and receiver-oriented reservations,
respectively.

Reservation on the new path happens when a refreshing RESERVE message
arrives at the QNE where the old and the new path diverge.  The
refreshing RESERVE will be interpreted as a new RESERVE on the new
path.  Depending on the transfer mode, this may require installation
of a new messaging association.  Rapid recovery at the NSLP layer
therefore requires short refresh periods.  Detection before the next
RESERVE message arrives is only possible at the IP layer or through
monitoring of GIST peering relations (e.g. by TTL counting the
number of GIST hops between NSLP peers or the observing changes in
the outgoing interface towards GIST peer).  These mechanisms can
provide implementation specific optimisations, and are outside the
scope of this specification.

When the QoS NSLP is aware of the route change, it needs to set up
the reservation on the new path.  This is done by incrementing the
RSN and then sending a new RESERVE message.  On links that are common
to the old and the new path, this RESERVE message is interpreted as a
refreshing RESERVE.  On new links, it creates the reservation.

After the reservation on the new path is set up, the branching node
or the merging node may want to tear down the reservation on the old
path (faster than what would result from normal soft-state time-out).
This functionality is supported by keeping track of the old SII.
This specification requests GIST design to provide support for an
SII that is interpreted as a random identifier at the QoS NSLP but
that allows, when passed over the API, to forward QoS NSLP messages
to the QNE identified by that SII.

A QNI or a branch node may wish to keep the reservation on the old
branch.  This could for instance be the case when a mobile node has
experienced a mobility event and wishes to keep reservation to its
old attachment point in case it moves back there.  For this purpose,
a REPLACE flag is foreseen in the common header, which, when set to
FALSE, indicates that the reservation on the old branch should be
kept.

The design of the QoS-NSLP allows reservations to be installed at a
subset of the nodes along a path, including cases where those nodes
might not included the endpoints of the application data flow.

In the case where the data flow receiver does not support the
QoS-NSLP, some particular considerations must be given to node
discovery and rerouting at the end of the signalling path.

There are three cases for the last node on the signalling path:
1) Last node is the data receiver
2) Last node is a configured proxy for the data receiver
3) Last node is not the data receiver and is not explicitly configured
to act as a signalling proxy on behalf of the data receiver.

Cases (1) and (2) can be handled by the QoS-NSLP itself during the
initial path setup, since the QNE knows that it should terminate the
signalling. Case (3) requires some assistance from GIST which provides
messages across the API to indicate that no further QoS-NSLP
supporting GIST nodes are present downstream, and downstream route
change probing needs to continue once the reservation is installed to
detect any changes in this situation.

##### section 4.8 #####

.sh 2 "Rerouting scenario"

The QoS NSLP needs to adapt to route changes in the data path.  This
assumes the capability to detect rerouting events, perform QoS
reservation on the new path and optionally tear down reservations on
the old path.

When the QoS NSLP is aware of the route change, it needs to set up
the reservation on the new path.  This is done by incrementing the
RSN and sending a RESERVE message.  On links that are common to the
old and the new path, this RESERVE message is interpreted as a
refreshing RESERVE.  On new links, it creates the reservation.

After the reservation on the new path is set up, the branching node or
the merging node may want to tear down the reservation on the old path
(faster than what would result from normal soft-state time-out).  This
functionality is supported by keeping track of the old SII, as
provided over the GIST API.  The SII is opaque to the QoS NSLP, i.e.
QoS NSLP does not make any assumptions on how this identifier is
constructed.  When passed over the API from the NSLP to GIST, it
allows QoS NSLP to indicate that its messages should be sent to the
QNE identified by that SII.

In case of a receiver-initiated reservation, a QNE can detect a route
change by receiving a RESERVE message with a different SII.  In case
of a sender-initiated reservation, the same information is learned
from a RESPONSE message, or from a NOTIFY message sent by the
downstream peer.  A QNE that has detected the route change via the
SII change sends a RESERVE message towards the QNR on the old path
(using the old SII) with the TEAR flag set.  Note that in case of
receiver-initiated reservations, this involves a QNE that is notified
of the route change in another way and wants to tear down the old
branch needs to send the RESERVE on the new path with an RII object.
When it receives the RESPONSE message back, it can check whether its
peer has effectively changed and send a RESERVE with the TEAR flag
set if it has.  Otherwise, teardown is not needed.  A QNE that is
unable to support an RII or does not receive a RESPONSE needs to rely
on soft-state timeout on the old branch.

A QNI or a branch node may wish to keep the reservation on the old
branch.  This could for instance be the case when a mobile node has
experienced a mobility event and wishes to keep reservation to its
old attachment point in case it moves back there.  In that case, it
sets the REPLACE flag in the common header to zero. Note that keeping
old reservations affects the resources available to other nodes. Thus,
the operator of the access network must make the final decision on
whether this behavior is allowed. Also, the QNEs in the access network
may add this flag even if the mobile node has not used the flag initially.

##### section 5.2.5 (new) #####

.sh 3 "Rerouting"

.sh 4 "Last node behaviour"

As discussed in section 3.2.10 particular mechanisms need to be used
at the QNR when it is not also the data receiver or a configured proxy
for the data receiver.

Two particular cases for rerouting need to be considered in this
situation. In the first, referred to as "Path Extension", rerouting
occurs such that an additional QNE is inserted into the signalling
path between the old last node and the data receiver, as shown in
Figure 4.

.nf
            /-------\\   Initial route
           /         v
               /-\\
            /--|B|--\\                +-+
           /   \\-/   \\               |x| = QoS-NSLP aware
        +-+           /-\\            +-+
    ----|A|           |D|
        +-+           \\-/            /-\\
           \\   +-+   /               |x| = QoS-NSLP unaware
            \\--|C|--/                \\-/
               +-+
           \\         ^
            \\-------/   Updated route

.fi
.ce
Figure 4: Path Extension

When rerouting occurs, the data path changes from A-B-D to
A-C-D. Initially the signalling path ends at A. Despite initially
being the last node, node A MUST continue to attempt to send messages
downstream to probe for path changes, unless it has been explicitly
configured as a signalling proxy for the data flow receiver. This is
required so that the signalling path change is detected, and C will
become the new last QNE.

In a second case, referred to as "Path Truncation", rerouting occurs
such that the QNE that was the last node on the signalling path is no
longer on the data path. This is shown in Figure 5.

.bp
.nf
            /-------\\   Initial route
           /         v
               +-+
            /--|B|--\\                 +-+
           /   +-+   \\                |x| = QoS-NSLP aware
        +-+           /-\\             +-+
    ----|A|           |D|
        +-+           \\-/             /-\\
           \\   /-\\   /                |x| = QoS-NSLP unaware
            \\--|C|--/                 \\-/
               \\-/
           \\         ^
            \\-------/   Updated route

.fi
.ce
Figure 5: Path Truncation
.fi

When rerouting occurs, the data path again changes from A-B-D to
A-C-D. The signalling path initially ends at C, but this node is not
on the new path. In this case, the normal GIST path change detection
procedures at A will detect the path change and notify the
QoS-NSLP. GIST will also notify the signalling application that no
downstream GIST nodes supporting the QoS-NSLP are present. Node A MUST
take over as the last node on the signalling path.

.sh 4 "Reservation maintenance on route change"

QoS NSLP is notified by GIST when GIST believes that a rerouting event
may have occurred. As part of the API, GIST provides an SII-Handle
which can be used by the NSLP to direct a signalling message to a
particular peer. The current SII-Handle will change if the signalling
peer changes. However, it is not guaranteed to remain the same after a
rerouting event where the peer does not change. Therefore, the QoS
NSLP mechanism for reservation maintenance after a route change
includes robustness mechanisms to avoid accidentally tearing down a
reservation in situations where the peer QNE has remained the same
after a 'route change' notification from GIST.

When a QNE detects that its neighbour QNE in the direction of the QNR
has changed, it SHOULD send a RESERVE message, including the full
QSPEC. This RESERVE message MUST include an RII, to request a response
from the QNR. When sending this message the RSN MUST be incremented by
two (and this becomes the current RSN value). An SII MUST NOT be
specified when passing this message over the API to GIST, so that it
is correctly routed to the new peer QNE.

When the QNE receives the RESPONSE message that relates to that the
RESERVE message sent down the new path, it SHOULD send a RESERVE
message with the TEAR flag sent down the old path, by specifying the
SII relating to the old peer QNE. When sending this RESERVE message
the RSN field MUST be set to one less than the current RSN value (and
the current RSN value remains unchanged). This 'RSN-1' will cause the
message to be reject by the next peer if the old and new next peers
are actually the same.

Depending on the particular route change, there may be a 'merge point'
(or 'crossover node') where the old and new paths merge. Initially this
has a reservation installed by the old peer QNE, identified by an old
SII. When the new reservation is installed after the route change the
new peer QNE will be identified by a new SII. At a later point the
crossover node may receive a RESERVE message with the TEAR flag set
from the QNE identified by the old SII. A node receiving a RESERVE
message with the TEAR flag set which does not come from the current
peer QNE, identified by its SII, MUST be ignored and MUST NOT be
forwarded.

.sh 4 "Upstream route change notification"

GIST may notify QoS NSLP that a possible upstream route change has
occurred over the GIST API. On receiving such a notification, QoS NSLP
SHOULD send a NOTIFY message with Informational code ????? for
signalling sessions associated with the identified MRI.

On receiving such a NOTIFY message, QoS NSLP SHOULD use the
InvalidateRoutingState API call to inform GIST that routing state
may be out of date. QoS NSLP SHOULD send a NOTIFY message upstream.

.sh 4 "Route change oscillation"

In some circumstances a route change may occur, but the path than
falls back to the original route.

After a route change the routers on the old path will continue to
refresh the reservation until soft state times out, or an explicit
TEAR is received.

After detecting an upstream route change a QNE SHOULD consider the new
upstream peer as current and not fall back to the old upstream peer
unless:

- it stops receiving refreshes from the old upstream peer for at least
the soft state timeout period

- or, it stops receiving refreshes from the new upstream peer for at
least the soft state timeout period

GIST routing state keeps track of the latest upstream peer it has
seen, and so may spuriously indicate route changes occur when the old
upstream peer refreshes its routing state until the state at that node
is explicitly torn down or times out.

Any comments?

Best regards,

Andrew

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis