RE: [Seamoby] Minutes for Meeting at IETF 53
"Gary Kenward"<gkenward@nortelnetworks.com> Thu, 18 April 2002 16:37 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13844 for <seamoby-archive@odin.ietf.org>; Thu, 18 Apr 2002 12:37:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12927; Thu, 18 Apr 2002 12:26:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12900 for <seamoby@optimus.ietf.org>; Thu, 18 Apr 2002 12:26:47 -0400 (EDT)
Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13505 for <seamoby@ietf.org>; Thu, 18 Apr 2002 12:26:41 -0400 (EDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3IGQDA28399 for <seamoby@ietf.org>; Thu, 18 Apr 2002 12:26:14 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <JCV28466>; Thu, 18 Apr 2002 12:26:14 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A4A@zcard031.ca.nortel.com>
From: Gary Kenward <gkenward@nortelnetworks.com>
To: seamoby@ietf.org
Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
Date: Thu, 18 Apr 2002 12:26:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E6F5.AAF3AFBC"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
My observation on this MN centric approach is that, to me, there
are logical flaws. Let me present these flaws in two cases; I will
refer to the "old and candidate" networks, meaning the network that
was supporting the MN, and a network that is a possible candidate
network for handover of the MN's traffic. Each has an AR, AP, etc.
1. The old and candidate networks have an interworking capability:
in this case, the networks have a more complete, and current
view of the services available before and after handover. The
proposal is to use CAR to ship information describing this view
to the MN. At best, this implies using wireless bandwidth, and MN
CPU cycles and battery power to make a decision that can be made
by two networks that have relatively unlimited link bandwidth,
CPU cycles, and power.
Note that if the two networks are under the same administration,
it would seem reasonable to assume that the networks are deployed
with some sort of interworking capability.
2. The old and candidate networks have no interworking capability,
e.g. they know nothing of each other. In this opposite extreme,
the primary model is essentially one of an IP service running
over two wireless access networks. Since, by definition, the MN
is the main common element between the two networks, it would
appear to make sense to have it make the handover decision.
There are then three alternatives to how the MN can access the
information from the candidate network: the candidate network
broadcasts capability information "regularly" over the wireless
channel; the candidate network responds to all requests for
capability information; and, the candidate network responds
to authorized requests from a specific MN (implying that the
MN is authenticated).
Now, at this point, I will assume that each network has an
operator that wishes to recover his/her investment in spectrum,
equipment, backhaul links, operating costs, etc. In a commercial
operation, it is reasonable to assume competition: what operator
would be willing to promiscuously broadcast capability information
about their network that could be used by a competitor to lure
away customers? Wireline network operators are leery of exposing
any information that might identify their network topology or
how it operates, and so why would a wireless operator be different?
So, this implies that the MN must establish a link with the candidate
network, be authenticated and authorized to receive capability
information. A lot has to happen before IP packets can be exchanged
(CAR is an L3 solution), and, in order for capability discovery
to be useful, the MN must be in communication with at least two
candidate networks. If the MN is assumed to have single channel,
multi-mode NICs, this discovery process has to occur sequentially
- the equivalent of channel scanning used in FDM wireless systems
- which is very difficult to do and provide "seamless" handover,
particularly when L2 authentication and L3 capability discovery
have to be completed.
This leads to the conclusion that the MN has to have multi-channel,
multi-mode NICs, which might make the NIC vendors happy, and
certainly would make the battery vendors very happy.
None of these arguments apply if we are talking about best effort service
over an "open" access network. To me, the idea of must be open and
non-commercial
access networks outside of select government/academic networks is
unrealistic.
It is arguable that that access to the Internet today is predominately
commercial.
The bottom line is that there are significantly greater resources within
the network to perform these functions, and the communications between
networks are relatively (note, I said "relatively") easier to make secure.
Why does this matter? If Seamoby develops both solutions, then won't the
marketplace determine what makes sense or not? Perhaps, but this approach
makes sense only if there is no cost to defining a one-size-fits-all
solution.
I would prefer that the effort be focussed on inter-AR capability discovery,
including internetwork capability discovery.
Just more of my delusional thoughts,
Gary
> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se]
> Sent: April 18, 2002 10:09
> To: seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>
>
> Since a couple of emails disagreed with me about this point,
> I'm sending one email reply to clarify. As in the minutes,
> the concept was that the only entity which can find out
> all the possible CARs is the MN (that's what I mean by
> mobile-centric).
> The network could give hints, but it is the MN that has the complete
> view and decides. That's what I understood from the meeting and there
> seemed to be consensus on this. Hope we agree so far. The network
> could assist in CAR discovery (e.g. it's L2 can help in anticipating
> the movement). That's also somewhere in the minutes. In fact what I
> said below was that I couldn't understand why there was focus on a
> network-centric solution (i.e. where the MN is NOT involved). I wasn't
> ruling out network involvement, but I couldn't understand why there
> was work on ARs only doing CAR discovery. Hope my point is more clear
> now. Maybe I misinterpreted some emails and people are in agreement
> with this. I think Dirk's email at least was in line with what I
> have above (i.e. we need to focus on the MN's role and allow the
> network to assist where needed).
> Rgds
> /Karim
>
*snip*
_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Glenn Morrow
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Glenn Morrow
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- RE: [Seamoby] Minutes for Meeting at IETF 53 Dirk.Trossen
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Govind Krishnamurthi
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- RE: [Seamoby] Minutes for Meeting at IETF 53 Gary Kenward
- Re: [Seamoby] Minutes for Meeting at IETF 53 Charles E. Perkins
- RE: [Seamoby] Minutes for Meeting at IETF 53 Gary Kenward
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- RE: [Seamoby] Minutes for Meeting at IETF 53 Govind Krishnamurthi
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- Re: [Seamoby] Minutes for Meeting at IETF 53 Phil Neumiller
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 Xiaoming Fu
- Re: [Seamoby] Minutes for Meeting at IETF 53 Xiaoming Fu
- RE: [Seamoby] Minutes for Meeting at IETF 53 Singh Ajoy-ASINGH1
- RE: [Seamoby] Minutes for Meeting at IETF 53 Glenn Morrow
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- RE: [Seamoby] Minutes for Meeting at IETF 53 Singh Ajoy-ASINGH1
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim