Subject: [netlmm] Using (or not?) netlmm multihoming in real-world

From: Jari Arkko <[email-masked]>
Date: Sat, 06 Oct 2007 02:17:59 +0300

There seems to be a couple of ways out of the current
discussion.

One way is to declare the issue out of scope. However,
there are a couple of potential problems with this. First,
declaring an issue out of scope may not actually prevent
users configuring things in a bad way. Or if we don't
describe the true limitations, operators/SDOs may
deploy it in the wrong way. But depending on the
circumstances, this might still work, particularly
if we are able to explain what will happen if the
limitations are not followed and/or if we can make
things fail gracefully.

Second, we can make it work. I've seen some promising
discussion in the last two days; maybe we can make this
happen.

Third, we can convince ourselves that there was no
problem to begin with.

However, I have some questions for those who intend to
deploy NETLMM.

1) Will there be NETLMM domains that have multiple access
technologies?

2) Do you intend to use NETLMM for movements
across multiple access technologies? While retaining
the same IP address? Does this have to work even
if you plug in regular, separate WLAN and 3G cards
to an unmodified host?

3) Is there an expectation to use multiple interfaces
simultaneously (or perhaps just long enough to
make make-before-break work).

Please note that these are not questions about what
you want to have in the base spec; I want to know what
3GPP etc. would likely do with NETLMM.

Jari

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 05 Oct 2007 22:03:13 -0700

Hi Jari,

I don't want to speak for 3GPP, but here is my opinion on whats 
happening in 3GPP.

> 1) Will there be NETLMM domains that have multiple access

Yes.

> the same IP address? 

Yes to both.

> Does this have to work even

This is a tricky question. There is no easy answer to this since I don't 
think 3GPP has figured this out yet. IMHO, there is typically some 
software on the laptop that would be used to share security credential 
across the WLAN and 3G cards. Moreover you cannot connect to a 3GPP 
packet network using WLAN interface with an unmodified host. You need 
some software that sets up an IPsec tunnel to the PDG (packet data gateway).

> make make-before-break work).

No. I think it is just for the make-before-break handover. I could be 
wrong though.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Sat, 06 Oct 2007 00:42:17 -0500

Hi Jari,

My take on the questions in your email below:

> limitations are not followed and/or if we can make

I think providing guidelines and explaining the limitations of a protocol
would be sufficient in many cases. In order to develop a system level
solution, the IETF protocols are developed piecemeal. We don't have to solve
all the issues or include every feature that is required in a single
document. Hence I do agree that in the context of the current PMIP6 I-D
explaining the limitations and providing some guidelines is enough. A full
solution to the multihoming issue can be taken up subsequently.

> discussion in the last two days; maybe we can make this

I guess it depends on how detailed and broad in terms of scope the solution
will be if taken up as an add-on to the current base protocol spec.

> Third, we can convince ourselves that there was no

That would be even better :)

> 1) Will there be NETLMM domains that have multiple access

Yes. I see no reason to limit a Netlmm domain to be access technology
specific. It would be useful for the network elemnts to be aware of the
access technology via which the MN is attaching.

> across multiple access technologies?

Yes.

> While retaining

Yes.. In order to maintain session continuity the same IP address has to be
maintained.

> if you plug in regular, separate WLAN and 3G cards

Depends on what you classify as an unmodified host...
Personally I don't think this will work in a generic unmodified host. But
the point is there could be PC cards which include multiple interfaces such
as 3G and WLAN in the same card or access networks for which hosts are
designed with a different set of criteria. So I think we can recognize the
limitation of such capability in generic unmodified legacy hosts, it should
not be a roadblock for other types of hosts.

> make make-before-break work).

The use cases for simultaneous use of multiple interfaces are quite limited
at least IMO. However for handover such use is expected to optimize the HO
performance.

Disclaimer: I do not speak for 3GPP or other SDOs which may have an interest
in PMIP6.

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 6 Oct 2007 00:16:22 -0700

Hi Jari,

My view on this.

The problem I see is that we are trying to argue on the legal
grounds and ignoring the practical side. NETLMM does not require
the host to participate in any mobility related signaling, but
that does not imply there is zero software requirements for 
supporting multi-homing. No operator will qualify a host for
multi-homing in PMIP6 domain, if it has just the basic IP stack.
There needs to be additional software on the host besides the
basic stack, otherwise the address mobility is unpredictable
and that beats the basic goal of NETLMM. We are ignoring this
aspect and trying to solve the issue of brief connectivity loss
due to prefix oscillation between the MAG's where the mobile node
is attached. Lets look at the following:

The key property of a PMIPv6 domain:
====================================
A host will be able to move in the Proxy Mobile IPv6 domain
with out loosing its address configuration. Session continuity
is guaranteed. This is the absolute goal, whether the host
connects to the network using a single point of attachment or
using multi-homing.

Properties of a Multi-homed host
================================
Typically, there will be only one active interface, even though
there is address configuration on multiple interfaces. When
application makes a socket call, the kernel typically returns
the first valid address on the interface. Depending on what
interface was active initially, the applications are bound to the
valid address on that interface. 

If that active interfaces goes down, the applications that are
bound to the address on that interface will not survive, as the
source address is lost.

Host will not do load balancing or move the flows from one interface
to the other, if the interface shuts down.

Impact of connecting a multi-homed host to a PMIP6 domain
=========================================================
Now, if a multi-homed host connects to the PMIP6 domain, some 
interfaces may be attached to the PMIP6 domain and some interfaces
may be connected to access networks outside the PMIP6 domain. We
cannot ensure the host only connects to the PMIP6 domain. Because,
our assumption of a legal 2461 IP host. The host will have address
configuration on the interfaces from PMIP6 domain and also address
configuration from access network outside the PMIP6 domain.
Applications may end up binding to address on the PMIP6 domain or
to non PMIP6 domain addresses. Now, if the mobile looses connectivity
to the access network in the non-PMIP6 domain, the applications bound
to the address on that interface are dead. 

Whether we give a unique prefix to each interface or the same
prefix to all interfaces in the PMIP6 domain, we WILL NOT be able
to guarantee session continuity for applications on that host. In
other words, the basic property of the PMIP6 domain will be broken
for a multi-homed host. Unless there is additional software on the
host. 

The solution for this requires additional application software 
such as connection manager on the host, which all operators today
ship with the 3G cellular cards and that is not a new requirement.
The solution also requires simultaneous binding/bicasting support
in the PMIP6 network.

Bottom line
============
Multi-homing is out of scope.

Multi-homing is not a baseline feature. The solution requires 
changes/additional software on the host and requires simultaneous
binding support in the network. 

Operators using AAA or other interfaces will have the ability to
ensure only one interface connects to the PMIP6 domain. 

We should preserve the basic property of per-MN prefix model as
supposed to a per-interface prefix model. Any such restrictions
are bad and will not allow us to do future work on multi-homing.

The document clearly specifies the protocol requirements with 
respect to the host and also the issues with multi-homing. So,
IMHO, that should be sufficient.

Thanks
Sri

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, October 05, 2007 4:18 PM
> To: [email-masked]
> Subject: [netlmm] Using (or not?) netlmm multihoming in real-world
> 
>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sat, 06 Oct 2007 17:27:20 +0900

Hi Jari,

I also observed in the same way as Vijay does. Inter access technology 
handover and multi-homing have different purposes and different 
requirements. What is most wanted is the former, which is still my 
personal opinion and not any SDO's. All the discussions on this thread 
are very valid, so it may be a good idea to note what should be 
considered to make it happen in the base spec. It is, however, not 
necessary to provide a complete and future-proof solution at this point.

Regards,
-- 
Hidetoshi

---

From: "Tsirtsis, George" <[email-masked]>
Date: Sat, 6 Oct 2007 03:09:52 -0700

Just adding some notes on the questions Vijay/Raj responded to....

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Saturday, October 06, 2007 6:42 AM
To: ext Jari Arkko; [email-masked]
Subject: Re: [netlmm] Using (or not?) netlmm multihoming in real-world
...

Yes.

> the same IP address?

Yes.. In order to maintain session continuity the same IP address has to
be
maintained.

GT> I think the answer to 1 & 2 is clear. 3GPP REL8 (which is still in
progress but somewhat stable) uses NETLMM for inter-technology and
inter-domain mobility and session continuity as one of the options; the
other being DSMIPv6. Also note that the two approaches are supposed to
coexists.

Depends on what you classify as an unmodified host...
Personally I don't think this will work in a generic unmodified host.
But
the point is there could be PC cards which include multiple interfaces
such
as 3G and WLAN in the same card or access networks for which hosts are
designed with a different set of criteria. So I think we can recognize
the
limitation of such capability in generic unmodified legacy hosts, it
should
not be a roadblock for other types of hosts.

GT> This is indeed a more difficult question and gets into a bit of
business aspects which are not exactly our domain here. I will risk
saying the following though. It seems to me that 3GPP currently does not
deal with this case directly i.e., I am not aware of any explicit work
trying to define exactly how such thing is does. We should not, however,
confuse not dealing with something, with not allowing it or not
expecting it. In general the industry has benefited from allowing device
manufacturers maximum flexibility in the products they create. 

> make make-before-break work).

The use cases for simultaneous use of multiple interfaces are quite
limited
at least IMO. However for handover such use is expected to optimize the
HO
performance.
 
GT> It would be a major error in judgment to make assumptions on this
issue. The user device market is one of the most competitive and diverse
in the industry. No one in this thread has full understanding or
knowledge of all the devices connected to the Internet and Cellular
networks. What device manufacturers come up with and how these devices
are combined and used is unknown and unpredictable, while it also
demands our commitment to serve the general case so the industry does
not stagnate due to our limited imagination!

Disclaimer: I do not speak for 3GPP or other SDOs which may have an
interest
in PMIP6.

GT> Me neither.

---

From: Sebastian Thalanany <[email-masked]>
Date: Sat, 06 Oct 2007 10:08:23 -0500

Hi, Jari,
                   In terms of providing a set of standard capabilities 
(protocols and procedures) for localized mobility management, my thought 
is that the support for inter-technology handoffs is likely to have a 
relatively more practical applicability, in the emerging diverse access 
technology landscape, as compared to the need for supporting 
simultaneous interfaces.

                   Thanks.

Regards,
     Sebastian

---

From: "Kalin Getov" <[email-masked]>
Date: Sat, 06 Oct 2007 17:42:40 +0200

Hi Jari, all,

> 1) Will there be NETLMM domains that have multiple access

[KG] I think, yes

> if you plug in regular, separate WLAN and 3G cards

[KG] According to 3GPP - yes (TS: 23.402), as to the unmodified host, I don't think it's feasible without any changes to MN software...

> make make-before-break work).

[KG] I find this irrelevant to PMIP, when emulating the home link of the MN it is obvious, that there would be problems when trying to do this on two different interfaces at the same time...therefore PMIP is for break-before-make cases only, IMHO

Thanks,
Kalin

-- 
******************************************
Best Regards
Kalin Getov

[email-masked]
******************************************

Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

---

From: Ashutosh Dutta <[email-masked]>
Date: Sat, 06 Oct 2007 14:50:13 -0400

Jari,
       I think it is a common practice to assume that carriers are going 
to provide inter-access handoff  (e.g., handoff between 802.11, 3G or 
vice versa)in future. Thus, we should make sure that PMIP should be able 
to support inter-access handoff just like any other mobility protocol 
supports handoff between 802.11 and 3G currently.

       I think it is important to define what exactly a multi-homing 
means. In PMIP scenario, multi-homing means both the interfaces are 
active and connected at the same time. An inter-access handoff may 
require multi-homing feature for a transient period if one has to 
support make-before-break to reduce the packet loss during inter-access 
handoff. But supporting multi-homing feature in PMIP would involve some 
modification on the host as pointed out by Sri. Similarly, a static host 
having connectivity to both the access technologies could also use 
multi-homing feature to support load balancing, but will need 
simultaneous binding feature at LMA.

     Thus, I think supporting inter access handoff is a MUST for PMIP, 
but multi-homing feature (e.g., keeping both the interfaces connected at 
the same time) could be considered out of scope for the base 
specification, but needs to be looked into as part of future charter, as 
it brings in some optimization benefit at the cost of some additional 
complexity in the mobile.

Answers to your questions are inline.

> 1) Will there be NETLMM domains that have multiple access

Yes

There maybe two cases however.

Case I. There may be one NTELMM domain (one LMA) supporting two MAGS 
where each MAG may support different access technoloiges, such as MAG1 
supports 802.11 and MAG2 (PDSN) supports 3G (CDMA).

Case II. Different NETLMM domain supports different access technologies, 
such as MAGS under LMA1 support different access technology (e.g., 
802.11) than the MAGS under LMA2 (e.g., CDMA).

I think the current debate is on Case I.

> if you plug in regular, separate WLAN and 3G cards

  As per PMIP's base requirement, one needs to have same IP address for 
data delivery. How to achieve that for two different cards (WLAN, 3G) 
with different MAC address may involve some changes on the host which 
may not be PMIP specific. One can always different Identifier other than 
MAC address during address configuartion.

> make make-before-break work).

In normal scenario having both the interfaces active does not mean that 
one would have to use both the interfaces for data delivery (except for 
simultaneous binding case). One can always bring up the second interface 
while receiving data on the first interface when the handoff is imminent 
to avoid the delay due to configuration of the second interface.

But in PMIP case, address configuration process is somehow tightly 
coupled with PMIP binding process. Thus, although keeping multiple 
interfaces active momentarily could be useful to support 
make-before-break, but appears to be more challenging than other 
mobility protocols such as CMIPv6, where address configuration of the 
interface is not tied with the mobility protocol itself.

Thanks
Ashutosh

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 8 Oct 2007 00:11:33 +0800

> make make-before-break work).
I guess other items have been analysized in detail.
Here only respond to this, we are interested in this scenario,
not just for the purpose of make-before-break,

thanks

-Hui

---

From: "Shyam H" <[email-masked]>
Date: Sun, 7 Oct 2007 20:21:19 -0700

Dear Jari and all,

> if you plug in regular, separate WLAN and 3G cards

Inter technology handovers is a very important feature of P-MIP, it
may not be a good idea to limit prefix to  access technology. this
will not allow us to aggregate low bandwidth access links for one
application using one pfx/address; using multi-bindings in future and
with changes in mobile stack.   Please consider not imposing
prefix/intf rules; i'm ok leaving this open; we may need both ways of
prefix allocation; but no restrictions please.

- Shyam

---

From: Julien Laganier <[email-masked]>
Date: Mon, 8 Oct 2007 10:19:34 +0200

Jari,

Just a clarification on your question:

> if you plug in regular, separate WLAN and 3G cards

Since this activity started we have discussed what is the significance 
of the "unmodified host"/"no host involvement" requirement.

AFAIK, the requirement is w.r.t. mobility management only -- OTOH it 
would be acceptable that the non-mobility related functionality is 
added/used on the host.

Was that also your understanding and assumption when asking this 
question?

Thanks.

--julien

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 8 Oct 2007 16:56:55 +0800

> not just for the purpose of make-before-break,
I would like to add what we are interested can be in the seperate doc,
Current spec is sufficient and should go forward.

-Hui