[Seamoby] Technical issues of protocol assessment

[Marco Liebsch <[e-mail]>]

Hi all,

in order to address the issues of the paging protocol assessment, I send
the following comments to you. I already sent a list of comments on the
assessment on Dec, 4th, 2001. Some of the statements are taken over, but
I think it is reasonable to address the issues step by step. This is
open for discussion in order to move on and improve the current
architecture and protocol.

marco

----------------------------------
Issues addressed in 4.2:

4.2 Scalability:
The concept describes explicit idle state registration, which
requires one handshake with the composite Paging Agent. Additional
mechansims, like implicit/explicit dormancy as described in
draft-koodly, could be added. In case of not registering the
composite Paging Agent with the system in order to be able to
receive paging trigger packets, no additional signaling is
required (could be realized for example by integrating DMA
functionality in border routers). Since there will be multiple
composite Paging Agents in a domain, load will be shared between
them. Multiple Paging Agents furthermore will introduce redundancy
in order to support failover handling.

4.4 Efficient signaling while inactive
Please correct me if I misinterpreted this point.
The MN is either registered as IDLE or ACTIVE. When a MN is INACTIVE,
this is not an explicit state transition, which is to be signaled,
but could happen due to entering a location, where no wireless link
connection is available for any reason (e.g. due to obstacles) or
when the MN switches off due to unexpectied reasons (MN crashes).
Therefore, a MN never notifies the system of entering an inactive
state. It's up to the system to discover, that the MN is currently
not reachable. This is to be done only in case of an incoming paging
trigger packet. When the MN does not respond to paging request
messages, it's marked as 'not reachable' or 'inactive'.
This behaviour is described in D.4 of draft-renker-paging-ipv6-01.
From signaling point of view, at least a search within the
registered paging area is to be done before the MN can be marked as
'not reachable' [exponential backoff behaviour]. For this process,
even enhanced paging strategies (for example sequential polling)
introduce no gain in signaling avoidance. Tracking the idle MN by
e.g. polling periodically or expecting the MN to send 'heartbeat
massages' in order to proof that the MN is able to answer a
possible Paging Request, is somehow against the concepts of
paging and idle mode support.

4.6 Multiple Dormant Modes
Early requirements of the paging protocol referred to a paging
protocol, which should be independent of link interface specifics.
What the Paging Agent in draft-renker-paging-ipv6-01.txt supports
is a L3 protocol, that is independent of link interface specifics
'up to the Access Routers'. An appropriate paging functional entity
in each Access Router can map the L3 Paging Requests to link specifics
(L2 wake up mechanisms, ...) in order to support hardware power saving
modes. If there are more modes possible per interface and the MN
should select one and store this mode with the system, then some more
message options would be required (which could be easily conveyed as
TLV-encoded (sub-)options. Specifics on access technology should not
(yet) be part of the paging architecture/protocol specification.
First We should focus on having a generic functional architecure,
which allows easily extensions like the one discussed in this section
(and others).

4.7 Independence of Mobility Protocol
As already clarified, the explicit rehistration described in the
base-line draft should be taken for the generic case. As some already
suggested, the implicit case description could be part of
optimizations in the annex, if entirely de-coupled from the generic
protocol specified in the main part of the WG document.


To be continued...



_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby