Subject: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Feb 2002 14:20:41 -0800

I'm separating out the thread about how to get packets from the HA to
the dormant mode mobile so I can follow the issues.

So my understanding of the primary issues are:

1) The alternate CoA won't work because the PA address doesn't belong to
the MN.

2) Using Routing Headers and the Home Address Option to route packets
from the HA to the PA results in awkward and unusual processing at the
PA.

3) It is not clear how packets would get to the MN after it responds to
the page, because the incoming packet has the MN's Home Address on the
encapsulated packet, not the CoA.

Here's a tenatitive suggestion about how to solve this. This requires an
extension to MIP and a MIP binding for the paging protocol, and assumes
that the Paging Agent and DMA are bundled into a network element called
the PA.

1) The MN or the PA (after the right trust relationship has been
established) sends a BU to the HA when the MN goes into dormant mode or
the PA detects that the MN has gone into dormant mode. The BU is not a
standard BU, but a "paging BU", with maybe an additional option or flag.
The address of the PA is included to indicate where the HA should send
any packets. The HA maintains a "dormant mode binding" for the mobile.

2)  When the MN changes paging area, either it or, if an L2 paging
protocol is available, the AR where the L2 paging protocol is terminated
informs the PA. The PA then sends the BU to the HA, the HA changes its
dormant mode binding.
(Note: there is some handwaving here about how the trust relationship
gets transferred from the PA handling the orignal paging area and the PA
handling the new, but this could be solved by having the PAs use a trust
relationship between them to have the original PA do the actual location
update).

3) When the HA receives a packet for a MN for which it has a dormant
mode binding, it sets up a tunnel to the PA and sends the packet down
the tunnel.

4) The PA executes paging, the MN responds after having re-established
its routing by sending a BU to the HA with its new CoA. The response
includes the CoA.

5) The PA then tunnels the packet to the MN at the new CoA. The tunnel
looks exactly like the tunnel from the HA would.

Comments?

                            jak

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

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 15 Feb 2002 12:29:27 +0100

Jim,

> 1) The alternate CoA won't work because the PA address doesn't belong to

In case of MN going dormant, it acquires no CoA when entering a new
lcoation.
Therefore, PA address is the MN's CoA, registered with the HA. Same as
hierarchical approaches intend to do. In my eyes it is reasonable to allow a

MN to register a CoA, which is different to one or more addresses assigned
to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA
sub
option then for?

> from the HA to the PA results in awkward and unusual processing at the

In case of capturing/intercepting packets on a DMA located 'somewhere', is
this processing less unusual? DMA has to check IP-IP encapsulated packets
(when tunnel set up by HA) as well and to re-address after getting CoA info
in order to allow forwarding of buffered packets. I'm not sure.

> encapsulated packet, not the CoA.

Idea was to register an identifyer with the PA when a MN enters dormant
mode. This is the home address in case of MIPv6, as an example. After the
paging trigger packet arrives at DMA FE (currently located in the PA node),
the PA checks registration status and initiates polling the paging area.
During
active registration, MN notifies the PA of its CoA, allowing to forward
paging
trigger packets.

> relationship between them to have the original PA do the actual location

Intentionally, PA node might manage multiple paging areas. This has many
advantages, like keeping PA registration with HA in case of entering a new
paging area, dynamic paging area management (maybe individual paging
areas).. Allowing the PA to send a BU to the HA is a very special case and
requires establishment of a security association.

> its routing by sending a BU to the HA with its new CoA. The response

That's how draft-renker intends to manage.

> looks exactly like the tunnel from the HA would.

...only that the source address of the outer IP header might be the PA
address
instead of the HA address.

marco

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 15 Feb 2002 11:53:36 -0500

Marco,

> to its local interface (e.g. PA, MAP, ...). Otherwise, what is the alt. CoA

I don't think you understand the problem correctly.  In the case of
MAP, a distinct alternate CoA is used by each MN (only the first
64-bit of the blobal IP address for MAP advertised through ND is
shared among multiple MNs and the lower 64-bit part is different per
MN).  In the case of PA, the entire part of the IP address of the PA
is used as the alternate CoA and shared among multiple MNs.

Regards,
Yoshihiro Ohba

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Feb 2002 11:12:41 -0600

Dear all,
I consider this thread bogus,
are you talking about home agent based paging?
DMA is an entity to be used in a MIP independent paging protocol. PA is
commonly used to conduct the paging and as such it exists in both
MIP-based (draft-sarikaya and several earlier drafts have it) and
MIP-independent protocols.
How can you fuse the two?

>On Fri, Feb 15, 2002 at 12:29:27PM +0100, Marco Liebsch wrote:
behcet

---

From: "James Kempf" <[email-masked]>
Date: Sat, 16 Feb 2002 18:55:31 -0800

Yoshi,

> is used as the alternate CoA and shared among multiple MNs.

I think another problem is that Section 10.9 of the MIPv6 draft isn't
clear. What does "in use" mean?
In MIPv4, a Care-of Address is "in use" when it is assigned to an active
network interface on the Foreign Agent. The Foreign Agent isn't the
mobile node. Is this also OK in IPv6? Given that IPv6 uses CoCoA, it
would seem not, but the specification doesn't say that. Just because
HMIPv6 uses Alternate CoA in one way, doesn't mean that is the only way
it can be used. The MIPv6 spec should either state explicitly that the
address is required to be assigned to an active network interface on the
mobile node, or it should say that the mobile node can delegate the
address to another entity which is receiving the mobile node's traffic
on its behalf.

                jak

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 18 Feb 2002 12:30:24 +0100

Yoshi,
I see. This should be clarified what MIP allows. Actually, PA could also generate
a different alternate CoA for each registered MN. This would make use of same
mechansim as you described. The idea was as follows: To explicitly address the DMA
FE in the PA in order to reduce performance desgradation due to tracking all
packets coming by and checking whether or not it is a paging trigger packet for a
registered idle MN. This addresses requirement 4.8, which is to 'make use of
existing registration support'.

In general: MIP approaches belong to the re-addressing based mobility management
protocols, others, like CIP, are routing-based approaches. For the first class of
protocols, explicit addressing of a PA might be a good choice for the reasons
mentioned above. For routing-based approaches, maybe a distributed set of DMAs
might be a direction to go. These DMAs could be located on or nearby border
routers, checking the packets coming by for registered MNs identifiers.

What do you think?

Greetings,

Marco

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 18 Feb 2002 16:20:31 -0500

> is used as the alternate CoA and shared among multiple MNs.

After reading the recent discussion on the mobile-ip mailing list,
I've realized that the above MAP usage is only for basic mode of
HMIPv6.  If HMIPv6 operates in another mode (extended mode), the
alternate CoA (i.e., RCoA) is an address assigned to the MAP.
However, the extended mode is not possible without modifying the way
of intercepting and tunneling packets at HA (i.e., in extended mode,
HA adds a Routing Header to each tunneled packet so that MAP can
deliver the packet to the MN without looking the inner header containing
the global Home Address of the MN).  Although I'm not sure whether the 
this kind of modification is acceptable or not, I think that draft-renker
would also require similar modification to the HA operation.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Feb 2002 16:15:31 -0800

Marco and Yoshi,

I sent email to the MIP list about this and asked Charlie Perkins. I did
not get much of a response on the MIP list, but one person repiled, I
think from the Australian group that implemented HMIPv6.

The general opinion was that the alt-CoA did not necessarily have to be
associated with a configured interface on the MN. There are a variety of
applications where this might be useful, for example, handing over from
a cell phone to a workstation when you entered an office. Paging is
another.

The particular technical twist on paging that makes this more difficult
is that one would like the DMA to perform handover to a new DMA in a new
paging area for the MN when the MN moves in dormant mode, rather than
have the MN wake up, configure its interface, perform the binding update
to the HA with the new DMA's CoA, then go back to sleep. One would
rather like the L2 paging support response to the L2 IP paging area
beacon (if available) or a lightweight IP response (if no L2 support) be
able to cause the DMA to perform the handover.

There is a security issue here. One could imagine the MN sending an IP
AH header secured BU over the paging channel without having to bring up
an interface, but this is pretty unlikely to be universally useful. So
it seems like there may be some need for setting up a trust relationship
between the HA and DMA initially, then being able to transfer that trust
relationship to allow the DMAs in the foreign network to perform the
update.

Am I missing something?

            jak

----- Original Message -----
From: "Marco Liebsch" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Monday, February 18, 2002 3:30 AM
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 19 Feb 2002 14:48:59 +0100

James,

> a cell phone to a workstation when you entered an office. Paging is

As you got from feedback on the MIP list, HMIPv6 makes use of the basic and
extended mode. In my understanding Extended mode works exactly like it is
described for the paging agent, which is addressing the PA from HA (means
paging trigger packets are 'received' at DMA-FE of PA, not 'intercepted').
PA address has been registered with the altern. CoA option at HA. No
modification to MIPv6 is required so far. The only requirement for the HA is
to make use of an additional Routing Header 'in case of having a site-local
home address' registered instead of a global one. Processing at the PA is
exactly as natural or unnatural as it is described for the MAP in extended
mode (assuming a global home address is registered). Assuming global home
addresses, the paging concept makes use of registration mechansism provided
by MIPv6 without any modifications (requirement 4.8). They propose some HMIP
extensions, like a flag in the BU that allows to indicate that the source
address of the IP packet carrying the BU is a 'global CoA'. This allows
avoidance of altern. CoA suboptions, but is specific.

> able to cause the DMA to perform the handover.

If the scope of a PA's capability to manage paging areas would be increased
rather to restrict an individual PA to manage one paging area only, a MN
could move through many different paging areas without sending any binding
update to the HA, since DMA stays the same! Only paging area update
notification to the PA would be necessary. This can be done by signaling
originated from MN or from AR on behalf of he MN, triggered by means of L2.

> relationship to allow the DMAs in the foreign network to perform the

A SA between DMA and mobility agent is reasonable for DMA initiated
registration update (instead of MN initiated), as you described. Same as
above, having one DMA for 'multiple' paging areas could avoid updating each
time the MN enters a new paging area. Then updating DMA at mobility agent
could be restricted to be dependent on binding lifetime. What do you think?

Marco

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 19 Feb 2002 12:19:14 -0500

Marco and Jim,

> avoidance of altern. CoA suboptions, but is specific.

Then, it seems to me that:

draft-renker = HMIPv6 extended mode + DMHA functionality, 

where the part of HMIPv6 extended mode is the hook to MIPv6.

In other words, it actually depends on HMIPv6.

If DMA is put at last hop subnets as described in draft-ohba, then the
hook becomes independent of HMIPv6, since all packets can be captured
at last hop subnets without a special mechanism.  Moreover, if we
consider time-slotted dormant mode support at L3, some agent would be
needed at last hop subnets to provide better synchronization between a
host and network, so putting DMA at each last hop subnet would not be
unrealistic to me.

> originated from MN or from AR on behalf of he MN, triggered by means of L2.

Yes (and draft-ohba takes this approach).

> could be restricted to be dependent on binding lifetime. What do you think?

Yes (and draft-ohba takes this approach).

Yoshihiro Ohba

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 19 Feb 2002 18:32:03 +0100

Yoshi,

> In other words, it actually depends on HMIPv6.

What the mail tries to clarify is that draft-renker makes use of available
registration mechanism, which is a requirement in RFC 3154, since draft-renker
took a MIPv6 platform 'as an example' in order to explain how to integrate the
system modularly.  The discussion intended to clarify, that there is no 'magic'
behind the reception of the paging trigger packet and no 'unnatural' processing of
paging trigger packets within the DMA-FE of the PA.

Regards,
Marco

--

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Feb 2002 09:41:36 -0800

Yoshi,

> In other words, it actually depends on HMIPv6.

Telnet uses TCP, and so does HTTP. Does that mean that HTTP depends on
Telnet?

What this is pointing up is that both HMIPv6 and the IPv6 hooks for
paging in draft-renker are using the same mechanism from MIPv6. As I
mentioned in my email to the MIP list,  I could imagine another
application in which a handoff is done from a cell phone to a
workstation when the cell phone is switched off. What this is pointing
out is that MIPv6 actually has a sufficiently generalized mechanism for
our purposes, a good thing.

> host and network, so putting DMA at each last hop subnet would not be

So explain to me how DMA can be put at the last hop without having a
one-to-one mapping between the paging area and the subnet? That was
never clearly articulated in draft-ohba, IMHO.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Feb 2002 10:03:34 -0800

So it seems like we have some deeper technical understanding of how it
might be possible to separate location tracking from paging in MIPv6 and
have location tracking handled by the mobility protocol. There are still
plenty of details to fill out, but in principle, it seems as if the same
technique as is used in HMIPv6 extended mode would work here as well.

Now, how about MIPv4? Here's a tentative suggestion.

If the FA detected that the MN went to sleep or if the MN signaled the
FA that it was about to go to sleep, the FA could issue a registration
to the HA with the DMA as the CoA. This would require a FA/HA "security
association" (actually not really an IPSec SA but a trust relationship
established by AAA). And also a DMA/HA "security association"?

The FA on the subnet handles dormant mode movement by  conveying the
MN's response to the L2 or L3 paging area beacon to the HA. This is
similar to Yoshi's last hop suggestion, however, it is actually not the
DMA that is at the last hop but rather the TA, along the lines of my
original suggestion that the TA be made mobility protocol dependent.

Comments?

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 19 Feb 2002 14:10:57 -0500

> Telnet uses TCP, and so does HTTP. Does that mean that HTTP depends on

TCP is mandatory for both telnet and HTTP.  On the other hand, HMIPv6
or equivalent mechanism seems to be mandatory for draft-renker while
HMIPv6 is optional for MIPv6.  So the situation is not exactly 
analogous to the case of telnet and http.

> our purposes, a good thing.

I agree that the part of sending BU from MH to HA with alternate-CoA
would be a good thing.  But I don't think that the other part in which
PA has to maintain the binding between CoA and the global home address
(whose prefix part is an on-link prefix of HA, not an on-link prefix
on PA) of a MN.

> never clearly articulated in draft-ohba, IMHO.

This would not be the main topic of this thread, but this would be a
good chance to explain.

In draft-ohba, DMAs are put on last-hop subnets.  A DMA is a separated
entity from Paging Agent and Tracking Agent, and does not have a
knowledge about what is the paging area.  So the DMA sends a Paging
message to Tracking Agent to page the MN.

A Tracking Agent maintains the mapping between MN's terminal
identifier and MN's paging area.  It also maintains a list of Paging
Agents per paging area so that it can forward a Paging message
received from a DMA to the Paging Agent(s) corresponding to the paging
area.  The location of Tracking Agent is arbitrary.

A Paging Agent maintains the mapping between paging area and IP
subnets.  The mapping between paging area and subnet is arbitrary,
i.e., a paging area could contain multiple IP subnets, or an IP subnet
could contain multiple paging areas.  To support the arbitrary mapping
between paging area and IP subnets, the location of Paging Agent is
also arbitrary, e.g., it could be co-located on AR, it could be put
behind ARs, or it could be put on APs.  If a Paging Agent is put far
behind ARs, a list of Access Routers per paging area is maintained at
the Paging Agent and the list is used for advertising paging areas and
for wide-casting Paging messages.  There may be multiple Paging Agents
in a single paging area and this would be useful when a paging area
covers multiple IP subnets or multiple APs while Paging Agents are
co-located with ARs or APs.

Any of two agents or all agents can be co-located in a single node,
depending on various requirements such as scalability, robustness,
complexity.  For example, a DMA and a Paging Agent can be put together
in an AR.  Or a Tracking Agent and a Paging Agent can be put together
in a single node behind ARs.  Or all three types of agents are put
together in a single AR.  And if co-located, external message exchange
is not necessary between different agents.

Yoshihiro Ohba

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Feb 2002 19:25:56 -0600

Hello Jim,

Regarding HMIPv6 extended mode discussion, I am quoting from your mail sent on Dec.
17,2001: (full email is at the archives)
Seamoby group could possibly accept a protocol proposal based on
a protocol that has yet to even complete the requirements phase in
another
working group, to say nothing of the dependence on Mobile IPv6, which
is something the Seamoby working group has tried to avoid. The
HMIPv6-based
paging proposal not only didn't satisfy the requirements, but it set up
a dependence
that could ultimately hamper taking the Seamoby protocol to proposed
standard, if
the Mobile IP group rejected HMIPv6 in favor of another LMM protocol.

>technique as is used in HMIPv6 extended mode would work here as well.
As for draft-ohba, oh yes you are right, I thought Yoshi proposed
draft-ohba in one his emails, it seems that he did not.

>>
>>I do not recall having see this proposal during the current last call
>>period, which started on Feb. 11. However, I will take this email as a
>>proposal from you that the draft-ohba be used. So now we have two
>>proposals for a different base draft, draft-ohba and draft-guri.
>>
Here is another quote from email dated Dec 21 on HA based paging:

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

Have fun.

-- 
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Feb 2002 21:24:46 -0800

Yoshi,

>(whose prefix part is an on-link prefix of HA, not an on-link prefix

Could you explain this some more? I don't understand what having the DMA
mantain a CoA for the home agent has to do with where the prefix of the
HoA is. To me, the DMA looks like a kind of FA in MIPv4, but potentially
remote from the last hop (though it could be there). As long as the
proper trust relationship exists, the MN should be able to allow it to
take over.

> area.  The location of Tracking Agent is arbitrary.

Why not have the paging area identifier simply be an anycast (multicast
in IPv4) address?
And what is a "terminal identifier"? Home address? MAC address?

I still don't understand why having the DMA on the last hop is so
important. Also, I don't understand
how it could work.

Suppose an MN goes into dormant mode  in subnet X in paging area A.
Presumably, the DMA in subnet X now is waiting for packets for the MN.
Now, suppose the MN moves to subnet Y, still in paging area A. Does the
DMA perform a "handover"? If so, what is the point of having the paging
areas? How could it even know? Does the DMA in subnet X continue to
handle the MN? If so, what is the point of having the DMA on the last
hop? Why not move it back, and have the option of an arbitrary mapping
of DMAs to subnets?

The other thing I don't like about this is that if the mobility protocol
is, say, MIPv6, and the TA is in the HA, then the message flows like
this:

        <incoming IP packet for MN> -> HA ----- (across the
Internet) -----> DMA
         DMA ------------------- (across the Internet) ----------> HA
(cum TA)
         HA ---------------------(across the Internet)----------->PA
         PA--------------------------------------------------> MN

So there's a grand total of three traversals of the Internet in order to
page the MN. Not too efficient.

Maybe there is some thing I am missing here?

> co-located with ARs or APs.

OK, we seem to be in some agreement here about the Paging Agent. I do
see the Paging Agent maintaining a list of Access Routers in its paging
area. Also, I see it doing dynamic paging area configuration and
failover.

> is not necessary between different agents.

But you said above that the DMA had to be on the last hop, thus there
are constraints.

I think the DMA and the PA need to be co-located. They could be on an
access router if there
is only one subnet per paging area. Or they could be somewhere behind
the access router.
The DMA hooks for MIPv6 manage the MN's CoA while in dormant mode. It
requires some hooks to support the other mobility protocols as well (see
my message on MIPv4).

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 20 Feb 2002 09:54:11 -0500

> proper trust relationship exists, the MN should be able to allow it to

In general, we should be very careful about sending BU since it could
easility change the behavior of routing in the Internet.  If BU is
sent to a CN (MAP is a CN in the case of HMIPv6), then the binding
cache created at the CN should be applied only to the packets
originated from the CN, not to the packets to be forwarded at the CN.

If a MAP(or PA/DMA) maintains a home address (HoA) where the prefix of
the HoA does not match one of the on-link prefix of the MAP, then
undesired routing behavior could occur, assuming that synchronization
between the two binding caches at the MAP and the HA for HoA is
impossible.  For example, if the lifetime of the binding cache of the
MAP is shorter than that of the HA (an attacker can easifly change the
lifetime for the BU for the MAP and the BU for the HA), then a routing
loop can easily form between the HA and MAP during the period in which
the binding cache at the MAP is deleted (due to expiration of the
lifetime) while the binding cache at the HA remains active.

Otherwise, if a MAP(or PA/DMA) maintains a HoA where the prefix of the
HoA matches one of the on-link prefix of the MAP (HMIPv6 basic mode
belongs to this case), then no routing loop occur even if the lifetime
of the binding cache is not synchronized between MAP and HA (If the
MAP does not have a binding cache while HA has, then packets tunneled
from the HA will be simply discarded at the MAP).

So, I think that a solution relying on the HMIPv6 extended mode is not
acceptable.  A solution relying on the HMIPv6 basic mode seems to be
less problematic, but the technique would be applicable only to IPv6,
not to IPv4...

BTW, this technical discussion raises one issue as Behcet pointed
out: the selection team needs to explain for the fact that they
rejected one of the proposals because it depends on HMIPv6 and the
fact the selected proposal also turned out to depend on a mechanism
which is virtually equivalent to HMIPv6.

> And what is a "terminal identifier"? Home address? MAC address?

Because paging area can be different per MN (personalized paging area).
Anycast (or multicast in IPv4) is not defined per host, I think.

Regarding terminal identifier, it is described in section 5.1.11 of
draft-ohba:

  If Host supports Mobile IP [MOBILEIP] or Mobile IPv6 [MOBILEIP-V6],
  the Home Address of the Host MAY be specified in this TLV.

Essentially, any stable identifier can be used as the terminal
identifier.

> important. Also, I don't understand

Having the DMA on the last hop is important for (i) working with any
mobility management protocol and null mobility management protocol
(i.e., stationaly hosts) and (ii) avoiding a single point of failure.

> DMA perform a "handover"? 

No.  The MN can stay dormant without performing handover.  When the
DMA captures a data packet destined for the CoA, it sends a Paging
message to Paging Agent (via TA) and Paging Agent can "page" the MN.
Note that since the DMA is on the last hop subnet of the subnet of the
CoA, any data packet in which the CoA is specified in the destination
address is captured without an exception regardless of what kind of
mobility managenet protocol is used, and this is one of the reasons
for why DMA is in last hop subnet as I explained above.  The DMA does
not have to know what is the paging area, because TA and Paging Agent
have the knowledge on the paging area.

The DMA is used just for capturing a data packet and then triggering 
paging.  

> If so, what is the point of having the paging

In that particular case, why not putting the DMA on the HA?
Then it could be much more efficient as: 

          <incoming IP packet for MN> -> HA (=DMA=TA)
           HA ---------------------(across the Internet)----------->PA
           PA--------------------------------------------------> MN

> But you said above that the DMA had to be on the last hop, thus there

But less problematic, I believe.

Yoshihiro Ohba

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Feb 2002 09:48:27 -0600

Thanks Yoshi.
It is clear that the discussions led to the identification of what is
missing in draft-renker which already exists in other drafts, such as
DMA (DMA-FE as Marco calls it) is already in draft-guri for IPv6 and in
draft-ohba for IPv4 and (P)MAP in draft-sarikaya.
Why don't we say to Marco, Marco, sorry but you missed the train
and continue our business?

Regards,

-- 
Behcet

---

From: Tao Zhang <[email-masked]>
Date: Wed, 20 Feb 2002 10:58:47 -0500

James,

In addition to Yoshi's reply to your following question regarding
draft-ohba, please see my comments below.

> requires some hooks to support the other mobility protocols as well (see

The DMA does not have to be on the last hop. Placing a DMA on every last-hop
subnet is one way of implementing the paging protocol which will enable the
paging protocol to be completely independent of mobility protocols. However,
if we know what mobility protocol is used and wish to optimizee the paging
protocol for that particular mobility protocol, the DMA does not HAVE to be
on the last hop. For example, if the mobility protocol is MIPv4, the DMA may
be co-located with the FAs or the HA. The jobs of the DMA are to capture
packets destined to a dormant host and trigger the paging process. Where to
put the DMA in a real network can be determined based on how much dependency
or collaboration one wishes the paging protocol to have on/with the mobility
protocols.

The DMA and the PA MAY be co-located, but do not NEED to be co-located.

Regards
Tao Zhang

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 20 Feb 2002 13:24:24 -0500

> and continue our business?

Note that draft-ohba is for both IPv4 and IPv6.  

And I don't much care about whatever protocol is selected as a
starting point, as I mentioned earlier.  But I do care about what the
final WG product will be.

Thanks,
Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Feb 2002 19:31:43 -0800

Yoshi,

> lifetime) while the binding cache at the HA remains active.

I guess I don't see how this follows. If the binding cache entry at the
MAP
times out, it simply drops the packet when the HA forwards it. How does
the loop form?
(I'm assuming we are talking straight HMIPv6 here, and not paging.)

> less problematic, but the technique would be applicable only to IPv6,

Still not clear to me.

But you do bring up a good point here.

In order to have the DMA relay the MN's paging area movement to the MN,
it would have to keep around the MN's HoA, which is a piece of MN
location
state. It would be good to avoid this, but I don't see how short of
requiring
the MN to come out of dormant mode and issue the BU when it changes
paging area.

> which is virtually equivalent to HMIPv6.

This is a category error.

As I said before, draft-renker depends on a particular way of using
MIPv6.
HMIPv6 depends on a particular way of using MIPv6. This does not make
draft-renker equivalent to HMIPv6.

To see the error, suppose draft-renker would have been published before
HMIPv6. Would that make HMIPv6 "virtually equivalent" to draft-renker?

> Anycast (or multicast in IPv4) is not defined per host, I think.

But the MN doesn't have to have a personalized paging area, that is
a policy option. Anyway, the point is, it can be an IP address.

> Essentially, any stable identifier can be used as the terminal

OK.

> (i.e., stationaly hosts) and

This isn't clear (but I see you explain it better below).

> (ii) avoiding a single point of failure.
>

But you could have multiple DMAs behind the last hop. And, as I have
mentioned in previous notes (and I believe you even specified in
draft-ohba) the DMAs can exchange periodic messages. If a message falls
out, others reconfigure to take over. The router solution.

> CoA, any data packet in which the CoA is specified in the destination

What does the CoA have to do with it? The MN is in dormant mode, roaming
across multiple
subnets. It no longer has a fixed CoA. Or, are you proposing that the
CoA stay the
same as when the MN went to sleep? That's the point I was trying to make
about
the extreme message legs across large chunks of the Internet.

> The DMA is used just for capturing a data packet and then triggering

It seems like what you are saying is that, in essence, the Access Router
in the last hop must maintain the state for any dormant nodes that have
gone to sleep, presuming we map the DMA to the Access Router.
But I thought we wanted to offload this state from the Access Router.

>            PA--------------------------------------------------> MN

Well, then the DMA *certainly* isn't on the last hop, is it? :-)

Also,  I think we want some way that we can avoid having the MN come out
of
dormant mode to do a MIPv6 BU when it changes paging area. I'd like
somebody in the network
to be able to do it for the MN. It is much more efficient powerwise, and
it allows using an efficient (and existing) L2 paging protocol without
requiring that protocol to carry IP.

But perhaps this isn't possible to do (securely).

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Feb 2002 20:20:25 -0800

Tao,

> The DMA and the PA MAY be co-located, but do not NEED to be
co-located.

OK, now this is starting to make a little sense to me. If the DMA
doesn't need to be at the last hop,
then I think we could arrange to optimize as you say, and consider that
as part of adding something
to the mobility protocol for paging and not changing it fundamentally. I
think that would be better than specifying
it at the last hop and then incurring the messaging overhead.

Since I think we now seem to agree on this point, then maybe we can move
the focus to what I think is
a more important design question. Is there any way to arrange the DMA
and TA in MIPv6 so that a) the foreign network is not maintaining any
location state for the mobile node, including not maintaining the home
agent address, and
b) that the MN doesn't have to come out of dormant mode to do a BU and
can use an existing, lightweight L2 paging protocol or lightweight IP
protocol to somehow get that done by the network, modulo the security
question.

I think these goals may not be reconcilable, but I hope I am mistaken.

For MIPv4, the problem seems much easier to solve because the FA can
change the registration for the MN when the MN changes paging area
(provided the right security association exists).

                jak

PS: In Hawaii paging, I think the DMA and TA will be in the foreign
network, because mobilitiy management is localized, unlike MIP. They
won't be on the last hop though, at least, not according to Ram's
Mobicomm paper of last year.

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 21 Feb 2002 12:05:10 +0100

Yoshi,

> message to Tracking Agent to page the MN.

As already described, putting the DMA on routers in a distributed manner, is a
good approach which is probably required for e.g. routing based mobility
management approaches, since paging trigger packets do not address the DMA
directly. This is described for the concept in draft renker, which allows to
take away DMA functional entity from PA and locate it on e.g. border routers.
I'm not sure if placing the DMA on the last hop is the right approach. Your
proposal 'last-hop DMHA' proposes a rather distributed architecture, having a
lot of communication and protocol message exchange between the entities. I am
not sure if this complexity is really necessary in order to design a scalable
and flexible system. In draft-renker, taking the DMA functional entity away
from PA and placing them on or close to border routers, is an option. But for
the described example mobility management platform MIPv6, the PA makes use of
available registration mechansims and allows addressing the DMA function.
Again, in order to avoid replying emails w.r.t the latter sentence: This does
NOT mean, that the concept is dependent on MIPv6. And also not on HMIPv6. This
should be clear. Separating the DMA is a minor issue and only a small fraction
in the entire paging issue, addressing 'how deoes the IP paging architecture
gets paging trigger packets'. What should be considered is the entire
architecture described, which keeps flexibility without introducing
unnecessary complexity..

Marco

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 21 Feb 2002 13:46:51 +0100

Hi Yoshi and James,

I do not understand why the discussion is now on MAPs and HMIPv6 ??? Original
issue was 'how are paging trigger packets received/intercepted at the DMA'.
Isn't it?
1st issue: DMA receives or intercepts paging trigger packet
2nd issue: DMA makes use of the MN identifiers in the paging trigger packet in
order to request other functional antities to resolve paging area and to
acquire exact routing information for the MN registered as idle.

draft-renker describes an architecture, where the DMA functional entity can be
integrated with the PA function and considers distributed functional entity,
e.g. on border routers. For a MIPv6 managed system, the concept proposes the
explained registration mechanism (meeting the requirement 4.8). It considers
to extract the DMA fucntional entity. The entire concept ( PA, AR attendants
and integrated or separated DMA ) intends to design a flexible architecture
without introduction of unneeded complexity.

draft-ohba describes an entirely distributed architecture with a lot of
protocol interaction between entities, also considering distributed DMA (as
described, its on the last hop)..

DMA location is obviously different for individual platforms and scenarios.
But not only DMA, but entire architecture advantages and disadvantages should
be taken into account.

Marco

---

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Feb 2002 05:18:47 -0800

Marco,

>Separating the DMA is a minor issue and only a small fraction

Actually,  I think getting the DMA part right is one of the critical
questions.
It is where paging impacts routing, and if we don't do it right, we
could end up with a design that compromises routing in critical
ways, or introduces yet another "agent" that can compromise
robustness. That's why I'm happy we are spending so much
time on it.

We should try to have a discussion about this in Minneapolis.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Feb 2002 05:24:08 -0800

Marco,

I agree. Perhaps we can take the discussion on HMIPv6 to the MIP list.

            jak

----- Original Message -----
From: "Marco Liebsch" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Thursday, February 21, 2002 4:46 AM
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 21 Feb 2002 14:38:23 +0100

> (I'm assuming we are talking straight HMIPv6 here, and not paging.)

Since the Paging Agent is not a MAP (!), paging related information is to be
maintained in an individual and synchronized way in order to avoid
compelling a MN to wake-up in order to maintain paging related registrations
even though mobility related registration is still valid. draft-renker
discusses some of these issues, which is e.g. (in case of MIPv6) preferring
a longer lifetime at HA for PA registration as alternate CoA. Since it is
not desirable to modify the mobility management system when integrating
paging, the paging system has to cope with re-registration. This is the same
for a PA registration at a HA (as draft-renker describes as an example) as
well as for a MN's CoA registration (as proposed for an interception based,
distributed DMA architecture). When having appropriate security associations
established, respective entities of the paging system could do
re-registration on behalf of the mobile node.

> the MN to come out of dormant mode and issue the BU when it changes

Again, in case of keeping a DMA as long as possible for an individual node,
no handover is required and no BU is to be sent to the mobility agent. When
entering a new paging area, Tracking Agent functional entity is to be
notified, requested by the same DMA to initiate paging in case of incoming
paging trigger packets.
That's what draft-renker describes. As far as I understood, Yoshi mentioned
that this is what draft-ohba allows as well.

> HMIPv6. Would that make HMIPv6 "virtually equivalent" to draft-renker?

Right, but I do not like the expression 'depends' on a particular way of
using MIPv6. It's a generic concept. In order to meet the requirement 4.8 we
described a way, the architecture deploys the registration mechanisms
provided by the mobilty protocol. This does not make it dependent. A
distributed DMA function is also possible.

> a policy option. Anyway, the point is, it can be an IP address.

Right, personalized paging areas is an option, but an important one. This is
discussed and allowed in draft-renker. It is not clear to me how individual
paging areas could be managed with a static assignment of a paging agent
functional entity to a paging area.

For the terminal identifier, the paging system has to cope with the
identifier a paging trigger packet carries. This can be the home address in
case of MIPv6, as Yoshi explained, which leads to the same thread again
discussing processing paging trigger packets in the draft-renker concept
(which was said to be unnatural).

Marco

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 21 Feb 2002 14:51:42 +0100

Behcet Sarikaya wrote:

> ....
> ....

Behcet,

I am looking to your statements for quite a long time, which are actually
not technically beneficial, but only destructive. Is this the way
standardization work in IETF should be driven? If yes, then this is very
unfortunate.

Marco

---

From: Pars MUTAF <[email-masked]>
Date: Thu, 21 Feb 2002 15:01:52 +0100

Hello all,

A terminology question:

Should we use the term "mobile node", "mobile host" or just
"host"?

> functional entity to a paging area.

It would be good to have some flexibility on that issue...

Regards,
pars

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 21 Feb 2002 16:28:07 +0100

James,

of course it is definitely a big issue. I only wanted to express that
quality of a concept should not only be dependent on where the DMA
functional entity is described to be located for an individual example. The
entire architecture should be looked at w.r.t complexity, flexibility and
reliability. Again, the DMA issue an important one to be studied
thoroughly.

Marco

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Feb 2002 10:16:53 -0600

Hello Yoshi,
draft-ohba 00 was on IPv4, I think. Refering to your section 5 on
message formats, I thought you mainly addressed v4 formats. Yes it is
true that in previous text you try to accomodate IPv4, IPv6, Mobile IPv4
and Mobile IPv6. I have been indicating all along that this is a
mistake. Hope you come to agree it.

>final WG product will be.

Are you throwing the towel?

-- 
Behcet

---

From: Tao Zhang <[email-masked]>
Date: Thu, 21 Feb 2002 11:43:42 -0500

James,

> location state for the mobile node, including not maintaining the home

It will be nice to figure out such a solution and I think it is worth a try.

One issue is that if there are multiple paging areas in a foreign network
and the location states for dormant hosts are not maintained in the foreign
network but rather, say, in the home network, the home netowrk (or any
network that needs to maintain the mobility states) will have to understand
the paging areas defined in the foreign network. However, each foreign
network may have their own ways of defining and representing these paging
areas and may not wish to disclose much information regarding their paging
area configures to an outside network for competitive reasons. Another issue
is that each foreign network may wish to implement its own paging
algorithms. Some paging algorithms may need close interactions with location
update strategies used to update dormant host locations. If location state
is not maintained in the foreign network, it may become difficult for the
paging algorithms in the foreign network to interact with the dormant
location udpate strategies.
For example, one location update strategy is to send not only the current
paging area ID but also the last paging area ID so that the paging algorithm
can analyze the movement pattern of the mobile and use it to determine the
area to page the mobile. This will be difficult to implement if location
state for a dormant mobile is only maintained at, say, the home network
(i.e., when location update is done with the home network only).

> protocol to somehow get that done by the network, modulo the security

If we do not require every location update to be done with 100% reliability
(which seems to be a reasonable assumption), there will be no need for the
dormant mobile to obtain a new IP address or perform BU just for the purpose
of performing location update in a subnet different from the one in which it
entered into dormant mode. It can simply wake up to the level that it can
send IP packets, send an location update (or a few to increase the succes
probability), and go back to sleep right away. This may not take too much
time (it should be much shorter than getting an new IP address and then
performing BU). It also reduces the dependency on L2 techniques for dormant
host location update.

> Mobicomm paper of last year.

If I understand Ram's 2001 Mobicom paper correctly, there is no separate TA
entity in HAWAII paging. The DMA and the PA functions are combined into an
entity called a paging initiator. Any base station and router in a HAWAII
network will be equipped with the paging initiator functionality. HAWAII
uses host-based routing and combines location update with routing. In
particular, the network maintains a host-based paging route for each dormant
host and the route leads from the DRR to the base station from which the
network received the last paging update from the dormant host. When the
dormant host updates its location, the host-based paging route for this
mobile will also be udpated accordingly (therefore no need for a separate
TA). The base station and any router on the latest paging route knows how to
send paging messages to the corresponding paging area to which the paging
route leads. The base station on the latest paging route for a mobile will
be the default paging initiator that pages the mobile upon receiving user
packets. Each base station is indeed in the last hop. Any router along the
latest paging route could also be a paging intiator (to allow load balancing
and increase reliability).

Thanks
Tao

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Feb 2002 12:02:36 -0500

Jim,

> (I'm assuming we are talking straight HMIPv6 here, and not paging.)

I don't think MAP can simply discard it.  What if the MAP is on the
path between CN and HA and the MAP receives a packet destined for HoA?
Do you change the processing rule depending on whether the HoA is
included in an IP-in-IP encapsulated packet or in normal IP packet
without IP-in-IP encapsulation (I know that Mobile IPv4 Foreign Agent
does a similar thing to avoid routing loop)?  Then, what if the MAP is
also a tunnel end-point of other protocols and a packet received on
that tunnel and also contain the HoA as the destination address?

Anyway, HMIPv6 and draft-renker uses the same mechanism that is not
used in Mobile IPv6 in order to redirect packets from HA to an agent
(MAP or PA) and a DHMA protocol should not mandate the mechanism until
HMIPv6 is finalized.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Feb 2002 12:54:37 -0500

On Thu, Feb 21, 2002 at 10:16:53AM -0600, Behcet Sarikaya wrote:
> message formats, I thought you mainly addressed v4 formats. 

No.  What makes you think in such a way?

> Yes it is

That depends on the layer where the DMHA signaling is supposed to work.
If it is supposed to run over L4, then is should be a single document.

> Are you throwing the towel?

I guess your goal is different from my goal.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Feb 2002 13:53:13 -0500

> out, others reconfigure to take over. The router solution.

As Tao mentioned, if we can use a stable method (unlike the method
used in HMIPv6) for redirecting packets from HA to DMA at arbitrary
location, DMAs could be put behind the last hop.

> the extreme message legs across large chunks of the Internet.

Sorry, CoA was not a good word.  It could be HoA when DMA is co-located 
with HA.  In fact, we have the following description in section 4.15 of 
draft-ohba:

4.15.  Supporting Mobility Management Protocol

   If a Host is a mobile node, it is able to move around while it is in
   a dormant mode, with changing L2 attachment points or L3 subnets but
   without changing its IP address.

   It is possible for a Dormant Monitoring Agent to be co-located with a
   Home Agent of Mobile IP so that packets destined for the mobile
   Host's home address are captured at the Home Agent for triggering
   paging operation before it is forwarded to the care-of address,
   instead of having a Dormant Monitoring Agent at each last hop subnet
   in foreign networks.  This is still consistent with the definition of
   Dormant Monitoring Agent because the mobile's home network is
   considered to be the last hop subnet in terms of home address.
   Alternatively, if inter-administrative domain paging is not allowed
   due to network management policies, a Dormant Monitoring Agent can be
   co-located with a Foreign Agent of Mobile IP.

I think this is one of what you want.

[...]

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Feb 2002 14:19:25 -0500

> > a policy option. Anyway, the point is, it can be an IP address.

Yes, that can be an IP address.  I guess this is not an essential 
issue compared with other issues.

> functional entity to a paging area.

This is a good point.  Fxine-grained assignment of personal paging
area is difficult with a static assignment of a paging agent, unless
all paging agents are co-located with base stations.

> (which was said to be unnatural).

Yes, it will lead to the same thread, except for the case DMA is
co-located with HA.

Yoshihiro Ohba

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Feb 2002 17:39:09 -0600

Hi Yoshi,
As for the message formats, draft-guri defines them as destination
option extension headers. I could not see any such specification in your
section 5. I thought that you defined your messages as IPv4 options.

MIPv4 (RFC 3220) defines registration messages as UDP messages (e.g.
port 434 is defined as destination port) but the tunneling is IP based.
No one considers MIPv4 as L4 protocol though. I think that in IPv4 there
is no other way, so maybe you should also have defined the paging
messages as UDP messages, something to note for the next version?

MIPv6 uses IPv6 extension headers to define BU/BAck UDP is not used at
all. MIPv6 also is not considered L4 protocol.

As for layering, what you said is correct, i.e. if we define as L4 then
of course IP Paging is above IP layer so we can define one independent
of IP or MIP version as UDP or TCP is.

Has anybody (any of the 5 drafts) defined it that way? My answer is no.
Because then you have to define source and destination ports on which
the L4 protocol will work.

This has been very useful, hopefully people will realize the need for
multiple drafts.

Behcet

---

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Feb 2002 15:56:42 -0800

"host" No reason why a fixed host couldn't use paging. On the other
hand, I don't think a router would, so "node" is too broad.

            jak

----- Original Message -----
From: "Pars MUTAF" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 21, 2002 6:01 AM
Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility
Protocol Issues

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Feb 2002 19:11:18 -0500

> the L4 protocol will work.

Yes, draft-ohba is defined it that way. i.e., using UDP as transport
for all signaling messages, and that's why I mentioned: "That depends
on the layer where the DMHA signaling is supposed to work."

Yoshihiro Ohba

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 22 Feb 2002 12:42:33 +0100

Yoshi,

Yoshihiro Ohba wrote:

>    in foreign networks.

this would require pre-establishment of a security association between DMA and
TA/PA located in foreign network. Anyway, this is what we discussed in our
proposal, to allow paging areas beyond the scope of an admin. domain, which is
allowed to be managed at the paging agent node, but addressing the additional
security issue where a pre-establishment of a SA netween PA and PA-attendants
in ARs is to be taken into account.

> This is still consistent with the definition of

Is there any difference between the latter approach in your description and
what the Paging Agent node-DMA combination for Mobile IPv6 provides w.r.t
routing issues addressed in this thread?

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 22 Feb 2002 13:06:50 +0100

Yoshi,

> all paging agents are co-located with base stations.

I am not sure, but I think this is exactly written in the requirements (maybe I
misinterpreted)

'...each paging area is served by a unique paging agent...'. I think what we did
in our proposal loosens this requirement a bit, since we allowed a paging agent to
support multiple paging areas, which could be individual (personal) ones. Anyway,
I think this is still in relation to what the requirement sais, having a unique
paging agent per paging area (which could be a static one or an individual one).

Marco

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 22 Feb 2002 07:02:50 -0800

Hello folks,

I think we should allow for routers to use paging.

For instance, I may have a wide-area wireless router
that forwards packets to other short-range wireless
devices attached to my belt.  That router still needs
to be able to make use of paging as a way to conserve
battery power.

Regards,
Charlie P.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Feb 2002 10:33:14 -0500

> routing issues addressed in this thread?

Good question.

When Mobile IPv4 Foreign Agent operates in co-located Care-of Address
mode (I think RFC3220 supports this), the Mobile IPv4 registration is
forced via the FA but the the IP-in-IP tunnel is terminated on the MN,
not on the FA.  This case does not raise the routing issue I
mentioned.

On the other hand, when Mobile IPv4 Foreign Agent operates in Foreign
Agent Care-of Address mode, the IP-in-IP tunnel is terminated on the
FA.  This case raises the routing issue I mentioned.  But this is the
problem of vanilla Mobile IPv4 and out of the control of DMHA, I
think.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Feb 2002 10:42:22 -0500

Marco,

RFC3154 talks about functional elements.
A single PA-FE could be realized by multiple protocol entities 
of the same name 'PA'.  So I don't think we loosen the requirement.

Yoshihiro Ohba

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 22 Feb 2002 12:17:22 -0600

Hi Yoshi,
It is one thing to say the signaling messages sent over UDP, it is
another thing to say LA-DMHA is an application layer protocol which runs
over UDP.
On page 5 of draft-ohba, the first sentence states LA-DMHA is an
application layer protocol which runs over UDP.
Of course in MIPv6 they could have defined BU/BAck as UDP messages, I
think that they wanted to have the whole operation including signaling
to be independent of higher layers.
Main paging functionalities such as packet capturing (not only for one
specific application but any application running at the host) and paging
operations are IP version specific.
For example paging areas and related interactions utilize multicasting
which is different in IPv4 and in IPv6.
For example packet capturing and forwarding are also version dependent.

So just because we can define the signaling using UDP does not render
the protocol an application layer protocol. IP Paging with its
functionalities so basic to all applications running on a host can not
simply be application layer protocol.

IP paging can not also be defined as a transport layer protocol because
it is not a new transport mechanism. L4 protocols such as UDP, TCP and
SCTP define specific transport mechanisms. That's why they are transport
layer protocols.

Hope you agree with the above.

>on the layer where the DMHA signaling is supposed to work."
--behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 22 Feb 2002 12:30:15 -0600

Hi Marco,
  RFC 3154 has this on page 10 in section 5.1:
 Each paging area is served by a unique Paging Agent.
I think that in some drafts this was interreted as  we need to have a 
paging agent for each paging area.
Certainly this statement is not saying that. But it is allowing a 
one-to-one mapping as well.

-- 
Behcet

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Feb 2002 21:35:23 -0500

> Hope you agree with the above.

Not yet.  I have a counter example.  Realm-Specific IP (RFC3103),
which is a NAT technology, defines an application layer protocol for
controlling a NAT box, while actual data packet transfer through the
NAT box is version dependent.

Yoshihiro Ohba

---

From: Pars MUTAF <[email-masked]>
Date: Sat, 23 Feb 2002 17:21:41 +0100

Hello,

We (myself and Claude Castelluccia) have submitted a detailed
threat analysis of using paging in the Internet. The abstract is
below.

Interested people can see that document by clicking on the
following link:

http://www.inrialpes.fr/planete/people/mutaf/draft-mutaf-paging-threats-00.txt

If you have time, we are especially looking for your precious
comments on the "malicious paging signaling" attack
which exploits legitimate dormant hosts (Section 4.1).
This is serious, because "paging" which is intended for
optimizing bandwidth use, may become a bandwidth threat.
IP layer solutions may be necessary. This is, perhaps, one more
motivation for IP paging.

The questionable issues were whether the attack is feasible and
the DoS gain of paging in the Internet. This is what we tried to
analyze.

Thank you in advance.

Best regards,

Pars Mutaf

---------------

                                 IP Paging Threat Analysis

Abstract

   This document is an analysis of threats that arise from using
   link layer paging technologies or IP paging in the Internet
   where denial-of-service attacks are common and easy. These
   problems fall in the scope of IP paging, since link layer paging
   technologies do not have provisions for repelling such threats
   and the source of an attack may be anywhere in the Internet. In
   addition, vulnerabilities that may be added by IP paging are
   also discussed.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 27 Feb 2002 18:23:03 -0600

Hi Yoshi,
I just saw a paper entitled Application Layer Mobility Using SIP by
Schulzrinne in which as part of SIP which is an application layer
protocol a paging protocol is very shortly described. Paging is used to
alert the mobile host in dormant mode in order to forward SIP Invite
request.
You can certainly define such things for specific applications but then
for each application, another paging protocol will have to be defined.
In the same paper mobility is defined for SIP not using Mobile IP.

Maybe now you will be convinced where IP Paging should be placed in
layering.

-- 
Behcet

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 27 Feb 2002 20:08:33 -0500

> Maybe now you will be convinced where IP Paging should be placed in

Not yet.

As long as IP Paging is defined as a separate protocol which is
independent of any existing application layer protocol such as SIP, it
logically does not matter whichever layer it is defined and thus
defining IP paging in application layer is also valid in this regard.
There must be other factors to determine the layer where IP paging is
defined.

Yoshihiro Ohba

---

From: "pdn \(N9FCW\) in FL" <[email-masked]>
Date: Wed, 27 Feb 2002 20:45:31 -0500

With the challenges facing mobile hosts these days, cross layer design is
becoming the
"way things are built".  The layers are only really useful as design
abstractions.  I believe
most implementers are finding that they must build tight coupling between
the PHY-MAC
LLC--IP and in some cases the routing layer for higher speed mobile nodes.
Of course there
is a solution which seems to have died several deaths in the IETF.  That is,
a generic
and efficeint triggering system into and out of IP, for the express purposes
of cross layer
design.

-pdn

----- Original Message -----
From: "Yoshihiro Ohba" <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 28 Feb 2002 08:50:24 -0800

Phil,

> and efficeint triggering system into and out of IP, for the express
purposes

I think a better design principle is to keep a clear idea of what each
layer is supposed to
accomplish and what information is needed from lower layers or higher
layers to accomplish it. Rather than
a tight coupling, I think a collection of design abstractions that
clearly deliniate the contract
between layers is more useful. One can do that with abstract triggers,
and I believe there may be some hope for work on this in the IETF.

            jak