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

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 23 Jan 2002 11:01:42 -0500

Hello Phil,
I'm not able to understand your concern clearly.

>
>Hi Govind,
>
>I will try to fill in some of the blanks below.
>
> > -----Oriinal Message-----
> > From: Govind Krishnamurthi [mailto:[email-masked]]
> > Hello James,
> >
> > My comments inline
> >
> > -Govind.
> >
> > >
> > >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?
> > >
> >
> > [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]  ---> OK.
>
> > >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?
> > >
> >
> > [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.

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

Second what do you mean by it should support MIP and MANET? The reason
why CAR discovery is needed is to support the need for MIP (for example) in 
finding the next router for handover. So where does the question come of 
ignoring MIP? The approriate TAR selection algorithm is going to act
on the bunch of ARs selected by CAR along with other parameters and then 
decide an AR for handover.  Infact, the current set of requirements
go much farther and say that the CAR discovery protocol output must
be available (The Inter-technology requirement) to other mobility management 
protocols other than MIP.

I think the main ability it should
have is that of translating different types of L2 identifiers to appropriate 
L3 Identifiers. It must be able
to give its output to the TAR selection algorithm used to select
the TAR. But this is obvious.
If any other need is there for the output of CAR discovery then it is 
implementation specific.

Sorry again if I missed your point :)

Regards,
Govind.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Jan 2002 09:49:47 -0800

Govind,

> an environment wherein a fixed infrastructure as well as a ad-hoc

I believe the issue here was discovering an access router that
would let the MANET route back into the fixed network.

            jak

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 24 Jan 2002 18:07:06 -0800

James,

> would let the MANET route back into the fixed network.

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