Subject: Re: [NSIS] QoS NSLP: rerouting issues

From: Roland Bless <[email-masked]>
Date: Thu, 02 Feb 2006 22:30:34 +0100

Hi Andrew,

sorry, unfortunately I had no time to reply earlier...so I'm too late
draft-..-nslp-09 was published today.
[Warning, long E-Mail, see comments inline]

> 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).

Which was initiated by Thomas IIRC...

> 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.

Yep.

> - 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).

Yep.

> - 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

This is right. Markus and I discovered the same problem. So
in this case it is always required to send a RESERVE with an RII.

> 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).

Ok, need to check this one.

> 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 #####
> 
[previous text ok.]
> 
> 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

Hm, I'm a little bit confused about this statement. The incoming
refreshing RESERVE will usually _not_ trigger a transmission of
a new RESERVE along the new path. Refreshing state is independently
triggered at each node rather than a refreshing RESERVE traversing
the path downstream. The branching node (i.e. the QNE
where the old and the new path diverge) will send a refresh
to his downstream peer. If rerouting happens, there
are different cases to be considered:
- GIST will detect a new path by its own mechanism, i.e. while
  sending an NTLP refresh. In this case a notification may be given
  to the NSLP that a downstream SII has changed. This should
  trigger immediate sending of a refreshing RESERVE (usually
  with full QSPEC and RII, otherwise we'll get an error back first).
- NSLP has to send a refresh to its downstream peer, because the refresh
  timer expired. GIST will find the new route then, notify NSLP of a
  new SII and will also get back an error message from its downstream
  peer, because he needs a full QSPEC. NSLP then should send the RESERVE
  with RII and full QSPEC again.

> 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.

Yep.

> 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.

Not quite correct. Incrementing the RSN is not necessary in this
case and  contradicts to the statement that an increased RSN indicates
a changed session. Furthermore, remember that an RSN has only
local significance.
Because the RSN is different it will not directly
be considered as refresh by nodes that know this session.
Only if the QSPEC and MRI did not change,
then there is no need to send it further along the path.
I would suggest that we clarify text when to "forward"
a RESERVE (at end of sec. 5.4.1) or TEAR anyway.
Section 5.3.1. states
   It MUST be incremented for each new RESERVE message where the
   reservation for the session changes.
Strictly speaking the above statement does not infer that
a new RSN necessarily means that the session changes. But
in case nothing changed, the RSN must stay the same.

Let's look what happens: the branching node should send
a full refreshing RESERVE (RSN not changed, added RII) along the new
link. If the next QNE is really a new peer that doesn't
know about the reservation, it will setup a new reservation
anyway. In this case this QNE will also emit a _new_ RESERVE
(include a new RSN, because the QNE is new). In case the
RESERVE hits the merging node again, the latter should
detect that: it knows the referenced session and that it
has a new upstream peer. But because neither MRI nor QSPEC
are changed, a new RESERVE along the unchanged path will
not be triggered (the normal refreshing RESERVE will be sent
when the refreshing timer fires).

The last two sentences are confusing, because
the RESERVE will not be forwarded (esp. not with the very same RSN).
Correct would be: The RESERVE may be sent along a new link but possibly
hits the same QNE as before (multi-homing scenario). In this case the
QNE will consider the RESERVE as refresh. If a new QNE is hit, it will
establish a new reservation (if possible) and send a new RESERVE downstream.

> 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).

As already written earlier
(http://www.ietf.org/mail-archive/web/nsis/current/msg05826.html):
I don't know how the merging node (i.e. the node where the paths
join again) should TEAR down the session.
Currently this is not possible because a RESERVE with TEAR can only
flow in the direction from QNI to QNR.

> 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.

This is the same text as above. I'm not really sure that we need
this redundancy.

> 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

Only the branching node... see above

> 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

This TEAR would IMHO be too early. The TEAR should be triggered by the
RESPONSE to the RESERVE on the new path indicating that the reservation
is already installed.

> 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.

This is ok, but also applicable to the sender-initiated case.

> 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.

Yep. Therefore, we should exactly describe at the end of the
RESERVE section 5.4.1 that a RESERVE with a TEAR should
not be sent to the next peer in this case.

> .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.

When should forwarding of NOTIFY stop?
I'm currently not sure how the branching node will detect this
case. Maybe if the NOTIFY arrives via an inactive/invalid routing
state.

> .sh 4 "Route change oscillation"
> 
> In some circumstances a route change may occur, but the path than
typo: then
> 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

??? in this case it really makes no sense to fall back to the old
upstream peer ???

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

Ok.

> 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?

Thanks for trying to improve the spec.

Regards,
 Roland

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 Feb 2006 15:22:05 +0100

Hi,

> the path downstream. The branching node (i.e. the QNE

Hmm, I'm sorry. I forgot that the current spec also allows to send a
refreshing RESERVE with an RII. However, is there a reason for doing
this?

Regards,
 Roland