Re: [Seamoby] proposal on next steps in paging

[Behcet Sarikaya <[e-mail]>]

Jim,
  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.
  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.
  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.
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.
On links with no L2 paging areas we must define L3 paging areas. L3 paging
areas must be IP subnet based. We must define how to interface, configure
L3 paging areas. 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).
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.
  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..

Regards,

James Kempf wrote:

> Behcet,
>
> >   There is a very important issue with the way paging protocol
> assessment
> > was concluded, i.e. one of the candidate proposals was not eliminated
> in a
> > way which is not acceptable. As I said in one of my previous emails,
> the
> > assessment result is moot.
> >   I do not we can proceed without this issue being resolved
> satisfactorily.
> >
>
> I had taken from your previous email response on this topic that you
> were
> willing to work with Marco and the working group to assure
> that the Seamoby protocol reflected the work in
> draft-guri-seamboy-lahap-00.txt,
> which I presume is the source your discontent. And also to work with
> me and whoever else is interested in moving toward finding an IETF home
> for
> the L2 trigger work on paging which you've been doing. However, it now
> seems that this is not the case.
>
> What do you consider satisfactory resolution?
>
>             jak
>
> _______________________________________________
> Seamoby mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/seamoby

--
Behcet


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby