Re: [Seamoby] proposal on next steps in paging

Behcet,

>   I am going to  be positive and conciliatory as much as I can. Please
see
> Yoshi's email, he also has a strong point there.

Yes, I agree that we need to make sure everyone understands the
decision process.

>   The satisfactory resolution I think relies on an agreement in
> architecture. Let's agree on an architecture based on the entities
defined
> in RFC 3154 and then I do not care who does the editing.

I believe that is implied. But remember: RFC 3154 is a functional
architecture. The network architecture may cause the functional
entities in RFC 3154 to be grouped into larger entities so some
of the interfaces become internal interfaces and are not
exposed in the protocol. The network entities are those
between which the protocol is defined.

>   Considering the different pieces of IP paging protocol, the right
> architecture would place the entities as follows:
> DMA- takes care of paging registration, packet capturing in dormant
mode
> and starting the paging. Therefore DMA must be placed high in the
> architecture possibly together with the Paging Agent. DMA could be
mapped
> to the MAP of hmipv6 in case of domain-based mobility or paging, or
DMA
> could be mapped to HA of mipv6 in case of home agent based paging.

Well, there is the meta-issue of identifying the DMA with a mobility
specific architectural element, such as the HA or MAP, as we discussed.
Note that this is not saying that an implementation could not combine
a mobility architectural element and paging in one process or on
one host, just that they need to be separable from a network
interface standpoint.

Then there is a scalability issue in mapping the DMA to the HA or MAP.

There is also an issue in initiating a page from the HA. The HA might
be far across the Internet from the paging area where the MN is
located. There may be security and other (like latency) concerns
associated with having the DMA in another domain.

Thus, I think having the DMA in the same administrative domain as
the paging area is important.

> TA- tracks the mobility in dormant mode. see below.
> Paging areas. Whereever available, L2 paging areas must be used. L2
paging
> areas are under the subnet. We must define how to interface with L2
paging
> areas. In here paging triggers can prove useful. L2 paging areas can
> probably be better utilized with the help of paging triggers.

I agree, and I am attempting to set up some kind of IETF context in
which we can discuss paging triggers.

> On links with no L2 paging areas we must define L3 paging areas.

Actually, I think L3 paging areas may be needed regardless of whether
L2 paging areas are available or not. Suppose a mobile device
has 5 interfaces, each of which supports its own L2 paging
protocol. By confining the L2 paging to the last hop, it may be
possible to unify paging in the network and increase interoperability.
For this purpose, there may need to be some map between the
L2 paging areas and an L3 paging area.

>L3 paging
> areas must be IP subnet based.

As was discussed in the problem statement, one key aspect
of IP paging is to get away from a one to one mapping
between subnets and IP paging. This is the case
with current 3G networks (i.e. Location Area Identifiers)
and it is an aspect of inflexibility that the problem statement
identified may be a problem going forward toward
micro- and picocells.

>We must define how to interface, configure
> L3 paging areas.

Well, I certainly agree as the recent discussion on
paging area configuration should indicate. The
issue here is that it is not currently on the Seamoby
charter. My inclination is to wait until the paging
protocol is almost complete before requesting any
addition, but it certainly is a major candidate,
and we can consider requesting that it
be put on the charter if the working
group feels strongly about it.

>Paging triggers can have some limited use here.
> Paging Agent. Paging agent is placed somewhere in the Internet. It
> interacts with DMA and then takes care of paging. Therefore the paging
> agent behaviour can be defined based on the paging areas (L2 or L3).

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.

> TA- tracks the mobility in dormant mode. In case of L3 paging areas,
TA
> must be on the subnet. In case of L2 paging areas TA becomes less
> important.

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. It is a candidate
to group with the PA, IMHO, since they both play an L2 to
L3 transition role if there is L2 paging support.

>   We may develop an architecture document before going on the details
of
> the protocol in an ununderstandable rush. Once we have the
architecture, I
> think that the protocol design will follow smoothly and will deal with
the
> PDUs and on-link support for dormant mode and time-slot based paging
and so
> on..
>
>

I consider RFC 3154, on which you are a co-author, as sufficient
architecture.
Actually, it is far more architecture than is typically done in IETF and
we got some amount of flak for that during its preparation.

I really think we have enough preparation to move forward on the
protocol
design. If you have some ideas about taking the functional architectural
elements that are identified in RFC 3154 and grouping them differently
from the way they are grouped in draft-renker-paging-ipv6-01.txt, then
I suggest you communicate them with Marco and the working group.
What you've outlined above doesn't give me a clear idea about how
you would accomplish such a grouping, however. I agree that the
paging protocol document should have a section that clearly
defines how the functional elements in RFC 3154 map to
network entities between which the protocol would be exchanged.

                    jak

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