Subject: RE: [Seamoby] Examples of CAR discovery

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 10:25:27 -0500

Satish:

  The reason that CT should remain separate from CAR is that
CT is useful in many scenarios where CAR is not required. Consider
the (trivial) case of an access network engineered to provide all
the necessary QoS capabilities at each AR (note: this does not mean
that the network is homogenous, just designed/configure with forethought). 

  Indeed, if saving time during handover is the issue, then it is
always faster to do as little signalling as possible, which, for
some networks, would be CT without CAR.

  A similar argument can be put forth for the use of an NSIS solution
during handover. Note that I am talking in the general case here, there will
always be situations where the network (including the MNs) will have to
resort to signalling to maintain or re-establish sessions. Mobility is 
always about probabilistic success, and it is overkill to apply worse
case solutions to all scenarios.

Gary

> -----Original Message-----
> From: Satish Jamadagni [mailto:[email-masked]]
> Sent: April 2, 2002 00:39
> To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; [email-masked]
> Subject: Re: [Seamoby] Examples of CAR discovery
> 
> 
> Hi All,
> I feel that CT and CAR should go hand in hand. The reasons 
> are as follows
> (taking a Bottom - Up approach trying to arrive at a CAR 
> protocol from a
> final TAR selection perspective assuming that this is what 
> CAR discovery is
> supposed to assist in)
> 
> Combining CT and CAR -
> 1. Saves signaling time (Time is one of the main factors for deciding
> seamless ness)
> 2. Makes sense as during a seamless HO "Context" preservation 
> is what every
> mobile terminal aims at (we are not considering application 
> adaptation and
> such kind of stuff)
> 3. Typical TAR selection would be based on a "MATCH" of the 
> MN context and
> the AR context support capabilities (any other policies and 
> user fancies can
> also be brougnt under the "Context" perspective (I assume 
> that "context"
> reflects a desired QoS feel at the MT so for all practical purposes
> "Context" and QoS are the same).
> 
> For a TAR selection the MT would send in his present 
> "Context" list to find
> a match. This I guess would be sent to all CARs (with all the 
> signaling
> overheads)
> 
> So for all practical purposes by the time I would have done a 
> TAR selection
> I would have at least achieved a partial CT if the new AR can 
> preserve the
> messages that I use for initial inquiry for TAR selection. 
> All other CARs
> where the MT would have sent a message with a wish list ( its present
> context) can release the context list if the MT finally does 
> not choose them
> based on a timer.
> 
> So I feel a CAR discovery protocol SHOULD identify and standardize "an
> ABSTRACT Context" notion for initial CAR selection and finally should
> provide for classes of Contexts to ease the TAR selection 
> process. The exact
> match algorithms  can be left to implementations. Such 
> classes of contexts
> helps in either a partial or a full CT under TAR selection itself.
> 
> Combining CT and CAR has signaling advantages and this can 
> prove critical
> for a seamless handover where the "objective is Zero latency handover"
> 
> Regards,
> Satish Jamadagni.
> 
> 
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
> To: "'Hemant Chaskar'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 02, 2002 5:46 AM
> Subject: RE: [Seamoby] Examples of CAR discovery
> 
> 
> > Bingo, Hemant,
> >
> > you hit it right in the bulls eye. CAR discovery is
> > about finding the destination, CT will happen after you found
> > the destination. QoS CT will only help maintaining QoS after
> > (or during) the handoff, but it cannot be used to determine
> > where to handoff to.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hemant Chaskar [mailto:[email-masked]]
> > Sent: Monday, April 01, 2002 10:45 AM
> > To: [email-masked]
> > Subject: Re: [Seamoby] Examples of CAR discovery
> >
> >
> > Hi James:
> >
> > Pardon my ignorance here, but isn't CT about *transferring* 
> context rather
> > than negotiating capabilities. In other words, doesn't CT 
> protocol take
> > source and dest. of CT as input? Now, source is obvious, we 
> still need to
> > work on finding dest. which is target AR of handoff.
> >
> > BR,
> > Hemant
> >
> >
> > >From: "James Kempf" <[email-masked]>
> > >To: "Charlie Perkins" <[email-masked]>
> > >CC: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
> > >Subject: Re: [Seamoby] Examples of CAR discovery
> > >Date: Mon, 1 Apr 2002 08:16:02 -0800
> > >
> > >Hi Charlie,
> > >
> > >
> > > > Lastly, we have already some evidence that handing QoS from one
> > > > access router to another access router is about the 
> same as handing
> > > > any other context between routers -- again, under the 
> assumption that
> > > > the basic authorization has already been negotiated at 
> some time in
> > > > the past.  There is no need to have two protocols where 
> one is better,
> > > > regardless of political divisions within the IETF.
> > > >
> > >
> > >This sounds like context transfer, not CAR discovery. QoS 
> was one of the
> > >intended applications of context transfer, so I believe it 
> is in scope.
> > >
> > >             jak
> > >
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _________________________________________________________________
> > Chat with friends online, try MSN Messenger: 
http://messenger.msn.com
>
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 09:13:48 -0800

Gary/All,

So I think what it comes down to is this. Is handover:

1) An opportunity for the mobile node to express its preferences for a
new access router with characteristics that better match what the mobile
node and its user need,

2) A link/routing failure that needs to be fixed up as quickly as
possible.

3) Both of the above.

Most of the discussion/disagreement/confusion (including my own) I've
seen on this list seems to revolve around this question.

My opinion:

For intratechnology, Door Number 2.

For intertechnology, Door Number 1.

Comments?

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'Satish Jamadagni'" <[email-masked]>; "Nakhjiri
Madjid-MNAKHJI1" <[email-masked]>; "'Hemant Chaskar'"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, April 02, 2002 7:25 AM
Subject: RE: [Seamoby] Examples of CAR discovery

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 09:13:48 -0800

Gary/All,

3) Both of the above.

My opinion:

Comments?

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 02 Apr 2002 09:36:20 -0800

Hello Jim,

I have some comments, as requested :-)

> new access router with characteristics that better match what the mobile

No, this is preparation for handover.

> 2) A link/routing failure that needs to be fixed up as quickly as

Handover is not a failure.  Handover is a success.  It happens in
response to an actual or likely routing failure.  The former is
"reactive", the latter "predictive".

>  3) Both of the above.

I would say that handover is neither, but closer to (2) as I have
just indicated.  If pressed, I would define handover as "operations
which expedite the establishment of a new link by a mobile node".
This definition probably still needs some refinement.

> seen on this list seems to revolve around this question.

Maybe, but on the other hand "handover" is like "art".  I might not be
able to articulate exactly what it is, but I know it when I see it.

> For intertechnology, Door Number 1.

I would instead strongly suggest that the definition of
"handover" should have no dependence on whether the access
points offer the same technology{,ies} for establishing links.
Of course, certain things not related to IP connectivity
might depend on that (e.g., framing, data rates), but
the IP mechanisms and the definition should not exhibit
any dependence.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 02 Apr 2002 09:36:20 -0800

Hello Jim,

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 02 Apr 2002 11:52:21 -0800

Jim,

we had a lot of discussion on this. For instance, take a look at
http://www.ietf.org/proceedings/01aug/51-132.htm#TopOfPage

Anyway, here is my (re)take on this.

IP handover: a process that enables a MN to acquire network layer
_connectivity_ when it changes access routers, allowing it to send and
receive
IP packets. IP handover is a routing issue.

CT:  a process that facilitates continued offering of IP features,
typically
during terminal mobility.
CT addresses performance of transport protocols assuming IP
connectivity is available. It is a transport issue.

I thought we had a good understanding on this, especially after London
IETF meeting.

Let me extend the above and say..

CARD: a process that facilitates resolving the prospective link
(identifier)
with its prefix and assocaited capabilities. This comes out as off-link ARP

with extensions.

TARS: a process that assists in selecting _a_ router from among multiple
candidates.

For what it is worth.. I do feel strongly however that these be treated as
separate protocols.

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 02 Apr 2002 11:52:21 -0800

Jim,

with extensions.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 14:29:45 -0800

Rajeev,

Let me number these to make it easier:

1) > IP handover: a process that enables a MN to acquire network layer
> IP packets. IP handover is a routing issue.

2) > CT:  a process that facilitates continued offering of IP features,
> connectivity is available. It is a transport issue.

3) > CARD: a process that facilitates resolving the prospective link
> with its prefix and assocaited capabilities. This comes out as
off-link ARP

4) > TARS: a process that assists in selecting _a_ router from among
multiple
> For what it is worth.. I do feel strongly however that these be
treated as

I agree with this position. I do see another position, however, and that
is that 3) and 4) are subsumed under 1). The reason I mention this is
because in order for the routing to get fixed up, there needs to be a
router. The problem with subsuming 3) and 4) under 1) is that I believe
for intratechnology handovers 1) must be very fast while 3) and 4) are
likely to be slower. For intertechnology handover, or what I think
should more properly be called *wireless media selection* (and that
includes selecting a new router with different IP characterists on the
same media - please note Govind :-), the time scale is more leisurely.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 14:29:45 -0800

Rajeev,

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 02 Apr 2002 16:06:22 -0800

James Kempf wrote:

> router.

Actually, if a MN does not know which AR it is attaching to a priori,
IP handover (per def 1 above) still works!  Base MIP is a good example.
So, without 3) and 4), you could still have IP handovers. With 3) and 4),
the experience is presumably  improved however. Since handover works
with or without 3) and 4), and this includes failure scenarios when 3) and
4) are in place, I wonder about the additional benefit of 1) subsuming
3) and 4)..

> The problem with subsuming 3) and 4) under 1) is that I believe

So, that's the applicability statement for 3) and 4).    :-)

> same media - please note Govind :-), the time scale is more leisurely.

Possibly yes. In any case, if the target link resolution is not fast
enough, the
protocol usefulness is likely going to be questioned. [Read: static
configuration, especially for intra-tech handovers might suffice :-)].

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 02 Apr 2002 16:06:22 -0800

Regards,

-Rajeev

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 17:09:15 -0800

Hello again,

> same media - please note Govind :-), the time scale is more leisurely.

Well, I don't see this.  The target router could well be determined
by current conditions (load, bandwidth availability, etc.) and that
does not necessarily depend on the "type" of the technology.
The protocol may well be used to identify a new access router
on a different wireless medium that has roughly the same speed.
With several variations of 802.11 and Bluetooth and UMTS and
3G coming, this is very likely.  I am not very comfortable with the
term "IP characteristics", since IP pretty much has the same
characteristics no matter what the physical medium happens to
be.  We know the minimum packet size, for instance.  IP itself
doesn't have any delay or speed (for example) characteristics.

The problem you refer to as "wireless media selection" should
not be the focus of the discussion, because we don't want to select
a medium.  We want to select a point of attachment to the Internet.
The medium is _not_ the message.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 17:09:15 -0800

Hello again,

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 3 Apr 2002 10:47:47 -0800

Hi Charlie,

> doesn't have any delay or speed (for example) characteristics.

So it sounds to me like you see the selection basically done on
link characteristics, and not something based on IP service, is that
correct?

> The medium is _not_ the message.

:-)

The problem I'm trying to solve here is I have a laptop with 802.11 and
GPRS and I am wandering through Ginza. The 802.11 service is not
continuous, periodically it drops out. I'm watching streaming video and
it's real jerky on GPRS. I'd like to know when I enter a hot spot, so I
can switch to the smoother 802.11 service. The reason I'm interested in
this problem (speaking here as a WG member and not the co-chair) is
because, within about a year, I expect that DoCoMo could offer this
capability to its customers if we had some way to interoperably do it,
i.e. this is not a theoretical exercise. I believe it should be possible
to accommodate this application of CAR discovery with others, but since
I can see a real need for this, I would certainly like CAR discovery to
solve it.

I don't particularly care whether the 802.11 service is advertised as
"broadband" or "WLAN" to the customer (I don't know what the Japanese
term is for this kind of service due to my limited knowledge of
Japanese), but, the IP stack on the laptop  has got to know what
interface to bring up and configure, so it has to know some kind of
agreed upon name for wireless medium in order to find the interface
card. Which is why I suggested "wireless medium selection".

Most of the other applications of CAR discovery I've heard don't seem
like they have the same time pressure for solution that this one does,
but I'm certainly open to being convinced otherwise.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 3 Apr 2002 10:47:47 -0800

Hi Charlie,

:-)

            jak