Subject: RE: [NSIS] Message Looping in GIMPS

From: [email-masked]
Date: Thu, 18 Mar 2004 14:12:11 +0200

Hi Robert,

I'll cut to the chase and comment on your suggestions:

> So, I would propose to keep the GHC as a loop detection mechanism
> within the GIMPS layer. (Obviously, the rules about how to process
> it need to be specified more precisely.) This can then also be used
> as *one* weapon to handle message looping at the signalling application
> layer (since NSLPs can read and set the GHC in their messages).

I agree with this.
 
> Should GIMPS provide route recording as a service?
> --------------------------------------------------
> 
> Despite all this, it is still possible (likely?) that there is 
> a use for route recording for various purposes for use by
> signalling applications. That may be for loop detection or
> something else. Loops may be caused by negotiation loops within
> a single instance of a NSLP (between peers or over a longer
> distance), or by feedback between microflow and aggregate signalling,
> or any other sort of reason, and the GHC may not be suitable or
> powerful enough to handle this. We could make a recording mechanism
> almost directly out of the comparable functionality in SIP or
> Diameter.
> 
> However, I think this functionality comes into the same class as
> some other items of 'generally useful signalling protocol' function,
> like state refresh management or MLPP: it may be useful for several
> signalling applications, but doesn't have a significant interaction
> with the other functions within GIMPS itself. Exactly how to make
> such re-usable components is an interesting question, but our
> assumption within NSIS (up to now) is that it is a question for the
> signalling application layer, not for the NTLP layer.

I'd punt this question up to the NSLP-folks.  Do you see benefits for path
recording?  I agree with Robert that it falls into the nice to have
category, but I'd like to know if the NSLPs would like to use such
a feature.

John

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

---

From: [email-masked]
Date: Thu, 18 Mar 2004 13:39:41 +0100

Hi John,

From a QoS NSLP point of view, I would say that record route is useful but
that we would probably use it indirectly to:

1. keep/tear down reservations on old paths or branches

The QoS NSLP draft currently proposes the use of the Source Identification
Information (SII) as a way to detect peer changes at the QoS NSLP and/or as
a way to rapidly tear down old branches (alternatively, it could be used to
keep the reservation of these old branches). The SII is just an identifier
to the QoS NSLP. However, one way to implement it at the GIMPS level would
be a record route. This would ensure that messages can be send on old paths
(instead of keeping state at the nodes, the state is kept in the recorded
route).

2. make reservations on backup paths

Support of record routing begs the question of what to do with explicit
routing (which has already been mentioned in the discussions). Explicit
routing (at the GIMPS layer) would mean that a mechanism is needed to
derive the "route object" via other means than recording it during path
setup. If used for e.g. reservations on backup paths, however, it would
only offer one hop protection and would need to be complemented by an
explicit routing mechanism at the NSLP layer.

Since we are at this point not so much interested in the explicit route per
se, but more in its applications, other mechanisms to do the above would
also be OK.

Best regards,
Sven

[email-masked]@ietf.org on 18/03/2004 13:12:11

Sent by:    [email-masked]

To:    <[email-masked]>, <[email-masked]>
cc:
Subject:    RE: [NSIS] Message Looping in GIMPS

Hi Robert,

I agree with this.

John