Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 19 Sep 2002 09:43:30 -0500

I don't quite understand your comment. My point was to avoid signaling  
from the critical path. MN can always send or receive signaling when 
high bandwidth channel is allocated or when no voice frames are 
being sent over dedicated channel.
Regards,
Ajoy

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 8:43 PM
To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; [email-masked]
Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
configuration

I still don't understand how we can ensure smooth
operation using this dedicated channel which cannot
even accomodate few additional IP packets.

For example, what happens if some of those
real-time packets needed to be fragmanted? Maybe this
doesn;t apply to voice packets since they are small,
but any larger packet can be pushed over the edge due
to tunneling overhead of Mobile IP based protocols. Now
you have more packets....

If accumulative bandwidth is an issue, well then additional
extension headers (e.g., routing header) and one or more
encapsulation can consume more bandwidth than we
have provisioned for the dedicated channel.

Also, how does the network decide which packets can take
the dedicated channel? In the presence of IPsec encryption
and changing source and destionation addresses via Mobile IP,
filtering of those packets is not practical.

What I'm trying to say is, before 2 packets of mobility signaling,
I think this system has some other problems to deal with....

alper 

> 
> Ajoy, under what conditions sending few extra packets
> is an issue? If we have such delicate conditions, how do
> they perform when a router sends an unsolicited router
> advertisement, or some other node sends a neighbor solicitation,
> or user of the mobile node wants to browse the Internet
> simultaneously, etc.. (many reasons to send/receive
> packets at the same time...)
> 
> Ajoy->
> 
> This question is difficult to answer unless I use 
> a specific air interface technology. For example, in CDMA
> 2000 access network, each mobile is allocated a low 
> bandwidth dedicated pipe and a high bandwidth shared
> pipe. The high bandwidth pipe is shared among multiple 
> users for obvious reason. The high bandwidth pipe is allocated 
> when an MN has enough buffered data to send or receive. Moreover, 
> the access time of this channel is very high, hence 
> it is not suitable for carrying any real time 
> voice or Fast Mobile/IP messages. Typically the shared channel won't 
> get allocated for low bandwidth voice over IP or
> say Mobile/IP signaling message. In this case, the Mobile/IP
> messages will have to compete with VoIP traffic for low
> bandwidth channel. On the other hand, the bulky traffic (e.g., FTP)
> are buffered until the high bandwidth channel is available for 
> communication. This is ok for non-real time traffic because
> the users don't care about the buffering delay associated with 
> these packets. BTW, the one solution of this problem is 
> to allocate high bandwidth dedicated channel to each 
> users which is very expensive and not done so far.
> 
> 
> -----Original Message-----
> From: Alper E. YEGIN [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2002 1:54 PM
> To: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; [email-masked]
> Subject: Re: [mobile-ip] Fastv6: Issue 2: Deferring new CoA
> configuration
> 
> 
> > Hello Rajeev,
> > I have not read all the emails exchanged about this
> > issue. BTW, I would like to have the option to defer 
> > new care of address configuration. 
> > Following are a few advantages of this approach:
> > 
> > 1.Avoid the possibility of blocking real time traffic 
> > by the signaling traffic.
> 
> Ajoy, under what conditions sending few extra packets
> is an issue? If we have such delicate conditions, how do
> they perform when a router sends an uncolicited router
> advertisement, or some other node sends a neighbor solicitation,
> or user of the mobile node wants to browse the Internet
> simultaneously, etc.. (many reasons to send/receive
> packets at the same time...)
> 
> alper
> 
> 
> 
> 
> 
> 
> > 2.Provides mechanism to remove header compression 
> > context transfer or re-negotiation out of critical path 
> > of handover. Similarly, provides mechanism to remove PPP 
> > context transfer or or re-negotiatio (if PPP is used)out 
> > of critical path of handover. 
> > 
> > If we keep context transfer as well as the handover signaling 
> > in the critical path of handover, I do see possibility of call drop
> > which will beat the purpose of fast handoff. BTW, in order to support 
> > above feature (2,3), we need a mechanism to tunnel 
> > compressed IP packet or PPP frame.
> > 
> > Regards,
> > Ajoy
> > 
> > -----Original Message-----
> > From: Rajeev Koodli [mailto:[email-masked]]
> > Sent: Monday, September 16, 2002 8:37 PM
> > To: [email-masked]
> > Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration
> > 
> > 
> > 
> > Issue: Should a Fastv6 MN be required to have the
> > option of deferring its new CoA configuration until
> > a "convenient" time ?
> > 
> > Background: In version 04, a MN can defer new CoA
> > configuration until it finds, for instance, suitable
> > radio resources (See Section 3.5.2). This would mean
> > that the MN would be required to suppress RS and
> > Router Advertisement every time it changes access routers
> > until a convenient time. This also means the previous CoA
> > would potentially have to be supported across a series of
> > access routers for arbitrary periods of time.
> > 
> > The proposal is to remove this restriction on new CoA
> > configuration.
> > 
> > Please respond
> > - YES if you agree to remove the restriction
> >     of deferring new CoA
> > - NO otherwise. Indicate a brief reason
> > 
> > Thanks,
> > 
> > -Rajeev
> > 
> > 
>

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 19 Sep 2002 15:30:49 -0700

Ajoy,

My point is, designing a network that can barely
accomodate an ongoing multimedia session and not
even few additional packets once in a while is not
practical. Therefore, "IP address conffiguration
messages blocking real time traffic" should not be
a concern here, IMHO.

alper

----- Original Message -----
From: "Singh Ajoy-ASINGH1" <[email-masked]>
To: "'Alper E. YEGIN'" <[email-masked]>; "Singh Ajoy-ASINGH1"
<[email-masked]>; "'Rajeev Koodli'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, September 19, 2002 7:43 AM
Subject: RE: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Sep 2002 16:55:17 -0700

I tend to agree with Alper in general. We should
assume that a link layer will accommodate IP
address configuration! If the channel allocation
is such that there is delay, then performance
tuning is necessary. We cannot predicate something
like IP address configuration (for our protocol design
purposes) on how _each_ link layer carries frames.
I am not saying that it is unimportant, but it has
to be done some place else.

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 19 Sep 2002 20:15:16 -0700

Hello,

I'd like to solicit some comments/feedback on a Mobile IPv4
feature...

When 'R' bit in the mobility agent advertisement is set, that
means the MNs have to register with the FA even if they are using
co-located care-of address. They have to get authenticated and
authorized. My understanding is that this feature is meant to be
used as an access control mechanism...

Question is: what happens when there are more than one router
on the subnet? One or more of them might be implementing an
FA functionality. Is a MN supposed to be registering with every
one of the FAs? Even if it does, how are the non-FA routers notified
about this MN? Even if an FA requires MNs to register, they can
still get around this if other routers do not apply access control.

Any thoughts/feedback, especially design/deployment experience 
on this matter??

We are looking at a similar scenario with PANA, and need to make
a design decision. PANA authentication agents are likely to be
co-located with first hop routers, and there can be multiple such
agents. Therefore the same issue....

Thanks.

alper

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Mon, 23 Sep 2002 15:05:46 +0900

Hi Alper,

 Good point.  I think it will depend on the policy of a visited
 subnet and an MN's capability.  But, from my understanding,
 registration requests via one FA that sends advertisements
 with an R-bit should be enough.

 One policy and a desirable MN's capability will be as follows:
 - Those FAs that send advertisements with an R-bit know
   how to pass through a firewall.  So, registration requests
   via those FAs may succeed.
 - But, via other FAs or routers, registration request packes
   will be blocked at a firewall.  So, registration requests will
   never succeed via those other FAs or routers.
 - MNs should select or change the 1st hop FA to those FAs
   that send advertisements with an R-bit.

Cheers.
-Yoshi

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 24 Sep 2002 12:25:06 -0700

Hi Yoshi,

>    that send advertisements with an R-bit.

This says MN should only use the FA it has registered with.
I was looking for an answer that enables MN to use any
router/FA on the network once it's registered.

alper

> 
> Cheers.
> -Yoshi
> 
> at Thu, 19 Sep 2002 20:15:16 -0700, Alper E. YEGIN wrote:
> >Hello,
> >

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 24 Sep 2002 12:24:34 +0200

> used as an access control mechanism...

Access control is only one possibility. Accounting is related to
that, but not quite the same thing. There may be other uses, too,
I believe. The rfc uses the words 'visiting policies'.

> still get around this if other routers do not apply access control.

Per RFC3344 (Section 3.1, bullet 2), the MN is supposed to (SHOULD) 
register with *one* of the FA's on the link, if it receives a mobility 
agent advertisement with the 'R' bit set . The implications, although not 
spelled out, would be that:

	.. It is enough to register with one FA, even when multiple FAs
	   and other non-FA routers are present

	.. If this is used to implement access control, it is up to the
	   FA the registration goes through to communicate with other FAs
	   and routers on the link, to implement this properly. The
	   mechanism is not specified.

	.. If other routers are not implementing access control, it is
	   indeed possible to get around this.

I believe the way this is specified in 3344 is good; it codifies the way
things should work with respect to mobile-ip, but does not go into
specifying mechanisms that are not directly mobility related, e.g.
communication of access control or other mechanisms between routers.

	Regards,

		Henrik

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 26 Sep 2002 15:57:00 -0700

> communication of access control or other mechanisms between routers.

I think this is a job half-done. I don't think even forcing a host to
register
with the FA has anything to do with Mobile IP. The FA is simply
providing fowarding service, just like any standard router would do.
It really doesn't matter if the IP packets have another IP packets inside
and the host is doing some magic with them.

alper

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Fri, 27 Sep 2002 03:23:03 +0200

> and the host is doing some magic with them.

To the extent that a visited network may only wish to provide mobility
support to authenticated and registered nodes, I'd say that this *is*
relevant to mobile ip. And I agree that the job is only half done (if
even that), but I think that it's perfectly fine that the mobile ip spec
didn't go further :-).

	Henrik

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 27 Sep 2002 14:30:11 -0700

> relevant to mobile ip.

But in the case of co-located care-of address, the access network
*is not* providing any mobility support. It's just providing "IP access".

> And I agree that the job is only half done (if

alper

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Sat, 28 Sep 2002 02:07:25 +0200

> *is not* providing any mobility support. It's just providing "IP access".

Not so. The network has a choice of permitting nodes migrating in and out
to get connectivity. It can choose to be wide open or completely closed:
not handing out any addresses, not permitting passage to and from the
internet for messages from/to any unknown node, migrating node. OR it
(the visited network) may choose a middle road, by selectively opening
up for some mobile nodes. Providing "just IP access" to mobile nodes *is*
to provide support for them. It is not specifically FA support, but
nevertheless support for them coming in, sending and receiving traffic,
and moving on. It is mobility support, and providing a way to handle
the middle ground between a fully open and fully closed visited network
deserved kudos.

	Henrik

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 27 Sep 2002 17:36:01 -0700

> to provide support for them. It is not specifically FA support, but

Exactly! All you described is only about "IP access" service, nothing
to do with mobility management in the context of Mobile IP protocol.
This network is doing nothing special for the "network-layer mobility
management" of the "nodes". Just because some of those nodes are
"mobile node" doesn't mean that the service provided by the network
is "mobile IP". Some of those nodes might even be using end2end IPsec with
their peers on the other side of the Internet. Now would we say that the
access network is also providing "security" support?

alper

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Sat, 28 Sep 2002 02:55:00 +0200

> Exactly! All you described is only about "IP access" service, nothing

You seem to equate "mobile ip" with "FA". I don't. I do wish you'd read
on to the end of the paragraph. 

> access network is also providing "security" support?

Hm. You seem more interesting in propagating a different viewpoint than
in getting the feedback you solicited. Anyway, it seems that I value the
possibility of providing visitors to a foreign network with a way to
authenticate themselves and then get connectivity, while you would prefer
them to have no such possibility, and be locked out?

	Henrik