Re: [Seamoby] DMHA framework draft architecture

Marco,

I had been thinking about this change myself.
So the basic idea is that the composite paging
agent contains that part of the tracking agent
that does IP paging area tracking, dormant
mode monitoring agent, and that part of
the paging agent which initiates IP paging.
Another part of the paging agent and
tracking agent sits in the access routers.
The part in the access router is responsible for
taking the L3 paging and tracking protocol
and converting it into an L2 paging and tracking
protocol, or, if the L2 does not support such
a protocol, translating into a last hop L3 protocol
to the MN (which actually might be the same
as the incoming L3 tracking and paging protocol).

I think this architecture would facilitate failover
if the composite paging agent for an IP
paging area fails. Consider
the following scenario. The composite agent
keeps track of the subnets it is currently covering.
Periodically, it propagates that information
to other, neighboring paging agents, just like
routing protocols do. Now suppose a paging
agent fails and the neighboring agents notice
due to an update failing to arrive. The neighboring
agents could use a dynamic paging area protocol
to arrange for the hosts under the control of the
failed paging agent to receive new paging
area location informing them that their
paging area changed. This would allow
the hosts to continue receiving service even though
their paging agent failed, without having to use
a server duplication protocol for the composite
agent. So paging area resiliency would work
somewhat like routing resilency, which is
a proven benefit of Internet routing.

            jak

----- Original Message -----
From: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
To: "Seamoby" <seamoby@ietf.org>
Sent: Monday, January 14, 2002 4:56 AM
Subject: [Seamoby] DMHA framework draft architecture

> Hi all,
>
> referring to the functional architecture for DMHA in RFC 3154,
currently
> the protocol base line draft describes a composite architecture.
> Appendix C of draft-renker-paging-ipv6-01.txt illustrates a mapping
> between the described architecture and the functional elements given
in
> RFC 3154. In order to come up with a first cut of a framework draft, I
> would like to request a WG consensus of taking over the proposed
> architecture, having a composite Paging Agent node (PA node)
addressing
> paging related attendant functional entities within ARs. Actually,
> taking the description of the Paging Agent Functional Entity (FE) as
it
> is described in RFC 3154, this functional entity could be split into a
> master FE, currently assigned to the PA node, and multiple attendant
> FEs, located in ARs, responsible for local paging function and mapping
> L3 paging requests to lower layer specifics.
>
> Comments are welcome.
>
> marco
>
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

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