Subject: RE: [Seamoby] CARD between Routers - will CT do?

From: [email-masked]
Date: Tue, 14 Jan 2003 15:48:20 -0500

Hi James:

See below:

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 3:30 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Hemant,

> [Hemant] Routing protocol does not tell physical neighborhood. It tells
logical neighborhood. So a router one hop away from me could actually be far
away physically and no candidate for handoff. Turning it around, routers
physically next to each other can be in different BGP domains and BGP aggregated
(or otherwise) exchanges do not have this information. So, I think discovery
related message are very much required and issues draft has emphasized it. How
you do it is open for discussion though.

As I mentioned at the ATL meeting, interdomain CARD is not possible unless the
ISP exposes some part of the internal routing tables to the other domain, namely
the access routers. 

The access routers are not border routers, they are internal
routers. BCP in the Internet today is to not expose such information to peering
ISPs. Are you proposing that we change this practice?

Hemant --> I  agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. 

As for your point about physical v.s. logical, my recollection of past
conversations on this was that we had concluded that it is possible to determine
whether a router is in the geographical neighborhood of another only if a) the
information is configured in b) both routers have access to some source of
geographical information about the other and can calculate the geographical
distance somehow (but that still doesn't tell whether it's possible to move from
a cell of an access point connnected up to one router to a cell connected to the
other router, i.e. wireless connectivity between routers) or c) a mobile node
which can hear both routers tells one about the other either before handoff or
afterwards (which does give wireless connectivity).

Of these three a) is of course always possible, b) is impractical and still
needs some way to determine wireless connectivity, and c) is possible using MN
to AR CARD, together with an inter-router protocol that allows the access router
to tell if the MN is telling the truth. Therefore, I'm curious where you see a
need for additional information to be exchanged about routers about wireless
connectivity, and how that could be determined?

Hemant --> I generally agree with your points a), b), c) above. The information of the kind you mention here is what I was referring to, in addition to capability exchange between ARs.

Regards,
Hemant

            jak

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

---

From: Pat Calhoun <[email-masked]>
Date: 15 Jan 2003 06:55:44 -0800

> Hemant --> I  agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical a…

Doesn't this fly in the face of Mobile IPvx, which requires that
internal topological information be known outside the AS? How else would
foreign and home agents be contacted? How is this case different?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: 15 Jan 2003 06:55:44 -0800

PatC

---

From: "James Kempf" <[email-masked]>
Date: Wed, 15 Jan 2003 08:13:34 -0800

Pat,

I assume you're talking about MIPv4, right?

In that case, the HA sees the FA's address in the case where the MN sends the
RegRqst via the FA instead of directly to the HA. Since the FA's address is also
typically the care of address for the MN, the difference isn't all that great.
The source address on the forwarded RegRqst will be the care of address, so it
looks as if the RegRqst is coming from the MN.

In MIPv6, this isn't a problem because there is no FA.

            jak

----- Original Message -----
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, January 15, 2003 6:55 AM
Subject: RE: [Seamoby] CARD between Routers - will CT do?

> > Hemant --> I  agree with you that CARD should not mess with Internet routing
infrastructure. With Mobile IP, MN will know its old router and new router.
Thus, information about their geographical adjacency is already exposed to third
party. CARD should only be concerned about this information (however you
distribute it and use it) without impacting routing infrastructure in any way.
CARD is an edge phenomenon.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 15 Jan 2003 08:13:34 -0800

Pat,

            jak

----- Original Message -----
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 15 Jan 2003 08:18:06 -0800

The MN only knows the AP identifier, it doesn't know the router.

For example, suppose I have an MN with an 802.11b card and two hotspot
providers, in different ASs, are providing service in the airport I happen to be
in: one does the United lounge and the other does the rest of the airport. If I
am standing next to the United lounge and using the provider for the rest of the
airport, my laptop may be able to see the BSSID for the United lounge but it
won't know anything about the IP routing infrastructure, unless, of course, CARD
or some other protocol tells it. Similarly, the routers in the other provider
won't know anything about the routers in the United provider.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 15 Jan 2003 08:18:06 -0800

jak