Subject: [Seamoby] Summary of Discussion on CAR Discovery Requirements

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Jan 2002 15:08:17 -0800

Hi folks,

I've just read through the back email on this thread over the past
couple weeks
in response to Phil and  Govind's original posting, and here
are a couple observations and proposals.

1) There seems to be broad agreement that we need a requirement saying
that
the CAR discovery protocol MUST support IPv4 and IPv6.

2) There was some difference of opinion on whether the requirements
draft
should say anything about how this might be done. If nobody has a
further
objection, can we leave this as an implementation issue?

3) There also seems to be a certain degree of agreement that we have
an explicit requirement, in addition to Requirement 9, which states that
a solution MUST be provided which supports existing mobility protocols.
Thus, the protocol must be both independent of mobility protocol
and capable of supporting existing mobility protocols. Again, if
there is no objection, can we include this as a requirement?

4) There was some difference of opinion about whether support
for interdomain discovery SHOULD or MUST be required.
Since some good arguments were made for supporting
interdomain discovery, I'd like to suggest we keep this
in for now as a SHOULD unless there are any further objections
to be discussed.

5) Some working group members suggested that the requirements
for MN-based v.s. AR-based discovery be separated. The
draft editors would like to see examples of requirements that
need to be separated. Does anyone have some examples?
If not, can we just go forward with a single set of requirements
for now?

Comments?

            jak

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

---

From: Phillip Neumiller <[email-masked]>
Date: Wed, 23 Jan 2002 08:59:56 -0500

Hi Govind,

I will try to fill in some of the blanks below.

> -----Original Message-----
> From: Govind Krishnamurthi [mailto:[email-masked]]
> Hello James,
> 
> My comments inline
> 
> -Govind.
> 
> >
> >Hi folks,
> >
> [GK] I think it is a strong requirement that we MUST support
> IPv4 and IPv6. I agree, how this is done is a protocol 
> specification issue. 
> I also pointed out to Phil that this requirement is very much
> already there in the given set of requirements and IMO an
> explicit statement is redundant. I did not get a response from Phil
> about this so I don't know whether he agrees with my comment.

pdn>To me it did not seem explicit enough.  If others feel its in
pdn>there than that's OK with me.
 
> [GK] Again Phil did not answer Dirk's question regarding what he
> means by the above statement that it MUST support mobility management
> protocols? CAR discovery happens parallel to mobility management. It
> is in the definition of CAR discovery that mobility management
> protocols are going to use CAR discovery for the purpose of handovers.
> What else is needed? Why do we need a separate requirement. 
> Essentially
> we are stating the need for CAR discovery here. Also, by the very fact
> that we say we support inter-technology handovers (which clearly may
> have different mobility management protocols) we imply that 
> any mobility
> management protocol will be able to use the output of CAR discovery.
> Ofcourse, I might be wrong about this and Phil may have something else
> in his mind.
> 
pdn>I think James hit it exactly.  Yes, we don't want to bind the CAR
pdn>protocol to MIP and MANET protocols only, but we also do not want to
pdn>ignore their existence.  There has been too much ignoring going on
pdn>between the respective WGs.  CAR can be a nice bridge and as such
pdn>we must diligently support the best of MIP and MANET protocols.
pdn>I think we can do this without precluding future mobility protocols.
pdn>To get something useful out of CAR early on, it MUST support MIP and
pdn>MANET protocols, and in fact it should be aware of them and facilitate
pdn>candidate discovery for the respective protocols.

Thanks,

Phil
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures.

---

From: [email-masked]
Date: Wed, 23 Jan 2002 10:54:34 -0500

Hi all,

sorry, forgot to press 'Reply to All' for the below answer to
Phil's email.

Thanks,

Dirk

-----Original Message-----
From: Trossen Dirk (NRC/Boston) 
Sent: Wednesday, January 23, 2002 10:51 AM
To: 'ext Phillip Neumiller'
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
Requirements

Hi Phil,

comment inline. 

> pdn>candidate discovery for the respective protocols.

Again, I'd like to point out that it is not clear to me what 
'MUST support MIP and MANET' means. 

Firstly, MUST is a very strong statement. Is a solution that discovers
CARs in MIP, MANET, and any other mobility environment bad (or even
out of scope due to the MUST) if it doesn't take the mobility management
protocol into account but fulfils the task, namely discovering the CARs??

Secondly, what does 'support' means? We had this discussion before and
for me you haven't made clear what you exactly mean by that. The 
independence of mobility management (MM) is a very strong argument.
It means that it has to work with any MM protocol, which from my point of
view means that it must support MIP and MANET (and, BTW, other MM protocols).
However, how you achieve this is totally in the solution space. It can 
be a protocol comprised of modules for all sorts of MM protocols. It is 
therefore independent (at least for the existing ones). But if you propose 
a solution that does not take specific MIP/MANET/etc features into account, the
requirement is fulfilled, too, and I don't see any disadvantage in this.

Again, it comes to the differentiation, I asked to clarify, namely the
difference between being compatible to MM protocols or to accomodate
MM features. The first one is addressed by the independence requirement
from my point of view. Making the second one mandatory or even a SHOULD 
only doesn't make sense as a requirement (see question above regarding a
solution that doesn't accomodate MM features). Although nobody prevents 
you from proposing a solution that does accomodate MM features as long 
as you don't restrict your solution to specific, e.g., MIP, environments 
only.

In conclusion, we should first clearly define what 'support' really
means. The terms above, i.e., 'being compatible' and 'accomodate',
might help for this. If we agree on this, we have to discuss if
we really want this (at this point hopefully more clear) requirement or
if it even necessary.

Regards,

Dirk

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 23 Jan 2002 17:22:19 +0100

Hi James, 

  > If not, can we just go forward with a single set of requirements

=> So here's a scenario: in point 4) above, if we
consider the MN-AR interface then I can't see why 
it wouldn't be a MUST. However, for the AR- AR 
protocol, I can see some scalability and other
business issues that may force us to avoid 
mandating this requirement. 

Hesham

---

From: [email-masked]
Date: Wed, 23 Jan 2002 11:46:30 -0500

Hi Hesham,

> mandating this requirement. 

The requirement states that ARs SHOULD or MUST be discovered 
irrespectively of the domain to which they belong. This is a 
generic requirement which reflects one very fundamental nature 
of seamless mobility, namely seamlessly roaming between ARs 
irrespectively of the domain to which they belong. 
Apparently you want the focus of seamlessness more on time
(reducing the connectivity disruption) rather than on networks 
(roaming seamlessly between networks). 

Furthermore, I have a problem what exactly you mean with 'MN-AR'
and 'AR-AR' interfaces. But let me interpret how I understood these
terms. Do you mean by 'MN-AR interface' an MN-based discovery scheme, 
hence 'AR-AR interface' is an AR-based scheme for discovery? 

If so, do you propose that if the MN is doing (mainly) the job, 
it MUST discover ARs irrespectively of the domain, while in the 
(mainly) AR-based scheme it should only (if at all), i.e., it doesn't
have to? Does this make sense? With that, you fix the solution space
in a sense that seems inappropriate to me. This will open doors
for fights to which 'category' the solution belongs. What about
schemes that divide the tasks between AR and MN? MUST or SHOULD
they fulfill the requirement? What about a scheme that uses MN
for discovery but AR for capability exchange? Do you really 
propose (which is the natural extension of demanding two 
categories of requirements) that we first define categories
for our solution space and then assign requirements (and their
strengths) to them?

If we want to enable seamlessness in the sense I described
above, namely between networks, reflected by the inter-domain
requirement, the requirement is a MUST. Probably, we should
think about the possibility that a solution that does not fulfill 
this requirement is one that shouldn't be considered.

BTW, I see your scalability point. But again, if a solution that
tries to fulfill the inter-domain requirement doesn't scale, it
is probably simply not a good solution? 

Do you really want to have a requirements document that says 
'we want CAR discovery in inter-domain case, but if you have 
an AR-based solution you don't really have to do the job'???

I don't see your business reason. If you are talking about hiding
ARs to ARs of other domains, you can do this by a) private address
space and b) not revealing your capabilities during the exchange.

In conclusion, as a first step, it is necessary that you define
your terms 'MN-AR interface' and 'AR-AR interface' so that we
know what we are talking about in the context of separating
requirements.

Regards,

Dirk

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 23 Jan 2002 18:32:17 +0100

> The point about the need to support existing mobility protocols
  > was not only made by Phil, it was made by Hesham and others.
  > So I think there is a group of people that would like to see this
  > as a requirement. It also seems almost a given to me, why
  > would the WG want to come up with a protocol that
  > doesn't support existing mobility protocols, so I'm
  > having a hard time seeing why you're resisting putting
  > it in.

=> Fully agree. 

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 23 Jan 2002 13:41:44 -0500

James,
I don't mind this requirement being a SHOULD for now.
But there were a large number
of people who were of the opinion (including one of our ADs :)) that
this requirement should be changed to a MUST. So maybe they can speakup now 
and let us know why they felt so strongly about this requirement.

Regards,
Govind.

>Dirk/Hesham,
>
>So it sounds like there is a case for interdomain discovery, but it
>might be mitigated by certain difficulties. Business considerations
>shouldn't really be an issue here, but scalability certainly should,
>and I can see an argument about technical difficulty integrating
>the CAR discovery with interdomain routing, in both the MN
>and AR cases.
>
>There was really not much technical discussion on this issue
>at SLC. Since then, there has been more, and the
>outlines of possible problems are beginning to emerge.
>I think we really need to do a deeper study to determine
>whether or not this is technically doable.
>
>How about if we keep the requirement a SHOULD? I
>believe that is how Govind originally listed it.
>
>             jak
>
>----- Original Message -----
>From: "Hesham Soliman (ERA)" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>;
><[email-masked]>
>Sent: Wednesday, January 23, 2002 9:22 AM
> > Dirk,
> > => Did I say that ? I don't think so, I simply
> > said that a MN listening to ARs directly
> > (possibly multi-homes) would relatively easily
> > discover GAARs outside its current domain.
> > On the other hand, for ARs to discover GAARs
> > outside their domain, several security issues and
> > 'agreements' between operators are needed. So
> > It does seem more difficult for the AR - AR protocol
> > to work across domains.
> > To conclude: If AR discovers GAARs then inter-domain
> > is more difficult.
> > If MN discovers GAARs then inter-domain discovery is
> > not so difficult.
> >
> >   >
> > => Yes. I realise that AR-AR can also be relayed
> > to the MN (in some cases).
> >
> >   >
> >   > have to?
> > => It doesn't need to be a MUST.
> >
> > Does this make sense?
> >
> > => Why don't we let the WG decide that.
> >
> >
> > With that, you fix the solution space
> >   > in a sense that seems inappropriate to me.
> >
> > => Huh ? can you elaborate. I'm not fixing
> > anything, I said one is simpler than the other.
> >
> > This will open doors
> >   > for discovery but AR for capability exchange?
> >
> > => I'm only interested in technical reasons.
> >
> > Do you really
> > => I really think you're reading way too much
> > into my emails.
> >
> >   >
> > => Well there may not be a 'good' solution for this.
> > People make design choices and tradeoffs, what do you
> > mean by 'good' ?
> >
> >
> > => If communication between AR and GAARs exists e2e
> > then there is some AR - AR protocol.
> >
> > MN - AR : AR sends information to MN about itself
> > and (possibly) GAARs.
> >
> > I hope this is clearer.
> >
> > Hesham
> >
> >
> >
>
>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: [email-masked]
Date: Wed, 23 Jan 2002 13:24:05 -0500

Hi,

ups, I forgot the 'reply all' button again. See comments in 
mail below.

-----Original Message-----
From: Trossen Dirk (NRC/Boston) 
Sent: Wednesday, January 23, 2002 1:23 PM
To: 'ext Hesham Soliman (ERA)'
Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery
Requirements

Hi Hesham,

> If MN discovers GAARs then inter-domain discovery is 

As I said, I see your point that for specific solutions,
it might be more difficult to do CAR discovery. But the
question here is, do we want to make the requirement
mandatory or not that GAARs are discovered independent of their
domains? This is certainly an open point for discussion within
the WG and will eventually lead to a SHOULD or MUST for this
requirements. 

But then we should make this decision for ALL solutions. Making 
it mandatory for MN-based schemes but not for AR-based, doesn't 
make sense from my point of view. That was my concern regarding 
'separation' of requirements.

> anything, I said one is simpler than the other.

You do in the sense that you imply a certain complexity for
certain solutions (or categories for solutions) so that you
want to soften or to harden certain requirements for certain 
(categories of) solutions.

> People make design choices and tradeoffs, what do you 

Good in the sense that it fulfils the requirement or not. If we
define the requirement as a SHOULD for all, that's ok. But if it
is a MUST, it should be defined for all solutions. I'm trying to
avoid that we define requirements for different solution spaces
for the same problem.

Regards,

Dirk

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 23 Jan 2002 14:35:16 -0500

Hello all,
I will add statements to Requirement 9 to reflect the fact that CAR 
discovery's output must be usable by existing IP mobility protocols.
Please let me know if there are any more concerns.

Regards,
Govind.

>Perhaps the wording of the requirment could be changed?
>How about:
>
>     The CAR discovery protocol MUST be usable by Internet
>     hosts and nodes that support existing IP mobility protocols,
>     such as Mobile IP and MANET.
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 24 Jan 2002 16:58:00

Hi:

I think the central issue in CAR discovery is about "IP handoffs", actually 
"capability-aware IP handoffs". Every IP mobility management protocol that 
has handoff as a central theme, may it be Mobile IP, MANET or something 
else, should be able to use CAR discovery protocol. This means that:

1. CAR discovery protocol cannot use any  "protocol specific technique" (of 
course other than handoff as it is central to all mobility management 
protocols).

2. Output of CAR discovery needs to be usable by these mobility management 
protocols.

Do we agree with this or is there anything more in Mobile IP and MANET that 
solicits their explicit MUST mention in the requirements document?

Hemant

>To: "'James Kempf'" <[email-masked]>,        Govind Krishnamurthi 
>  <[email-masked]>, [email-masked]
>Subject: RE: [Seamoby] Summary of Discussion on CAR Discovery Requirements
>Date: Wed, 23 Jan 2002 18:32:17 +0100
>
>

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: Phillip Neumiller <[email-masked]>
Date: Thu, 24 Jan 2002 12:11:06 -0500

Seems reasonable to me.

--
Mesh Networks, Inc. (www.meshnetworks.com)
Phillip D. Neumiller, Staff Scientist
[email-masked] PH: 1-407-659-5387

> From: Hemant Chaskar [mailto:[email-masked]]
> Sent: Thursday, January 24, 2002 11:58 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 24 Jan 2002 19:03:18 +0100

Sorry...replying to my own mail.
This was said to give another example of 
why AR - AR may need different requirements
from MN - AR. 

Hesham

  > From: Hesham Soliman (ERA) 
  > Sent: Thursday, January 24, 2002 2:12 PM
  > To: Hesham Soliman (ERA); [email-masked]';
  > [email-masked]'; [email-masked]'
  > uHi, 
  > Another requirement which is more relevant 
  > for the inter-domain case (if an AR is to 
  > discover GAARs) is that the protocol must 
  > be able to function despite of network 
  > renumbering of either domain. 
  > 
  > Regs,
  > Hesham
  >

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 25 Jan 2002 21:27:09

Hi,

I agree with Jari on the MANET issue. If MANET has to use CAR discovery, it 
is only the "edge" nodes that are connected to the Internet gateways that 
use it. There can be a whole family of nodes of MANET behind the edge nodes 
which do not do handoffs between gateways. In other words, these other nodes 
may not need to use CAR discovery. Thus, I see no difference between handoff 
performed by an isolated single node and edge node of MANET, as far as CAR 
discovery is concerned. So why does MANET need an explicit "MUST" mention in 
requirements?

Hemant

>From: "Jari T. Malinen" <[email-masked]>
>To: James Kempf <[email-masked]>
>CC: Govind Krishnamurthi <[email-masked]>, [email-masked]
>Subject: Re: [Seamoby] Summary of Discussion on CAR Discovery Requirements
>Date: Thu, 24 Jan 2002 18:07:06 -0800
>
>James,
>
> > Govind,
> >
> > > [GK] ----> First, how CAR discovery is useful in Ad-hoc
> > > networks is quite unclear to me as every communication is line of
> > sight,
> > > unless you mean that we can exchange capabilities. Or do you mean
> > > an environment wherein a fixed infrastructure as well as a ad-hoc
> > > nodes are there.
> > >
> >
> > I believe the issue here was discovering an access router that
> > would let the MANET route back into the fixed network.
> >
> >             jak
>
>There are several issues to let MANET route back to the fixed
>network. Discovering an on-link fixed access router by a manet
>node, and establishing the routable communication.
>
>There, establishment of communication with the fixed network
>is more of an addressing problem, how to get a routable
>address from the edge box. Manet nodes communicate among
>themselver with potentially topologically incorrect addresses.
>When connecting with the fixed network, obtaining a
>topologically correct address is needed.
>
>There use of gateway discovery to obtain the topologically correct
>address is being considered in work in the MANET working group,
>see drafts
>
>http://search.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-00.txt
>http://search.ietf.org/internet-drafts/draft-royer-manet-globalv4-00.txt
>
>for IPv6 and IPv4 gateway discovery, respectively.
>
>Clearly, the MANET gateway discovery and addressing issues are out
>of scope of CAR, but it is possible CAR can direct an edge MANET node
>to connect to a suitable fixed network node for link establishment.
>
>This should, however, be independent of the MANET protocols or
>MANET connectivity protocols, and minimally consider
>MANET itself, except, perhaps, by providing capabilities for
>the immediate MANET nodes connecting to the fixed network to
>locate, e.g., a globalv6-capable fixed access router or an
>access router that can hand out topologically correct prefixes
>to be used by a mobile globalv6 gateway node.
>
>Hence, independence of mobility protocol should basically be
>a valid and an adequate requirement for MANET operation while
>recognizing that CAR does not solve the MANET node-fixed network
>routing or reachability problem, just link establishment for
>mobile nodes, MANET edge nodes included.
>
>BR,
>
>-Jari
>

---

From: Phillip Neumiller <[email-masked]>
Date: Fri, 25 Jan 2002 17:42:21 -0500

I disagree, but I can not respond till next week.  
> Sent: Friday, January 25, 2002 4:27 PM
> To: [email-masked]

_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 28 Jan 2002 09:01:26 -0500

Heman Chaskar wrote:

>use it. 

You have introduced a word "edge" that is not defined by the MANET group to 
my knowledge.  What do you mean by this?  Also, what do you mean by "if
MANET *has* to use CAR discovery?   If CAR discovery *is* useful, then wouldn't
MANET protocols want to make use of it?  Also, all nodes in MANETs can 
function as ARs so I find your description a bit skewed.

> There can be a whole family of nodes of MANET behind the edge nodes 
>which do not do handoffs between gateways. 

If all nodes in MANETS are ARs then what is the difference?  Recall peer-to-peer
traffic and "handing off" between these nodes.  With high speed mobiles, no known
MANET routing algorithm will converge fast enough to hand off between micro-cells.
This is precisely why CAR is needed for MANETs, irrespective of your edge/core
distinction.

> In other words, these other nodes 
>discovery is concerned. 

Again, you have some kind of "architecture" in mind here and that is a no-no.  When 
referring to MANETs we should stick to the pure definition of ad hoc and not impose
hierarchy as you are doing.

> So why does MANET need an explicit "MUST" mention in 
>requirements?

Because CAR MUST be useful (i.e. have utility) for mobile IP, MANET, and any other
IETF created mobility protocol.

Thanks,

Phil Neumiller
MeshNetworks, Inc.

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 28 Jan 2002 16:42:47

Hi Phil:

I have only the following "cannonical" architecture in mind. There is a 
mobile node attached to access router, and it needs to change its physical 
connectivity seamlessly to another access router, i.e., execute IP-level 
handoff. CAR discovery will help you do that. If the mobility management 
protocol has the above cannonical central idea, it will use the CAR 
discovery.

What you are suggesting is just a scenario in which the above central theme 
can be indentified. This is a good example of how one can easily map this 
cannonical central theme to scenarios and mobility management protocols at 
hand and apply CAR discovery to it.

Hence, IMHO, I see no need to do explicit mention of MANET or MOBILE IP as 
MUST consumers in the requirements document. This is because, both of them 
(at least MANET) carry much more baggage with them in addition to the 
central idea of seamelss handoff described above.

Hemant

>From: "Phil Neumiller" <[email-masked]>
>Reply-To: "Phil Neumiller" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>Date: Mon, 28 Jan 2002 09:01:26 -0500
>
>
>Heman Chaskar wrote:
>