[Seamoby] Feedback on Paging protocol assessment, draft-renker-paging-ipv6-01.txt

Dear all,

these are some comments on the Seamoby DMHA protocol assessment draft.
The related proposal is <draft-renker-paging-ipv6-01.txt>. Numbers refer

to the respective chapter in the requirements document, as they are used

also in the assessment draft. Please feel free to comment on this.

Regards,

Marco

---------------

4.2 Scalability
At least one signaling handshake is required for registration of a MN
with its serving Paging Agent (PA). Dependent on the integration of
the Paging Agent into the mobility platform, if dedicated paging
trigger packet forwarding to the Paging Agent is to be made use of,
the mobility agents have to redirect packets to the PA instead of to
the MN directly. Therefore, the respective PA is to be registered
with the mobility agent for this purpose, which is one additional
handshake in case of MIP. This registration can be valid for the
entire allowed registration lifetime (which should be large). When
integrating the PA appropriately within a domain, packet filtering
for registered MNs could be made use of. This could avoid the
explicit registration of the PA with the mobility agent (but does not
solve the increased registration lifetime issue). As a general
comment, I advacoate the first approach described, but the Paging
Agent should support packet filtering/tracking as well. The concept
allows deployment of the PA from outside a domain (e.g. for
inter-domain paging). When following the establlishment of required
security associations, this would allow a MN to have its individual
Paging Agent (for example at home). For inter-domain paging, security
associations have to be taken care of, since the PA addresses the
paging related functional entities in individual domain's Access
Routers. Having more (assigned) PA should allow coping with the
scalability issue, even if more advanced paging strategies (not only
blanket polling) are to be deployed.

4.4 Efficient Signaling for Inactive Mode
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.txt. 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
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 yet.
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
Of course, in order to be generic, the explicit case is the choosen
signaling approach.

4.9 Dormant Mode Termination
When the MN has been paged, having first a nCoA registration with
the mobility agent avoids timing complications with PA de-registration.
Then the PA is to be notified of the MN's nCoA in order to allow
paging trigger packet's forwarding to the MN (mechanism: IPIP
encapsulation).

4.10 Network updates
When having static paging areas in a system, the MN updates
its Paging Agent with a new paging area identifier. For the
'implicit case', the PA could assign the packets source address prefix
to a static paging area. But, since the generic case (mobility
independent solution' is considered in Seamoby, the explicit
signaling case should be considered. In case of having individual
paging areas, these could require less system updates with respect
to leaving/entering paging areas.
In the latter case, individual AR identifier are for example to be
made use of instead of having one identifier for a static set of ARs
as a paging area. This allows more flexible paging area construction.

4.11 Efficient Utilization of L2
As decribed above and in draft-renker-paging-ipv6-01.txt, the
concept specifies paging relevant functional entities (FE) in
Access Routers, having knowledge on their respective access
technology. This FE makes use of L2 specifics on the access link
in order to support interworking of L3 /L2- paging and dormant modes.
Dependent on the mobility platform, the MN has to send updates to
the network frequently. When no connection is open and having the
requirements of entering the IDLE mode of
draft-renker-paging-ipv6-01.txt in mind, the MN should enter L3
dormancy. Dependent on the interface technology, these timers
and algorithms (L2/L3 dormancy) could be optimized.

4.12 Orthogonality of PA and subnets
Since multiple access technologies are to be used, some static
identifier must be used in order to address individual idle
mobile nodes. This should be the same for cellular and non-cellular
networks. This could be the home address for MIP managed networks.
We expect administrative domains supporting several access
technologies. Access Routers supporting different link technologies
can be grouped to a L3 paging area on a static basis as well as on
an individual basis. In a current project, we assume one Access
Router link interface supporting one ip subnet. Whether an individual
Access Router provides access to MNs with multiple L2 Access Points,
this does not influence the L3 paging area construction.

4.15 Reliability of Packet Delivery
The described mechanism, where encapsulated packets arrive at
the Paging Agent as paging trigger packets, makes use of
encapsulation (tunnelling) in order to forward the packet to
its final destination as soon as the new address (nCoA for MIP) is
known.

4.19 and the following: Security issues
Currently, as described in draft-renker-paging-ipv6-01.txt,
the concept makes use of IPSec for sender authentication. The concept
described on how the Paging Agent integrates to a security platform
(as discussed in the IETF). No details are described yet on SA
establishment mechanisms, but IPSec is currently used for providing
fields for sender authentication and integrity check.

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby