Subject: [Seamoby] DMHA framework draft architecture

From: Marco Liebsch <[email-masked]>
Date: Mon, 14 Jan 2002 13:56:03 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Mon, 14 Jan 2002 10:35:44 -0800

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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 15 Jan 2002 15:13:44 +0100

James,

> as the incoming L3 tracking and paging protocol).

The only difference I see, compared to the architecture described in the
base-line document,  is that you propose to have a further attendant for the
TA located within ARs. Is this correct?
What you propose next is to have periodic updating of redundant composite
Paging Agents, allowing to intervene in case of a composite Paging Agent
failure. Only to understand correctly, this refers more to a lightweight
mechanisms for keeping redundant composite Paging Agents updated, rather
than introducing a complex protocol for PA mirroring and maintenance of
reliability, and has nothing to do with your proposal above, which is
introducing a TA attendant in ARs. Correct?

In case of a failure, the paging area, made up by one or more ARs, should be
the same as before, but the composite Paging Agent, addressing the
respective attendants within a paging area's ARs, is different. Information
on which ARs are assigned to which paging area could be included in the
periodic update information or beeing configured making use of the dynamic
paging area protocol you addressed. Is this understanding correct?

marco