Subject: nsis mobility interactions (was: RE: [NSIS] Some comments on draf t-ietf-nsis-req-04.txt)

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 24 Oct 2002 23:01:47 +0100

Bob,

brief comments in line:

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: 24 October 2002 20:05
> To: [email-masked]; [email-masked]; Hancock, Robert
> Subject: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt
> 
> 
> 
>    *> 
>   *> *>    11. Handoff decision and trigger sources: An NSIS 
> protocol is not 
>   *> *>    used to trigger handoffs in mobile IP, nor is it 
> used to decide 
>   *> > 
>   *> > Why not, and who says?
>   *> > 
>   *> *>    whether to handoff or not. As soon as or in some 
> situation even 
>   *> *>    before a handoff happened, an NSIS protocol might 
> be used for 
>   *> *>    signaling for QoS again. However, NSIS MUST 
> interwork with several 
>   *> *>    protocols for mobility management. 
>   *> *>      
>   *> 
>   *> this question pops up periodically in some form (see 
> also threads on
>   *> route pinning and bidirectional reservations).
>   *> 
>   *> i think the basic (simplifying) assumption has been that 
> the route
>   *> comes first (defining the path) and the signalling comes after it
>   *> (following the path). [this doesn't prevent a signalling 
> application at
>   *> some node interacting with something that modifies the 
> path, but the
>   *> requirement is then just for NSIS to live with that 
> possibility.] since
>   *> a handoff is a basically a route change, it comes into 
> this category;
>   *> if we don't make some assumption like this it's 
> impossible to see where
>   *> nsis stops and things like seamoby CARD start.
> 
> Robert,
> 
> OK, now I understand what you meant.  I think the paragraph should be
> more carefully worded.

[reh] i'll leave that to marcus [emphatic grin]

> 
>   *> 
>   *> i certainly used to think this was a reasonable 
> restriction (and still
>   *> do, for the 'NSIS base protocol'). but if we are trying 
> to broaden our
>   *> minds to think of possible NSIS uses (cf. your initial 
> comments) should
>   *> we also be thinking about signalling applications that 
> set up or modify
>   *> routes?
> 
> This is certainly a hard problem, which we struggled with in RSVP.
> We took the same approach you suggest, simply because to do anything
> else (like entangling QoS signaling with routing) seemed doomed to
> complexity death.

[reh] i have to agree it is low on my list of priorities; maybe we should leave the door open.

> 
>   *> 
>   *> *> 5.4.3 Independence of reservation identifier 
>   *> *>     
>   *> *>    A reservation identifier, which is independent of the flow 
>   *> *>    identifier (flow end-points), MUST be used. 
> Various scenarios in the 
>   *> *>    mobility area require this independence because 
> flows resulting from 
>   *> *>    handoff might have changed end-points etc. but 
> still have the same 
>   *> *>    service requirement. Also several proxy-based 
> signaling methods 
>   *> *>    might profit from such as independence. 
>   *> > 
>   *> > The semantics of this identifier needs to be precisely 
> defined.  It is
>   *> > unclear whether it needs to be used E-E, or only in 
> the mobile domain.
>   *> > 
>   *> 
>   *> we agonised about precisely this detail in the framework document
>   *> (current status: we don't know.) one point to make is 
> that i don't
>   *> think you can restrict the scope of the identifier to a 
> 'mobile domain'
>   *> because route changes due to mobility may have an impact 
> anywhere along
>   *> the data path (all the way up to the correspondent).
>   *> 
> 
> Robert,
> 
> I would like to understand myself what the issue is here.  What
> function does the identifier serve? Exactly what will be done
> differently if you have the identifier?
> 
> I can imagine that its function is to prevent "trading" reservations
> when end points move, i.e., it allows you to reuse the resources you
> already have for an ongoing call, rather than allocating new resources
> and freeing the old ones.  Is that right? (If so, it seems like a
> second-order optimization that might be nice but is not critical.)

[reh] You have it precisely. Whether it is critical seems to be a matter for debate. Certainly, there seem to be strong proponents; particular aspects to consider are that teardown may be difficult in a hard handover situation, and it might also be nice to short circuit authorisation stages and so on. There are some interesting discussions in draft-thomas-seamoby-rsvp-analysis-00.txt (now sadly expired) and draft-westphal-nsis-qos-mobileip-00.txt.

At the moment, my only opinion on this feature is that it is hard to support.

> Bob

cheers,

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

---

From: "Marcus Brunner" <[email-masked]>
Date: Sun, 27 Oct 2002 17:57:34 +0100

[...]
> [reh] i'll leave that to marcus [emphatic grin]

Please not too many [emphatic grin]. I will try to get this into the paragraph.

> [reh] i have to agree it is low on my list of priorities; maybe we should
leave the door open.

I aggree. We should stay away from combining signaling and routing. But we
should still keep the door open to use different routing mechnisms.

> [reh] You have it precisely. Whether it is critical seems to be a matter for
debate. Certainly, there seem to be strong proponents; particular aspects to
consider are that teardown may be difficult in a hard handover situation, and
it might also be nice to short circuit authorisation stages and so on. There
are some interesting discussions in draft-thomas-seamoby-rsvp-analysis-00.txt
(now sadly expired) and draft-westphal-nsis-qos-mobileip-00.txt.
> At the moment, my only opinion on this feature is that it is hard to support.

I am a proponent for this type of feature. It allows for more independence from
the topology (mobility case) and gives better identification of the reservation
for policy/security/AAA functionality.

Marcus
[...]
-------
Marcus Brunner
Network Labs
NEC Europe Ltd
Heidelberg, Germany

E-Mail: [email-masked]
WWW: www.brubers.org/marcus

---

From: Bob Braden <[email-masked]>
Date: Tue, 29 Oct 2002 19:18:35 -0800

>should still keep the door open to use different routing mechnisms.

There is a subtle difference between neighbor discovery and routing.  Discovery
allows a node to find all the neighbor nodes to which signaling messages might
be forwarded.  Routing determines which actual next hops are used for 
forwarding
a particular signaling message.  Neighbor discovery involves only local 
information,\
while routing involves global information in general.

I can imagine that the new QoS signaling protocol [I refuse to call it "NSIS",
because I think that's a dumb name for a protocol] might want to have a
neighbor discovery mechanism (roughly an "up/down" protocol), but it
might still want to route signaling packets using the same routing that
is used for data packets.  Note that if you use "some different routing
mechanism", you almost certainly have times when data routing
differs from signal routing, which is busted.

Thanks,

Bob Braden