RE: [802.21] Ad-hoc on ES/CS discussion
>-[Vivek G Gupta]
>We need to understand clearly what are the issues we need to
>solve/tackle within MIH protocol before just diving into a set of
different solutions.
>Best Regards
>-Vivek
Hi Vivek and all,
Agree with the previous point that we need to better understand the
issues we need to solve on route to designing the MIH protocol. But i am
stunned by this discussion.
Robustness/state machine we want of such a protocol as MIH is completely
separated from the transport protocol reliability be it at L2 or L3.
Just look at MIP: whenever a host informs its home agent that it would
like to bind its home adress to an alternative care-of-adress, it waits
until it receives the corresponding ACK from the home agent before
actually using that new care-of-adress to start sending packets again.
And that behavior is needed irrespective of wich transport one might
ever want to carry the MIP signalling with. It turns out that UDP is
used as the transport for MIP and one might argue that that was the
reason to ack the binding update. Designers of MIP might bring
contradictions but my conviction is that the reason was not there at
all.
The same applies in our case. Some deployments scenarios would for
example want the station to ACK the reception of an MIH switch command
so that appropriate action (for example re-routing of IP traffic to the
new link) is started by a mobility anchor in the network. And
reliability of the used transport won't provide any useful information
to that mobility anchor that the switch command was received and
treated. Note that a transport can be reliable and still for any reason
the host is not able to properly process the request (something got
wrong for example on local stack). Sending an ACK usually serves the
purpose of telling the peer that everything happened as planned upon
reception of the command.
To some up, let's not divert ourselves with transport issues too much.
That's not really much of the problem here!
Let's rather evaluate the necessity for a peer node to receive an ACK on
an action requested by that node on a pure protocol conception basis.
Best Regards
Eric