Subject: [Seamoby] proposal on next steps in paging

From: Marco Liebsch <[email-masked]>
Date: Thu, 20 Dec 2001 16:10:59 +0100

Dear all,

in order to proceed with DMHA protocol specification, I propose the
following:
Since the current base-line document is maybe a bit overloaded for being
the first Seamoby WG draft, I will take out the Mobile IPv6 specific
options out of the main part, but keep the generic explicit signaling in
the document. Mobile IPv6 specific optimization could be kept in the
documents annex or in a separate document (what do you think?).
Furthermore, my opinion is that the concept should allow deployment of
several paging strategies, as currently described in the draft. But
maybe it is reasonable to extract the sections on paging strategies out
of the current draft keeping them in a separate document, which could be
further evaluated and extended. This would allow to get a first
framework draft, which is clearly arranged and open for further
specification of open issues.
What about the following:
Coming up with a first famework draft end of January, possibly having
some further ideas and issues already addressed by then. Then we have
about one month in order to prepare a second version ready for
submission right in time for IETF#53.

First issues to be addressed with respect to the base-line concept
should be the issues described in the assessment draft. Maybe this is a
good starting point for proceeding. As mentioned in Salt Lake already,
all protocol proposals have very good ideas, which should be discussed
and considered to be folded into a common WG DMHA protocol draft.
Comments are appreciated.

I am looking forward to working with you all on bringing the DMHA
protocol specification ahead.

Regards,

Marco

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Dec 2001 12:12:58 -0600

Hi Marco,
  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.

  Regards,

--
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Dec 2001 10:30:08 -0800

Behcet,

>   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

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 21 Dec 2001 11:20:49 +0100

Behcet,
you are not satisfied working together on the WG's protocol specification
bringing all the good ideas into the base-line concept? What do you propose how
to proceed then? Please tell me.

Marco

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 21 Dec 2001 13:06:07 -0600

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,

--
Behcet

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Dec 2001 13:53:34 -0500

> areas are under the subnet. We must define how to interface with L2 paging

One technical thing.  L2 paging area as well as L3 paging area is
orthogonal to IP subnet.  While there is a case in which an IP subnet 
contains one or more L2 paging areas, there may be other case in 
which an L2 paging area covers multiple IP subnets.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Fri, 21 Dec 2001 12:37:41 -0800

Behcet,

> Yoshi's email, he also has a strong point there.

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

> 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.

> 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.

> 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.

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.

> must be on the subnet. In case of L2 paging areas TA becomes less

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.

> PDUs and on-link support for dormant mode and time-slot based paging
and so

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