Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

From: "Noll, Kevin" <[email-masked]>
Date: Wed, 1 Jul 2009 09:52:08 -0400

I've been lurking here for a while watching the conversation. Please
accept my apologies for dropping in unexpectedly, but I thought I might
give at least one operator's viewpoint.

You are correct that most data cards being sold today require you to
install the carrier's software. This software typically contains a
connection manager and the OS drivers required to operate the data card.
Technically speaking, the data cards that I have worked with do not all
*require* the connection manager to operate, though it varies from card
to card. Obviously, though, they *do* need the drivers.

What we saw with WiFi was a technology that began as an add-on to our
computing devices (laptops, etc.). WiFi grew, matured, and became so
widely accepted that operating systems began to ship with native
drivers, the add-on device became integrated into the computing devices
and we no longer needed to install 3rd-party drivers or connection
software.

As a network provider/operator, we like this model because it is very
expensive to write and maintain the connection software and drivers and
keep the user's device up to date. Adding a mobility stack to the
software being installed adds significantly to this cost. We are seeing
the cost come down, but there's still the issue of configuration and
what-not.

We expect to see open networks and technologies like WiMAX (and possibly
LTE) change the traditional cellular data-card model to one that is more
similar to WiFi, hopefully driving down the cost of the software and
moving the software development tasks out of the operator and into the
OS vendor community.

This said, I think it would be a mistake to make any assumptions on
either of the two points mentioned below. 

1. In the future the carrier may not deliver software with the data
card, so it's probably a bad assumption to say that the carrier would
simply deliver a mobility stack with the device.

2. It's probably a good assumption to say that devices will eventually
have native mobility stacks. We are already seeing this development in
mainstream operating systems. This is similar to the evolution of WiFi.

3. It's probably not a good assumption to say that *all* devices will
have the perfect combination of native support or carrier support.

4. At least some carriers prefer to manage mobility inside the network
rather than on the customer device. This is something that we are
constantly discussing internal to our organization, with vendors, and
with other operators.

Based on this, the case for extending the functionality of PMIP6 is
pretty strong, at least in my opinion. 

On the other hand, we will also continue following the development of
native stacks and evaluate when and how best to use them in our product
offerings. Similarly, we will continue to evaluate whether or not we
need to deliver a mobility stack with our data card software.

Thanks!

--kan--
--
Kevin A. Noll

P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hesham Soliman
Sent: Tuesday, June 30, 2009 11:59 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof
description

Hi Raj, 

I had a brief offline chat with Julien and thought that I could refine
my
suggestion a bit more to make the point clearer. My point is that there
are
currently two slightly different points being made about the requirement
on
host involvement 1) no SW on the host and the more nuanced 2) no
protocol
support on the host. I won't even get into the reasons for point 2)
above
and I'll let the people who raise it provide those reasons, I can't
figure
out any technical reasons there.

Anyway, my point is that 1) above is not an issue today because it
already
happens on a very large scale, so requiring it for a specific feature
like
multihoming is hardly a leap. I can imagine ads for "download your
wireless
optimiser from wwww.operator.com and save money" (ok not very creative).
The subtle difference between 1) and 2) is IMO a moot point anyway
because
2) simply says that operators don't want protocol support in the
network,
but that support already exists in the form of PMIP and if you have PMIP
you
have MIP. So, both motivations seem to be on shaky ground.
And yes, you can of course integrate 3G modems in computers, but you can
also integrate mobility code in the same computers with the 3G support.
The
SW that is provided with the modems is not only connection SW it
actually
provides a number of features (e.g. Receiving SMS, account information,
email ....etc) so it's a clear move by operators to be present on those
machines. I don't think it's anything like WLAN connctions SW.

Of course it's worth mentioning that the elephant in the room is the
binary
requirement on host support of protocols. We need to have a yes/no
answer as
to whether there is a requirement to NOT have protocol support in the
host.
At the moment this is being kept very vague.

Hesham

>> => No one I know can get a 3G data card to access the Internet from
their PC
>> without having to install a piece of software  on their PC to make it
work.
>> So I think your assumption that the operator cannot mandate software
on the
>> host is questionable, because they already do (unfortunately).
> 
> The situation that you describe above was the same when 802.11 first
rolled
> around as well.
> You had to install a piece of software that came with the PC card. But
that
> has changed with 
> wifi now being an integral part of the notebook computers.
> And I think you could expect 3G chipsets and access built-in as well
in due
> course of time. At least I know of a few
> operators in the US (as well as notebook manufacturers) who offer such
> net/notebook computers,
> i.e with integrated 3G access. I do not know what additional sw is
loaded on
> these but at least the end user
> is not installing anything else.
> Does it imply that such hosts will include the software that would
enable host
> mobility? Its an open question (i.e unknown)
> and will depend largely on operator choices and vendors.
> 
> -Raj
> 
>> Hesham
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

---

From: "Noll, Kevin" <[email-masked]>
Date: Wed, 1 Jul 2009 11:39:59 -0400

Perhaps I didn't catch the whole intent of the discussion, but I am assuming that there is *no* client software or stack requirement to support PMIP6 or any of its extensions.

If there were extensions to PMIP6 that required client software changes, then we might as well install a complete MIP6 stack. On the other hand, I can see scenarios where we might want some functionality on the client to help make HO decisions or improve the efficiency of a HO, but not want a complete IP mobility stack. This second scenario seems to suggest using extensions based on something like MIH.

Based on this (only some brief thought given to it), perhaps an approach would be to specify the ability for a PMIP6 client (not the MN, but the network element) to converse with an MIH client and/or server. This could avoid the need to *require* something on the MN, but take advantage of it when it is available.

--kan--
--
Kevin A. Noll

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2009 11:14 AM
To: Noll, Kevin; [email-masked]
Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description

Hi Kevin,
  Nice to hear from you!

----- Original Message ----
> From: "Noll, Kevin" <[email-masked]>
> To: [email-masked]; [email-masked]
> Sent: Wednesday, July 1, 2009 8:52:08 AM
> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
> 

Are you saying that the extended functionality for PMIPv6  can be downloaded with the device driver, or in the future it will be included in the OS?

Can you please elaborate on this as this is the most relevant to the current discussion? Why not then some other things like MIP6 client?

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Jul 2009 08:51:22 -0700 (PDT)

I don't see any enthusiasm on MIH anywhere.
I think the current discussion is around additional functionality for HO. I think PMIP supporters will argue that this can be done in IETF and the opponents will argue that that is L2 and thus not an IETF issue.

My post to netext ML didn't go through, anyways it is OK to exhange ideas with you. We can go to the list if you like.

Regards,

Behcet

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>; [email-masked]
> Sent: Wednesday, July 1, 2009 10:39:59 AM
> Subject: RE: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
> 
> 
> Perhaps I didn't catch the whole intent of the discussion, but I am assuming 
> that there is *no* client software or stack requirement to support PMIP6 or any 
> of its extensions.
> 
> If there were extensions to PMIP6 that required client software changes, then we 
> might as well install a complete MIP6 stack. On the other hand, I can see 
> scenarios where we might want some functionality on the client to help make HO 
> decisions or improve the efficiency of a HO, but not want a complete IP mobility 
> stack. This second scenario seems to suggest using extensions based on something 
> like MIH.
> 
> Based on this (only some brief thought given to it), perhaps an approach would 
> be to specify the ability for a PMIP6 client (not the MN, but the network 
> element) to converse with an MIH client and/or server. This could avoid the need 
> to *require* something on the MN, but take advantage of it when it is available.
> 
> --kan--
> --
> Kevin A. Noll
> 
> 
> 
> P Go Green! Print this email only when necessary. Thank you for helping Time 
> Warner Cable be environmentally responsible.
> 
> 
> > From: "Noll, Kevin" 
> > computing devices (laptops, etc.).. WiFi grew, matured, and became so
> Are you saying that the extended functionality for PMIPv6  can be downloaded 
> with the device driver, or in the future it will be included in the OS?
> 
> Can you please elaborate on this as this is the most relevant to the current 
> discussion? Why not then some other things like MIP6 client?
> 
> Regards,
> 
> Behcet
> 
> 
>       
>

---

From: "Noll, Kevin" <[email-masked]>
Date: Wed, 1 Jul 2009 11:53:01 -0400

Behcet, I didn't answer your question in my previous e-mail.

I believe there are factors outside of our control that will determine whether these extensions will be included in the OS. These are things like market acceptance, widespread deployment, etc. 

It is reasonable to think that lightweight extensions could be included in data-card drivers, whether they are provided by the carrier, by an OEM, or someone else.

However, it seems to me that if this solution is an IP-based solution, the extensions may be outside the scope of the typical OS-level driver implementation. Based on this, you may see that you are forced into a scenario that requires an actual stack modification. I doubt this would be something that a carrier would want to support unless there is a significant economic, operational, or user-experience advantage. Instead, they would rather not use it at all, or use what is natively available in the OS.

--kan--
--
Kevin A. Noll

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2009 11:14 AM
To: Noll, Kevin; [email-masked]
Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description

Hi Kevin,
  Nice to hear from you!

----- Original Message ----

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Jul 2009 08:56:19 -0700 (PDT)

Behcet Sarikaya wants to recall this message.

It was intented to be a private message, sent to the list by mistake.

----- Forwarded Message ----
> From: Behcet Sarikaya <[email-masked]>
> To: "Noll, Kevin" <[email-masked]>; Behcet Sarikaya <[email-masked]>; [email-masked]
> Sent: Wednesday, July 1, 2009 10:51:22 AM
> I think the current discussion is around additional functionality for HO. I 
> think PMIP supporters will argue that this can be done in IETF and the opponents 
> will argue that that is L2 and thus not an IETF issue.
> 
> > To: Behcet Sarikaya ; [email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Jul 2009 08:56:19 -0700 (PDT)

---

From: <[email-masked]>
Date: Wed, 1 Jul 2009 19:46:27 +0200

Hi Hesham,

On 6/30/09 10:59 PM, "ext Hesham Soliman" <[email-masked]> wrote:

> 
> 
> Hi Raj,
> 
> I had a brief offline chat with Julien and thought that I could refine my
> suggestion a bit more to make the point clearer. My point is that there are
> currently two slightly different points being made about the requirement on
> host involvement 1) no SW on the host and the more nuanced 2) no protocol
> support on the host. I won't even get into the reasons for point 2) above
> and I'll let the people who raise it provide those reasons, I can't figure

I believe that host involvement is imperative to enable features such as
inter-tech HO and flow binding/mobility for PMIP6. Some aspects of these
features may be potentially accomplished by doing some additional signaling
in the network itself and involving the policy store function to an even
greater degree. I do not believe that you can avoid having some requirements
on the host.  

> 
> Anyway, my point is that 1) above is not an issue today because it already
> happens on a very large scale, so requiring it for a specific feature like
> multihoming is hardly a leap. I can imagine ads for "download your wireless
> The subtle difference between 1) and 2) is IMO a moot point anyway because
> 2) simply says that operators don't want protocol support in the network,
> but that support already exists in the form of PMIP and if you have PMIP you
> have MIP. 

While I agree that having PMIP equates to having MIP, it is only from the
perspective of the fact that the LMA is also a DSMIP6 HA. But this fact is
of no use in actual deployments. An LMA will not operate as a DSMIP6 HA
unless there is explicit support enabled for it to operate as an HA. I just
don't see the LMA accepting BUs from a (DS)MIP6 MN or establishing IPsec SAs
to secure the signaling. My point is that while the functionality of the
DSMIP6 HA exists in the LMA, it is simply unable to operate as such without
additional features being enabled.

Regarding point 1 above, I don't know if you are suggesting that MIP6 client
SW can simply be downloaded on a host and would work subsequently. While I
wish that were the case, I think we are still pretty far from such
capability. 

> So, both motivations seem to be on shaky ground.
> also integrate mobility code in the same computers with the 3G support. The
> SW that is provided with the modems is not only connection SW it actually

If the 3G modem requires a mobility stack in order to attach and access a 3G
network, then yes the host will include such SW. But if the only thing
needed is a device driver and some interface to a connection manager type of
app, then I don't see OS vendors going out of their way to add SW that would
be considered optional. If all the connectivity aspects are in the 3G modem
and the device driver then the need for mobility stack SW at L3 are
diminished. 

> 
> Of course it's worth mentioning that the elephant in the room is the binary
> requirement on host support of protocols. We need to have a yes/no answer as
> to whether there is a requirement to NOT have protocol support in the host.

I think it is an unknown. Is there a need for L3 protocol support on the
host to accomplish the functionality being aimed for?
It might be the case that some of this L3 protocol support be achieved by
extending existing protocols such as DHCPv6 or ND (just examples and not to
be considered as solutions). Or there may be recommendations to L2s in which
case the IETF would only recommend some capabilities that L2 would be
required to have to provide these features. This is probably the reason why
there is no definitive yes/no answer on the need for protocol support in the
host. It should also be pointed out that requiring protocol support on the
host is not directly equilavalent to having a MIP client on the host. There
are degrees of differences between a MIP client vs some simple protocol
support. 

-Raj

> 
> Hesham
> 
>>> => No one I know can get a 3G data card to access the Internet from their PC
>>> without having to install a piece of software  on their PC to make it work.
>>> So I think your assumption that the operator cannot mandate software on the
>> The situation that you describe above was the same when 802.11 first rolled
>> around as well.
>> You had to install a piece of software that came with the PC card. But that
>> has changed with
>> And I think you could expect 3G chipsets and access built-in as well in due
>> i.e with integrated 3G access. I do not know what additional sw is loaded on
>> Does it imply that such hosts will include the software that would enable
>> host

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Jul 2009 02:25:45 +1000

Kevin, 

Thanks for the input. I understand where you're coming from and I have two
small comments to make.

First I think you're assuming that mobility support for the multihoming
scenario we're discussing must be done in the kernel. This is not the case
at all. Things can be done in user space as an add-on application.

> constantly discussing internal to our organization, with vendors, and

=> To be precise, all carriers manage mobility from both the network and
host sides. It's just not L3 mobility. So the question should be whether it
is acceptable to manage L3 mobility on both sides as well. And there is
pretty good reasons for doing that, especially that most mobile devices
today have multiple interfaces to different technologies, which never
happened before. 

Hesham

On 1/07/09 11:52 PM, "Noll, Kevin" <[email-masked]> wrote:

> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Noll, Kevin" <[email-masked]>
Date: Wed, 1 Jul 2009 14:48:45 -0400

Hesham,

I don't think I was assuming kernel-space or user-space. I *think* I was
approaching this from how I have seen most implementations. It seems
pretty typical that the connection manager is a user-space application,
but the data-card drivers are OS-level. For example, in Windows a 3G
data-card typically is installed as a RAS device and WiFi cards show up
as NDIS.

I don't think any solution *must* hold to this model. Thanks, though,
for calling out what may be an unknown assumption on my part.

Agreed, carriers manage mobility on both sides and at multiple layers.
>From my point of view (at least for this discussion) I only care about
L3 and assume that any lower-layer mobility is hidden from me. On the
other hand, I think it is important, if not necessary, that L1/L2
information be available to L3 and above in order to make HO functions
more robust.

Also, I tend to think that network-based mobility (e.g. PMIP6) should be
network-based and not place requirements on the MN. Similarly, if you
are going to make a requirement on the MN, you might as well go all-in
and make it CMIP. Of course, there are implications on memory, CPU, etc.
so my all or nothing approach is probably not a very practical one. 

--kan--
--
Kevin A. Noll

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2009 12:26 PM
To: Noll, Kevin; [email-masked]; [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof
description

Kevin, 

Thanks for the input. I understand where you're coming from and I have
two
small comments to make.

First I think you're assuming that mobility support for the multihoming
scenario we're discussing must be done in the kernel. This is not the
case
at all. Things can be done in user space as an add-on application.

host sides. It's just not L3 mobility. So the question should be whether
it

Hesham

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 1 Jul 2009 18:57:56 -0400

Hi Kevin,

> L3 and assume that any lower-layer mobility is hidden from 
> me. On the other hand, I think it is important, if not 
> necessary, that L1/L2 information be available to L3 and 
> above in order to make HO functions more robust.

Yes, such indications could include the network informing the MN to use
a different interface for a particular traffic flow.

> 
> Also, I tend to think that network-based mobility (e.g. 
> PMIP6) should be network-based and not place requirements on 
> the MN. Similarly, if you are going to make a requirement on 
> the MN, you might as well go all-in and make it CMIP. Of 
> course, there are implications on memory, CPU, etc.

Perhaps implicit here is the distinction between changes to mobility
protocol that affects the MN and extensions in general (such as the
ability to inform a MN to use a different i/f for a particular traffic
flow).

I agree that MN should still be unaware of how its mobility is managed.
We should also allow for "supplementary" (for the lack of a better word)
extensions (which may need to be done L3).

Regards,

-Rajeev

> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft 
> of the bof description
> 
> Kevin, 
> 
> Thanks for the input. I understand where you're coming from 
> and I have two small comments to make.
> 
> First I think you're assuming that mobility support for the 
> multihoming scenario we're discussing must be done in the 
> kernel. This is not the case at all. Things can be done in 
> user space as an add-on application.
> 
> => To be precise, all carriers manage mobility from both the 
> network and host sides. It's just not L3 mobility. So the 
> question should be whether it is acceptable to manage L3 
> mobility on both sides as well. And there is pretty good 
> reasons for doing that, especially that most mobile devices 
> today have multiple interfaces to different technologies, 
> which never happened before. 
> 
> Hesham
> 
> 
> > my suggestion a bit more to make the point clearer. My point is that
> there
> > are
> > protocol support on the host. I won't even get into the reasons for 
> > point 2) above and I'll let the people who raise it provide those 
> > reasons, I can't figure out any technical reasons there.
> > 
> > already happens on a very large scale, so requiring it for 
> a specific 
> > feature like multihoming is hardly a leap. I can imagine ads for 
> > "download your wireless optimiser from wwww.operator.com and save 
> > money" (ok not very
> creative).
> > network, but that support already exists in the form of PMIP and if 
> > you have
> PMIP
> > you
> > actually provides a number of features (e.g. Receiving SMS, account
> information,
> > binary requirement on host support of protocols. We need to have a 
> > yes/no answer as to whether there is a requirement to NOT have 
> > protocol support in the host.
> >> course of time. At least I know of a few operators in the 
> US (as well 
> >> as notebook manufacturers) who offer
> such
> >> net/notebook computers,
> >> mobility? Its an open question (i.e unknown) and will 
> depend largely 
> >> on operator choices and vendors.
> >> 
> >> -Raj
> >> 
> >>> Hesham
> >> 
> > This E-mail and any of its attachments may contain Time 
> Warner Cable 
> > proprietary information, which is privileged, confidential, 
> or subject 
> > to copyright belonging to Time Warner Cable. This E-mail is 
> intended 
> > solely for the use of the individual or entity to which it is 
> > addressed. If you are not the intended recipient of this 
> E-mail, you 
> > are hereby notified that any dissemination, distribution, 
> copying, or 
> > action taken in relation to the contents of and attachments to this 
> > E-mail is strictly prohibited and may be unlawful. If you have 
> > received this E-mail in error, please notify the sender immediately 
> > and permanently delete the original and any copy of this E-mail and 
> > any printout.
> This E-mail and any of its attachments may contain Time 
> Warner Cable proprietary information, which is privileged, 
> confidential, or subject to copyright belonging to Time 
> Warner Cable. This E-mail is intended solely for the use of 
> the individual or entity to which it is addressed. If you are 
> not the intended recipient of this E-mail, you are hereby 
> notified that any dissemination, distribution, copying, or 
> action taken in relation to the contents of and attachments 
> to this E-mail is strictly prohibited and may be unlawful. If 
> you have received this E-mail in error, please notify the 
> sender immediately and permanently delete the original and 
> any copy of this E-mail and any printout.
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 02 Jul 2009 10:31:31 +1000

> and make it CMIP.

=> I agree with this. I think it's a practical approach to do that, at least
from a requirements point of view. I personally don't believe you can use
PMIP to support multihoming, flow movements ....etc but as far as
requirements go this is sensible because it's sticking for the reasons with
going to PMIP in the first place.

 Of course, there are implications on memory, CPU, etc.
> so my all or nothing approach is probably not a very practical one.

=> I wouldn't worry about memory/CPU requirements for MIP with today's 3G
devices, by the time it's implemented it will be an insignificant part of
the memory on a phone, not to mention a PC.

Hesham

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 09:21:54 +0200

Raj,

in one mail you wrote

[email-masked] escribió:
>
> Or there may be recommendations to L2s in which
> required to have to provide these features. 

and then in another where is posed :

Questions:
> 
> 1)- What L2 technologies are supported? All the L2 technologies? A
> subset of L2 technologies?

You answered:

I don't think we should be developing solutions for some subset of L2
technologies. I think the discussion of what L2s are applicable in the
context of this discussion is a rat-hole.

So, I am very very confused now
.
Is the requirement that the solution works with any L2 or is the 
requirement that the solution works with only a subset of L2 that have 
some capabilties?

Cause AFAIU, if we require that the solution applies to all L2, then the 
first option is not accetpable.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 09:24:32 +0200

[email-masked] escribió:
> to secure the signaling.

Are you implying some form of requirement in terms of which entities can 
have SAs?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 09:37:46 +0200

> ability to inform a MN to use a different i/f for a particular traffic

i fail to see how this is not central to the flow mobility feature that 
we need to provide

Regards, marcelo

>>> 4. At least some carriers prefer to manage mobility inside 
>>>       
>> the network 
>>     
>>> constantly discussing internal to our organization, with 
>>>       
>> vendors, and 
>>     
>>> with other operators.
>>>       
>>> I've been lurking here for a while watching the 
>>>       
>> conversation. Please 
>>     
>>> accept my apologies for dropping in unexpectedly, but I thought I
>>>       
>> might
>>     
>>> You are correct that most data cards being sold today 
>>>       
>> require you to 
>>     
>>> connection manager and the OS drivers required to operate the data
>>>       
>> card.
>>     
>>> Technically speaking, the data cards that I have worked with do not
>>>       
>> all
>>     
>>> *require* the connection manager to operate, though it varies from
>>>       
>> card
>>     
>>> What we saw with WiFi was a technology that began as an 
>>>       
>> add-on to our 
>>     
>>> computing devices (laptops, etc.). WiFi grew, matured, and 
>>>       
>> became so 
>>     
>>> drivers, the add-on device became integrated into the computing
>>>       
>> devices
>>     
>>> As a network provider/operator, we like this model because 
>>>       
>> it is very 
>>     
>>> expensive to write and maintain the connection software and drivers
>>>       
>> and
>>     
>>> software being installed adds significantly to this cost. We are
>>>       
>> seeing
>>     
>>> the cost come down, but there's still the issue of 
>>>       
>> configuration and 
>>     
>>> what-not.
>>>
>>> We expect to see open networks and technologies like WiMAX (and
>>>       
>> possibly
>>     
>>> LTE) change the traditional cellular data-card model to one that is
>>>       
>> more
>>     
>>> similar to WiFi, hopefully driving down the cost of the 
>>>       
>> software and 
>>     
>>> moving the software development tasks out of the operator 
>>>       
>> and into the 
>>     
>>> OS vendor community.
>>>
>>> card, so it's probably a bad assumption to say that the 
>>>       
>> carrier would 
>>     
>>> 2. It's probably a good assumption to say that devices will 
>>>       
>> eventually 
>>     
>>> have native mobility stacks. We are already seeing this 
>>>       
>> development in 
>>     
>>> mainstream operating systems. This is similar to the evolution of
>>>       
>> WiFi.
>>     
>>> 3. It's probably not a good assumption to say that *all* 
>>>       
>> devices will 
>>     
>>> 4. At least some carriers prefer to manage mobility inside 
>>>       
>> the network 
>>     
>>> constantly discussing internal to our organization, with 
>>>       
>> vendors, and 
>>     
>>> with other operators.
>>>
>>> On the other hand, we will also continue following the 
>>>       
>> development of 
>>     
>>> native stacks and evaluate when and how best to use them in our
>>>       
>> product
>>     
>>> offerings. Similarly, we will continue to evaluate whether 
>>>       
>> or not we 
>>     
>>> P Go Green! Print this email only when necessary. Thank you for
>>>       
>> helping Time
>>     
>>> From: [email-masked] [mailto:[email-masked]] On
>>>       
>> Behalf
>>     
>>> Of Hesham Soliman
>>> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft 
>>>       
>> of the bof 
>>     
>>> description
>>>
>>>
>>> Hi Raj,
>>>
>>> I had a brief offline chat with Julien and thought that I 
>>>       
>> could refine 
>>     
>>> currently two slightly different points being made about the
>>>       
>> requirement
>>     
>>> on
>>> And yes, you can of course integrate 3G modems in computers, but you
>>>       
>> can
>>     
>>> also integrate mobility code in the same computers with the 3G
>>>       
>> support.
>>     
>>> The
>>> email ....etc) so it's a clear move by operators to be present on
>>>       
>> those
>>     
>>> Of course it's worth mentioning that the elephant in the 
>>>       
>> room is the 
>>     
>>>>> => No one I know can get a 3G data card to access the 
>>>>>           
>> Internet from
>>     
>>> their PC
>>>       
>>>>> without having to install a piece of software  on their PC to make
>>>>>           
>> it
>>     
>>> work.
>>>       
>>>>> So I think your assumption that the operator cannot 
>>>>>           
>> mandate software
>>     
>>> on the
>>>       
>>>> The situation that you describe above was the same when 
>>>>         
>> 802.11 first
>>     
>>> rolled
>>>       
>>>> around as well.
>>>> You had to install a piece of software that came with the PC card.
>>>>         
>> But
>>     
>>> that
>>>       
>>>> has changed with
>>>> And I think you could expect 3G chipsets and access 
>>>>         
>> built-in as well
>>     
>>> in due
>>>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 2 Jul 2009 13:22:03 -0400

Hi Marcelo,

>> i fail to see how this is not central to the flow mobility feature that

RKo> if the network decides to move a flow from one interface to another, it would be good to have the ability to inform the MN, no?

-Rajeev

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 20:13:06 +0200

> RKo> if the network decides to move a flow from one interface to another, it would be good to have the ability to inform the MN, no?

exactly, so this is why i fail to see how this is not central to the 
mobility mechanisms that we want to define

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 2 Jul 2009 14:39:52 -0400

> > RKo> if the network decides to move a flow from one 
> interface to another, it would be good to have the ability to 
> inform the MN, no?
> >  
> 
> exactly, so this is why i fail to see how this is not central 
> to the mobility mechanisms that we want to define
> 

Okay, we seem to be in agreement largely. 

I don't claim that this is central to mobility management, which is
basically PMIP.

However, this kind of indication may be necessary for a feature (such as
flow mobility) to work - if we cannot find support in L2. 

-Rajeev

> >> We should also allow for "supplementary" (for the lack of a better 
> >> word) extensions (which may need to be done L3).
> >>
> >>  
> >>     
> >
> >
> >   
> >> Regards,
> >>
> >> -Rajeev
> >>
> >>
> >>  
> >>     
> >>> --kan--
> >>> --
> >>> Kevin A. Noll
> >>>
> >>>
> >>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first 
> draft of the 
> >>> bof description
> >>>
> >>> Kevin,
> >>>
> >>> Thanks for the input. I understand where you're coming from and I 
> >>> have two small comments to make.
> >>>
> >>> multihoming scenario we're discussing must be done in the kernel. 
> >>> This is not the case at all. Things can be done in user 
> space as an 
> >>> add-on application.
> >>>
> >>> => To be precise, all carriers manage mobility from both 
> the network 
> >>> and host sides. It's just not L3 mobility. So the 
> question should be 
> >>> whether it is acceptable to manage L3 mobility on both sides as 
> >>> well. And there is pretty good reasons for doing that, especially 
> >>> that most mobile devices today have multiple interfaces 
> to different 
> >>> technologies, which never happened before.
> >>>
> >>> Hesham
> >>>
> >>>
> >>> proprietary information, which is privileged, confidential, or 
> >>> subject to copyright belonging to Time Warner Cable. This 
> E-mail is 
> >>> intended solely for the use of the individual or entity 
> to which it 
> >>> is addressed. If you are not the intended recipient of 
> this E-mail, 
> >>> you are hereby notified that any dissemination, distribution, 
> >>> copying, or action taken in relation to the contents of and 
> >>> attachments to this E-mail is strictly prohibited and may be