El 08/10/2006, a las 17:09, Deguang Le escribió:
I don't mean that there are any situation where we could have a locator
change and the usage of the Update message wouldn't apply. ^-^
I mean: could the usage of the Update message apply in the mobility
situation where we could have a locator change? :-)
i guess so...
i mean, in the mobility scenario, the host learns a new address from the
visited network. This address can be used as a locator for established
contexts. The result is that there is a new locator available for the
shim context. If the host wants to use the new locator for the
estbalished communication, it must add it to the existent locator set
and in order to do that, it should use the Update message
But in any case, imho this falls in the general case where the host
learns a new locator and wants to use it in the established contexts
(similar to the case where a new prefix is added for a multihomed site)
I think it would be better if this draft could provide some
examples (cases) about the locator change in real applications. For
examples, I would like to know if the follwoing cases belong to the
"locator change" situation described in this draft:
-A SHIM6 host is assigned a new usable locator at some interface of
the SHIM6 host.
We can add in the draft that a locator change is either to add new
locators to the locator set or to remove locators from it.
-A SHIM6 host finds one of its locators is unusable or failure.
Please note that when a host finds that one of its locators is
temporarily unusable e.g. it is unreachable, or there is a local
failure, it can use the Update message to inform about the situation
or it can simply convey Locator Preference infromation. This lasst
option is a cheaper option in terms of processing because of the
security checks
You are right, I agree with you. However, there still may be the case
where the shim6 host determines one of its locators is permanently
unusable. I think in this case it is better to remove the unusable
locator from the locator set. right? :-)
yes, this seems the most neat approach
By the way, I would like to discuss the efficiency of using the Locator
List option for the addition/deletion of locator to/from the locator set
further.
Because this draft specifies that "ALL" the locators must be carried in
the Locator List option (see page42), I think it is not efficient to use
the Locator List option in the case where only one locator needs to be
add or removed while other locators keep unchanged. I think it is not
necessary to update those unchanged locators and repetitively perform
locator verification for those unchanged locators each time when only a
locator changes. As you said , it is expensive option. Right? :-)
this issue was discussed during the design and there were two possible
approaches: the atomic approach, where each update message contains all
the locators and the diferential approach where each message contains
the diff from the existent locator set. As you mention the differential
approach is more efficient in terms of overhead. The problem with the
differential approach is that is more complex because both peers need to
be synchronized i.e. both ends need to have the same idea of what the
current locator set is. If a message is lost and the synchronization
between the peers is lost, then they will end up with different
perceptions of what the locator set is. This must be avoided. If we want
to avoid this we need to build a reliable mechanism for exchanging the
update message and its associated complexity, and also how to deal if
the peers end up out of sync. We decided that it was a reasonable
tradeoff to use the atomic approach and we have more overhead but less
complexity.
If my above issue is reasonable, do you think it is possible to define
two new separate options (e.g. Locator Addtion option and Locator
Deletion option) for adding a new locator to the locator set on a SHIM6
context and for deleting a failured locator from the locator set on a
SHIM6 context.
see above...
If the above two examples belong to the "locator change" situation,
then I would like to know if a SHIM6 host must (or can or need to)
send the Locator Request message with Locator List option to its
peers when the SHIM6 host is assigned a new usable locator at some
interface of the SHIM6 host or when the SHIM6 host finds one of its
locators is unusable or failure.
but this would be up to the host to decide based in its local policy
rather than a protocol issue imho
You are right, and I know what you mean. But, I'd only like to know,
from the functionality point of view, if the Update Request message with
Locator List option "CAN" be used for this purpose when the above two
situations occur. :-)
From the your following explanations, I think you agree the Update
Request message with Locator List option "CAN" do this.
absolutely, this is possible and a shim6 host can use it in the way you
propose
I mean if a host has a new locator it can either add it to all of its
established contexts, or to some of them or none of them depending
of local considerations. Moreover, a host does not need to add all
its locator to all its shim contexts. for instance a host could have
a set of locators tha it uses for certain communications (e.g.
communications within its own site) and some other set of locators
that it uses for other communications (e.g. intersite
communications) All these cases are perfectly ok and the spec
supports any behaviour that the host decides to choose
A similar consideration applies to the case where the host looses on
locator. Depending on the situation it can either rmove from the
locator set using an Update message or it can mark it as broken using
the preference option or it can even do nothing and the peer will
determine that the locator pairs contianing this locator are
unreachable and will not use them. All these approaches are possibel
and they are supported in the spec.
So, i am not sure we need to add additional constraints on how ths
needs to be used, what do you think?
Thank you again, I think your answer confirms my understanding.
This draft specifies the messages, which are used for multihoming, but
it does not clearly present (or explain) if these specifications could
be appled for mobilty usage.
right, but this is a multihoming solution.... whether this can or not be
used for mobility is another issue and i think it is explicitly out of
the scope of the wg (see the charter)