Re: [Seamoby] IP Paging ]Framework discussion

"James Kempf" <kempf@docomolabs-usa.com> Wed, 02 January 2002 20:06 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09817 for <seamoby-archive@odin.ietf.org>; Wed, 2 Jan 2002 15:06:00 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19166; Wed, 2 Jan 2002 14:55:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19141 for <seamoby@ns.ietf.org>; Wed, 2 Jan 2002 14:55:02 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09605 for <seamoby@ietf.org>; Wed, 2 Jan 2002 14:54:59 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g02JsJS24177; Wed, 2 Jan 2002 11:54:19 -0800 (PST)
Message-ID: <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Behcet Sarikaya <behcet.sarikaya@alcatel.com>, seamoby@ietf.org
References: <3C335823.5030009@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Wed, 02 Jan 2002 11:52:43 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Hi Behcet,

Hope you had a pleasant holiday.

>    I went thru the emails that I missed on the list during holiday
> period. You referred to our work several times, do I have right to
rebuttal?

Sure.

> -James Kempf said in his mail to Yoshi:
> --Something like the time-slotted
> --paging support in draft-sarikaya is what is needed in
> --the final protocol.
> We have included a shortedned version of time-slotted paging in the
> LAHAP draft. You seem to ignore the LAHAP draft always, why? (I think
> the answer is implicit in your other mail, parts of it I am copying
here)

No evil intent, it was strictly a matter of oversight.

> -James Kempf said in his mail:
> --There must be a TA per paging area, not per subnet. In the case of
> --L2 paging areas, the TA is identified as the entity that is taking
> --the L2 paging area update and coverting it into an L3 paging
> --area update. So it plays an important role there.
>
> The movement at IP level is based on the subnet so if we are going to
> track movement then TA functionality is needed in every subnet. If
every
> subnet is a L3 paging area then this becomes what you said.
>

The requirements specifically state that the paging area needs
to be independent of subnet (Requirement 4.12 Orthogonality
of Paging Area and Subnet). How the TA converts the
mobile's L2 paging area update to an L3 paging area
update is TBD in the design. It could involve the
AR doing the conversion, for example, or it could
involve the TA itself doing the conversion. To
maintain independence of paging area from
subnet, the former seems like probably the
better choice. Draft-renker,
which is now the basis for future work, does not
address this issue. If you have any thoughts
about how this should be done within the
context of draft-renker, please send them
to Marco and to the list.

> -James Kempf said in his mail:
> --I view the Paging Agent as the entity that initiates the actual page
> --directly
> --to the MN. This may be an L2 page or it may be an L3 page. I view it
> --as similar to the last hop router.
> The last hop router can take part in paging in communication with the
> Paging Agent. In case L3 paging area contains several IP subnets, then
> don't you need an upper level entity to take care of the paging
process?
>

Right, if you look at the diagram on pg. 13 of draft-renker, you
will see what I was trying to get at. The AR would have to
initiate an L2 page. The PA signals the ARs for subnets it covers. So
the PA
in that case would be the upper level entity, AR
would take care of the conversion.

In general,  I think having the AR perform the L3 to
L2 conversion is probably the best way to maintain
paging area independence from subnet.

As for (copied from you email to Hideaki):

>L3 paging areas need to be set up in a 4G type of network where
>there are
>no L2 paging areas. In this case our protocols define maximum L3 paging
>protocol
>operations because all IP paging need to be performed in Layer 3,
except
>on-link
>paging.

One of the uses of IP paging for seamless mobility is the ability
to abstract across a variety of different L2 paging protocols.
Suppose a device has five wireless interfaces, three of
which define L2 paging protocols specific to their
particular medium. In this case, confining the L2
paging information to the AR would simplify
management of paging within the network. L3
paging areas could be used to abstract across
various L2 paging protocols, in the same way
that an IP subnet abstracts across a different
L2 link. In this case, I think there is an advantage
to having L3 paging areas even if there is
already L2 support.

                        jak




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