Subject: [Seamoby] CAR Discovery Requirements

From: "Govind Krishnamurthi" <[email-masked]>
Date: Thu, 10 Jan 2002 12:50:28 -0500

Hello all,
I wanted to send out a reminder about the CAR Discovery requirements. Does
anyone have any major revisions to the set of requirements that was posted 
earlier on the mailing list?
There requirements were

1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs

2. MUST support L2 devices of different technologies

3. MUST (?) support for L2 devices (and ARs) in private/site-local spaces

4. MUST communicate capability information between GAARs in a secure and
reliable manner

5. MUST use standard format for capabilities..
and this is TBD

6. Protocol applicability ? SHOULD (?) (show of hands indicated that this
item should be changed to a MUST) support inter-domain as well
as Intra-domain scope

7. MUST NOT introduce network elements dedicated to CAR discovery.

8. SHOULD minimize involvement of ARs which are not GAARs in CAR
discovery

9. MUST NOT depend on a particular mobility management protocol

Thanks,
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: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 11:46:55 -0500

At 12:50 PM 1/10/2002, Govind Krishnamurthi wrote:
>...
>6. Protocol applicability ? SHOULD (?) 
>(show of hands indicated that this item should be changed to a MUST) 
>support inter-domain as well as Intra-domain scope

Inter-domain discovery of access routers (which seems implied by what
might otherwise seem an innocuous protocol design feature) is problematic.

It would require resolving which users are subscribers of which domains,
or complex inter-domain roaming and billing reciprocity. 

While it seems reasonable to avoid locking mobile stations into a single
domain, the policy interactions of requiring multiple-domain discovery
would make the task much more difficult at the start.

Please reconsider even the SHOULD for this item, much less moving toward
MUST.

John

---

From: "James Kempf" <[email-masked]>
Date: Mon, 14 Jan 2002 09:47:56 -0800

John,

> would make the task much more difficult at the start.

I'm not quite sure I understand the reasoning behind this statement. How
does
inter-domain CAR discovery complicate roaming and billing reciprocity
any
more than simply statically configuring the inter-domain CAR routers?

            jak

---

From: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 12:56:10 -0500

At 12:47 PM 1/14/2002, James Kempf wrote:

>> It would require resolving which users are subscribers of which
>> domains or complex inter-domain roaming and billing reciprocity.
>>
>> While it seems reasonable to avoid locking mobile stations into a
>> single domain, the policy interactions of requiring multiple-domain 
>> discovery would make the task much more difficult at the start.
>
>I'm not quite sure I understand the reasoning behind this statement. 
>How does inter-domain CAR discovery complicate roaming and billing
>reciprocity any more than simply statically configuring the 
>inter-domain CAR routers?

It is not increasing the complexity of roaming and reciprocity that 
worries me, it is the potential that requiring discovery be inter-domain 
would complicate the discovery (by drawing in these difficult issues).

John

---

From: "James Kempf" <[email-masked]>
Date: Mon, 14 Jan 2002 10:12:15 -0800

John,

> would complicate the discovery (by drawing in these difficult issues).

I believe that your intuition here is correct, that inter-domain
discovery
will compilicate discovery in general. However, I don't necessarily see
there being only one way to do discovery. Just as their are inter-
and intra-domain routing protocols, I think there could be inter-
and intra-domain discovery protocols, with the intra-domain
protocol being simpler. One could argue that
routers on the border of a domain which could participate
in an inter-domain handover are actually border routers, though
to my limited understanding, the current border router protocol
does not envision a host sitting between border routers, much
less moving between them.

As a practical matter, I think that we will in fact need some way
of doing inter-domain discovery, particularly for inter-technology
handover. Consider a dual interface device, with one interface
on 802.11 and the other on cdma2K. The current situation is
that there is one collection of wireless ISPs that are supplying
802.11 hotspot service and another that are supplying
cdma2K wide area service. Unless the MN and/or
ARs have the capability to do inter-domain discovery, the
service providers will end up statically configuring their
routers with the addresses of the other routers, which could
lead to problems if the network topologies change unexpectedly.

Alternatively, without any information about ARs in the other domain,
the MNs will be forced back to standard MIP handover to
move from one provider's network to the other's. While this might
not seem so bad in the end, it will certainly preclude doing fast
handover of voice calls from one network to the other.
Since the current IS-41 protocol on SS7 allows intersystem
handovers for ongoing calls (though I do not know
in the end what percentage of these handovers actually
are fast enough that the user doesn't notice), this will be a limitation
of VoIP networks that is not there in the current cellular
networks, and thus an argument against deploying VoIP
for cellular.

It would be interesting to have some data on the
actual time involved in an intersystem handover
on IS-41. If the amount of time is on the order
of seconds, then maybe we don't have to worry
about this problem.

            jak