Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 7 Nov 2002 15:25:01 +0100

Hello Hannes,

my comments in line

>>> Marcus:
>>> And the number space for the reservation id could be 5-dimensionl
>>> containing src/dest addr, ports, and proto number...

>> Rüdiger:
>> Yes, that's kind of the largest possible reservation ID.

> Hannes:
> that's probably a bad choice since it changes due to
> - movement
> - ipsec encryption
> - other tunneling techniques
> - ipv4/ipv6 transition
> etc.

Rüdiger:
In general, I'd regard the so called "flow identifier" as the
largest possible reservation ID, no matter how it looks like.
 
>>> Marcus:
>>> but it can also be derived from any other information
>>> or chosen randomly etc.

>> Rüdiger:
>> I disagree. The reservation ID must be non ambiguous. A part
>> of it may be assigned randomly. A simple solution may be
>> reservation ID = source address + random number.

> Hannes: 
> which source address? home address / care-of address
> if home address then what happens without mobility.
> if care-of address then there is a mobility problem.
> both?

I think the care-of address will do. As I've explained 
in another message, I'd expect signaling with complete 
flow ID should the latter change. That will solve the 
mobility problem. 

The above is valid for sender based reservations. Things
may look different for receiver based schemes like RSVP 
in combination with mobility.

I'm not deeply into mobility. The flow towards a mobile 
terminal once was routed to the home address and from 
there to the care-of address. If it is still like that, 
our signaling protocol must care about the issue. 
Wouldn't a reservation ID be helpful then?

Regards, Rüdiger 

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 7 Nov 2002 17:44:07 +0100

hi ruediger!

> largest possible reservation ID, no matter how it looks like.
[hannes] my point of view is that the reservation (or session) identifier
should be something different than the flow identifier. if this is not the
case then no such separation is required.

> flow ID should the latter change. That will solve the
[hannes] i am not sure to which mail you are referring. in any case i have
the strong feeling that you need to have some sort of session / reservation
identifier which is not subject to change. if you also want to change this
identifier then you need to update it along the entire path. maybe i do not
catch your point.

> in combination with mobility.
[hannes] are you sure? both sender and receive can move. i guess that there
is still a need for analysis work.

> Wouldn't a reservation ID be helpful then?
[hannes] doesn't this contradict to your previous argument?

ciao
hannes