Subject: [Seamoby] CAR Discovery Requirements

From: "James Kempf" <[email-masked]>
Date: Fri, 11 Jan 2002 10:22:49 -0800

Since there seems to be some differing opinions about requirements
for CAR discovery, it seems appropriate to have a WG discussion
and record the results in a draft. We've requested that Govind be
editor for a requirements draft, and he is currently preparing a
draft based on the initial set of requirements that he presented
at SLC.

I think we should run the requirements discussion until perhaps
the end of Feb., so we can conclude requirements collection by
Minneapolis.
*By no means*, should this discussion drag out for longer. We do not
want to bog down and spend a year discussing requirements, as
was the case for CT. The interesting part is the protocol, the
sooner we can agree on a suitable set of requirements, the
sooner we can start discussing that.

            jak

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

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Fri, 11 Jan 2002 13:35:38 -0500

Hi Phil,

> Perhaps we can compromise here and say that some particular set of 
> specific methods MUST be supported as a minimum and not restrict at
> all what goes on beyond this.  Lets be honest with ourselves here,
> this protocol will be used by MIP and MANET protocols as their 
> primary customers.  If not, then what customer does this requirement
> serve?  Maybe I am dense on this, but I just don't get why we can't
> specify the existance of an interface here?
> 
Maybe, there is some misunderstanding on my side what this interface
is about. 

Let's assume a final CAR discovery solution (however it'll work)
that provides the current AR with a set of GAARs and its associated
capabilities. Do you want to make the necessity mandatory to define
an interface to access this information for any (maybe mobility
management
dependend) subsequent actions, such as a policy server-based TAR
selection 
for the fast handover case?

Regards,

Dirk

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Mon, 14 Jan 2002 11:57:41 -0500

Hi John,

I'm kind of confused by your comment. Are you questioning
the inter-domain handoff or the discovery? Why do I have to
resolve which users are subscribers of which domains if I want
to discover ARs in my proximity?

We're discussing CAR discovery. I don't see your policy
interactions, inter-domain roaming, and billing problems in this
context. However, it is certainly an issue for the actual selection of
the
target AR, but TAR selection is not within the scope of the
CAR discovery protocol.

Regards,

Dirk
> -----Original Message-----
> From: ext John Schnizlein [mailto:[email-masked]]
> Sent: Monday, January 14, 2002 11:47 AM
> To: Govind Krishnamurthi
> Cc: [email-masked]
> Subject: Re: [Seamoby] CAR Discovery Requirements
> 
> 
> 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: John Schnizlein <[email-masked]>
Date: Mon, 14 Jan 2002 12:28:42 -0500

At 12:00 PM 1/14/2002, Hesham Soliman (ERA) wrote:
>  > Inter-domain discovery of access routers is problematic.
>
>AR - AR or AR MN ???

This is a good question.

>Clearly AR - MN lis an obvious way to discover all routers that 
>the MN can hear. Inter/intra domain issues are not relevant. 

If the WG goes that way, the resulting protocol would be usable
only by operators who allow access to any mobile node (MN). But 
normal business arrangements might require a pre-existing 
relationship between the subscriber (MN) before service providers 
are willing to be discovered. Remember the implication that the
AR would be willing to accept an operating context for the MN from
some other provider.

The issue is potentially even more problematic for AR - AR. Would the
operator of an access service willingly include another operator's
routers to be neighbors, encouraging the possibility that the MN
would switch into/out-of service from a different provider?
We know that telephone companies try to avoid this.

>So please make it clear which part of the protocol
>you're referring to. We should not always assume 
>that we're discussing the AR - AR case. 
>
>...
>Let the MN decide.

This is a good answer. But then the MN would need to get the sort of
information it needs to make a reasonable decision. This might include
pricing information, or information regarding the which providers
share access reciprocity agreements. Are we ready for all this?

John

---

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

At 11:57 AM 1/14/2002, Trossen Dirk (NRC/Boston) wrote:

>I'm kind of confused by your comment. 
>Are you questioning the inter-domain handoff or the discovery? 
>Why do I have to resolve which users are subscribers of which 
>domains if I want to discover ARs in my proximity?

I will admit the possibility that I simply don't understand.
My impression is that the discovery is for the purpose of finding
neighbors for potential context hand-off. One way to limit getting
or giving hand-offs to/from domains with which the provider has no
business relationship is to limit forming the neighborhood.

In non-cyber-space, there are sometimes houses closer to mine that
are considered a different neighborhood because their $/sq.ft. are
so different. On just the other side of a street, the children often
attend a different school (with sometimes dramatically different
$/student expenditure).

Is it necessary to preclude this method of operation for mobility?

>context. However, it is certainly an issue for the actual selection 
>of the target AR, but TAR selection is not within the scope of the
>CAR discovery protocol.

If you operated a network that supported mobility, would you want the
protocol to imply that other operators could discover your routers for
the purpose of handing off subscriber context to you or getting context
from you? Possibly one or the other, depending on who pays whom, but
you might not want to treat other domain's routers according to the
same policy. You might not even want your competitors to know how well
you cover particular regions.

John

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 14 Jan 2002 12:46:31 -0500

> From: John Schnizlein [mailto:[email-masked]]
> Sent: January 14, 2002 12:29
> To: Hesham Soliman (ERA)
> Cc: Govind Krishnamurthi; [email-masked]
> Subject: RE: [Seamoby] CAR Discovery Requirements
> 
> 
*snip*
> We know that telephone companies try to avoid this.

Inter-domain roaming of this type is common in cellular networks. 
In the US inter-domain handover is specified in IS-41. The operators 
may prefer to keep a customer in their network, but they recognize that 
mobility has greater value to the customer if it is not limited artificially

by administrative domains, and most operators cannot provide contiguous, 
continent wide coverage.

Gary

*snip*

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 14 Jan 2002 13:07:13 -0500

John,
What you ask is here is clearly an implementation issue. Whether
the protocol becomes complicated by including inter-domain discovery
is debatable. What we are looking into right now is whether there
SHOULD or MUST be support for inter-domain domain discovery. Many of
us feel it is necessary given that the Internet is  a bunch of domains
put together.

-Govind.

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

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 14 Jan 2002 13:12:10 -0500

Hesham,
Where does the current set of requirements preclude any sort of mobile node 
involvement. I think
whether an MN is involved or not is implementation specific.. and
not a requirements issue. I don't think the requirements for CAR discovery 
change whether a MN is involved or not. Also letting the MN or AR decide 
where actually to handover is out of scope of CAR discovery.
Just letting the MN also hear does not complete CAR discovery.. CARs 
comprise of GAARS + their capabilities.. What you say is just GAARs.

-Govind.
>   > might otherwise seem an innocuous protocol design feature)
>   > is problematic.
>   >
>=> This is exactly why I urge you (this wg) to clearly
>explain which protocol you are talking about. AR - AR or
>AR MN ???
>Clearly AR - MN lis an obvious way to discover all routers
>that the MN can hear. Inter/intra domain issues are
>not relevant.
>
>=> Certainly. But there is an easy way of doing that:
>Let the MN decide.
>
>Hesham
>

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 14 Jan 2002 13:16:27 -0500

Good point,
and as pointed out in the Issues draft the CAR discovery may not be used
just in the case of mobility. It could be used for example, to even out
the load on the ARs in a hotspot.
-Govind.

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

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Mon, 14 Jan 2002 14:08:07 -0500

Hi all,

Can anybody make clear to me why this separation of requirements is
really necessary? In the issues draft, we have identified three cases 
(anticipated, dynamic, and hybrid) to address the problem of CAR
discovery, 
and to my understanding the requirements cover all three. I would urge 
not only to suggest a separation but really to outline a proper
definition of
(separate) requirements so that everybody can see that this separation
makes sense. 

But just as a reminder (please look into the issue draft). This, i.e.,
CAR discovery, is merely about identifying GAARs including their
capabilities,
whereby the the spectrum and exact definition of the latter are not
within
the scope of the protocol, to enable either the AR (anticipated case) or
the MN (dynamic case) to determine a set of ARs, namely the CARs, that
meet 
MN's requirements.

HOW (and by what parties) to determine this set, e.g., by signalling the
MN's requirements to the AR for the anticipated case, and how to select
a 
TAR, i.e., the final candidate for handover, are out of scope of this 
protocol.

Hence, I don't understand how billing and accounting comes in here and
why anything should be considered separately for AR-AR or AR-MN. The
problems
to be addressed are similar for all three cases, namely anticipated,
dynamic, and hybrid. I admit that the decision as to how to select the
TAR 
would probably heavily depend on operator's policies. But this is
(again) not in
the scope of what we are discussing here. 

For instance, if you want to keep other ARs out of the decision of TAR
selection,
then implement your TAR selection algorithm appropriately. It does not 
at all influence the CAR discovery. It is rather a local (adminstrative)
implementation issue. And that's how it is defined in the issues
draft. 

In conclusion, John's comments are already considered by taking these
problems out of the scope of CAR discovery. How they still affect CAR 
discovery and its requirements, is unclear to me.

Regards,

Dirk

> From: ext James Kempf [mailto:[email-masked]]
> Sent: Monday, January 14, 2002 12:53 PM
> To: Hesham Soliman (ERA); John Schnizlein; Govind Krishnamurthi
> Cc: [email-masked]
> You are correct, the protocol must apply to both cases,
> and the requirements should reflect that.
> 
> Perhaps it would make sense to divide the requirements
> document into three sections: a) common requirements,
> b) requirements for AR-AR case, c) requirements
> for AR-MN case.
> 
> 
>             jak
> 
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 14 Jan 2002 20:27:53

Hi John:

Some comments inline:

>From: John Schnizlein <[email-masked]>
>To: "Trossen Dirk (NRC/Boston)" <[email-masked]>
>CC: "Govind Krishnamurthi" <[email-masked]>, <[email-masked]>
>Date: Mon, 14 Jan 2002 12:41:19 -0500
>

Whenever that is indeed the case, CAR discovery protocol will discover it. 
Either by getting explicit policy from the other router that it does not 
allow handoffs from the former or by not getting any answer to capability 
query. Policy information is an important piece of information that will be 
exchanged during capability exchange.

>Is it necessary to preclude this method of operation for mobility?

We are not precluding this at all. Again dollar cost can be exchanged as a 
part of capability exchange.

>you cover particular regions.

If you bother to co-operate with other operators to provide seamless 
handoffs to MN, you should talk to them. You need not disclose AR's 
identities (IP addresses) for security reasons. That is why the requirement 
of private address space is important. Also, it is entirely upto the 
operator as to which capabilities it wants to disclose and which he does 
not.

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

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 Jan 2002 13:43:26 +0100

> only by operators who allow access to any mobile node (MN). 

=> I don't think so, this is not related to access control.
If some authentication is required to hear RAs from a router 
then this step will be done first.

  > We know that telephone companies try to avoid this.

=> Sure, but the WG doesn't have to address this problem.

  > share access reciprocity agreements. Are we ready for all this?

=> Well, why not ? I don't know how much detail we should 
put in the protocol, but something along those lines
will be necessary. Do you see problems with this ?

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 Jan 2002 14:57:40 +0100

Govind, 

  > change whether a MN is involved or not. 

=> What is this in response to exactly ? I didn't claim
the opposite of what you said, I said 'separate' the 
requirements so we know what you refer to when you 
say 'support inter-domain discovery' 'support mapping 
from L2 to L3'. 

Also letting the MN 
  > or AR decide 

=> Ok, please respond to the statements I made, just so
I can understand which parts you are referring to. 

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 15 Jan 2002 13:12:07 -0500

Hello Hesham,
I guess Dirk answered your questions in an earlier mail, explaining
my mail.
-Govind.