Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
From: sunseawq at huawei.com (Qin Wu)
Date: Wed, 17 Jun 2009 10:24:08 +0800

Hi, Marco:
Some clarification below.

> Any thought, comment and discussion is welcome.
> 
> marco
> 
> ----
> 
> [1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)
> 
> [2] MN's and CN's MAG support different IP versions to signal to the LMA(s)
> 
> [3] NAT between MN's and CN's MAG
> 
> [4] NAT between MN's and CN's LMA
> 
> [5] Different IP version for signaling between MN's and CN's MAG
> 
> [6] Different IP version for forwarding of localized traffic between 
> MN's and CN's MAG
> 
> [7] IP address conflict when MN and CN use the same IPv4 HoA
> Isn't that an issue with base PMIPv6 already?

[Qin]:
In PMIPv6 domain, the MAG and the LMA can distinguish each mobile node flow based on the GRE key encapsulated within the tunneled packet [ID-PMIP-GREKEY], even though two mobile nodes are assigned the same IPv4 HoA. However, when the traffic destined for the CNs with same HoA does not pass through the tunnel between the MAG and the LMA and go directly to the path between the MAGs associated with MN and CN, the MAG attached by the two CNs with the same IPv4 HoA can not identify the right CN based on the overlapped IPv4 HoA in the destination field of the incoming packet, therefore can not forward the user traffic to the right CN.

> [8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
> localized forwarding between MAGs
> Should work if both MAGs are dual stack and can negotiate the IP version 
> (?).

[Qin] I agree. In this case, IP version or Encapsulation mode negotiation is required.

> [9] Compatibility of route optimization states with IPv4
> In my opinion related to the issues above. If we set up IPv4 transport 
> or user plane support on relevant PMIPv6 nodes, route entries and binding 
> management need to
> have entries for IPv4 addresses.
> 
> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: sunseawq at huawei.com (Qin Wu)
Date: Mon, 15 Jun 2009 18:50:06 +0800
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Hi Qin,
> 
> please see inline for my thoughts.
> 
> Qin Wu schrieb:
>>> from previous mails and drafts, we can identify a couple of issues which we
>>> must take into account when designing a localized routing protocol for 
>>> PMIPv6.
>>> For the PS, I don't think we need to analyze problems which have been 
>>> addressed
>>> for standard RFC5213 operations already, such as a NAT between MAG and LMA.
>>>     
>>
>> [Qin]: Probably you are right. I think there are some misunderstandings.
>> Let me clarify why NAT between MAG and LMA is shown in the figure 1 of draft-wu-netext-pmipv6-ipv4-ro-ps.
>> I think NAT between MAG and LMA can be further divided into two case:
>> case 1: The MAG is behind the NAT
>> case 2: The LMA is behind the NAT
>> As regarding the Case 1, suppose there is one scenario where the MN attaches to MAG1 and CN attaches to MAG2, MAG1 and MAG2 register
>> to the different LMA, In this scenario, if there is NAT between MAG1 and LMA1 and the MAG1 is behind the NAT, I think also there is a NAT between 
>> MAG1 and MAG2, the MAG1 is behind the same NAT as the NAT located between MAG1 and LMA1.
>>   
> Yes, but that can be mapped to the case where there is a NAT between 
> MAGs, right? So it does not
> represent an extra case which introduces additional problems, or?

[Qin]: What I want to emphasize here is the scenario where the NAT is located between the MAG and the LMA is relevant to the case 1 and case 2 mentioned above if we consider local routing path setup between the MAGs or between LMAs.  In order to avoid confusion, I agree to  leave out this scenario where the NAT between the MAG and LMA from the IPv4 RO PS draft. Actually it does not reflected anywhere in the draft except in the figure.

>> As regarding Case 2,  as described in draft-ietf-netlmm-pmip6-ipv4-support-12, it is impossible for the LMA to locate behind a NAT unless the MAG and 
>> the LMA both locate behind NAT. Take the same scenario mentioned in the case 1 as example, if there is NAT between MAG1 and LMA1 and the LMA1
>> and MAG1 are both behind the NAT, I  think also there is a NAT between LMA1 and LMA2.
>>   
> If the IPv4 draft indicates that the LMA must not be behind a NAT, the 
> same holds for the
> RO protocol extension. Or is there anything extra to be analyzed for RO?

[Qin]: I agree. Does it mean RO PS draft needs one strong reason if it include the scenario where NAT is located between MN and CN's LMA?

>>   
>>> We could start with the following list to discuss and identify a 
>>> possible problem space
>>> for PMIPv6 localized routing and to find out which of these or new 
>>> issues are relevant
>>> for the PS and the NetExt protocol solution. I tried to collect 
>>> individual items from
>>> mail exchange with Sangjin, from draft-jeong-netlmm-pmipv6-roreq-01 and
>>> draft-wu-netext-pmipv6-ipv4-ro-ps-00.
>>>     
>>
>> [Qin]: As regarding IPv4 aspects, I am glad the draft-wu-netext-pmipv6-ipv4-ro-ps is credited. 
>>
>>   
>>> Any thought, comment and discussion is welcome.
>>>
>>> marco
>>>
>>> ----
>>>
>>> [1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)
>>>
>>> [2] MN's and CN's MAG support different IP versions to signal to the LMA(s)
>>>
>>> [3] NAT between MN's and CN's MAG
>>>
>>> [4] NAT between MN's and CN's LMA
>>>
>>> [5] Different IP version for signaling between MN's and CN's MAG
>>>
>>> [6] Different IP version for forwarding of localized traffic between 
>>> MN's and CN's MAG
>>>
>>> [7] IP address conflict when MN and CN use the same IPv4 HoA
>>> Isn't that an issue with base PMIPv6 already?
>>>
>>> [8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
>>> localized forwarding between MAGs
>>> Should work if both MAGs are dual stack and can negotiate the IP version 
>>> (?).
>>>
>>> [9] Compatibility of route optimization states with IPv4
>>>     
>>
>> [Qin]: Thank for your summarizing and re-catogorizing the scenarios described in the draft-wu-netext-pmipv6-ipv4-ro-ps.
>> I think most of these scenarios you enumerated are reflected in the draft-wu-netext-pmipv6-ipv4-ro-ps except the case where the NAT is located between
>> MN's and CN's LMA. If my understanding is  correct, this case should require both MAG and LMA behind the same NAT. Because as described in the draft->> ietf-netlmm-pmip6-ipv4-support-12:
>> "
>> 4.  IPv4 Transport Support
>> the local mobility anchor must not be behind a NAT and must be using a globally routable IPv4 address. 
>> "
>> I wonder whether we need to address this case in the PMIPv6 localized routing PS draft.
>>   
> Probably not. In particular since NetExt scope is limited to RO within a 
> single PMIPv6 domain, where in
> a multi-LMA scenario these LMAs should be behind the same NAT. But as 
> you said, LMAs behind a
> NAT are ruled out, if my understanding is correct. 

[Qin] Actually I did not exclude the LMA behind a NAT if we allow both LMA and MAG are located behind the same NAT or there is any other concrete scenario.
But I wonder in muti-LMA scenario , why all these LMA should be behind the same NAT?
Is it possible for one domain to have several private networks or VPNs and each private networks has one LMA?

>But maybe there are 
> other opinions
[Qin]:  I look forward to seeing that if possbible.

> marco
> 
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>     
> 
>

From: service at payapal.com (service at payapal.com)
Date: Fri, 12 Jun 2009 11:38:41 -0500
Subject: [Netext] Confirm Your Account Information!
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090612/a53d30b6/attachment-0001.html>

From: assad.adane80 at ymail.com (Assad Adane)
Date: 12 Jun 2009 08:29:53 -0700
Subject: [Netext] Urgent assistance.
Message-ID: <[email-masked]>

?????? "Urgent assistance.".

?????? AdaneAssad:

     ??:		6?12? ??? 2009

     ??:		13:00 - 14:00 (GMT +00:00)
     ??:		dear, I am. mr assad adane .I work in the audit/remittance department of bank of Africa (boa.) Ouagadougou Burkina Faso . I have a business which will be beneficial to both of us. the amount of money involved is ($20, million us dollars) which I want to transfer out of the country to your bank account, all to my financial benefit and yours too, also to take my wife to use for treatment of liver damage. this money is owned by a deceased persona business commercialist in west-African regions. he has been dead since six years ago and since then no claim has been placed on his bank account balance. not be transferred with out a next of kin attached to the fund. he fund could be transferred in this way; you shall present yourself as business associates to the deceased person, as details shall be that you are the care-taker business associates deceased person and his properties. I shall make available to you materials and information with which a successful claim shall be placed on the fund. I shall be your guidance and instructor throughout the duration of this transaction so as to ensure a swift and sure transfer of the fund to your bank account. as to your benefits, you shall be entitled to 40% of this fund for your co-operation in this transaction while 5% will be set aside for expenses both of us incurred during the course of this transaction. so if you are interested, send a reply to me immediately and in your reply please include your [private phone and your fax numbers] urgency has to be implied and this business must strictly be a deal between both of us. however if you are really sure of your integrity towards this proposal reply to me immediately.kindly get back to me as soon as possible through this alterative and confidential e- mail account hues ;assad_adane2009 at live.com)stating your stand in this deal. best regards, mr assad adane

?????????????:

     http://calendar.yahoo.com/assad.adane80 at ymail.com?v=126&a1=0&iid=7haFo-t%40n4Xi%40a0AKxB8B%40h%40cFdea4H8Dhi9IfjaWAWa%40dulSpdE6h%40%40&igid=nxaXk0l%40PMjoaecEchaMMtlcSTYb%40NoIkht3ppn%40TSLeary9-%40%40dPH%40%40iyf%40
    
??? 2009 ????
 www.yahoo.com.cn

?????:
 http://misc.yahoo.com.cn/copyright.html#2

????:
 http://misc.yahoo.com.cn/copyright.html#3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090612/8ce7d4cf/attachment.html>

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Fri, 12 Jun 2009 17:19:28 +0200
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Qin,

please see inline for my thoughts.

Qin Wu schrieb:
>> from previous mails and drafts, we can identify a couple of issues which we
>> must take into account when designing a localized routing protocol for 
>> PMIPv6.
>> For the PS, I don't think we need to analyze problems which have been 
>> addressed
>> for standard RFC5213 operations already, such as a NAT between MAG and LMA.
>>     
>
> [Qin]: Probably you are right. I think there are some misunderstandings.
> Let me clarify why NAT between MAG and LMA is shown in the figure 1 of draft-wu-netext-pmipv6-ipv4-ro-ps.
> I think NAT between MAG and LMA can be further divided into two case:
> case 1: The MAG is behind the NAT
> case 2: The LMA is behind the NAT
> As regarding the Case 1, suppose there is one scenario where the MN attaches to MAG1 and CN attaches to MAG2, MAG1 and MAG2 register
> to the different LMA, In this scenario, if there is NAT between MAG1 and LMA1 and the MAG1 is behind the NAT, I think also there is a NAT between 
> MAG1 and MAG2, the MAG1 is behind the same NAT as the NAT located between MAG1 and LMA1.
>   
Yes, but that can be mapped to the case where there is a NAT between 
MAGs, right? So it does not
represent an extra case which introduces additional problems, or?

> As regarding Case 2,  as described in draft-ietf-netlmm-pmip6-ipv4-support-12, it is impossible for the LMA to locate behind a NAT unless the MAG and 
> the LMA both locate behind NAT. Take the same scenario mentioned in the case 1 as example, if there is NAT between MAG1 and LMA1 and the LMA1
> and MAG1 are both behind the NAT, I  think also there is a NAT between LMA1 and LMA2.
>   
If the IPv4 draft indicates that the LMA must not be behind a NAT, the 
same holds for the
RO protocol extension. Or is there anything extra to be analyzed for RO?

>   
>> We could start with the following list to discuss and identify a 
>> possible problem space
>> for PMIPv6 localized routing and to find out which of these or new 
>> issues are relevant
>> for the PS and the NetExt protocol solution. I tried to collect 
>> individual items from
>> mail exchange with Sangjin, from draft-jeong-netlmm-pmipv6-roreq-01 and
>> draft-wu-netext-pmipv6-ipv4-ro-ps-00.
>>     
>
> [Qin]: As regarding IPv4 aspects, I am glad the draft-wu-netext-pmipv6-ipv4-ro-ps is credited. 
>
>   
>> Any thought, comment and discussion is welcome.
>>
>> marco
>>
>> ----
>>
>> [1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)
>>
>> [2] MN's and CN's MAG support different IP versions to signal to the LMA(s)
>>
>> [3] NAT between MN's and CN's MAG
>>
>> [4] NAT between MN's and CN's LMA
>>
>> [5] Different IP version for signaling between MN's and CN's MAG
>>
>> [6] Different IP version for forwarding of localized traffic between 
>> MN's and CN's MAG
>>
>> [7] IP address conflict when MN and CN use the same IPv4 HoA
>> Isn't that an issue with base PMIPv6 already?
>>
>> [8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
>> localized forwarding between MAGs
>> Should work if both MAGs are dual stack and can negotiate the IP version 
>> (?).
>>
>> [9] Compatibility of route optimization states with IPv4
>>     
>
> [Qin]: Thank for your summarizing and re-catogorizing the scenarios described in the draft-wu-netext-pmipv6-ipv4-ro-ps.
> I think most of these scenarios you enumerated are reflected in the draft-wu-netext-pmipv6-ipv4-ro-ps except the case where the NAT is located between
> MN's and CN's LMA. If my understanding is  correct, this case should require both MAG and LMA behind the same NAT. Because as described in the draft-ietf-netlmm-pmip6-ipv4-support-12:
> "
> 4.  IPv4 Transport Support
> the local mobility anchor must not be behind a NAT and must be using a globally routable IPv4 address. 
> "
> I wonder whether we need to address this case in the PMIPv6 localized routing PS draft.
>   
Probably not. In particular since NetExt scope is limited to RO within a 
single PMIPv6 domain, where in
a multi-LMA scenario these LMAs should be behind the same NAT. But as 
you said, LMAs behind a
NAT are ruled out, if my understanding is correct. But maybe there are 
other opinions

marco

>   
>> In my opinion related to the issues above. If we set up IPv4 transport 
>> or user
>> plane support on relevant PMIPv6 nodes, route entries and binding 
>> management need to
>> have entries for IPv4 addresses.
>>     
>
> [Qin] I fully agree with you. This point is also reflected in draft-wu-netext-pmipv6-ipv4-ro-ps,i.e, in the section 3 "Scenarios and Problem statement",
> it point out routing optimization states for IPv4 support need to be maintained and updated.
>
>   
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>     

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Fri, 12 Jun 2009 10:34:37 +0200
Subject: [Netext] PMIPv6 local routing - update of the PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <1244795677.23075.84.camel@localhost>

Hi Marco, Qin,

Please see inline some minor comments...

El vie, 12-06-2009 a las 09:45 +0200, Marco Liebsch escribi?:
> Hi Qin,
> 
> please see inline.
> 
> Qin Wu schrieb:
> >> Folks,
> >>
> >> according to the feedback the current version of the localized routing 
> >> problem
> >> statement seems to cover almost all aspects which are relevant for the
> >> NetExt work on localized routing.
> >> Two remaining aspects have been addressed, which should be considered in
> >> an update of the draft to be in line with the WG's view. These are as 
> >> follows:
> >>
> >> *Localized Routing between a PMIP attached MN and a regular IPv6 node*:
> >> This was a comment from Carlos and addresses the type of nodes
> >> RFC5213 mentions in a few paragraphs about local routing. We could clarify
> >> this offline and better text about what RFC5213 describes and how this
> >> impacts NetExt work on localized routing will go into an update of the PS.
> >>     
> >
> > [Qin]: It is  a interesting issue. What scenario do we need to think about?
> > Suppose the CN is a regular IPv6 node without PMIP protocol support,
> > It seems difficult to utitlize any PMIP6 protocol to estalish direct Path between the CN
> > and the MAG which the MN attaches to. Based on this, only one scenario occur to me is 
> > one mobile node and one regualr IPv6 node attahes to the same MAG. Is there any other scenario I miss?
> > if someone can do some clarification, it would be helpful.
> >   
> The isse raised by Carlos was actually referring to the text in RFC5213, 
> as this can be understood
> as localized routing on a single MAG between a PMIPv6-attached MN and a 
> regular IPv6
> node rather than between two PMIPv6-attached nodes. We'll need to update 
> the text in the PS accordingly
> to cover the 'state of the art'. But according to chairs, the scope of 
> NetExt covers solely localized routing
> between two PMIPv6-attached nodes. And I think this makes sense, as 
> handling localized routing with
> a regular IPv6 node can be easily handled as long as both nodes are 
> attached to the same AR/MAG, but

Agree. I don't know where it should be done (netext, netlmm), but it
might be good to standardise a solution for that (it'd be very simple).

> as soon as one node hands over to a different AR, there is much more to 
> be done to maintain localized routing
> between these nodes. So, I think the limitation in NetExt is acceptable.

Agree.

Thanks,

Carlos

> 
> marco
> 
> 
> >   
> >> *Consideration of IPv4*:
> >> This is a good point made by Sangjin and the PS should cover an analysis
> >> of relevant issues with IPv4 for PMIPv6 localized routing. There is 
> >> valuable
> >> early work available, such as draft-jeong-netlmm-pmipv6-roreq-01 and
> >> draft-wu-netext-pmipv6-ipv4-ro-ps-00. 
> >>     
> >
> > [Qin];Thank you for your initiating this discussion, it is helpful for us to move the PMIPv6 local routing work forward .
> >
> > I think it makes sense to send a
> >   
> >> separate mail to collect different aspects of IPv4 problems in PMIPv6
> >> localized routing and to discuss individual issues we need to cover in
> >> the PS.
> >>
> >> marco
> >>
> >>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >>     
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
-- 
   Carlos Jes?s Bernardos Cano     http://www.netcoms.net
   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                IEEE Network Special Issue on
        Advances in Vehicular Communications Networks
 http://www.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0110.htm 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090612/62f9c2f2/attachment.bin>

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Fri, 12 Jun 2009 09:45:46 +0200
Subject: [Netext] PMIPv6 local routing - update of the PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Qin,

please see inline.

Qin Wu schrieb:
>> Folks,
>>
>> according to the feedback the current version of the localized routing 
>> problem
>> statement seems to cover almost all aspects which are relevant for the
>> NetExt work on localized routing.
>> Two remaining aspects have been addressed, which should be considered in
>> an update of the draft to be in line with the WG's view. These are as 
>> follows:
>>
>> *Localized Routing between a PMIP attached MN and a regular IPv6 node*:
>> This was a comment from Carlos and addresses the type of nodes
>> RFC5213 mentions in a few paragraphs about local routing. We could clarify
>> this offline and better text about what RFC5213 describes and how this
>> impacts NetExt work on localized routing will go into an update of the PS.
>>     
>
> [Qin]: It is  a interesting issue. What scenario do we need to think about?
> Suppose the CN is a regular IPv6 node without PMIP protocol support,
> It seems difficult to utitlize any PMIP6 protocol to estalish direct Path between the CN
> and the MAG which the MN attaches to. Based on this, only one scenario occur to me is 
> one mobile node and one regualr IPv6 node attahes to the same MAG. Is there any other scenario I miss?
> if someone can do some clarification, it would be helpful.
>   
The isse raised by Carlos was actually referring to the text in RFC5213, 
as this can be understood
as localized routing on a single MAG between a PMIPv6-attached MN and a 
regular IPv6
node rather than between two PMIPv6-attached nodes. We'll need to update 
the text in the PS accordingly
to cover the 'state of the art'. But according to chairs, the scope of 
NetExt covers solely localized routing
between two PMIPv6-attached nodes. And I think this makes sense, as 
handling localized routing with
a regular IPv6 node can be easily handled as long as both nodes are 
attached to the same AR/MAG, but
as soon as one node hands over to a different AR, there is much more to 
be done to maintain localized routing
between these nodes. So, I think the limitation in NetExt is acceptable.

marco

>   
>> *Consideration of IPv4*:
>> This is a good point made by Sangjin and the PS should cover an analysis
>> of relevant issues with IPv4 for PMIPv6 localized routing. There is 
>> valuable
>> early work available, such as draft-jeong-netlmm-pmipv6-roreq-01 and
>> draft-wu-netext-pmipv6-ipv4-ro-ps-00. 
>>     
>
> [Qin];Thank you for your initiating this discussion, it is helpful for us to move the PMIPv6 local routing work forward .
>
> I think it makes sense to send a
>   
>> separate mail to collect different aspects of IPv4 problems in PMIPv6
>> localized routing and to discuss individual issues we need to cover in
>> the PS.
>>
>> marco
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>     

From: renatogalvez at globelines.com.ph (Natz Crawford)
Date: Fri, 12 Jun 2009 08:57:49 +0800
Subject: [Netext] [SPAM]Do you want to earn extra cash? $900 or even more!!!
Message-ID: <[email-masked]>

Hello Friend, 

Would you like to earn an extra $200, $900 or even 
$5,000 everyday! for just 45 minutes work! If you 
answered "YES" then this is the right decision & right 
opportunity for you to work.
 
 >> Here is the Links: 

http://affiliates.undergroundcashsecret.com//idevaffiliate.php?id=1171

https://www.coldcashpartners.com/1888-3.html

https://www.coldcashpartners.com/1888-5.html

Best Regards,

Natz Crawford

From: sunseawq at huawei.com (Qin Wu)
Date: Thu, 11 Jun 2009 11:13:33 +0800
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
References: <[email-masked]>
Message-ID: <[email-masked]>

> from previous mails and drafts, we can identify a couple of issues which we
> must take into account when designing a localized routing protocol for 
> PMIPv6.
> For the PS, I don't think we need to analyze problems which have been 
> addressed
> for standard RFC5213 operations already, such as a NAT between MAG and LMA.

[Qin]: Probably you are right. I think there are some misunderstandings.
Let me clarify why NAT between MAG and LMA is shown in the figure 1 of draft-wu-netext-pmipv6-ipv4-ro-ps.
I think NAT between MAG and LMA can be further divided into two case:
case 1: The MAG is behind the NAT
case 2: The LMA is behind the NAT
As regarding the Case 1, suppose there is one scenario where the MN attaches to MAG1 and CN attaches to MAG2, MAG1 and MAG2 register
to the different LMA, In this scenario, if there is NAT between MAG1 and LMA1 and the MAG1 is behind the NAT, I think also there is a NAT between 
MAG1 and MAG2, the MAG1 is behind the same NAT as the NAT located between MAG1 and LMA1.
As regarding Case 2,  as described in draft-ietf-netlmm-pmip6-ipv4-support-12, it is impossible for the LMA to locate behind a NAT unless the MAG and 
the LMA both locate behind NAT. Take the same scenario mentioned in the case 1 as example, if there is NAT between MAG1 and LMA1 and the LMA1
and MAG1 are both behind the NAT, I  think also there is a NAT between LMA1 and LMA2.

> We could start with the following list to discuss and identify a 
> possible problem space
> for PMIPv6 localized routing and to find out which of these or new 
> issues are relevant
> for the PS and the NetExt protocol solution. I tried to collect 
> individual items from
> mail exchange with Sangjin, from draft-jeong-netlmm-pmipv6-roreq-01 and
> draft-wu-netext-pmipv6-ipv4-ro-ps-00.

[Qin]: As regarding IPv4 aspects, I am glad the draft-wu-netext-pmipv6-ipv4-ro-ps is credited. 

> Any thought, comment and discussion is welcome.
> 
> marco
> 
> ----
> 
> [1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)
> 
> [2] MN's and CN's MAG support different IP versions to signal to the LMA(s)
> 
> [3] NAT between MN's and CN's MAG
> 
> [4] NAT between MN's and CN's LMA
> 
> [5] Different IP version for signaling between MN's and CN's MAG
> 
> [6] Different IP version for forwarding of localized traffic between 
> MN's and CN's MAG
> 
> [7] IP address conflict when MN and CN use the same IPv4 HoA
> Isn't that an issue with base PMIPv6 already?
> 
> [8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
> localized forwarding between MAGs
> Should work if both MAGs are dual stack and can negotiate the IP version 
> (?).
> 
> [9] Compatibility of route optimization states with IPv4

[Qin]: Thank for your summarizing and re-catogorizing the scenarios described in the draft-wu-netext-pmipv6-ipv4-ro-ps.
I think most of these scenarios you enumerated are reflected in the draft-wu-netext-pmipv6-ipv4-ro-ps except the case where the NAT is located between
MN's and CN's LMA. If my understanding is  correct, this case should require both MAG and LMA behind the same NAT. Because as described in the draft-ietf-netlmm-pmip6-ipv4-support-12:
"
4.  IPv4 Transport Support
the local mobility anchor must not be behind a NAT and must be using a globally routable IPv4 address. 
"
I wonder whether we need to address this case in the PMIPv6 localized routing PS draft.

> In my opinion related to the issues above. If we set up IPv4 transport 
> or user
> plane support on relevant PMIPv6 nodes, route entries and binding 
> management need to
> have entries for IPv4 addresses.

[Qin] I fully agree with you. This point is also reflected in draft-wu-netext-pmipv6-ipv4-ro-ps,i.e, in the section 3 "Scenarios and Problem statement",
it point out routing optimization states for IPv4 support need to be maintained and updated.

> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: sunseawq at huawei.com (Qin Wu)
Date: Thu, 11 Jun 2009 11:09:28 +0800
Subject: [Netext] PMIPv6 local routing - update of the PS
References: <[email-masked]>
Message-ID: <[email-masked]>

> Folks,
> 
> according to the feedback the current version of the localized routing 
> problem
> statement seems to cover almost all aspects which are relevant for the
> NetExt work on localized routing.
> Two remaining aspects have been addressed, which should be considered in
> an update of the draft to be in line with the WG's view. These are as 
> follows:
> 
> *Localized Routing between a PMIP attached MN and a regular IPv6 node*:
> This was a comment from Carlos and addresses the type of nodes
> RFC5213 mentions in a few paragraphs about local routing. We could clarify
> this offline and better text about what RFC5213 describes and how this
> impacts NetExt work on localized routing will go into an update of the PS.

[Qin]: It is  a interesting issue. What scenario do we need to think about?
Suppose the CN is a regular IPv6 node without PMIP protocol support,
It seems difficult to utitlize any PMIP6 protocol to estalish direct Path between the CN
and the MAG which the MN attaches to. Based on this, only one scenario occur to me is 
one mobile node and one regualr IPv6 node attahes to the same MAG. Is there any other scenario I miss?
if someone can do some clarification, it would be helpful.

> *Consideration of IPv4*:
> This is a good point made by Sangjin and the PS should cover an analysis
> of relevant issues with IPv4 for PMIPv6 localized routing. There is 
> valuable
> early work available, such as draft-jeong-netlmm-pmipv6-roreq-01 and
> draft-wu-netext-pmipv6-ipv4-ro-ps-00. 

[Qin];Thank you for your initiating this discussion, it is helpful for us to move the PMIPv6 local routing work forward .

I think it makes sense to send a
> separate mail to collect different aspects of IPv4 problems in PMIPv6
> localized routing and to discuss individual issues we need to cover in
> the PS.
> 
> marco
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: renatogalvez at globelines.com.ph (Natz Crawford)
Date: Thu, 11 Jun 2009 03:40:59 +0800
Subject: [Netext] [.] Do you want to earn extra cash? $900 or even more!!!
Message-ID: <[email-masked]>

Hello Friend, 

Would you like to earn an extra $200, $900 or even 
$5,000 everyday! for just 45 minutes work! If you 
answered "YES" then this is the right decision & right 
opportunity for you to work.
 
 >> Here is the Links: 

http://affiliates.undergroundcashsecret.com//idevaffiliate.php?id=1171

https://www.coldcashpartners.com/1888-3.html

https://www.coldcashpartners.com/1888-5.html

Best Regards,

Natz Crawford

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 10 Jun 2009 18:38:44 +0200
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
Message-ID: <[email-masked]>

Folks,

from previous mails and drafts, we can identify a couple of issues which we
must take into account when designing a localized routing protocol for 
PMIPv6.
For the PS, I don't think we need to analyze problems which have been 
addressed
for standard RFC5213 operations already, such as a NAT between MAG and LMA.

We could start with the following list to discuss and identify a 
possible problem space
for PMIPv6 localized routing and to find out which of these or new 
issues are relevant
for the PS and the NetExt protocol solution. I tried to collect 
individual items from
mail exchange with Sangjin, from draft-jeong-netlmm-pmipv6-roreq-01 and
draft-wu-netext-pmipv6-ipv4-ro-ps-00.

Any thought, comment and discussion is welcome.

marco

----

[1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)

[2] MN's and CN's MAG support different IP versions to signal to the LMA(s)

[3] NAT between MN's and CN's MAG

[4] NAT between MN's and CN's LMA

[5] Different IP version for signaling between MN's and CN's MAG

[6] Different IP version for forwarding of localized traffic between 
MN's and CN's MAG

[7] IP address conflict when MN and CN use the same IPv4 HoA
Isn't that an issue with base PMIPv6 already?

[8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
localized forwarding between MAGs
Should work if both MAGs are dual stack and can negotiate the IP version 
(?).

[9] Compatibility of route optimization states with IPv4
In my opinion related to the issues above. If we set up IPv4 transport 
or user
plane support on relevant PMIPv6 nodes, route entries and binding 
management need to
have entries for IPv4 addresses.

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 10 Jun 2009 18:33:18 +0200
Subject: [Netext] PMIPv6 local routing - update of the PS
Message-ID: <[email-masked]>

Folks,

according to the feedback the current version of the localized routing 
problem
statement seems to cover almost all aspects which are relevant for the
NetExt work on localized routing.
Two remaining aspects have been addressed, which should be considered in
an update of the draft to be in line with the WG's view. These are as 
follows:

*Localized Routing between a PMIP attached MN and a regular IPv6 node*:
This was a comment from Carlos and addresses the type of nodes
RFC5213 mentions in a few paragraphs about local routing. We could clarify
this offline and better text about what RFC5213 describes and how this
impacts NetExt work on localized routing will go into an update of the PS.

*Consideration of IPv4*:
This is a good point made by Sangjin and the PS should cover an analysis
of relevant issues with IPv4 for PMIPv6 localized routing. There is 
valuable
early work available, such as draft-jeong-netlmm-pmipv6-roreq-01 and
draft-wu-netext-pmipv6-ipv4-ro-ps-00. I think it makes sense to send a
separate mail to collect different aspects of IPv4 problems in PMIPv6
localized routing and to discuss individual issues we need to cover in
the PS.

marco

From: fxmatix at gmail.com (www.seo.goin.to)
Date: Wed, 10 Jun 2009 02:05:29 +0200
Subject: [Netext] SEO Tools That Drive Traffic to Your Website Like Crazy
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090610/78fee021/attachment.html>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 8 Jun 2009 21:07:25 -0700
Subject: [Netext] I-DAction:draft-gundavelli-netext-mn-groupid-option-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Qin,
 
Please see inline.

  _____  

From: netext-bounces at mail.mobileip.jp
[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Qin Wu
Sent: Friday, June 05, 2009 2:38 AM
To: netext at mail.mobileip.jp
Subject: Re:
[Netext]I-DAction:draft-gundavelli-netext-mn-groupid-option-01.txt

Hi, Sri: 
It is a quite good idea to use group mobile node ID to solve batch
registration and de-registration operations for
all the mobile node that belong to the specific realm. 
I wonder whether we can define or give the example format of mobile node
group identifier.
e.g.,username at companyA.com.
      username at LMA domain name
      username at LMA IP address
      username at VPN name or Identity
Also I have some comments on this draft below:
 
[Sri] Yes. I think Domagoj's latest update of his Bulk Registration draft is
pointing to this usage. I dont 
think he published the draft yet.

 
 
in the section3 " Signaling and other Considerations"
"
   The Mobile Node's Group Identifier option reflects the group
   affiliation that is local to the local mobility anchor or mobile
   access gateway, as determined by those respective entities.
"
I wonder who allocate the mobile node group identifier? The MAG, the LMA or
the AAA server. In my understanding, the LMA is a 
appropriate node to allocate the mobile node group identifier. Because LMA
can easily avoid allocating identifier conflict. 
If the mobile node's group identifier is local to the MAG, Does it means the
mobile node's group identifier is allocated by the MAG. In that case,
this mobile node's group identifier local to the MAG may be not unique or
cause allocation identifier conflict. What do you think of it? 
 
[Sri] LMA allocates the group affiliation of a mobile node for a given
session. That affiliation stays the life of that session. Now, how the LMA
generates such identifier should be open. It can be a local policy, or based
on other considerations. In one scheme, it can be an identifier of the blade
serving that request. As suggested by some one, that the identifier can be
even MAG specific, we need to think about the flexibility that we should
allow. In the most obvious usage is about the LMA allocating it for a
session. Need to fix the text, its missing these details.

 
Regards
Sri

Regards!
-Qin

On Wed, Jun 3, 2009 at 10:15 AM, <Internet-Drafts at ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : Mobile Node Group Identifier option
       Author(s)       : S. Gundavelli, et al.
       Filename        : draft-gundavelli-netext-mn-groupid-option-01.txt
       Pages           : 7
       Date            : 2009-06-02

This document specifies a new mobility option for use in Proxy
Binding Update and Proxy Binding Acknowledgement messages.  This
option can be used by the mobility entities in a Proxy Mobile IPv6
domain for carrying the group affiliation of a mobile node in any of
the mobility signaling messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gundavelli-netext-mn-groupid-optio
n-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> 
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
Internet Management Technology Lab, Sungkyunkwan University. 
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com 
#webpage: http://hurryon.googlepages.com/

  _____  

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090608/d7a816e2/attachment.html>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 8 Jun 2009 20:58:51 -0700
Subject: [Netext] New Version Notification for draft-gundavelli-netext-pmipv6-retransmit-option-00 (fwd)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Frank,

Thanks for the review. Please see inline.

> -----Original Message-----
> From: Frank Xia [mailto:xiayangsong at huawei.com] 
> Sent: Thursday, June 04, 2009 9:30 AM
> To: Sri Gundavelli; netext at mail.mobileip.jp
> Subject: Re: [Netext] New Version Notification for 
> draft-gundavelli-netext-pmipv6-retransmit-option-00 (fwd)
> 
> Hi Sri
> 
> After a quick glance, here a question for you.
> 
> Why does the receiver selectively ignor the
> retransmitted packets?
>

We are missing a semantic for tagging retransmitted packets.
The presence of such identifier will allow the receiver to
distinguish between the original request to a retransmitted
request. As noted in an interop test, its hard to align the MAG
retransmission rate to the LMA processing time. If the LMA
while waiting for a resource processing a prev request, can
identify a subsequently retransmitted packets, it can associate
the retransmitted request and respond accordingly and not
having to reprocess the new request. The idea is for the sender
and receiver to provide clear markings on retransmitted packets.

Regards
Sri

 
> BR
> Frank
> 
> ----- Original Message ----- 
> From: "Sri Gundavelli" <sgundave at cisco.com>
> To: <netext at mail.mobileip.jp>
> Sent: Tuesday, June 02, 2009 7:34 PM
> Subject: [Netext] New Version Notification for 
> draft-gundavelli-netext-pmipv6-retransmit-option-00 (fwd)
> 
> 
> >
> > 
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-pm
> ipv6-retransmit-option-00.txt
> >
> >
> > ---------- Forwarded message ----------
> > Date: Tue, 2 Jun 2009 17:33:36 -0700 (PDT)
> > From: Sri Gundavelli <sgundave at cisco.com>
> > To: netext at mail.mobileip.jp
> > Subject: New Version Notification for
> >     draft-gundavelli-netext-pmipv6-retransmit-option-00
> >
> >
> >
> > A small draft for identifying retransmitted PBU's.
> >
> > Currently, there are no clear semantics in Proxy Mobile IPv6 for
> > tagging/identifying retransmitted signaling packets. We defined a
> > simple option, retransmit option with the mesgid, retransmit id,
> > that can be used for this purpose. We realized the need for this
> > while implementation and Rajeev also had the same requirement.
> >
> > Please comment.
> >
> >
> > Regards
> > Sri
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > Date: Tue,  2 Jun 2009 17:26:24 -0700 (PDT)
> > From: IETF I-D Submission Tool <idsubmission at ietf.org>
> > To: sgundave at cisco.com
> > Cc: kleung at cisco.com, rkoodli at starentnetworks.com
> > Subject: New Version Notification for
> >       draft-gundavelli-netext-pmipv6-retransmit-option-00
> >
> >
> > A new version of I-D, 
> > draft-gundavelli-netext-pmipv6-retransmit-option-00.txt has been 
> > successfuly submitted by Sri Gundavelli and posted to the 
> IETF repository.
> >
> > Filename: draft-gundavelli-netext-pmipv6-retransmit-option
> > Revision: 00
> > Title: Retransmitted Message Identification Option for 
> Proxy Mobile IPv6
> > Creation_date: 2009-06-02
> > WG ID: Independent Submission
> > Number_of_pages: 8
> >
> > Abstract:
> > The Proxy Mobile IPv6 base protocol does not provide any mechanism
> > for the receiver of a mobility signaling message to determine if the
> > received message is the original message or a retransmitted message
> > of an earlier sent message.  The absence of such a semantic in some
> > cases results in inefficient processing of the signaling 
> messages and
> > will lead to additional processing load and network traffic.
> >
> > This document defines a new mobility option, Retransmitted Message
> > Identification option for use in Proxy Binding Update and Proxy
> > Binding Acknowledgement messages.  This option enables the mobility
> > entities to use proper message identifiers and retransmit 
> markings on
> > the signaling messages.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext 
> 

From: sgundave at cisco.com (Sri Gundavelli)
Date: Mon, 8 Jun 2009 20:57:11 -0700
Subject: [Netext] I-D Action:draft-gundavelli-netext-mn-groupid-option-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Jong-Hyouk,
 
Thanks for the review. Please see inline.

  _____  

From: Jong-Hyouk Lee [mailto:jonghyouk at gmail.com] 
Sent: Wednesday, June 03, 2009 12:35 AM
To: netext at mail.mobileip.jp
Cc: sgundave at cisco.com
Subject: Re: I-D Action:draft-gundavelli-netext-mn-groupid-option-01.txt

Hi, Sri.
 
As indicated at Sec. 1 of I.-D. (Mobile Node Group Identifier Option), this
option optimizes the performance of PMIPv6 by reducing the number of PBU/PBA
exchanging.
 
Comments on Mobile Node Group Identifier Option
(draft-gundavelli-netext-mn-groupid-option-01).

In Sec. 3, this option is used to indicate the group information for several
mobile nodes attached to an MAG. Accordingly, the sentence (... that is
local to the local mobility anchor or mobile access gateway, as ...) should
be modified as "... that is local to the mobile access gateway, as ...".
 
[Sri] I guess, some rewording is required. The group affiliation of a mobile
node can be on any basis, the usage should be open.

 
In Sec. 1, this option can be used to indicate a set of (mobile) nodes
attached to the mobile router if we consider that the mobile router attaches
to a specific MAG. The use-case for NEMO in PMIPv6 domain (i.e.,
draft-jhlee-netlmm-nemo-scenarios-01) should be added. 
 
[Sri] We can leave the option usage bit more open and allow such usecases.
 
Thanks for the review.
 
Regards
Sri

 
 
Cheers.

On Wed, Jun 3, 2009 at 10:15 AM, <Internet-Drafts at ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : Mobile Node Group Identifier option
       Author(s)       : S. Gundavelli, et al.
       Filename        : draft-gundavelli-netext-mn-groupid-option-01.txt
       Pages           : 7
       Date            : 2009-06-02

This document specifies a new mobility option for use in Proxy
Binding Update and Proxy Binding Acknowledgement messages.  This
option can be used by the mobility entities in a Proxy Mobile IPv6
domain for carrying the group affiliation of a mobile node in any of
the mobility signaling messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gundavelli-netext-mn-groupid-optio
n-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> 
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
Internet Management Technology Lab, Sungkyunkwan University. 
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com 
#webpage: http://hurryon.googlepages.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090608/e35ff20e/attachment.html>

From: sunseawq at huawei.com (Qin Wu)
Date: Tue, 09 Jun 2009 11:26:42 +0800
Subject: [Netext] I-DAction:draft-gundavelli-netext-mn-groupid-option-01.txt
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I wonder whether it is appropriate for AAA server to assign group MN ID. As you know, sometimes, the mobile node may join one group belong to the MAG1, after a while, this mobile node may leave this group belong to the MAG1 and join another group belong to the MAG2. I a little doubt the AAA server can handle this. :)

Regards
-Qin
  ----- Original Message ----- 
  From: Jong-Hyouk Lee 
  To: Qin Wu ; Sri Gundavelli 
  Cc: netext at mail.mobileip.jp 
  Sent: Friday, June 05, 2009 9:05 PM
  Subject: Re: [Netext] I-DAction:draft-gundavelli-netext-mn-groupid-option-01.txt

  Hi, all.

  The network entity who can allocate and manage group ids for mobile nodes would be a AAA server. Because of none present of it in the current document, it needs to be defined. When to allocate information of group ids to MNs? How to delivery these information to MNs? (IMO, these allocation would be delivered to MNs after MNs are authenticated by the AAA servers)

  Cheers.

  On Fri, Jun 5, 2009 at 6:38 PM, Qin Wu <sunseawq at huawei.com> wrote:

    Hi, Sri: 
    It is a quite good idea to use group mobile node ID to solve batch registration and de-registration operations for
    all the mobile node that belong to the specific realm. 
    I wonder whether we can define or give the example format of mobile node group identifier.
    e.g.,username at companyA.com.
          username at LMA domain name
          username at LMA IP address
          username at VPN name or Identity
    Also I have some comments on this draft below:

    in the section3 " Signaling and other Considerations"
    "
       The Mobile Node's Group Identifier option reflects the group
       affiliation that is local to the local mobility anchor or mobile
       access gateway, as determined by those respective entities.
    "
    I wonder who allocate the mobile node group identifier? The MAG, the LMA or the AAA server. In my understanding, the LMA is a 
    appropriate node to allocate the mobile node group identifier. Because LMA can easily avoid allocating identifier conflict. 
    If the mobile node's group identifier is local to the MAG, Does it means the mobile node's group identifier is allocated by the MAG. In that case,
    this mobile node's group identifier local to the MAG may be not unique or cause allocation identifier conflict. What do you think of it? 

    Regards!
    -Qin
      On Wed, Jun 3, 2009 at 10:15 AM, <Internet-Drafts at ietf.org> wrote:

        A New Internet-Draft is available from the on-line Internet-Drafts directories.

               Title           : Mobile Node Group Identifier option
               Author(s)       : S. Gundavelli, et al.
               Filename        : draft-gundavelli-netext-mn-groupid-option-01.txt
               Pages           : 7
               Date            : 2009-06-02

        This document specifies a new mobility option for use in Proxy
        Binding Update and Proxy Binding Acknowledgement messages.  This
        option can be used by the mobility entities in a Proxy Mobile IPv6
        domain for carrying the group affiliation of a mobile node in any of
        the mobility signaling messages.

        A URL for this Internet-Draft is:
        http://www.ietf.org/internet-drafts/draft-gundavelli-netext-mn-groupid-option-01.txt

        Internet-Drafts are also available by anonymous FTP at:
        ftp://ftp.ietf.org/internet-drafts/

        Below is the data which will enable a MIME compliant mail reader
        implementation to automatically retrieve the ASCII version of the
        Internet-Draft.

        _______________________________________________
        I-D-Announce mailing list
        I-D-Announce at ietf.org
        https://www.ietf.org/mailman/listinfo/i-d-announce
        Internet-Draft directories: http://www.ietf.org/shadow.html
        or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

      -- 
      Internet Management Technology Lab, Sungkyunkwan University. 
      Jong-Hyouk Lee.

      #email: jonghyouk (at) gmail (dot) com 
      #webpage: http://hurryon.googlepages.com/

--------------------------------------------------------------------------

      _______________________________________________
      NetExt mailing list
      NetExt at mail.mobileip.jp
      http://www.mobileip.jp/mailman/listinfo/netext

    _______________________________________________
    NetExt mailing list
    NetExt at mail.mobileip.jp
    http://www.mobileip.jp/mailman/listinfo/netext

  -- 
  Internet Management Technology Lab, Sungkyunkwan University. 
  Jong-Hyouk Lee.

  #email: jonghyouk (at) gmail (dot) com 
  #webpage: http://hurryon.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090609/e062ca30/attachment.html>

From: support at paypal.com (PayPal Customer Support)
Date: Mon,  8 Jun 2009 13:01:16 +0200 (CEST)
Subject: [Netext] Update Your PayPal Account
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090608/1d43a6c8/attachment.html>

From: drahmedi.idowu74 at gmail.com (Dr.Ahmed Idowu)
Date: Sun, 7 Jun 2009 02:07:51 -0700
Subject: [Netext] Investment Partner.
Message-ID: <0400c09d-39971-287d0887049653@user-2d912a83ae>

Dear Friend,

I am making this contact to you in good faith. I got your email in  my search for a trust worthy and honest person that could assist me in a confidential transaction. I am Honorable Dr. Ahmed Idowu .I am one of the members who conducted the 2007 election with some of my party members, after the election I discovered that the sum of $60 Million Dollars Was remaining and we decided to move it outside the country for safe keeping in a Finance House.

I hereby write to seek for  your opinion for an investment in your country . I will appreciate if you can be able to handle this project perfectly with us, by making sure that the money will be received and safe keep in your custody for investment . Kindly respond back soonest with your  private telephone/ fax numbers for more details.

Plesea kindly get back to me through my private email: idowu.ahmed204 at gmail.com

Thanks and God bless.

Yours sincerely,

Hon. Dr.Ahmed Idowu

From: webmaster at hallmark.org (webmaster at hallmark.org)
Date: Sun,  7 Jun 2009 09:45:21 +0200 (CEST)
Subject: [Netext] You have received a card from a family member!
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090607/0984e604/attachment.html>

From: webmaster at hallmark.org (webmaster at hallmark.org)
Date: Sat,  6 Jun 2009 22:11:32 +0200 (CEST)
Subject: [Netext] You have received a card from a family member!
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090606/6e5de0d9/attachment.html>

From: webmaster at hallmark.org (webmaster at hallmark.org)
Date: Sat,  6 Jun 2009 18:38:41 +0200 (CEST)
Subject: [Netext] You have received a card from a family member!
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090606/eea37abf/attachment.html>

From: jonghyouk at gmail.com (Jong-Hyouk Lee)
Date: Fri, 5 Jun 2009 22:05:32 +0900
Subject: [Netext] I-DAction:draft-gundavelli-netext-mn-groupid-option-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, all.

The network entity who can allocate and manage group ids for mobile nodes
would be a AAA server. Because of none present of it in the current
document, it needs to be defined. When to allocate information of group ids
to MNs? How to delivery these information to MNs? (IMO, these allocation
would be delivered to MNs after MNs are authenticated by the AAA servers)

Cheers.
On Fri, Jun 5, 2009 at 6:38 PM, Qin Wu <sunseawq at huawei.com> wrote:

>  Hi, Sri:
> It is a quite good idea to use group mobile node ID to solve batch
> registration and de-registration operations for
> all the mobile node that belong to the specific realm.
> I wonder whether we can define or give the example format of mobile node
> group identifier.
> e.g.,username at companyA.com.
>       username at LMA domain name
>       username at LMA IP address
>       username at VPN name or Identity
> Also I have some comments on this draft below:
>
> in the section3 " Signaling and other Considerations"
> "
>    The Mobile Node's Group Identifier option reflects the group
>    affiliation that is local to the local mobility anchor or mobile
>    access gateway, as determined by those respective entities.
> "
> I wonder who allocate the mobile node group identifier? The MAG, the LMA or
> the AAA server. In my understanding, the LMA is a
> appropriate node to allocate the mobile node group identifier. Because LMA
> can easily avoid allocating identifier conflict.
> If the mobile node's group identifier is local to the MAG, Does it means
> the mobile node's group identifier is allocated by the MAG. In that case,
> this mobile node's group identifier local to the MAG may be not unique or
> cause allocation identifier conflict. What do you think of it?
>
> Regards!
> -Qin
>
>   On Wed, Jun 3, 2009 at 10:15 AM, <Internet-Drafts at ietf.org> wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>        Title           : Mobile Node Group Identifier option
>>        Author(s)       : S. Gundavelli, et al.
>>        Filename        : draft-gundavelli-netext-mn-groupid-option-01.txt
>>        Pages           : 7
>>        Date            : 2009-06-02
>>
>> This document specifies a new mobility option for use in Proxy
>> Binding Update and Proxy Binding Acknowledgement messages.  This
>> option can be used by the mobility entities in a Proxy Mobile IPv6
>> domain for carrying the group affiliation of a mobile node in any of
>> the mobility signaling messages.
>>
>> A URL for this Internet-Draft is:
>>
>> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-mn-groupid-option-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce at ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>
>
> --
> Internet Management Technology Lab, Sungkyunkwan University.
> Jong-Hyouk Lee.
>
> #email: jonghyouk (at) gmail (dot) com
> #webpage: http://hurryon.googlepages.com/
>
> ------------------------------
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://hurryon.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090605/5dabc310/attachment.html>

From: sunseawq at huawei.com (Qin Wu)
Date: Fri, 05 Jun 2009 17:38:24 +0800
Subject: [Netext] I-DAction:draft-gundavelli-netext-mn-groupid-option-01.txt
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Sri: 
It is a quite good idea to use group mobile node ID to solve batch registration and de-registration operations for
all the mobile node that belong to the specific realm. 
I wonder whether we can define or give the example format of mobile node group identifier.
e.g.,username at companyA.com.
      username at LMA domain name
      username at LMA IP address
      username at VPN name or Identity
Also I have some comments on this draft below:

in the section3 " Signaling and other Considerations"
"
   The Mobile Node's Group Identifier option reflects the group
   affiliation that is local to the local mobility anchor or mobile
   access gateway, as determined by those respective entities.
"
I wonder who allocate the mobile node group identifier? The MAG, the LMA or the AAA server. In my understanding, the LMA is a 
appropriate node to allocate the mobile node group identifier. Because LMA can easily avoid allocating identifier conflict. 
If the mobile node's group identifier is local to the MAG, Does it means the mobile node's group identifier is allocated by the MAG. In that case,
this mobile node's group identifier local to the MAG may be not unique or cause allocation identifier conflict. What do you think of it? 

Regards!
-Qin
  On Wed, Jun 3, 2009 at 10:15 AM, <Internet-Drafts at ietf.org> wrote:

    A New Internet-Draft is available from the on-line Internet-Drafts directories.

           Title           : Mobile Node Group Identifier option
           Author(s)       : S. Gundavelli, et al.
           Filename        : draft-gundavelli-netext-mn-groupid-option-01.txt
           Pages           : 7
           Date            : 2009-06-02

    This document specifies a new mobility option for use in Proxy
    Binding Update and Proxy Binding Acknowledgement messages.  This
    option can be used by the mobility entities in a Proxy Mobile IPv6
    domain for carrying the group affiliation of a mobile node in any of
    the mobility signaling messages.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-gundavelli-netext-mn-groupid-option-01.txt

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.

    _______________________________________________
    I-D-Announce mailing list
    I-D-Announce at ietf.org
    https://www.ietf.org/mailman/listinfo/i-d-announce
    Internet-Draft directories: http://www.ietf.org/shadow.html
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

  -- 
  Internet Management Technology Lab, Sungkyunkwan University. 
  Jong-Hyouk Lee.

  #email: jonghyouk (at) gmail (dot) com 
  #webpage: http://hurryon.googlepages.com/

------------------------------------------------------------------------------

  _______________________________________________
  NetExt mailing list
  NetExt at mail.mobileip.jp
  http://www.mobileip.jp/mailman/listinfo/netext
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090605/aef23411/attachment.html>

From: terrancenory at yahoo.com (TERRANCE LEROY WILLIAMS)
Date: Thu, 04 Jun 2009 19:47:41 +0300
Subject: [Netext] Hello,
Message-ID: <[email-masked]>

Hello, 
  
My name is TERRANCE LEROY WILLIAMS, I am an American soldier in peace keeping force in Iraq
and serving in the military of the 1st Armored Division in Iraq . As you know
insurgents attack us daily. 
  
We succeeded in moving funds belonging to Saddam Hussein's family totaling
US $23 Million dollars in cash and would like to transfer this money to you for
safe keeping till we can come over to meet you and for your efforts we would
give you 40% while the remaining 60% will be for my partners and I. 
  
Since Iraq is a war zone we plan on using diplomatic courier and shipping the
money out in three large silver boxes, using diplomatic immunity. If you are
interested I will send you the full details, my job is to find a good partner
that we can trust and that will assist us; the question is can I trust you? 
  
When you receive this mail, kindly send me a reply signifying your interest
also include your private telephone/fax numbers for quick communication and any
other relevant contact details. This transaction is simple and risk free and the
boxes can be shipped out in 48hrs.

EMAIL:terrancewll at aim.com
Regards,
TERRANCE LEROY WILLIAMS

From: xiayangsong at huawei.com (Frank Xia)
Date: Thu, 04 Jun 2009 11:30:20 -0500
Subject: [Netext] New Version Notification for draft-gundavelli-netext-pmipv6-retransmit-option-00 (fwd)
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Sri

After a quick glance, here a question for you.

Why does the receiver selectively ignor the
retransmitted packets?

BR
Frank

----- Original Message ----- 
From: "Sri Gundavelli" <sgundave at cisco.com>
To: <netext at mail.mobileip.jp>
Sent: Tuesday, June 02, 2009 7:34 PM
Subject: [Netext] New Version Notification for 
draft-gundavelli-netext-pmipv6-retransmit-option-00 (fwd)

>
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-pmipv6-retransmit-option-00.txt
>
>
> ---------- Forwarded message ----------
> Date: Tue, 2 Jun 2009 17:33:36 -0700 (PDT)
> From: Sri Gundavelli <sgundave at cisco.com>
> To: netext at mail.mobileip.jp
> Subject: New Version Notification for
>     draft-gundavelli-netext-pmipv6-retransmit-option-00
>
>
>
> A small draft for identifying retransmitted PBU's.
>
> Currently, there are no clear semantics in Proxy Mobile IPv6 for
> tagging/identifying retransmitted signaling packets. We defined a
> simple option, retransmit option with the mesgid, retransmit id,
> that can be used for this purpose. We realized the need for this
> while implementation and Rajeev also had the same requirement.
>
> Please comment.
>
>
> Regards
> Sri
>
>
>
>
> ---------- Forwarded message ----------
> Date: Tue,  2 Jun 2009 17:26:24 -0700 (PDT)
> From: IETF I-D Submission Tool <idsubmission at ietf.org>
> To: sgundave at cisco.com
> Cc: kleung at cisco.com, rkoodli at starentnetworks.com
> Subject: New Version Notification for
>       draft-gundavelli-netext-pmipv6-retransmit-option-00
>
>
> A new version of I-D, 
> draft-gundavelli-netext-pmipv6-retransmit-option-00.txt has been 
> successfuly submitted by Sri Gundavelli and posted to the IETF repository.
>
> Filename: draft-gundavelli-netext-pmipv6-retransmit-option
> Revision: 00
> Title: Retransmitted Message Identification Option for Proxy Mobile IPv6
> Creation_date: 2009-06-02
> WG ID: Independent Submission
> Number_of_pages: 8
>
> Abstract:
> The Proxy Mobile IPv6 base protocol does not provide any mechanism
> for the receiver of a mobility signaling message to determine if the
> received message is the original message or a retransmitted message
> of an earlier sent message.  The absence of such a semantic in some
> cases results in inefficient processing of the signaling messages and
> will lead to additional processing load and network traffic.
>
> This document defines a new mobility option, Retransmitted Message
> Identification option for use in Proxy Binding Update and Proxy
> Binding Acknowledgement messages.  This option enables the mobility
> entities to use proper message identifiers and retransmit markings on
> the signaling messages.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext 

From: jonghyouk at gmail.com (Jong-Hyouk Lee)
Date: Wed, 3 Jun 2009 16:34:47 +0900
Subject: [Netext] I-D Action:draft-gundavelli-netext-mn-groupid-option-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi, Sri.

As indicated at Sec. 1 of I.-D. (Mobile Node Group Identifier Option), this
option optimizes the performance of PMIPv6 by reducing the number of PBU/PBA
exchanging.

Comments on Mobile Node Group Identifier Option
(draft-gundavelli-netext-mn-groupid-option-01).

In Sec. 3, this option is used to indicate the group information for several
mobile nodes attached to an MAG. Accordingly, the sentence (... that is
local to the local mobility anchor or mobile access gateway, as ...) should
be modified as "... that is local to the mobile access gateway, as ...".

In Sec. 1, this option can be used to indicate a set of (mobile) nodes
attached to the mobile router if we consider that the mobile router attaches
to a specific MAG. The use-case for NEMO in PMIPv6 domain (i.e.,
draft-jhlee-netlmm-nemo-scenarios-01) should be added.

Cheers.

On Wed, Jun 3, 2009 at 10:15 AM, <Internet-Drafts at ietf.org> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>        Title           : Mobile Node Group Identifier option
>        Author(s)       : S. Gundavelli, et al.
>        Filename        : draft-gundavelli-netext-mn-groupid-option-01.txt
>        Pages           : 7
>        Date            : 2009-06-02
>
> This document specifies a new mobility option for use in Proxy
> Binding Update and Proxy Binding Acknowledgement messages.  This
> option can be used by the mobility entities in a Proxy Mobile IPv6
> domain for carrying the group affiliation of a mobile node in any of
> the mobility signaling messages.
>
> A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-mn-groupid-option-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://hurryon.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090603/c077da13/attachment.html>

From: sgundave at cisco.com (Sri Gundavelli)
Date: Tue, 2 Jun 2009 17:34:40 -0700 (PDT)
Subject: [Netext] New Version Notification for draft-gundavelli-netext-pmipv6-retransmit-option-00 (fwd)
Message-ID: <[email-masked]>

http://www.ietf.org/internet-drafts/draft-gundavelli-netext-pmipv6-retransmit-option-00.txt

---------- Forwarded message ----------
Date: Tue, 2 Jun 2009 17:33:36 -0700 (PDT)
From: Sri Gundavelli <sgundave at cisco.com>
To: netext at mail.mobileip.jp
Subject: New Version Notification for
     draft-gundavelli-netext-pmipv6-retransmit-option-00

A small draft for identifying retransmitted PBU's.

Currently, there are no clear semantics in Proxy Mobile IPv6 for
tagging/identifying retransmitted signaling packets. We defined a
simple option, retransmit option with the mesgid, retransmit id,
that can be used for this purpose. We realized the need for this
while implementation and Rajeev also had the same requirement.

Please comment.

Regards
Sri

---------- Forwarded message ----------
Date: Tue,  2 Jun 2009 17:26:24 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission at ietf.org>
To: sgundave at cisco.com
Cc: kleung at cisco.com, rkoodli at starentnetworks.com
Subject: New Version Notification for
       draft-gundavelli-netext-pmipv6-retransmit-option-00

A new version of I-D, draft-gundavelli-netext-pmipv6-retransmit-option-00.txt 
has been successfuly submitted by Sri Gundavelli and posted to the IETF 
repository.

Filename:	 draft-gundavelli-netext-pmipv6-retransmit-option
Revision:	 00
Title:		 Retransmitted Message Identification Option for Proxy Mobile 
IPv6
Creation_date:	 2009-06-02
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
The Proxy Mobile IPv6 base protocol does not provide any mechanism
for the receiver of a mobility signaling message to determine if the
received message is the original message or a retransmitted message
of an earlier sent message.  The absence of such a semantic in some
cases results in inefficient processing of the signaling messages and
will lead to additional processing load and network traffic.

This document defines a new mobility option, Retransmitted Message
Identification option for use in Proxy Binding Update and Proxy
Binding Acknowledgement messages.  This option enables the mobility
entities to use proper message identifiers and retransmit markings on
the signaling messages.

The IETF Secretariat.

From: sgundave at cisco.com (Sri Gundavelli)
Date: Tue, 2 Jun 2009 17:33:36 -0700 (PDT)
Subject: [Netext] New Version Notification for draft-gundavelli-netext-pmipv6-retransmit-option-00
Message-ID: <[email-masked]>

A small draft for identifying retransmitted PBU's.

Currently, there are no clear semantics in Proxy Mobile IPv6 for
tagging/identifying retransmitted signaling packets. We defined a
simple option, retransmit option with the mesgid, retransmit id,
that can be used for this purpose. We realized the need for this
while implementation and Rajeev also had the same requirement.

Please comment.

Regards
Sri

---------- Forwarded message ----------
Date: Tue,  2 Jun 2009 17:26:24 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission at ietf.org>
To: sgundave at cisco.com
Cc: kleung at cisco.com, rkoodli at starentnetworks.com
Subject: New Version Notification for
      draft-gundavelli-netext-pmipv6-retransmit-option-00

A new version of I-D, draft-gundavelli-netext-pmipv6-retransmit-option-00.txt 
has been successfuly submitted by Sri Gundavelli and posted to the IETF 
repository.

Filename:	 draft-gundavelli-netext-pmipv6-retransmit-option
Revision:	 00
Title:		 Retransmitted Message Identification Option for Proxy Mobile 
IPv6
Creation_date:	 2009-06-02
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
The Proxy Mobile IPv6 base protocol does not provide any mechanism
for the receiver of a mobility signaling message to determine if the
received message is the original message or a retransmitted message
of an earlier sent message.  The absence of such a semantic in some
cases results in inefficient processing of the signaling messages and
will lead to additional processing load and network traffic.

This document defines a new mobility option, Retransmitted Message
Identification option for use in Proxy Binding Update and Proxy
Binding Acknowledgement messages.  This option enables the mobility
entities to use proper message identifiers and retransmit markings on
the signaling messages.

The IETF Secretariat.

From: admin at uknowledge.com (United Knowledge Pte Ltd)
Date: Tue, 2 Jun 2009 17:34:18 +0800
Subject: [Netext] <Adv> "Enhancing Empathy and EQ for Service Excellence" 22-23 Jun 09
Message-ID: <[email-masked]>

Dear Professionals,

1 Additional Seat Free for each Participant Registered before 15 Jun 09

New SeminarUnited Knowledge

Enhancing Empathy & EQ for Service Excellence

Seminar Details
 
$780 per participant for 2 days     
22-23 Jun 09 or 24-25 Sep 09
Include: Lunches, Snacks and Seminar Coursebook 
 
Time/Venue : 9.30am to 5pm,    
Venue :  MIS Building Singapore
             (to be Confirmed)

All Early Birds :    
2 Free Talk Tickets (Worth $50 each)  Plus 

1 Inspiration CD :  Printer-Ready Posters,  Screensavers Quotes, Articles, Forms, etc.

$60 Book Voucher and  24 A5-Posters for FIRST 20 Paid Registrations 

$30 Book Voucher for NEXT 50  Registrations 

Speaker
 
Dr Allen Teh, PhD is the founder and Chief Executive Officer for the Centre for Customer Care(CCC) Malaysia.  He has conducted extensive worldwide research on customer 

service, behavior and how EQ impacts business profitability through work performance.

Dr Allen Teh has more than 28 years of work experience in service operations as well as Human Resource Management, Training and Consultancy.   He has held several 

managerial positions in diverse industries namely food & beverage, entertainment, manufacturing, property develop, construction, insurance, oil-palm plantations and

BioTechnology.

Dr Teh has an intense passion in customer service excellence and a firm believer that customer service makes all the difference in today?s Businesses and government 

services.  Dr Allen Teh holds a Doctorate Degree in Business Administration from South Cross University, Australia and MBA from University of Dubuque, Iowa USA. 

More Information 
Contact 
United Knowledge Pte Ltd 
Tel : 6546 5801  or   
admin at uknowledge.com

EMOTIONAL INTELLIGENCE (EQ) has been defined as ?the ability to sense, understand, and effectively apply the power and acumen of emotions as a source of human energy, 

information, connection, and influence."   To put that into a simpler sense, EQ is ?A way of recognizing, understanding, and choosing how we think, feel, and act. It 

shapes our interactions with others and our understanding of ourselves. It defines how and what we learn; it allows us to set priorities; it drives many of our daily 

actions." 

Emotional Intelligence (EQ) may just be the ?missing link? in the equation for effective and top class performance and Empathy for customer service. 

This 2-Days program will teach participants how to develop EQ  and become more effective and successful in their work and lives.  Participants will be introduced to the 

important concepts of K-A-B Model of EQ.  Using this model, participants will learn how to enhance their self-awareness, self-confidence, self-control, empathy, 

motivation and social competency ? and then use them wisely and apply them effectively in their daily work and in their personal lives.

Seminar Topics 
 
Improving your  Emotional Intelligence (EQ) 

Balancing EQ and IQ

K-A-B Model of Emotional Intelligence 

Assessing Emotional Intelligence 

Rating EQ: Self-Assessment, Leadership and Interpretation 

Setting Personal Goals

The Fundamentals of Emotional Intelligence 

Self Fundamentals: Understanding and Accepting Ourselves 

Social Fundamentals: Social Interaction 

The Role of Self-Awareness in Emotional Intelligence 

How you can better understand your customers.

How Emotions Manifest Themselves

The Role of Self-Confidence in Emotional Intelligence 

Low  &  Over Self-Confidence

Taking Mistakes in Stride

The Role of Self-Control in Emotional Intelligence 

Develop Self-Management

Resilience to handle Challenging Interactions.

The Challenge of Self-Control & Anger

Keeping our Emotions in Balance

Maintaining a Positive Mood

The Role of Empathy in Emotional Intelligence 

Developing the Ability to Empathize 

Reading Social Cues: Listening With Your Eyes 

Tone of Voice

Listening ? The Vehicle to Empathy

What To Do When Listening

Why Empathy is so Vital

Motivation and Emotional Intelligence 

Engage your sense of purpose so you can connect with customers on a deep and meaningful level.

Importance of Meaning and Defining of Your Purpose 

Tips for Increasing Motivation and Optimism , Creativity

Promoting Emotional Intelligence in Others

Empower You Employees & Colleagues

Help Others Maintain Emotional Balance

Positive Confrontations

Exceptional Customer Service Development Plan

Apply KAB EQ Model to create a personal and professional development plan.

BONUS TOPIC :

Emotional Freedom Technique (EFT)  tips to help you cope with your emotions effectively.

 
Best Regards, 
Joanne Ng, Tel (65) 6546 5801 
United Knowledge Pte Ltd    23 Loyang View Singapore 507247
joanne at uknowledge.com

To UnSubscribe,  simply reply to this email with Subject : UnSubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090602/e7ded10e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3700 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090602/e7ded10e/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flyer_EQ_CustomerService_Jun09 [Compatibility	Mode].pdf
Type: application/pdf
Size: 44031 bytes
Desc: not available
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090602/e7ded10e/attachment-0001.pdf>

From: mkevin04 at yahoo.co.th (Kevin Moore)
Date: Tue, 2 Jun 2009 02:37:48 -0400 (EDT)
Subject: [Netext] INVESTMENT ASSISTANCE.
Message-ID: <[email-masked]>

>From : Kevin Moore
Abidjan, 
Ivory Coast.

                         INVESTMENT ASSISTANCE.
Dear One,

With due respect and with God all thing were possible that is why I call for help to please Permit me to inform you of my desire of going into business relationship with you. 

I am Kevin Moore the only son of late Mr. Joseph Moore, My father was a very wealthy cocoa merchant in Ivory Coast, my father was poisoned to death by his business associates on the first of October 2007 on their outing for a business trip.

My mother died when I was a baby and since then my father took me so special. Before the death of my father on the First of October 2007 in a private hospital here in Ivory Coast he secretly called me on his bed side and told me that he has the sum of Sixteen Million United State Dollars. US(16.m) left in fixed /suspense account in one of the prime bank here in Ivory Coast that he used my name as his only son for the next of Kin in Depositing of the money. 

He told me that I should seek for a foreign partner in a country of my choice where i will transfer this money into and use it for investment purpose such as real estate management or hotel management.

I am honourably seeking your assistance in the following ways:

(1) To provide a bank account in which this money would be transferred into.
(2) To serve as a guardian of this fund since I am only 23 years old. 
(3) To make arrangement for me to come over to your country to further my education and to secure a resident permit in your country.

Moreover, I am willing to offer you 20% of the total sum as compensation for your effort/input after the successful transfer of this fund into your nominated account overseas.

All the necessary arrangement has been made at the bank where my late father deposited this money and the Director of the bank told me that as soon as an account of my choice is forwarded to their bank that they will transfer this fund into my destination.

Please reply immediately for us to proceed in this transaction which I believed that in few days you shall call me for good news that you have confirm my money in an account which you will provide to the bank where my inheritance was deposited into.

Furthermore, you indicate your options towards assisting me as I believed that this transaction would be concluded within three (3) days you signify interest to assist me.

Anticipating to hear your voice immediately.
Thanks and God bless you.
Best regards,

Kevin Moore. 

From: drahmedi.idowu74 at gmail.com (Dr.Ahmed Idowu)
Date: Mon, 1 Jun 2009 09:16:27 -0700
Subject: [Netext] Investment Partner.
Message-ID: <00d968d8-39965-15783859201389@user-2d912a83ae>

Dear Friend,

I am making this contact to you in good faith. I got your email in  my search for a trust worthy and honest person that could assist me in a confidential transaction. I am Honorable Dr. Ahmed Idowu .I am one of the members who conducted the 2007 election with some of my party members, after the election I discovered that the sum of $60 Million Dollars Was remaining and we decided to move it outside the country for safe keeping in a Finance House.

I hereby write to seek for  your opinion for an investment in your country . I will appreciate if you can be able to handle this project perfectly with us, by making sure that the money will be received and safe keep in your custody for investment . Kindly respond back soonest with your  private telephone/ fax numbers for more details.

Plesea kindly get back to me through my private email: idowu.ahmed204 at gmail.com

Thanks and God bless.

Yours sincerely,

Hon. Dr.Ahmed Idowu

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Thu, 18 Jun 2009 20:01:01 +0300
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco, Qin,

On Jun 18, 2009, at 12:28 PM, Marco Liebsch wrote:

> Hi Qin,
>
> please see inline.
>
> Qin Wu schrieb:
>>> Hi Qin,
>>>
>>> please see inline for my thoughts.
>>>
>>> Qin Wu schrieb:
>>>
>>

[snap]

>>
>>>> As regarding Case 2,  as described in draft-ietf-netlmm-pmip6- 
>>>> ipv4-support-12, it is impossible for the LMA to locate behind a  
>>>> NAT unless the MAG and the LMA both locate behind NAT. Take the  
>>>> same scenario mentioned in the case 1 as example, if there is NAT  
>>>> between MAG1 and LMA1 and the LMA1
>>>> and MAG1 are both behind the NAT, I  think also there is a NAT  
>>>> between LMA1 and LMA2.
>>>>
>>> If the IPv4 draft indicates that the LMA must not be behind a NAT,  
>>> the same holds for the
>>> RO protocol extension. Or is there anything extra to be analyzed  
>>> for RO?
>>>
>>
>> [Qin]: I agree. Does it mean RO PS draft needs one strong reason if  
>> it include the scenario where NAT is located between MN and CN's LMA?
>>
> The interface between the two relevant LMAs is important for us.  
> Regarding the scope of
> NetExt to perform localized routing only within a single PMIPv6  
> domain, I am not
> sure if it's a realistic use case which considers a NAT between  
> these two LMAs.
> If this could happen, we need to take care about it.

IMHO it would be good to state what kind of NAT is actually meant  
here. Is it NAPT or what? Some NAT solutions are less harmful.

[snip]

Cheers,
	Jouni

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 18 Jun 2009 11:40:31 +0200
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Qin Wu schrieb:
> Hi, Marco:
> Some clarification below.
>
>   
>> Any thought, comment and discussion is welcome.
>>
>> marco
>>
>> ----
>>
>> [1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)
>>
>> [2] MN's and CN's MAG support different IP versions to signal to the LMA(s)
>>
>> [3] NAT between MN's and CN's MAG
>>
>> [4] NAT between MN's and CN's LMA
>>
>> [5] Different IP version for signaling between MN's and CN's MAG
>>
>> [6] Different IP version for forwarding of localized traffic between 
>> MN's and CN's MAG
>>
>> [7] IP address conflict when MN and CN use the same IPv4 HoA
>> Isn't that an issue with base PMIPv6 already?
>>     
>
> [Qin]:
> In PMIPv6 domain, the MAG and the LMA can distinguish each mobile node flow based on the GRE key encapsulated within the tunneled packet [ID-PMIP-GREKEY], even though two mobile nodes are assigned the same IPv4 HoA. However, when the traffic destined for the CNs with same HoA does not pass through the tunnel between the MAG and the LMA and go directly to the path between the MAGs associated with MN and CN, the MAG attached by the two CNs with the same IPv4 HoA can not identify the right CN based on the overlapped IPv4 HoA in the destination field of the incoming packet, therefore can not forward the user traffic to the right CN.
>   
Yes, good point. Can we re-use the same key for the local forward 
between MAGs? Probably not, as keys
are negotiated between an LMA-Mag pair and the key for the MN and the CN 
may be the same. Even though
the probability for a key conflict is low, it's not 0. Does it mean we 
need to re-negotiate keys between MAGs?
And does it mean we need to use GRE in such case?

>   
>> [8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
>> localized forwarding between MAGs
>> Should work if both MAGs are dual stack and can negotiate the IP version 
>> (?).
>>     
>
> [Qin] I agree. In this case, IP version or Encapsulation mode negotiation is required.
>   
Maybe there should be a default encapsulation mode and a fallback. And 
we need capability
indication about the encapsulation mode in the localized routing signaling.

Best regards,
marco

>   
>> [9] Compatibility of route optimization states with IPv4
>> In my opinion related to the issues above. If we set up IPv4 transport 
>> or user plane support on relevant PMIPv6 nodes, route entries and binding 
>> management need to
>> have entries for IPv4 addresses.
>>
>>
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>     

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 18 Jun 2009 11:28:35 +0200
Subject: [Netext] PMIPv6 localized routing - IPv4 aspects
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Qin,

please see inline.

Qin Wu schrieb:
>> Hi Qin,
>>
>> please see inline for my thoughts.
>>
>> Qin Wu schrieb:
>>     
>>>> from previous mails and drafts, we can identify a couple of issues which we
>>>> must take into account when designing a localized routing protocol for 
>>>> PMIPv6.
>>>> For the PS, I don't think we need to analyze problems which have been 
>>>> addressed
>>>> for standard RFC5213 operations already, such as a NAT between MAG and LMA.
>>>>     
>>>>         
>>> [Qin]: Probably you are right. I think there are some misunderstandings.
>>> Let me clarify why NAT between MAG and LMA is shown in the figure 1 of draft-wu-netext-pmipv6-ipv4-ro-ps.
>>> I think NAT between MAG and LMA can be further divided into two case:
>>> case 1: The MAG is behind the NAT
>>> case 2: The LMA is behind the NAT
>>> As regarding the Case 1, suppose there is one scenario where the MN attaches to MAG1 and CN attaches to MAG2, MAG1 and MAG2 register
>>> to the different LMA, In this scenario, if there is NAT between MAG1 and LMA1 and the MAG1 is behind the NAT, I think also there is a NAT between 
>>> MAG1 and MAG2, the MAG1 is behind the same NAT as the NAT located between MAG1 and LMA1.
>>>   
>>>       
>> Yes, but that can be mapped to the case where there is a NAT between 
>> MAGs, right? So it does not
>> represent an extra case which introduces additional problems, or?
>>     
>
> [Qin]: What I want to emphasize here is the scenario where the NAT is located between the MAG and the LMA is relevant to the case 1 and case 2 mentioned above if we consider local routing path setup between the MAGs or between LMAs.  In order to avoid confusion, I agree to  leave out this scenario where the NAT between the MAG and LMA from the IPv4 RO PS draft. Actually it does not reflected anywhere in the draft except in the figure.
>   
Ok.

>   
>>> As regarding Case 2,  as described in draft-ietf-netlmm-pmip6-ipv4-support-12, it is impossible for the LMA to locate behind a NAT unless the MAG and 
>>> the LMA both locate behind NAT. Take the same scenario mentioned in the case 1 as example, if there is NAT between MAG1 and LMA1 and the LMA1
>>> and MAG1 are both behind the NAT, I  think also there is a NAT between LMA1 and LMA2.
>>>   
>>>       
>> If the IPv4 draft indicates that the LMA must not be behind a NAT, the 
>> same holds for the
>> RO protocol extension. Or is there anything extra to be analyzed for RO?
>>     
>
> [Qin]: I agree. Does it mean RO PS draft needs one strong reason if it include the scenario where NAT is located between MN and CN's LMA?
>   
The interface between the two relevant LMAs is important for us. 
Regarding the scope of
NetExt to perform localized routing only within a single PMIPv6 domain, 
I am not
sure if it's a realistic use case which considers a NAT between these 
two LMAs.
If this could happen, we need to take care about it.

>   
>>>   
>>>       
>>>> We could start with the following list to discuss and identify a 
>>>> possible problem space
>>>> for PMIPv6 localized routing and to find out which of these or new 
>>>> issues are relevant
>>>> for the PS and the NetExt protocol solution. I tried to collect 
>>>> individual items from
>>>> mail exchange with Sangjin, from draft-jeong-netlmm-pmipv6-roreq-01 and
>>>> draft-wu-netext-pmipv6-ipv4-ro-ps-00.
>>>>     
>>>>         
>>> [Qin]: As regarding IPv4 aspects, I am glad the draft-wu-netext-pmipv6-ipv4-ro-ps is credited. 
>>>
>>>   
>>>       
>>>> Any thought, comment and discussion is welcome.
>>>>
>>>> marco
>>>>
>>>> ----
>>>>
>>>> [1] MN and CN use IPv4 HoA for communication (IPv4 HoA mobility)
>>>>
>>>> [2] MN's and CN's MAG support different IP versions to signal to the LMA(s)
>>>>
>>>> [3] NAT between MN's and CN's MAG
>>>>
>>>> [4] NAT between MN's and CN's LMA
>>>>
>>>> [5] Different IP version for signaling between MN's and CN's MAG
>>>>
>>>> [6] Different IP version for forwarding of localized traffic between 
>>>> MN's and CN's MAG
>>>>
>>>> [7] IP address conflict when MN and CN use the same IPv4 HoA
>>>> Isn't that an issue with base PMIPv6 already?
>>>>
>>>> [8] Switch of forwarding tunnel from IPv6 to IPv4 when changing to
>>>> localized forwarding between MAGs
>>>> Should work if both MAGs are dual stack and can negotiate the IP version 
>>>> (?).
>>>>
>>>> [9] Compatibility of route optimization states with IPv4
>>>>     
>>>>         
>>> [Qin]: Thank for your summarizing and re-catogorizing the scenarios described in the draft-wu-netext-pmipv6-ipv4-ro-ps.
>>> I think most of these scenarios you enumerated are reflected in the draft-wu-netext-pmipv6-ipv4-ro-ps except the case where the NAT is located between
>>> MN's and CN's LMA. If my understanding is  correct, this case should require both MAG and LMA behind the same NAT. Because as described in the draft->> ietf-netlmm-pmip6-ipv4-support-12:
>>> "
>>> 4.  IPv4 Transport Support
>>> the local mobility anchor must not be behind a NAT and must be using a globally routable IPv4 address. 
>>> "
>>> I wonder whether we need to address this case in the PMIPv6 localized routing PS draft.
>>>   
>>>       
>> Probably not. In particular since NetExt scope is limited to RO within a 
>> single PMIPv6 domain, where in
>> a multi-LMA scenario these LMAs should be behind the same NAT. But as 
>> you said, LMAs behind a
>> NAT are ruled out, if my understanding is correct. 
>>     
>
> [Qin] Actually I did not exclude the LMA behind a NAT if we allow both LMA and MAG are located behind the same NAT or there is any other concrete scenario.
> But I wonder in muti-LMA scenario , why all these LMA should be behind the same NAT?
> Is it possible for one domain to have several private networks or VPNs and each private networks has one LMA?
>   
Talking about an operator network, I think this is unlikely. But if it 
could happen, we need to take care about it.

>   
>> But maybe there are 
>> other opinions
>>     
> [Qin]:  I look forward to seeing that if possbible.
>   

Best regards,
marco

>   
>> marco
>>
>>     
>>>> _______________________________________________
>>>> NetExt mailing list
>>>> NetExt at mail.mobileip.jp
>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>     
>>>>         
>>     

From [email-masked]  Thu Jun 18 12:04:24 2009
From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 18 Jun 2009 21:04:01 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [netext] Test

Pls. ignore

From [email-masked]  Mon Jun 22 15:44:06 2009
From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 23 Jun 2009 00:44:22 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [netext] Solicitations for agenda items

Hello,

The NetExt WG will meet at IETF75.
Please submit any requests for a slot on the agenda.

Note that we will consider I-Ds that pertain to the scope of the charter.
Additionally please ensure that you have an accompanying I-D when you
request a slot.=20

-Chairs

From [email-masked]  Mon Jun 22 15:47:06 2009
From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 23 Jun 2009 00:47:15 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [netext] Netext meetings at IETF75

Hello,

If you are wondering what the second slot (Netext2 BoF) is about on the
agenda:

Since we were unable to form any consensus w.r.t some of the proposed
extensions to PMIP6, Jari has suggested that we have a discussion in a BoF
format. The 2nd slot in the agenda will be organized as a BoF and the scope
of the discussion and objectives will be published soon. Jari will also
decide who will chair this discussion itself.

-Basavaraj

From [email-masked]  Mon Jun 22 23:44:59 2009
From: jouni korhonen <[email-masked]>
To: <[email-masked]> <[email-masked]>
Date: Tue, 23 Jun 2009 09:45:09 +0300
Cc: [email-masked]
Subject: Re: [netext] Solicitations for agenda items

Hi,

We would like to have a slot for the "Runtime LMA Assignment Support  
for Proxy Mobile IPv6" I-D. The corresponding document is draft- 
korhonen-netext-redirect-02.

Cheers,
	Jouni

On Jun 23, 2009, at 1:44 AM, <[email-masked]> <[email-masked] 
 > wrote:

>
> Hello,
>
> The NetExt WG will meet at IETF75.
> Please submit any requests for a slot on the agenda.
>
> Note that we will consider I-Ds that pertain to the scope of the  
> charter.
> Additionally please ensure that you have an accompanying I-D when you
> request a slot.
>
> -Chairs
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Mon Jun 22 23:54:06 2009
Date: Tue, 23 Jun 2009 14:53:45 +0800
From: Qin Wu <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netext] I-D Action:draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt

Hi,

I have just submitted a new version for "Problem Statement of IPv4 Support for PMIPv6 Localized Routing"
<draft-wu-netext-pmipv6-ipv4-ro-ps-01>
http://www.ietf.org/internet-drafts/draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt

The changes to the previous 01-version are of pure editorial kind. 
I reduce the scope to the communication in the same PMIP6 domain,
polish the problem statements and add two more scenarios as Jouni's suggestions and comments.

Comments from the the contributors as well as anybody else are
highly appreciated.It would be great to get a discussion going before the next meeting.

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 23, 2009 12:15 PM
Subject: I-D Action:draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Problem Statement of IPv4 Support for PMIPv6 Localized Routing
> Author(s)       : W. Wu, et al.
> Filename        : draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt
> Pages           : 9
> Date            : 2009-06-22
> 
> [ID-PMIP6-RO-PS] describes the problem space of localized routing
> which allows end-to-end user traffic forwarding between MN and CN
> directly without involving Local Mobility Anchor (LMA) in a single
> Proxy Mobile IPv6 [RFC5213] domain. However, localized routing with
> IPv4 support which allows IPv4 transport between MAG and LMA and/or
> IPv4 enabled user traffic between MN and CN is not considered. This
> document details the scenarios and problem statement for localized
> routing with IPv4 support.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

From [email-masked]  Tue Jun 23 08:50:05 2009
Date: Tue, 23 Jun 2009 10:50:07 -0500
From: Frank Xia <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [netext] Solicitations for agenda items

Hi Raj

I would like to ask  for 5-10 minutes for the 
presentation of "Tunnel Negotiation for 
Proxy Mobile IPv6"
http://tools.ietf.org/id/draft-xia-netext-tunnel-negotiation-01.txt

BR
Frank

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 22, 2009 5:44 PM
Subject: [netext] Solicitations for agenda items

> 
> Hello,
> 
> The NetExt WG will meet at IETF75.
> Please submit any requests for a slot on the agenda.
> 
> Note that we will consider I-Ds that pertain to the scope of the charter.
> Additionally please ensure that you have an accompanying I-D when you
> request a slot. 
> 
> -Chairs
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Tue Jun 23 08:54:45 2009
Date: Tue, 23 Jun 2009 08:55:00 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netext] Solicitations for agenda items

Hi Raj:

I'd to request 10 min presentation slot for each of the following
two items.

Mobile Node Group Identifier Option:
http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01

Retransmit Message Identifier Option:
http://www.ietf.org/internet-drafts/draft-gundavelli-netext-pmipv6-retransmit-option-00.txt

Regards
Sri

On Tue, 23 Jun 2009, [email-masked] wrote:

>
> Hello,
>
> The NetExt WG will meet at IETF75.
> Please submit any requests for a slot on the agenda.
>
> Note that we will consider I-Ds that pertain to the scope of the charter.
> Additionally please ensure that you have an accompanying I-D when you
> request a slot.
>
> -Chairs
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

From [email-masked]  Wed Jun 24 20:16:15 2009
Date: Wed, 24 Jun 2009 20:15:38 -0700 (PDT)
From: Behcet Sarikaya <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [netext] Solicitations for agenda items
Reply-To: Behcet Sarikaya <[email-masked]>

Hi Raj,
  I would like to ask for a slot to present our solution draft at:
http://tools.ietf.org/id/draft-wu-netext-local-ro-00.txt

Regards,

Behcet

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Sent: Monday, June 22, 2009 5:44:22 PM
> Subject: [netext] Solicitations for agenda items
> 
> 
> Hello,
> 
> The NetExt WG will meet at IETF75.
> Please submit any requests for a slot on the agenda.
> 
> Note that we will consider I-Ds that pertain to the scope of the charter.
> Additionally please ensure that you have an accompanying I-D when you
> request a slot. 
> 
> -Chairs
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

      

From [email-masked]  Thu Jun 25 01:41:29 2009
Content-class: urn:content-classes:message
Date: Thu, 25 Jun 2009 03:35:57 -0500
From: "Ahmad Muhanna" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [netext] Solicitations for agenda items

Hello Raj,

We would like to have a 10 minutes slot to present Mobility Session
Suspend in PMIPv6. Please find below a link to the draft. Many thanks in
advance!

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muhanna-netext-mobility-sessio
n-suspend-00.txt

Regards,
Ahmad
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Monday, June 22, 2009 5:44 PM
> To: [email-masked]
> Subject: [netext] Solicitations for agenda items
>=20
>=20
> Hello,
>=20
> The NetExt WG will meet at IETF75.
> Please submit any requests for a slot on the agenda.
>=20
> Note that we will consider I-Ds that pertain to the scope of=20
> the charter.
> Additionally please ensure that you have an accompanying I-D=20
> when you request a slot.=20
>=20
> -Chairs
>=20
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>=20

From [email-masked]  Thu Jun 25 01:41:45 2009
Content-class: urn:content-classes:message
Date: Thu, 25 Jun 2009 03:33:25 -0500
From: "Ahmad Muhanna" <[email-masked]>
To: <[email-masked]>
Subject: [netext] FW: I-D Action:draft-muhanna-netext-mobility-session-suspend-00.txt

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9F56F.9BA1F180
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
Hello Folks,

We submitted a draft that address the mobility session suspend in
PMIPv6.
We appreciate your comments.
Thanks!

Regards,
Ahmad

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, June 25, 2009 3:30 AM
To: [email-masked]
Subject: I-D Action:draft-muhanna-netext-mobility-session-suspend-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Mobility Session Suspend Support in PMIPv6
	Author(s)       : A. Muhanna, et al.
	Filename        :
draft-muhanna-netext-mobility-session-suspend-00.txt
	Pages           : 9
	Date            : 2009-06-25

This specification defines a new extension to Proxy Mobile IPv6 for
suspending a mobility session by using a new Mobility Session Suspend
option.  This option is used by the mobile access gateway in the Proxy
Binding Update to request the local mobility anchor to suspend a
specific mobile node mobility session.  When the local mobility anchor
successfully processes the Proxy Binding Update, the local mobility
anchor suspends the delivery of the downlink traffic to the specified
mobile node mobility session.  The mobile access gateway sends another
Proxy Binding Update with the mobility session suspend option and the
suspend flag cleared to indicate to the local mobility anchor to resume
sending the downlink traffic for the mobile node mobility session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muhanna-netext-mobility-sessio
n-suspend-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C9F56F.9BA1F180
Content-Type: application/octet-stream;
	name="draft-muhanna-netext-mobility-session-suspend-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-muhanna-netext-mobility-session-suspend-00.URL
Content-Disposition: attachment;
	filename="draft-muhanna-netext-mobility-session-suspend-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1tdWhhbm5hLW5ldGV4dC1tb2JpbGl0eS1zZXNzaW9uLXN1c3BlbmQtMDAudHh0DQo=

------_=_NextPart_001_01C9F56F.9BA1F180
Content-Type: text/plain;
	name="ATT2122072.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT2122072.txt
Content-Disposition: attachment;
	filename="ATT2122072.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj
dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0
Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K

------_=_NextPart_001_01C9F56F.9BA1F180--

From [email-masked]  Fri Jun 26 09:04:11 2009
From: Ralph Droms <[email-masked]>
To: [email-masked]
Date: Fri, 26 Jun 2009 12:04:00 -0400
Cc: "Jonne \(NSN - FI/Espoo\) Soininen" <[email-masked]>
Subject: [netext] netext2 BOF at IETF 75

The IESG has approved the netext2 BOF at IETF 75, to discuss the  
extension of PMIP6 to support hosts with multiple interfaces.  Marcelo  
Bagnulo and Jonne Soininen have agreed to chair the BOF.  They will  
follow up with a draft BOF description for review and comment.

More information will be available at http://trac.tools.ietf.org/bof/trac/wiki#Internet

- Ralph Droms
   Internet AD

From [email-masked]  Fri Jun 26 09:20:56 2009
From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 26 Jun 2009 18:20:55 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [netext] WG view about problem statement I-D for localized routing

Hello,

One of the extensions to PMIP6 that NetExt will be working on is localized
routing. As per the charter:

" Localized Routing: a specification for routing traffic between the
MAG(s) without involving the LMA. That is, allow the MAGs to route
traffic between hosts from one MAG to another, without being tunneled
all the way to the LMA. This reduces latency and backhaul load.
Applications such as voice can benefit from the reduced latency."

At IETF74, we discussed the problem statement as per I-D:
draft-liebsch-netext-pmip6-ro-ps-00.txt

In order to ensure that we have clear scope and boundaries around the
localized routing extension, should we make the PS I-D a WG document before
proceeding to work on the solutions? At the present time there are several
I-Ds proposing solutions to localized routing. Agreeing on what needs to be
solved first would make the solution work better structured.
The other option is to capture the problem statement in a section of the
solution I-D itself. It is possible if the WG feels that the scope and the
feature is clear.

Thoughts?

-Basavaraj

From [email-masked]  Fri Jun 26 09:31:54 2009
Date: Fri, 26 Jun 2009 09:32:02 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

This is a very well defined problem. Other than the negotiation
aspect, 5213 already allows local routing. I dont believe PS
draft will add lot of value. Going directly to solution spec will
be better, IMO.

Sri

On Fri, 26 Jun 2009, [email-masked] wrote:

>
> Hello,
>
> One of the extensions to PMIP6 that NetExt will be working on is localized
> routing. As per the charter:
>
> " Localized Routing: a specification for routing traffic between the
> MAG(s) without involving the LMA. That is, allow the MAGs to route
> traffic between hosts from one MAG to another, without being tunneled
> all the way to the LMA. This reduces latency and backhaul load.
> Applications such as voice can benefit from the reduced latency."
>
> At IETF74, we discussed the problem statement as per I-D:
> draft-liebsch-netext-pmip6-ro-ps-00.txt
>
> In order to ensure that we have clear scope and boundaries around the
> localized routing extension, should we make the PS I-D a WG document before
> proceeding to work on the solutions? At the present time there are several
> I-Ds proposing solutions to localized routing. Agreeing on what needs to be
> solved first would make the solution work better structured.
> The other option is to capture the problem statement in a section of the
> solution I-D itself. It is possible if the WG feels that the scope and the
> feature is clear.
>
> Thoughts?
>
> -Basavaraj
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

From [email-masked]  Fri Jun 26 11:32:42 2009
Date: Fri, 26 Jun 2009 11:31:48 -0700
From: Vijay Devarapalli <[email-masked]>
To: Sri Gundavelli <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hello Sri, Raj,

On 6/26/09 9:32 AM, "Sri Gundavelli" wrote:

> This is a very well defined problem. Other than the negotiation
> aspect, 5213 already allows local routing. I dont believe PS
> draft will add lot of value. Going directly to solution spec will
> be better, IMO.

RFC 5213 only talks about route optimizations for two mobile nodes attached
to the same MAG. 

draft-liebsch-netext-pmip6-ro-ps-00.txt is looking at more scenarios. It
talks about tunneling the packets directly between two MAGs, when the MN and
the CN (also an MN) are attached two different MAGs.

Raj, I guess we need to decided as a WG, whether we should work on the
simple localized routing scenario where both the MN and the CN are attached
to the same MAG or look at the other scenarios involving multiple MAGs and
LMAs. If it is the former, then I guess we don't need a problem statement
draft.

Vijay

> 
> Sri
> 
> On Fri, 26 Jun 2009, [email-masked] wrote:
> 
>> 
>> Hello,
>> 
>> One of the extensions to PMIP6 that NetExt will be working on is localized
>> routing. As per the charter:
>> 
>> " Localized Routing: a specification for routing traffic between the
>> MAG(s) without involving the LMA. That is, allow the MAGs to route
>> traffic between hosts from one MAG to another, without being tunneled
>> all the way to the LMA. This reduces latency and backhaul load.
>> Applications such as voice can benefit from the reduced latency."
>> 
>> At IETF74, we discussed the problem statement as per I-D:
>> draft-liebsch-netext-pmip6-ro-ps-00.txt
>> 
>> In order to ensure that we have clear scope and boundaries around the
>> localized routing extension, should we make the PS I-D a WG document before
>> proceeding to work on the solutions? At the present time there are several
>> I-Ds proposing solutions to localized routing. Agreeing on what needs to be
>> solved first would make the solution work better structured.
>> The other option is to capture the problem statement in a section of the
>> solution I-D itself. It is possible if the WG feels that the scope and the
>> feature is clear.
>> 
>> Thoughts?
>> 
>> -Basavaraj
>> 
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Fri Jun 26 11:45:03 2009
Date: Fri, 26 Jun 2009 11:44:00 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi Vijay,

On Fri, 26 Jun 2009, Vijay Devarapalli wrote:

> Hello Sri, Raj,
>
> On 6/26/09 9:32 AM, "Sri Gundavelli" wrote:
>
>> This is a very well defined problem. Other than the negotiation
>> aspect, 5213 already allows local routing. I dont believe PS
>> draft will add lot of value. Going directly to solution spec will
>> be better, IMO.
>
> RFC 5213 only talks about route optimizations for two mobile nodes attached
> to the same MAG.
>

Sure. We dont support RO, its only localized routing within a
given MAG scope.

> draft-liebsch-netext-pmip6-ro-ps-00.txt is looking at more scenarios. It
> talks about tunneling the packets directly between two MAGs, when the MN and
> the CN (also an MN) are attached two different MAGs.
>
> Raj, I guess we need to decided as a WG, whether we should work on the
> simple localized routing scenario where both the MN and the CN are attached
> to the same MAG or look at the other scenarios involving multiple MAGs and
> LMAs. If it is the former, then I guess we don't need a problem statement
> draft.

I some how looked at RO and localized routing as two different problems.
I agree with this approach, if its about a basic localized routing, which
I assumed was the context of the discussion, going with a solution draft
is fine. If its for complete RO, may be a PS draft might help.

But, in general these PS drafts just add to the delay with no real
value, from my observation. But, if the scope is umlimited and if we
want to set the bounds, we can start with PS draft, spend a year or two
on it and move to the solution draft.

Sri

From [email-masked]  Fri Jun 26 12:49:44 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Fri, 26 Jun 2009 21:49:54 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi Sri/Vijay,

On 6/26/09 1:44 PM, "Sri Gundavelli" <[email-masked]> wrote:

> Hi Vijay,
>=20
>=20
> On Fri, 26 Jun 2009, Vijay Devarapalli wrote:
>=20
>> Hello Sri, Raj,
>>=20
>> On 6/26/09 9:32 AM, "Sri Gundavelli" wrote:
>>=20
>>> This is a very well defined problem. Other than the negotiation
>>> aspect, 5213 already allows local routing. I dont believe PS
>>> draft will add lot of value. Going directly to solution spec will
>>> be better, IMO.
>>=20
>> RFC 5213 only talks about route optimizations for two mobile nodes attac=
hed
>> to the same MAG.
>>=20
>=20
> Sure. We dont support RO, its only localized routing within a
> given MAG scope.

As we discussed at the BoF meeting (IETF74), we are not considering RO from
the classical MIP6 perspective.
We are only looking at localized routing.

>=20
>> draft-liebsch-netext-pmip6-ro-ps-00.txt is looking at more scenarios. It
>> talks about tunneling the packets directly between two MAGs, when the MN=
 and
>> the CN (also an MN) are attached two different MAGs.

Right.. This is the additional aspect to localized routing (LR) that is
captured in the PS I-D. Scope of LR is limited to a single PMIP6 domain.

>>=20
>> Raj, I guess we need to decided as a WG, whether we should work on the
>> simple localized routing scenario where both the MN and the CN are attac=
hed
>> to the same MAG or look at the other scenarios involving multiple MAGs a=
nd
>> LMAs. If it is the former, then I guess we don't need a problem statemen=
t
>> draft.

We need to work on both scenarios. That has been the intent.

>=20
> I some how looked at RO and localized routing as two different problems.

Well, as I said above, we are not considering RO at all (at least not from
what RO means in RFC3775).

> I agree with this approach, if its about a basic localized routing, which
> I assumed was the context of the discussion, going with a solution draft
> is fine. If its for complete RO, may be a PS draft might help.

It is about localized routing only. But it encompasses more scenarios than
the one that is covered in RFC5213.

>=20
> But, in general these PS drafts just add to the delay with no real
> value, from my observation. But, if the scope is umlimited and if we
> want to set the bounds, we can start with PS draft, spend a year or two
> on it and move to the solution draft.

Of course the scope is unlimited... What else would you expect? :)

No.. Seriously, the whole point of having a PS I-D that we all agree on is
to get everyone on the same page and constrain the boundaries of the
solution. I do not imagine spending significant time on this. By this I mea=
n
we will not be discussing PS beyond IETF75. The milestone as per the charte=
r
is to have an initial WG I-D on LR by Nov, 09 (IETF76). In fact if we can
agree on the PS scope that was discussed at the BoF, we can simply make tha=
t
a WG doc and move on.

-Raj

>=20
> Sri
>=20
>=20
>=20

From [email-masked]  Fri Jun 26 13:04:57 2009
Content-class: urn:content-classes:message
Date: Fri, 26 Jun 2009 16:03:43 -0400
From: "Koodli, Rajeev" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

No.. Seriously, the whole point of having a PS I-D that we all agree on =
is
to get everyone on the same page and constrain the boundaries of the
solution. I do not imagine spending significant time on this. By this I =
mean
we will not be discussing PS beyond IETF75. The milestone as per the =
charter
is to have an initial WG I-D on LR by Nov, 09 (IETF76). In fact if we =
can
agree on the PS scope that was discussed at the BoF, we can simply make =
that
a WG doc and move on.

Agree with Raj. We are not going to have RO-vs-Local-Routing discussion.
=20
-Rajeev
=20

-Raj

>
> Sri
>
>
>

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

From [email-masked]  Fri Jun 26 13:37:35 2009
Date: Fri, 26 Jun 2009 13:36:23 -0700
From: Vijay Devarapalli <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

I guess there is some confusion wrt terminology.

When I said "route optimization", I was talking about tunneling the packets
directly between two MAGs when the MN and the CN are attached to these two
MAGs. And localized routing meant routing the packets directly between the
MN and the CN when both are attached to the same MAG.

I was not talking about route optimizations between two MAGs in different
PMIPv6 domains.

Vijay

On 6/26/09 12:49 PM, "[email-masked]" wrote:

> 
> Hi Sri/Vijay,
> 
> 
> On 6/26/09 1:44 PM, "Sri Gundavelli" <[email-masked]> wrote:
> 
>> Hi Vijay,
>> 
>> 
>> On Fri, 26 Jun 2009, Vijay Devarapalli wrote:
>> 
>>> Hello Sri, Raj,
>>> 
>>> On 6/26/09 9:32 AM, "Sri Gundavelli" wrote:
>>> 
>>>> This is a very well defined problem. Other than the negotiation
>>>> aspect, 5213 already allows local routing. I dont believe PS
>>>> draft will add lot of value. Going directly to solution spec will
>>>> be better, IMO.
>>> 
>>> RFC 5213 only talks about route optimizations for two mobile nodes attached
>>> to the same MAG.
>>> 
>> 
>> Sure. We dont support RO, its only localized routing within a
>> given MAG scope.
> 
> As we discussed at the BoF meeting (IETF74), we are not considering RO from
> the classical MIP6 perspective.
> We are only looking at localized routing.
> 
>> 
>>> draft-liebsch-netext-pmip6-ro-ps-00.txt is looking at more scenarios. It
>>> talks about tunneling the packets directly between two MAGs, when the MN and
>>> the CN (also an MN) are attached two different MAGs.
> 
> Right.. This is the additional aspect to localized routing (LR) that is
> captured in the PS I-D. Scope of LR is limited to a single PMIP6 domain.
> 
>>> 
>>> Raj, I guess we need to decided as a WG, whether we should work on the
>>> simple localized routing scenario where both the MN and the CN are attached
>>> to the same MAG or look at the other scenarios involving multiple MAGs and
>>> LMAs. If it is the former, then I guess we don't need a problem statement
>>> draft.
> 
> We need to work on both scenarios. That has been the intent.
> 
>> 
>> I some how looked at RO and localized routing as two different problems.
> 
> Well, as I said above, we are not considering RO at all (at least not from
> what RO means in RFC3775).
> 
>> I agree with this approach, if its about a basic localized routing, which
>> I assumed was the context of the discussion, going with a solution draft
>> is fine. If its for complete RO, may be a PS draft might help.
> 
> It is about localized routing only. But it encompasses more scenarios than
> the one that is covered in RFC5213.
> 
>> 
>> But, in general these PS drafts just add to the delay with no real
>> value, from my observation. But, if the scope is umlimited and if we
>> want to set the bounds, we can start with PS draft, spend a year or two
>> on it and move to the solution draft.
> 
> Of course the scope is unlimited... What else would you expect? :)
> 
> No.. Seriously, the whole point of having a PS I-D that we all agree on is
> to get everyone on the same page and constrain the boundaries of the
> solution. I do not imagine spending significant time on this. By this I mean
> we will not be discussing PS beyond IETF75. The milestone as per the charter
> is to have an initial WG I-D on LR by Nov, 09 (IETF76). In fact if we can
> agree on the PS scope that was discussed at the BoF, we can simply make that
> a WG doc and move on.
> 
> -Raj
> 
>> 
>> Sri
>> 
>> 
>> 
> 

From [email-masked]  Fri Jun 26 14:22:12 2009
Date: Fri, 26 Jun 2009 14:22:30 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi Raj,

>>
>> But, in general these PS drafts just add to the delay with no real
>> value, from my observation. But, if the scope is umlimited and if we
>> want to set the bounds, we can start with PS draft, spend a year or two
>> on it and move to the solution draft.
>
> Of course the scope is unlimited... What else would you expect? :)
>
> No.. Seriously, the whole point of having a PS I-D that we all agree on is
> to get everyone on the same page and constrain the boundaries of the
> solution. I do not imagine spending significant time on this. By this I mean
> we will not be discussing PS beyond IETF75. The milestone as per the charter
> is to have an initial WG I-D on LR by Nov, 09 (IETF76). In fact if we can
> agree on the PS scope that was discussed at the BoF, we can simply make that
> a WG doc and move on.
>

Ok. That makes sense.

Regards
Sri

From [email-masked]  Fri Jun 26 18:31:40 2009
Date: Sat, 27 Jun 2009 09:31:45 +0800
From: Qin Wu <[email-masked]>
To: Vijay Devarapalli <[email-masked]>, Sri Gundavelli <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

I agree with Vijay for his opinion. 
Actually local routing described in the RFC5213,i.e., intra-MAG local routing is 
quite limited scenario, also does not support negotiation aspect.
And the boundaries around the localized routing extension cover but not limited to the
 local routing described in the RFC5213, from this aspect, it seems reasonable to have
WG draft if we agree on the PS scope and scenarios described in draft-liebsch-netext-pmip6-ro-ps-00
that is discussed in the IETF 74 meeting.
Also there are some further discussion on IPv4 aspect in relation to localized routing in the maillist. Personally, 
IPv4 aspect is a important feature for localized routing  for there is a long transition period to see IP versions coexistence 
and wait for fully widely deployment of IPv6. I would like request WG to take a look at this input of localized routing extension.

Regards!
-Qin

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, June 27, 2009 2:31 AM
Subject: Re: [netext] WG view about problem statement I-D for localized routing

> Hello Sri, Raj,
> 
> On 6/26/09 9:32 AM, "Sri Gundavelli" wrote:
> 
>> This is a very well defined problem. Other than the negotiation
>> aspect, 5213 already allows local routing. I dont believe PS
>> draft will add lot of value. Going directly to solution spec will
>> be better, IMO.
> 
> RFC 5213 only talks about route optimizations for two mobile nodes attached
> to the same MAG. 
> 
> draft-liebsch-netext-pmip6-ro-ps-00.txt is looking at more scenarios. It
> talks about tunneling the packets directly between two MAGs, when the MN and
> the CN (also an MN) are attached two different MAGs.
> 
> Raj, I guess we need to decided as a WG, whether we should work on the
> simple localized routing scenario where both the MN and the CN are attached
> to the same MAG or look at the other scenarios involving multiple MAGs and
> LMAs. If it is the former, then I guess we don't need a problem statement
> draft.
> 
> Vijay
> 
>> 
>> Sri
>> 
>> On Fri, 26 Jun 2009, [email-masked] wrote:
>> 
>>> 
>>> Hello,
>>> 
>>> One of the extensions to PMIP6 that NetExt will be working on is localized
>>> routing. As per the charter:
>>> 
>>> " Localized Routing: a specification for routing traffic between the
>>> MAG(s) without involving the LMA. That is, allow the MAGs to route
>>> traffic between hosts from one MAG to another, without being tunneled
>>> all the way to the LMA. This reduces latency and backhaul load.
>>> Applications such as voice can benefit from the reduced latency."
>>> 
>>> At IETF74, we discussed the problem statement as per I-D:
>>> draft-liebsch-netext-pmip6-ro-ps-00.txt
>>> 
>>> In order to ensure that we have clear scope and boundaries around the
>>> localized routing extension, should we make the PS I-D a WG document before
>>> proceeding to work on the solutions? At the present time there are several
>>> I-Ds proposing solutions to localized routing. Agreeing on what needs to be
>>> solved first would make the solution work better structured.
>>> The other option is to capture the problem statement in a section of the
>>> solution I-D itself. It is possible if the WG feels that the scope and the
>>> feature is clear.
>>> 
>>> Thoughts?
>>> 
>>> -Basavaraj
>>> 
>>> _______________________________________________
>>> netext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netext
>>> 
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Fri Jun 26 18:39:32 2009
Date: Sat, 27 Jun 2009 09:39:48 +0800
From: Qin Wu <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>, [email-masked],  [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi,all:
Just for clarification.
If my understanding is correct, 
RO mentioned here is RO within the same PMIP6 domain. This RO is defined in the 
draft-liebsch-netext-pmip6-ro-ps-00 as localized routing.
Local Routing is RO within the same MAG, i.e., MN and CN in communication attach to the same MAG.
This Local routing is defined in the section 6.10.3 of RFC5213.
Compare RO(i.e.,Localized routing) with Local Routing, the only difference is they have different scope and also
Localized routing contain Local routing and can supersede Local routing described in the RFC5213.
What am I  missing?

Regards!
-Qin

----- Original Message ----- 
From: "Koodli, Rajeev" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, June 27, 2009 4:03 AM
Subject: Re: [netext] WG view about problem statement I-D for localized routing

> 
> No.. Seriously, the whole point of having a PS I-D that we all agree on is
> to get everyone on the same page and constrain the boundaries of the
> solution. I do not imagine spending significant time on this. By this I mean
> we will not be discussing PS beyond IETF75. The milestone as per the charter
> is to have an initial WG I-D on LR by Nov, 09 (IETF76). In fact if we can
> agree on the PS scope that was discussed at the BoF, we can simply make that
> a WG doc and move on.
> 
> Agree with Raj. We are not going to have RO-vs-Local-Routing discussion.
> 
> -Rajeev
> 
> 
> -Raj
> 
>>
>> Sri
>>
>>
>>
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Fri Jun 26 19:33:49 2009
Date: Sat, 27 Jun 2009 10:33:54 +0800
From: Qin Wu <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi, Raj and all:
Since Localize routing is constrained within the same PMIP6. It does not mean the roaming can be supported for localized routing.
Two extra scenarios as described in draft-wu-netext-pmipv6-ipv4-ro-ps-01 we still need to take a look at:
Use Case 1: Roaming user MN and non-roaming user CN subscription belong to different Operators
In this case, Roaming user MN moves to the visited network owned by the operator where no-roaming CN is located. MN and CN are under the same PMIP6 domain. However, MN and CN subscription belong to the different operators.

Use Case 2: Both MN and CN are "roaming" and using visited network LMAs
In this case, both MN and CN moves to the same visited network owned by the operator. MN and CN are roaming user and both using visited network LMAs. However MN and CN subscription belong to the different operators.

Any opinions!

Regard!
Qin

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 27, 2009 12:20 AM
Subject: [netext] WG view about problem statement I-D for localized routing

> 
> Hello,
> 
> One of the extensions to PMIP6 that NetExt will be working on is localized
> routing. As per the charter:
> 
> " Localized Routing: a specification for routing traffic between the
> MAG(s) without involving the LMA. That is, allow the MAGs to route
> traffic between hosts from one MAG to another, without being tunneled
> all the way to the LMA. This reduces latency and backhaul load.
> Applications such as voice can benefit from the reduced latency."
> 
> At IETF74, we discussed the problem statement as per I-D:
> draft-liebsch-netext-pmip6-ro-ps-00.txt
> 
> In order to ensure that we have clear scope and boundaries around the
> localized routing extension, should we make the PS I-D a WG document before
> proceeding to work on the solutions? At the present time there are several
> I-Ds proposing solutions to localized routing. Agreeing on what needs to be
> solved first would make the solution work better structured.
> The other option is to capture the problem statement in a section of the
> solution I-D itself. It is possible if the WG feels that the scope and the
> feature is clear.
> 
> Thoughts?
> 
> -Basavaraj
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Sat Jun 27 01:44:55 2009
Date: Sat, 27 Jun 2009 16:45:08 +0800
From: Xiangsong Cui <[email-masked]>
To: Sri Gundavelli <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [netext] Solicitations for agenda items

Hi Sri,

I just read the draft 
draft-gundavelli-netext-pmipv6-retransmit-option-00.txt
I have a question about it.

The draft says:
----------------------------------------
1.  Introduction

   The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the
   ability for the sender of a signaling message to mark retransmitted
   messages with a proper tag, so the receiver can differentiate between
   the original message to a retransmitted message.  This semantic is
   important for the receiver to determine when to ignore processing a
   retransmitted packet, or for various other reasons.
---------------------------------------------

Is the motive is just to distinguish the original and retransmitted PBU?

I ask this question just because I think it is unnecessary. The reason is:

1, section 6.1.7 [RFC3775] shows there is a "Sequence #" field in BU 
message, and
   section 11.8 [RFC3775] says:
   --------------------------------------------------------
      Retransmitted Binding Updates MUST use a Sequence Number value
   greater than that used for the previous transmission of this Binding
   Update.
   ----------------------------------------------------
   So the BU messages are different for their sequence number.

2,  section 6.6 [RFC5213] says:
     -----------------------------------------
     6.6.  Acquiring Mobile Node's Identifier

   All the network entities in a Proxy Mobile IPv6 domain MUST be able
   to identify a mobile node, using its MN-Identifier.  This identifier
   MUST be stable and unique across the Proxy Mobile IPv6 domain.  The
   mobility entities in the Proxy Mobile IPv6 domain MUST be able to use
   this identifier in the signaling messages and unambiguously identify
   a given mobile node.  The following are some of the considerations
   related to this MN-Identifier.
   -------------------------------------------
   In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID.
   PBU message format also shows there is a sequence # field in PBU
   message and "Mobile Node Identifier option" is valid.

3, section 6.9.4 [RFC5213] has specified the rule for Retransmissions and 
Rate Limiting.

For these reasons, I believe the LMA can recognize the duplicate PBUs.
The LMA has been capable of making binding for the first PBU and ignore 
other PBUs
for the same mobile node.

Do I make any mistakes? and why we need a new extension?

Thanks and regards

Xiangsong

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 23, 2009 11:55 PM
Subject: Re: [netext] Solicitations for agenda items

>
> Hi Raj:
>
> I'd to request 10 min presentation slot for each of the following
> two items.
>
> Mobile Node Group Identifier Option:
> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01
>
> Retransmit Message Identifier Option:
> http://www.ietf.org/internet-drafts/draft-gundavelli-netext-pmipv6-retransmit-option-00.txt
>
> Regards
> Sri
>
>
>
>
>
> On Tue, 23 Jun 2009, [email-masked] wrote:
>
>>
>> Hello,
>>
>> The NetExt WG will meet at IETF75.
>> Please submit any requests for a slot on the agenda.
>>
>> Note that we will consider I-Ds that pertain to the scope of the charter.
>> Additionally please ensure that you have an accompanying I-D when you
>> request a slot.
>>
>> -Chairs
>>
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext 

From [email-masked]  Sat Jun 27 09:10:16 2009
Date: Sat, 27 Jun 2009 18:10:11 +0200
From: Marco Liebsch <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi Sri, all,

please see inline.

Sri Gundavelli schrieb:
> Hi Vijay,
>
>
> On Fri, 26 Jun 2009, Vijay Devarapalli wrote:
>
>> Hello Sri, Raj,
>>
>> On 6/26/09 9:32 AM, "Sri Gundavelli" wrote:
>>
>>> This is a very well defined problem. Other than the negotiation
>>> aspect, 5213 already allows local routing. I dont believe PS
>>> draft will add lot of value. Going directly to solution spec will
>>> be better, IMO.
>>
>> RFC 5213 only talks about route optimizations for two mobile nodes 
>> attached
>> to the same MAG.
>>
>
> Sure. We dont support RO, its only localized routing within a
> given MAG scope.
>
>> draft-liebsch-netext-pmip6-ro-ps-00.txt is looking at more scenarios. It
>> talks about tunneling the packets directly between two MAGs, when the 
>> MN and
>> the CN (also an MN) are attached two different MAGs.
>>
>> Raj, I guess we need to decided as a WG, whether we should work on the
>> simple localized routing scenario where both the MN and the CN are 
>> attached
>> to the same MAG or look at the other scenarios involving multiple 
>> MAGs and
>> LMAs. If it is the former, then I guess we don't need a problem 
>> statement
>> draft.
>
> I some how looked at RO and localized routing as two different problems.
> I agree with this approach, if its about a basic localized routing, which
> I assumed was the context of the discussion, going with a solution draft
> is fine. If its for complete RO, may be a PS draft might help.
The current individual PS draft specifies use cases taking the scope of
NetExt into account, which includes setting up an optimized forwarding 
path between MAGs.
I personally prefer the term route optimization, which is also the term 
being used
in this context in the charter description. However, the chater mixes 
both terms, which
should be ok if there is common understanding in that localized routing 
means 'local in the
access of a PMIP domain', not 'local on a single MAG'.

>
> But, in general these PS drafts just add to the delay with no real
> value, from my observation. But, if the scope is umlimited and if we
> want to set the bounds, we can start with PS draft, spend a year or two
> on it and move to the solution draft.
True, a PS may add delay and mentioning the problem in the solution 
document can help
to avoid such delay. However, looks like the current PS, which has been 
taken for the discussion
in the NetExt BOF, seems to meet the WG's understanding well. The 
additional items for a revision, which we
addressed on the list, need a bit more discussion, in particular the 
problem of NATs in IPv4 support.
As the solution must take at least some of these issues into account, we 
need to go through this
discussion anyway. The resulting problem description may be larger than 
what we'd like to have
in the solution document. As there is a document already, it should be 
little effort to get a
separate PS document towards a complete and stable version. But it's up 
to the WG if we
want to have this.

marco

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

From [email-masked]  Sun Jun 28 11:15:57 2009
Date: Sun, 28 Jun 2009 20:16:11 +0200
From: marcelo bagnulo braun <[email-masked]>
To: [email-masked], mext <[email-masked]>, [email-masked]
Cc: "Soininen Jonne \(NSN FI/Espoo\)" <[email-masked]>, [email-masked], Ralph Droms <[email-masked]>
Subject: [netext] NEXTEXT2: first draft of the bof description

Hi,

This is a first draft of the BOF description for your consideration. It 
is still very open so, feel free to comment on whether the proposed 
approach seems appropriate or not.

NETEXT2 BOF description
-----------------------

Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
IP hosts without requiring any protocol enhancements or additional
capabilities on the host.
Current PMIP6 specification fully defines how to provide mobility
support for mobile nodes with a single interface roaming in a PMIP6
domain. The goal of this BOF is gain understanding of how to support
nodes with multiple interfaces (of possible different technologies) in a
PMIP6 network.

In particular, this BOF assumes the following scenario:
We have a single PMIP6 domain that has deployed multiple
access technologies and needs to support nodes that have
multiple interfaces, possibly of different technologies.

In particular, the following capabilities are needed:

- Inter-technology handover support. The MN has initiated a
communication over one interface and it needs to be able to move
the established connection to a different interface of
a possibly different technology. The reason for moving
the communication to another interface is because of the MNs
mobility and attaching via a different interface. Basically
the ability to perform handovers that span different access
technologies.

- Multihoming support. The MN with multiple interfaces of possibly
different technologies should be able to use them simultaneously to
exchange data and manage the mobility of communications
established through the different interfaces.

- Flow mobility. A MN with multiple interfaces of possibly
different technologies must be able to move a flow from
one interface to another. Moreover, the MN should be able
to inform the network through which interface it wishes
to receive different types of flows.

In order to provide the support for these capabilities, different
approaches can be envisioned, namely:
- L2 only approaches. In this type of approaches, the mechanisms
to provide the required capabilities are fully L2 mechanisms and
no modification of the IP layer is needed.
- L3 only approaches. In this type of approaches, the mechanism to
provide to required capabilities are located in the IP layer
- Hybrid L2/L3 approaches. In this case, some mechanisms are
located in L2 and other mechanisms are located in L3.
Now, the different possible approaches vary greatly in their nature
and resulting capabilities. To understanding the benefits and
suitability of these alternatives, the requirements have to be
properly defined and understood.

The main goal of the BOF is understanding the need for work in the
IETF in this area. In order to do so, during the BOF, we will attempt to:

1) Understand the applicable scenarios, and the problem statement related to
those
2) Understand the restrictions and requirement imposed to solutions to
address the problem statement and scenarios
3) Get an overview of the proposed solutions

From [email-masked]  Sun Jun 28 18:26:43 2009
Date: Mon, 29 Jun 2009 09:27:01 +0800
From: Xiangsong Cui <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>, [email-masked], mext <[email-masked]>, [email-masked]
Cc: "Soininen Jonne \(NSN FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [netext] [MEXT] NEXTEXT2: first draft of the bof description

Hi Marcelo,

I have a comment about the description.

> - Inter-technology handover support. The MN has initiated a
> communication over one interface and it needs to be able to move
> the established connection to a different interface of
                          ^^^^^^^^^
> a possibly different technology.

I think "move the established communication" is better than "move the 
established connection".
Because all the connections exist at the time if they have been established. 
What we move
is the session or traffic flow, but not the connection.  For example, there 
is a word from
draft-ietf-mext-flow-binding-01.txt:

 "A single connection is
   typically identified by the source and destination IP addresses,
   transport protocol number and the source and destination port
   numbers. " (This sentence is modified in 02txt, but I think it is right.)

Regards

Xiangsong

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
Cc: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>; "Jari Arkko" 
<[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 2:16 AM
Subject: [MEXT] NEXTEXT2: first draft of the bof description

> Hi,
>
> This is a first draft of the BOF description for your consideration. It is 
> still very open so, feel free to comment on whether the proposed approach 
> seems appropriate or not.
>
> NETEXT2 BOF description
> -----------------------
>
> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
> IP hosts without requiring any protocol enhancements or additional
> capabilities on the host.
> Current PMIP6 specification fully defines how to provide mobility
> support for mobile nodes with a single interface roaming in a PMIP6
> domain. The goal of this BOF is gain understanding of how to support
> nodes with multiple interfaces (of possible different technologies) in a
> PMIP6 network.
>
> In particular, this BOF assumes the following scenario:
> We have a single PMIP6 domain that has deployed multiple
> access technologies and needs to support nodes that have
> multiple interfaces, possibly of different technologies.
>
> In particular, the following capabilities are needed:
>
> - Inter-technology handover support. The MN has initiated a
> communication over one interface and it needs to be able to move
> the established connection to a different interface of
> a possibly different technology. The reason for moving
> the communication to another interface is because of the MNs
> mobility and attaching via a different interface. Basically
> the ability to perform handovers that span different access
> technologies.
>
> - Multihoming support. The MN with multiple interfaces of possibly
> different technologies should be able to use them simultaneously to
> exchange data and manage the mobility of communications
> established through the different interfaces.
>
> - Flow mobility. A MN with multiple interfaces of possibly
> different technologies must be able to move a flow from
> one interface to another. Moreover, the MN should be able
> to inform the network through which interface it wishes
> to receive different types of flows.
>
> In order to provide the support for these capabilities, different
> approaches can be envisioned, namely:
> - L2 only approaches. In this type of approaches, the mechanisms
> to provide the required capabilities are fully L2 mechanisms and
> no modification of the IP layer is needed.
> - L3 only approaches. In this type of approaches, the mechanism to
> provide to required capabilities are located in the IP layer
> - Hybrid L2/L3 approaches. In this case, some mechanisms are
> located in L2 and other mechanisms are located in L3.
> Now, the different possible approaches vary greatly in their nature
> and resulting capabilities. To understanding the benefits and
> suitability of these alternatives, the requirements have to be
> properly defined and understood.
>
> The main goal of the BOF is understanding the need for work in the
> IETF in this area. In order to do so, during the BOF, we will attempt to:
>
> 1) Understand the applicable scenarios, and the problem statement related 
> to
> those
> 2) Understand the restrictions and requirement imposed to solutions to
> address the problem statement and scenarios
> 3) Get an overview of the proposed solutions
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext 

From [email-masked]  Sun Jun 28 23:41:53 2009
Date: Mon, 29 Jun 2009 08:42:07 +0200
From: marcelo bagnulo braun <[email-masked]>
To: Xiangsong Cui <[email-masked]>
Cc: [email-masked], mext <[email-masked]>, [email-masked], "Soininen Jonne \(NSN FI/Espoo\)" <[email-masked]>, [email-masked]
Subject: Re: [netext] [MEXT] NEXTEXT2: first draft of the bof description

Xiangsong Cui escribi�:
> Hi Marcelo,
>
> I have a comment about the description.
>
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>                          ^^^^^^^^^
>> a possibly different technology.
>
> I think "move the established communication" is better than "move the 
> established connection".
agree

regards, marcelo

> Because all the connections exist at the time if they have been 
> established. What we move
> is the session or traffic flow, but not the connection.  For example, 
> there is a word from
> draft-ietf-mext-flow-binding-01.txt:
>
> "A single connection is
>   typically identified by the source and destination IP addresses,
>   transport protocol number and the source and destination port
>   numbers. " (This sentence is modified in 02txt, but I think it is 
> right.)
>
>
> Regards
>
> Xiangsong
>
>
>
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>
> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> Cc: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>; "Jari 
> Arkko" <[email-masked]>; <[email-masked]>
> Sent: Monday, June 29, 2009 2:16 AM
> Subject: [MEXT] NEXTEXT2: first draft of the bof description
>
>
>> Hi,
>>
>> This is a first draft of the BOF description for your consideration. 
>> It is still very open so, feel free to comment on whether the 
>> proposed approach seems appropriate or not.
>>
>> NETEXT2 BOF description
>> -----------------------
>>
>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>> IP hosts without requiring any protocol enhancements or additional
>> capabilities on the host.
>> Current PMIP6 specification fully defines how to provide mobility
>> support for mobile nodes with a single interface roaming in a PMIP6
>> domain. The goal of this BOF is gain understanding of how to support
>> nodes with multiple interfaces (of possible different technologies) in a
>> PMIP6 network.
>>
>> In particular, this BOF assumes the following scenario:
>> We have a single PMIP6 domain that has deployed multiple
>> access technologies and needs to support nodes that have
>> multiple interfaces, possibly of different technologies.
>>
>> In particular, the following capabilities are needed:
>>
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>> a possibly different technology. The reason for moving
>> the communication to another interface is because of the MNs
>> mobility and attaching via a different interface. Basically
>> the ability to perform handovers that span different access
>> technologies.
>>
>> - Multihoming support. The MN with multiple interfaces of possibly
>> different technologies should be able to use them simultaneously to
>> exchange data and manage the mobility of communications
>> established through the different interfaces.
>>
>> - Flow mobility. A MN with multiple interfaces of possibly
>> different technologies must be able to move a flow from
>> one interface to another. Moreover, the MN should be able
>> to inform the network through which interface it wishes
>> to receive different types of flows.
>>
>> In order to provide the support for these capabilities, different
>> approaches can be envisioned, namely:
>> - L2 only approaches. In this type of approaches, the mechanisms
>> to provide the required capabilities are fully L2 mechanisms and
>> no modification of the IP layer is needed.
>> - L3 only approaches. In this type of approaches, the mechanism to
>> provide to required capabilities are located in the IP layer
>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>> located in L2 and other mechanisms are located in L3.
>> Now, the different possible approaches vary greatly in their nature
>> and resulting capabilities. To understanding the benefits and
>> suitability of these alternatives, the requirements have to be
>> properly defined and understood.
>>
>> The main goal of the BOF is understanding the need for work in the
>> IETF in this area. In order to do so, during the BOF, we will attempt 
>> to:
>>
>> 1) Understand the applicable scenarios, and the problem statement 
>> related to
>> those
>> 2) Understand the restrictions and requirement imposed to solutions to
>> address the problem statement and scenarios
>> 3) Get an overview of the proposed solutions
>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext 
>
>

From [email-masked]  Mon Jun 29 09:17:15 2009
Date: Mon, 29 Jun 2009 11:16:42 -0500
From: Frank Xia <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>, [email-masked], mext <[email-masked]>, [email-masked]
Cc: [email-masked], Ralph Droms <[email-masked]>
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Hi Guys

I have comments on inter-technology handover.

IMHO, flow mobility could solve problems
which inter-tech handover is try to deal with.
I assume that two heterogeneous interfaces are
all active during the handover.  It is easy to move
a flow(or all flows) from an interface to another.

This is probably the reason why there is no
inter-tech handover solution standerdized
for client MIP.

BR
Frank

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
Sent: Sunday, June 28, 2009 1:16 PM
Subject: [netlmm] NEXTEXT2: first draft of the bof description

> Hi,
>
> This is a first draft of the BOF description for your consideration. It is 
> still very open so, feel free to comment on whether the proposed approach 
> seems appropriate or not.
>
> NETEXT2 BOF description
> -----------------------
>
> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
> IP hosts without requiring any protocol enhancements or additional
> capabilities on the host.
> Current PMIP6 specification fully defines how to provide mobility
> support for mobile nodes with a single interface roaming in a PMIP6
> domain. The goal of this BOF is gain understanding of how to support
> nodes with multiple interfaces (of possible different technologies) in a
> PMIP6 network.
>
> In particular, this BOF assumes the following scenario:
> We have a single PMIP6 domain that has deployed multiple
> access technologies and needs to support nodes that have
> multiple interfaces, possibly of different technologies.
>
> In particular, the following capabilities are needed:
>
> - Inter-technology handover support. The MN has initiated a
> communication over one interface and it needs to be able to move
> the established connection to a different interface of
> a possibly different technology. The reason for moving
> the communication to another interface is because of the MNs
> mobility and attaching via a different interface. Basically
> the ability to perform handovers that span different access
> technologies.
>
> - Multihoming support. The MN with multiple interfaces of possibly
> different technologies should be able to use them simultaneously to
> exchange data and manage the mobility of communications
> established through the different interfaces.
>
> - Flow mobility. A MN with multiple interfaces of possibly
> different technologies must be able to move a flow from
> one interface to another. Moreover, the MN should be able
> to inform the network through which interface it wishes
> to receive different types of flows.
>
> In order to provide the support for these capabilities, different
> approaches can be envisioned, namely:
> - L2 only approaches. In this type of approaches, the mechanisms
> to provide the required capabilities are fully L2 mechanisms and
> no modification of the IP layer is needed.
> - L3 only approaches. In this type of approaches, the mechanism to
> provide to required capabilities are located in the IP layer
> - Hybrid L2/L3 approaches. In this case, some mechanisms are
> located in L2 and other mechanisms are located in L3.
> Now, the different possible approaches vary greatly in their nature
> and resulting capabilities. To understanding the benefits and
> suitability of these alternatives, the requirements have to be
> properly defined and understood.
>
> The main goal of the BOF is understanding the need for work in the
> IETF in this area. In order to do so, during the BOF, we will attempt to:
>
> 1) Understand the applicable scenarios, and the problem statement related 
> to
> those
> 2) Understand the restrictions and requirement imposed to solutions to
> address the problem statement and scenarios
> 3) Get an overview of the proposed solutions
>
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm 

From [email-masked]  Mon Jun 29 09:47:51 2009
Date: Mon, 29 Jun 2009 17:48:09 +0100
From: George Tsirtsis <[email-masked]>
To: Frank Xia <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], mext <[email-masked]>
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof description

Frank, your comment below is strange to say the least.

MIP handoffs can be between interfaces of the same or different
technologies. Since client MIP works at the IP layer (above the Link
Layer of any specific technology) there is nothing that client MIP
(and any of its features) need to specifically define for
inter-technology handoffs.

  >Did you so far think that this means that client MIP only works
intra-technology?<

For PMIP, this is an issue because currently there is no defined
protocol (on any layer) between MN and MAG...which is one of the
issues to be discussed in netext2 bof.

George

On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia<[email-masked]> wrote:
> Hi Guys
>
> I have comments on inter-technology handover.
>
> IMHO, flow mobility could solve problems
> which inter-tech handover is try to deal with.
> I assume that two heterogeneous interfaces are
> all active during the handover. =C2=A0It is easy to move
> a flow(or all flows) from an interface to another.
>
> This is probably the reason why there is no
> inter-tech handover solution standerdized
> for client MIP.
>
> BR
> Frank
>
> ----- Original Message ----- From: "marcelo bagnulo braun"
> <[email-masked]>
> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
> Sent: Sunday, June 28, 2009 1:16 PM
> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>
>
>> Hi,
>>
>> This is a first draft of the BOF description for your consideration. It =
is
>> still very open so, feel free to comment on whether the proposed approac=
h
>> seems appropriate or not.
>>
>> NETEXT2 BOF description
>> -----------------------
>>
>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>> IP hosts without requiring any protocol enhancements or additional
>> capabilities on the host.
>> Current PMIP6 specification fully defines how to provide mobility
>> support for mobile nodes with a single interface roaming in a PMIP6
>> domain. The goal of this BOF is gain understanding of how to support
>> nodes with multiple interfaces (of possible different technologies) in a
>> PMIP6 network.
>>
>> In particular, this BOF assumes the following scenario:
>> We have a single PMIP6 domain that has deployed multiple
>> access technologies and needs to support nodes that have
>> multiple interfaces, possibly of different technologies.
>>
>> In particular, the following capabilities are needed:
>>
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>> a possibly different technology. The reason for moving
>> the communication to another interface is because of the MNs
>> mobility and attaching via a different interface. Basically
>> the ability to perform handovers that span different access
>> technologies.
>>
>> - Multihoming support. The MN with multiple interfaces of possibly
>> different technologies should be able to use them simultaneously to
>> exchange data and manage the mobility of communications
>> established through the different interfaces.
>>
>> - Flow mobility. A MN with multiple interfaces of possibly
>> different technologies must be able to move a flow from
>> one interface to another. Moreover, the MN should be able
>> to inform the network through which interface it wishes
>> to receive different types of flows.
>>
>> In order to provide the support for these capabilities, different
>> approaches can be envisioned, namely:
>> - L2 only approaches. In this type of approaches, the mechanisms
>> to provide the required capabilities are fully L2 mechanisms and
>> no modification of the IP layer is needed.
>> - L3 only approaches. In this type of approaches, the mechanism to
>> provide to required capabilities are located in the IP layer
>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>> located in L2 and other mechanisms are located in L3.
>> Now, the different possible approaches vary greatly in their nature
>> and resulting capabilities. To understanding the benefits and
>> suitability of these alternatives, the requirements have to be
>> properly defined and understood.
>>
>> The main goal of the BOF is understanding the need for work in the
>> IETF in this area. In order to do so, during the BOF, we will attempt to=
:
>>
>> 1) Understand the applicable scenarios, and the problem statement relate=
d
>> to
>> those
>> 2) Understand the restrictions and requirement imposed to solutions to
>> address the problem statement and scenarios
>> 3) Get an overview of the proposed solutions
>>
>>
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

From [email-masked]  Mon Jun 29 09:50:09 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 29 Jun 2009 18:50:02 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Frank,

On 6/29/09 11:16 AM, "ext Frank Xia" <[email-masked]> wrote:

> Hi Guys
>=20
> I have comments on inter-technology handover.
>=20
> IMHO, flow mobility could solve problems
> which inter-tech handover is try to deal with.

Flow mobility also includes the ability to move a flow from one mobility
session to another. Multiple mobility sessions could be established via a
single interface in which case flow mobility would be achieved within the
scope of a single interface. Hence flow mobility and inter-technology
handovers are separate features.

> I assume that two heterogeneous interfaces are
> all active during the handover.  It is easy to move
> a flow(or all flows) from an interface to another.

Possibly.. But the point is to identify what extensions (possibly to the MN=
)
are needed in order to achieve handovers across interfaces.

>=20
> This is probably the reason why there is no
> inter-tech handover solution standerdized
> for client MIP.

Client MIP inherently supports handovers across multiple interfaces.
Performance improvements to the handovers are accomplished using solutions
such as FMIP.

-Raj

>=20
> BR
> Frank
>=20
> ----- Original Message -----
> From: "marcelo bagnulo braun" <[email-masked]>
> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
> Sent: Sunday, June 28, 2009 1:16 PM
> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>=20
>=20
>> Hi,
>>=20
>> This is a first draft of the BOF description for your consideration. It =
is
>> still very open so, feel free to comment on whether the proposed approac=
h
>> seems appropriate or not.
>>=20
>> NETEXT2 BOF description
>> -----------------------
>>=20
>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>> IP hosts without requiring any protocol enhancements or additional
>> capabilities on the host.
>> Current PMIP6 specification fully defines how to provide mobility
>> support for mobile nodes with a single interface roaming in a PMIP6
>> domain. The goal of this BOF is gain understanding of how to support
>> nodes with multiple interfaces (of possible different technologies) in a
>> PMIP6 network.
>>=20
>> In particular, this BOF assumes the following scenario:
>> We have a single PMIP6 domain that has deployed multiple
>> access technologies and needs to support nodes that have
>> multiple interfaces, possibly of different technologies.
>>=20
>> In particular, the following capabilities are needed:
>>=20
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>> a possibly different technology. The reason for moving
>> the communication to another interface is because of the MNs
>> mobility and attaching via a different interface. Basically
>> the ability to perform handovers that span different access
>> technologies.
>>=20
>> - Multihoming support. The MN with multiple interfaces of possibly
>> different technologies should be able to use them simultaneously to
>> exchange data and manage the mobility of communications
>> established through the different interfaces.
>>=20
>> - Flow mobility. A MN with multiple interfaces of possibly
>> different technologies must be able to move a flow from
>> one interface to another. Moreover, the MN should be able
>> to inform the network through which interface it wishes
>> to receive different types of flows.
>>=20
>> In order to provide the support for these capabilities, different
>> approaches can be envisioned, namely:
>> - L2 only approaches. In this type of approaches, the mechanisms
>> to provide the required capabilities are fully L2 mechanisms and
>> no modification of the IP layer is needed.
>> - L3 only approaches. In this type of approaches, the mechanism to
>> provide to required capabilities are located in the IP layer
>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>> located in L2 and other mechanisms are located in L3.
>> Now, the different possible approaches vary greatly in their nature
>> and resulting capabilities. To understanding the benefits and
>> suitability of these alternatives, the requirements have to be
>> properly defined and understood.
>>=20
>> The main goal of the BOF is understanding the need for work in the
>> IETF in this area. In order to do so, during the BOF, we will attempt to=
:
>>=20
>> 1) Understand the applicable scenarios, and the problem statement relate=
d
>> to
>> those
>> 2) Understand the restrictions and requirement imposed to solutions to
>> address the problem statement and scenarios
>> 3) Get an overview of the proposed solutions
>>=20
>>=20
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>=20

From [email-masked]  Mon Jun 29 10:19:55 2009
Date: Mon, 29 Jun 2009 12:20:00 -0500
From: Frank Xia <[email-masked]>
To: George Tsirtsis <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], mext <[email-masked]>
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof description

Hi Gorge

It seems that  I did not make me clear.

1)Single radio handover.
   MN should disconnect from one BS , and connect
   to a second BS.   MN can't connect to the two BS
   at the same time.  Handover solutions (FMIP/PMIP)
   are needed.

2)Dual radio handover
   MN connects to the two BS'  at the same time.
   Flow mobility is sufficient when move a flow( or  all
   flows)  from  one interface to another.

BR
Frank

----- Original Message ----- 
From: "George Tsirtsis" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>; "mext" 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 11:48 AM
Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description

Frank, your comment below is strange to say the least.

MIP handoffs can be between interfaces of the same or different
technologies. Since client MIP works at the IP layer (above the Link
Layer of any specific technology) there is nothing that client MIP
(and any of its features) need to specifically define for
inter-technology handoffs.

  >Did you so far think that this means that client MIP only works
intra-technology?<

For PMIP, this is an issue because currently there is no defined
protocol (on any layer) between MN and MAG...which is one of the
issues to be discussed in netext2 bof.

George

On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia<[email-masked]> wrote:
> Hi Guys
>
> I have comments on inter-technology handover.
>
> IMHO, flow mobility could solve problems
> which inter-tech handover is try to deal with.
> I assume that two heterogeneous interfaces are
> all active during the handover. It is easy to move
> a flow(or all flows) from an interface to another.
>
> This is probably the reason why there is no
> inter-tech handover solution standerdized
> for client MIP.
>
> BR
> Frank
>
> ----- Original Message ----- From: "marcelo bagnulo braun"
> <[email-masked]>
> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
> Sent: Sunday, June 28, 2009 1:16 PM
> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>
>
>> Hi,
>>
>> This is a first draft of the BOF description for your consideration. It 
>> is
>> still very open so, feel free to comment on whether the proposed approach
>> seems appropriate or not.
>>
>> NETEXT2 BOF description
>> -----------------------
>>
>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>> IP hosts without requiring any protocol enhancements or additional
>> capabilities on the host.
>> Current PMIP6 specification fully defines how to provide mobility
>> support for mobile nodes with a single interface roaming in a PMIP6
>> domain. The goal of this BOF is gain understanding of how to support
>> nodes with multiple interfaces (of possible different technologies) in a
>> PMIP6 network.
>>
>> In particular, this BOF assumes the following scenario:
>> We have a single PMIP6 domain that has deployed multiple
>> access technologies and needs to support nodes that have
>> multiple interfaces, possibly of different technologies.
>>
>> In particular, the following capabilities are needed:
>>
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>> a possibly different technology. The reason for moving
>> the communication to another interface is because of the MNs
>> mobility and attaching via a different interface. Basically
>> the ability to perform handovers that span different access
>> technologies.
>>
>> - Multihoming support. The MN with multiple interfaces of possibly
>> different technologies should be able to use them simultaneously to
>> exchange data and manage the mobility of communications
>> established through the different interfaces.
>>
>> - Flow mobility. A MN with multiple interfaces of possibly
>> different technologies must be able to move a flow from
>> one interface to another. Moreover, the MN should be able
>> to inform the network through which interface it wishes
>> to receive different types of flows.
>>
>> In order to provide the support for these capabilities, different
>> approaches can be envisioned, namely:
>> - L2 only approaches. In this type of approaches, the mechanisms
>> to provide the required capabilities are fully L2 mechanisms and
>> no modification of the IP layer is needed.
>> - L3 only approaches. In this type of approaches, the mechanism to
>> provide to required capabilities are located in the IP layer
>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>> located in L2 and other mechanisms are located in L3.
>> Now, the different possible approaches vary greatly in their nature
>> and resulting capabilities. To understanding the benefits and
>> suitability of these alternatives, the requirements have to be
>> properly defined and understood.
>>
>> The main goal of the BOF is understanding the need for work in the
>> IETF in this area. In order to do so, during the BOF, we will attempt to:
>>
>> 1) Understand the applicable scenarios, and the problem statement related
>> to
>> those
>> 2) Understand the restrictions and requirement imposed to solutions to
>> address the problem statement and scenarios
>> 3) Get an overview of the proposed solutions
>>
>>
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 

From [email-masked]  Mon Jun 29 11:03:38 2009
Content-class: urn:content-classes:message
Date: Mon, 29 Jun 2009 20:03:31 +0200
From: "MELIA TELEMACO" <[email-masked]>
To: "Frank Xia" <[email-masked]>, "George Tsirtsis" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], mext <[email-masked]>
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Frank,

I think you should not mix flow mobility and inter-tech handover. A MN =
might or might now use multiple connections at the same time...

telemaco

-----Message d'origine-----
De=A0: [email-masked] [mailto:[email-masked]] De la =
part de Frank Xia
Envoy=E9=A0: lundi 29 juin 2009 19:20
=C0=A0: George Tsirtsis
Cc=A0: [email-masked]; [email-masked]; [email-masked]; =
mext
Objet=A0: Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof =
description

Hi Gorge

It seems that  I did not make me clear.

1)Single radio handover.
   MN should disconnect from one BS , and connect
   to a second BS.   MN can't connect to the two BS
   at the same time.  Handover solutions (FMIP/PMIP)
   are needed.

2)Dual radio handover
   MN connects to the two BS'  at the same time.
   Flow mobility is sufficient when move a flow( or  all
   flows)  from  one interface to another.

BR
Frank

----- Original Message -----=20
From: "George Tsirtsis" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>; =
"mext"=20
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 11:48 AM
Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof =
description

Frank, your comment below is strange to say the least.

MIP handoffs can be between interfaces of the same or different
technologies. Since client MIP works at the IP layer (above the Link
Layer of any specific technology) there is nothing that client MIP
(and any of its features) need to specifically define for
inter-technology handoffs.

  >Did you so far think that this means that client MIP only works
intra-technology?<

For PMIP, this is an issue because currently there is no defined
protocol (on any layer) between MN and MAG...which is one of the
issues to be discussed in netext2 bof.

George

On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia<[email-masked]> =
wrote:
> Hi Guys
>
> I have comments on inter-technology handover.
>
> IMHO, flow mobility could solve problems
> which inter-tech handover is try to deal with.
> I assume that two heterogeneous interfaces are
> all active during the handover. It is easy to move
> a flow(or all flows) from an interface to another.
>
> This is probably the reason why there is no
> inter-tech handover solution standerdized
> for client MIP.
>
> BR
> Frank
>
> ----- Original Message ----- From: "marcelo bagnulo braun"
> <[email-masked]>
> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
> Sent: Sunday, June 28, 2009 1:16 PM
> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>
>
>> Hi,
>>
>> This is a first draft of the BOF description for your consideration. =
It=20
>> is
>> still very open so, feel free to comment on whether the proposed =
approach
>> seems appropriate or not.
>>
>> NETEXT2 BOF description
>> -----------------------
>>
>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>> IP hosts without requiring any protocol enhancements or additional
>> capabilities on the host.
>> Current PMIP6 specification fully defines how to provide mobility
>> support for mobile nodes with a single interface roaming in a PMIP6
>> domain. The goal of this BOF is gain understanding of how to support
>> nodes with multiple interfaces (of possible different technologies) =
in a
>> PMIP6 network.
>>
>> In particular, this BOF assumes the following scenario:
>> We have a single PMIP6 domain that has deployed multiple
>> access technologies and needs to support nodes that have
>> multiple interfaces, possibly of different technologies.
>>
>> In particular, the following capabilities are needed:
>>
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>> a possibly different technology. The reason for moving
>> the communication to another interface is because of the MNs
>> mobility and attaching via a different interface. Basically
>> the ability to perform handovers that span different access
>> technologies.
>>
>> - Multihoming support. The MN with multiple interfaces of possibly
>> different technologies should be able to use them simultaneously to
>> exchange data and manage the mobility of communications
>> established through the different interfaces.
>>
>> - Flow mobility. A MN with multiple interfaces of possibly
>> different technologies must be able to move a flow from
>> one interface to another. Moreover, the MN should be able
>> to inform the network through which interface it wishes
>> to receive different types of flows.
>>
>> In order to provide the support for these capabilities, different
>> approaches can be envisioned, namely:
>> - L2 only approaches. In this type of approaches, the mechanisms
>> to provide the required capabilities are fully L2 mechanisms and
>> no modification of the IP layer is needed.
>> - L3 only approaches. In this type of approaches, the mechanism to
>> provide to required capabilities are located in the IP layer
>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>> located in L2 and other mechanisms are located in L3.
>> Now, the different possible approaches vary greatly in their nature
>> and resulting capabilities. To understanding the benefits and
>> suitability of these alternatives, the requirements have to be
>> properly defined and understood.
>>
>> The main goal of the BOF is understanding the need for work in the
>> IETF in this area. In order to do so, during the BOF, we will attempt =
to:
>>
>> 1) Understand the applicable scenarios, and the problem statement =
related
>> to
>> those
>> 2) Understand the restrictions and requirement imposed to solutions =
to
>> address the problem statement and scenarios
>> 3) Get an overview of the proposed solutions
>>
>>
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>=20

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

From [email-masked]  Mon Jun 29 12:56:48 2009
Date: Mon, 29 Jun 2009 14:57:00 -0500
From: Frank Xia <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Hi Raj

My main point is make-before-break strategy
is the best way to solve multi-radio handover.

Please see my inline response.

BR
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 11:50 AM
Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description

Frank,

On 6/29/09 11:16 AM, "ext Frank Xia" <[email-masked]> wrote:

> Hi Guys
>
> I have comments on inter-technology handover.
>
> IMHO, flow mobility could solve problems
> which inter-tech handover is try to deal with.

Flow mobility also includes the ability to move a flow from one mobility
session to another. Multiple mobility sessions could be established via a
single interface in which case flow mobility would be achieved within the
scope of a single interface. Hence flow mobility and inter-technology
handovers are separate features.
Frank=>IMHO, inter-technology is trying to move all the traffic on
one interface to another interface.

> I assume that two heterogeneous interfaces are
> all active during the handover.  It is easy to move
> a flow(or all flows) from an interface to another.

Possibly.. But the point is to identify what extensions (possibly to the MN)
are needed in order to achieve handovers across interfaces.
Frank=>If we see inter-tech handover as a subset of flow mobility,
there is one problem left, that is flow mobility.

>
> This is probably the reason why there is no
> inter-tech handover solution standerdized
> for client MIP.

Client MIP inherently supports handovers across multiple interfaces.
Performance improvements to the handovers are accomplished using solutions
such as FMIP.
Frank=>Maybe, I am missing something.  However FMIP  is not applicable
to PAR/NAR collocated scenario.  For example, a mobile node with two
interface connects to the same access router (ASN-GW for WiMAX,
PDN-GW for LTE).   Does FMIP work when mobile node handover from
one technology to another?

-Raj

>
> BR
> Frank
>
> ----- Original Message -----
> From: "marcelo bagnulo braun" <[email-masked]>
> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
> Sent: Sunday, June 28, 2009 1:16 PM
> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>
>
>> Hi,
>>
>> This is a first draft of the BOF description for your consideration. It 
>> is
>> still very open so, feel free to comment on whether the proposed approach
>> seems appropriate or not.
>>
>> NETEXT2 BOF description
>> -----------------------
>>
>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>> IP hosts without requiring any protocol enhancements or additional
>> capabilities on the host.
>> Current PMIP6 specification fully defines how to provide mobility
>> support for mobile nodes with a single interface roaming in a PMIP6
>> domain. The goal of this BOF is gain understanding of how to support
>> nodes with multiple interfaces (of possible different technologies) in a
>> PMIP6 network.
>>
>> In particular, this BOF assumes the following scenario:
>> We have a single PMIP6 domain that has deployed multiple
>> access technologies and needs to support nodes that have
>> multiple interfaces, possibly of different technologies.
>>
>> In particular, the following capabilities are needed:
>>
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>> a possibly different technology. The reason for moving
>> the communication to another interface is because of the MNs
>> mobility and attaching via a different interface. Basically
>> the ability to perform handovers that span different access
>> technologies.
>>
>> - Multihoming support. The MN with multiple interfaces of possibly
>> different technologies should be able to use them simultaneously to
>> exchange data and manage the mobility of communications
>> established through the different interfaces.
>>
>> - Flow mobility. A MN with multiple interfaces of possibly
>> different technologies must be able to move a flow from
>> one interface to another. Moreover, the MN should be able
>> to inform the network through which interface it wishes
>> to receive different types of flows.
>>
>> In order to provide the support for these capabilities, different
>> approaches can be envisioned, namely:
>> - L2 only approaches. In this type of approaches, the mechanisms
>> to provide the required capabilities are fully L2 mechanisms and
>> no modification of the IP layer is needed.
>> - L3 only approaches. In this type of approaches, the mechanism to
>> provide to required capabilities are located in the IP layer
>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>> located in L2 and other mechanisms are located in L3.
>> Now, the different possible approaches vary greatly in their nature
>> and resulting capabilities. To understanding the benefits and
>> suitability of these alternatives, the requirements have to be
>> properly defined and understood.
>>
>> The main goal of the BOF is understanding the need for work in the
>> IETF in this area. In order to do so, during the BOF, we will attempt to:
>>
>> 1) Understand the applicable scenarios, and the problem statement related
>> to
>> those
>> 2) Understand the restrictions and requirement imposed to solutions to
>> address the problem statement and scenarios
>> 3) Get an overview of the proposed solutions
>>
>>
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>

From [email-masked]  Mon Jun 29 13:22:21 2009
Date: Mon, 29 Jun 2009 15:22:31 -0500
From: Frank Xia <[email-masked]>
To: MELIA TELEMACO <[email-masked]>, George Tsirtsis <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], mext <[email-masked]>
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Telemaco

There are three use cases in my mind:

1)Two interfaces are active at the same time.

  This is the most common case.  Flow mobility
  can handle all the problems relating to handover.

2)One interafce is active while the other is dormant.

  The dormant interface is activated before handover.
  Flow mobility can also do with it.

3)One interafce is active while the other is dormant, and
  traffic must be offloaded from the active one even though
  the dormant one is not ready.

  This is a rare case.  If   "inter-technology handover"
  focuses on dealing with this scenario, I am fine.

BR
Frank

----- Original Message ----- 
From: "MELIA TELEMACO" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "George Tsirtsis" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
"mext" <[email-masked]>
Sent: Monday, June 29, 2009 1:03 PM
Subject: RE: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Frank,

I think you should not mix flow mobility and inter-tech handover. A MN might 
or might now use multiple connections at the same time...

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de 
Frank Xia
Envoy� : lundi 29 juin 2009 19:20
� : George Tsirtsis
Cc : [email-masked]; [email-masked]; [email-masked]; mext
Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Gorge

It seems that  I did not make me clear.

1)Single radio handover.
   MN should disconnect from one BS , and connect
   to a second BS.   MN can't connect to the two BS
   at the same time.  Handover solutions (FMIP/PMIP)
   are needed.

2)Dual radio handover
   MN connects to the two BS'  at the same time.
   Flow mobility is sufficient when move a flow( or  all
   flows)  from  one interface to another.

BR
Frank

----- Original Message ----- 
From: "George Tsirtsis" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>; "mext"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 11:48 AM
Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description

Frank, your comment below is strange to say the least.

MIP handoffs can be between interfaces of the same or different
technologies. Since client MIP works at the IP layer (above the Link
Layer of any specific technology) there is nothing that client MIP
(and any of its features) need to specifically define for
inter-technology handoffs.

  >Did you so far think that this means that client MIP only works
intra-technology?<

For PMIP, this is an issue because currently there is no defined
protocol (on any layer) between MN and MAG...which is one of the
issues to be discussed in netext2 bof.

George

On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia<[email-masked]> wrote:
> Hi Guys
>
> I have comments on inter-technology handover.
>
> IMHO, flow mobility could solve problems
> which inter-tech handover is try to deal with.
> I assume that two heterogeneous interfaces are
> all active during the handover. It is easy to move
> a flow(or all flows) from an interface to another.
>
> This is probably the reason why there is no
> inter-tech handover solution standerdized
> for client MIP.
>
> BR
> Frank
>
> ----- Original Message ----- From: "marcelo bagnulo braun"
> <[email-masked]>
> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
> Sent: Sunday, June 28, 2009 1:16 PM
> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>
>
>> Hi,
>>
>> This is a first draft of the BOF description for your consideration. It
>> is
>> still very open so, feel free to comment on whether the proposed approach
>> seems appropriate or not.
>>
>> NETEXT2 BOF description
>> -----------------------
>>
>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>> IP hosts without requiring any protocol enhancements or additional
>> capabilities on the host.
>> Current PMIP6 specification fully defines how to provide mobility
>> support for mobile nodes with a single interface roaming in a PMIP6
>> domain. The goal of this BOF is gain understanding of how to support
>> nodes with multiple interfaces (of possible different technologies) in a
>> PMIP6 network.
>>
>> In particular, this BOF assumes the following scenario:
>> We have a single PMIP6 domain that has deployed multiple
>> access technologies and needs to support nodes that have
>> multiple interfaces, possibly of different technologies.
>>
>> In particular, the following capabilities are needed:
>>
>> - Inter-technology handover support. The MN has initiated a
>> communication over one interface and it needs to be able to move
>> the established connection to a different interface of
>> a possibly different technology. The reason for moving
>> the communication to another interface is because of the MNs
>> mobility and attaching via a different interface. Basically
>> the ability to perform handovers that span different access
>> technologies.
>>
>> - Multihoming support. The MN with multiple interfaces of possibly
>> different technologies should be able to use them simultaneously to
>> exchange data and manage the mobility of communications
>> established through the different interfaces.
>>
>> - Flow mobility. A MN with multiple interfaces of possibly
>> different technologies must be able to move a flow from
>> one interface to another. Moreover, the MN should be able
>> to inform the network through which interface it wishes
>> to receive different types of flows.
>>
>> In order to provide the support for these capabilities, different
>> approaches can be envisioned, namely:
>> - L2 only approaches. In this type of approaches, the mechanisms
>> to provide the required capabilities are fully L2 mechanisms and
>> no modification of the IP layer is needed.
>> - L3 only approaches. In this type of approaches, the mechanism to
>> provide to required capabilities are located in the IP layer
>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>> located in L2 and other mechanisms are located in L3.
>> Now, the different possible approaches vary greatly in their nature
>> and resulting capabilities. To understanding the benefits and
>> suitability of these alternatives, the requirements have to be
>> properly defined and understood.
>>
>> The main goal of the BOF is understanding the need for work in the
>> IETF in this area. In order to do so, during the BOF, we will attempt to:
>>
>> 1) Understand the applicable scenarios, and the problem statement related
>> to
>> those
>> 2) Understand the restrictions and requirement imposed to solutions to
>> address the problem statement and scenarios
>> 3) Get an overview of the proposed solutions
>>
>>
>> _______________________________________________
>> netlmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

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

From [email-masked]  Mon Jun 29 13:44:36 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 29 Jun 2009 22:43:18 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Hi Frank,

Comments inline:

On 6/29/09 2:57 PM, "ext Frank Xia" <[email-masked]> wrote:

> Hi Raj
>=20
> My main point is make-before-break strategy
> is the best way to solve multi-radio handover.

The IETF cannot do anything about whether an MN has the ability to
accomplish make-before-break connectivity. It depends on the link-layer
technology, spectrum that they operate in, etc. So this approach is a
non-starter. The IETF solution has to be agnostic to underlying access
technologies.=20

>=20
> Please see my inline response.
>=20
> BR
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, June 29, 2009 11:50 AM
> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description
>=20
>=20
>=20
> Frank,
>=20
>=20
> On 6/29/09 11:16 AM, "ext Frank Xia" <[email-masked]> wrote:
>=20
>> Hi Guys
>>=20
>> I have comments on inter-technology handover.
>>=20
>> IMHO, flow mobility could solve problems
>> which inter-tech handover is try to deal with.
>=20
> Flow mobility also includes the ability to move a flow from one mobility
> session to another. Multiple mobility sessions could be established via a
> single interface in which case flow mobility would be achieved within the
> scope of a single interface. Hence flow mobility and inter-technology
> handovers are separate features.
> Frank=3D>IMHO, inter-technology is trying to move all the traffic on
> one interface to another interface.

Right. I guess you answered the question about the difference between flow
mobility and inter-technology handovers. You could extrapolate and say that
inter-technology HO is the case where you move all flows from one interface
to another and hence a variant of flow mobility. While that is true, you
should also recognize that the granularity of flow mobility is finer and
does not have to necessarily be a relocation of a flow between physical
interfaces.=20

>=20
>> I assume that two heterogeneous interfaces are
>> all active during the handover.  It is easy to move
>> a flow(or all flows) from an interface to another.
>=20
> Possibly.. But the point is to identify what extensions (possibly to the =
MN)
> are needed in order to achieve handovers across interfaces.
> Frank=3D>If we see inter-tech handover as a subset of flow mobility,
> there is one problem left, that is flow mobility.

See above. Flow mobility is a feature that can work across multiple mobilit=
y
sessions within the scope of a single interface as well.

>=20
>>=20
>> This is probably the reason why there is no
>> inter-tech handover solution standerdized
>> for client MIP.
>=20
> Client MIP inherently supports handovers across multiple interfaces.
> Performance improvements to the handovers are accomplished using solution=
s
> such as FMIP.
> Frank=3D>Maybe, I am missing something.  However FMIP  is not applicable
> to PAR/NAR collocated scenario.  For example, a mobile node with two
> interface connects to the same access router (ASN-GW for WiMAX,
> PDN-GW for LTE).   Does FMIP work when mobile node handover from
> one technology to another?

Not sure I understand the question. In your example above, I believe the MN
would connect to the ASN-GW via the WiMAX interface and to an S-GW via the
LTE interface. The P-GW (LMA) may be the same. If the question is, can you
use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but
PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at optimizin=
g
handovers in this discussion.
As per the current PMIP6 specification wherein no changes to the host are
required, it is not possible to do an inter-technology handover. This is a
limitation which implies that PMIP6 provides host mobility to an MN within
the scope of a single access technology. Host based mobile IP does not have
this problem. =20

-Raj

>=20
> -Raj
>=20
>>=20
>> BR
>> Frank
>>=20
>> ----- Original Message -----
>> From: "marcelo bagnulo braun" <[email-masked]>
>> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
>> Sent: Sunday, June 28, 2009 1:16 PM
>> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>>=20
>>=20
>>> Hi,
>>>=20
>>> This is a first draft of the BOF description for your consideration. It
>>> is
>>> still very open so, feel free to comment on whether the proposed approa=
ch
>>> seems appropriate or not.
>>>=20
>>> NETEXT2 BOF description
>>> -----------------------
>>>=20
>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>>> IP hosts without requiring any protocol enhancements or additional
>>> capabilities on the host.
>>> Current PMIP6 specification fully defines how to provide mobility
>>> support for mobile nodes with a single interface roaming in a PMIP6
>>> domain. The goal of this BOF is gain understanding of how to support
>>> nodes with multiple interfaces (of possible different technologies) in =
a
>>> PMIP6 network.
>>>=20
>>> In particular, this BOF assumes the following scenario:
>>> We have a single PMIP6 domain that has deployed multiple
>>> access technologies and needs to support nodes that have
>>> multiple interfaces, possibly of different technologies.
>>>=20
>>> In particular, the following capabilities are needed:
>>>=20
>>> - Inter-technology handover support. The MN has initiated a
>>> communication over one interface and it needs to be able to move
>>> the established connection to a different interface of
>>> a possibly different technology. The reason for moving
>>> the communication to another interface is because of the MNs
>>> mobility and attaching via a different interface. Basically
>>> the ability to perform handovers that span different access
>>> technologies.
>>>=20
>>> - Multihoming support. The MN with multiple interfaces of possibly
>>> different technologies should be able to use them simultaneously to
>>> exchange data and manage the mobility of communications
>>> established through the different interfaces.
>>>=20
>>> - Flow mobility. A MN with multiple interfaces of possibly
>>> different technologies must be able to move a flow from
>>> one interface to another. Moreover, the MN should be able
>>> to inform the network through which interface it wishes
>>> to receive different types of flows.
>>>=20
>>> In order to provide the support for these capabilities, different
>>> approaches can be envisioned, namely:
>>> - L2 only approaches. In this type of approaches, the mechanisms
>>> to provide the required capabilities are fully L2 mechanisms and
>>> no modification of the IP layer is needed.
>>> - L3 only approaches. In this type of approaches, the mechanism to
>>> provide to required capabilities are located in the IP layer
>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>>> located in L2 and other mechanisms are located in L3.
>>> Now, the different possible approaches vary greatly in their nature
>>> and resulting capabilities. To understanding the benefits and
>>> suitability of these alternatives, the requirements have to be
>>> properly defined and understood.
>>>=20
>>> The main goal of the BOF is understanding the need for work in the
>>> IETF in this area. In order to do so, during the BOF, we will attempt t=
o:
>>>=20
>>> 1) Understand the applicable scenarios, and the problem statement relat=
ed
>>> to
>>> those
>>> 2) Understand the restrictions and requirement imposed to solutions to
>>> address the problem statement and scenarios
>>> 3) Get an overview of the proposed solutions
>>>=20
>>>=20
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>=20
>=20
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Mon Jun 29 14:36:34 2009
Date: Mon, 29 Jun 2009 16:36:20 -0500
From: Frank Xia <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Hi Raj

IMHO Make-before-break is not a link-layer technology.
, but  a concept (or a strategy).    Related to the topic we
are discussing, making target interface ready before moving
traffic to it is kind of make-before-break.

BR
Frank

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 29, 2009 3:43 PM
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Hi Frank,

Comments inline:

On 6/29/09 2:57 PM, "ext Frank Xia" <[email-masked]> wrote:

> Hi Raj
>
> My main point is make-before-break strategy
> is the best way to solve multi-radio handover.

The IETF cannot do anything about whether an MN has the ability to
accomplish make-before-break connectivity. It depends on the link-layer
technology, spectrum that they operate in, etc. So this approach is a
non-starter. The IETF solution has to be agnostic to underlying access
technologies.

>
> Please see my inline response.
>
> BR
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, June 29, 2009 11:50 AM
> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description
>
>
>
> Frank,
>
>
> On 6/29/09 11:16 AM, "ext Frank Xia" <[email-masked]> wrote:
>
>> Hi Guys
>>
>> I have comments on inter-technology handover.
>>
>> IMHO, flow mobility could solve problems
>> which inter-tech handover is try to deal with.
>
> Flow mobility also includes the ability to move a flow from one mobility
> session to another. Multiple mobility sessions could be established via a
> single interface in which case flow mobility would be achieved within the
> scope of a single interface. Hence flow mobility and inter-technology
> handovers are separate features.
> Frank=>IMHO, inter-technology is trying to move all the traffic on
> one interface to another interface.

Right. I guess you answered the question about the difference between flow
mobility and inter-technology handovers. You could extrapolate and say that
inter-technology HO is the case where you move all flows from one interface
to another and hence a variant of flow mobility. While that is true, you
should also recognize that the granularity of flow mobility is finer and
does not have to necessarily be a relocation of a flow between physical
interfaces.
>
>> I assume that two heterogeneous interfaces are
>> all active during the handover.  It is easy to move
>> a flow(or all flows) from an interface to another.
>
> Possibly.. But the point is to identify what extensions (possibly to the 
> MN)
> are needed in order to achieve handovers across interfaces.
> Frank=>If we see inter-tech handover as a subset of flow mobility,
> there is one problem left, that is flow mobility.

See above. Flow mobility is a feature that can work across multiple mobility
sessions within the scope of a single interface as well.

>
>>
>> This is probably the reason why there is no
>> inter-tech handover solution standerdized
>> for client MIP.
>
> Client MIP inherently supports handovers across multiple interfaces.
> Performance improvements to the handovers are accomplished using solutions
> such as FMIP.
> Frank=>Maybe, I am missing something.  However FMIP  is not applicable
> to PAR/NAR collocated scenario.  For example, a mobile node with two
> interface connects to the same access router (ASN-GW for WiMAX,
> PDN-GW for LTE).   Does FMIP work when mobile node handover from
> one technology to another?

Not sure I understand the question. In your example above, I believe the MN
would connect to the ASN-GW via the WiMAX interface and to an S-GW via the
LTE interface. The P-GW (LMA) may be the same. If the question is, can you
use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but
PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at optimizing
handovers in this discussion.
As per the current PMIP6 specification wherein no changes to the host are
required, it is not possible to do an inter-technology handover. This is a
limitation which implies that PMIP6 provides host mobility to an MN within
the scope of a single access technology. Host based mobile IP does not have
this problem.

-Raj

>
> -Raj
>
>>
>> BR
>> Frank
>>
>> ----- Original Message -----
>> From: "marcelo bagnulo braun" <[email-masked]>
>> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
>> Sent: Sunday, June 28, 2009 1:16 PM
>> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>>
>>
>>> Hi,
>>>
>>> This is a first draft of the BOF description for your consideration. It
>>> is
>>> still very open so, feel free to comment on whether the proposed 
>>> approach
>>> seems appropriate or not.
>>>
>>> NETEXT2 BOF description
>>> -----------------------
>>>
>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>>> IP hosts without requiring any protocol enhancements or additional
>>> capabilities on the host.
>>> Current PMIP6 specification fully defines how to provide mobility
>>> support for mobile nodes with a single interface roaming in a PMIP6
>>> domain. The goal of this BOF is gain understanding of how to support
>>> nodes with multiple interfaces (of possible different technologies) in a
>>> PMIP6 network.
>>>
>>> In particular, this BOF assumes the following scenario:
>>> We have a single PMIP6 domain that has deployed multiple
>>> access technologies and needs to support nodes that have
>>> multiple interfaces, possibly of different technologies.
>>>
>>> In particular, the following capabilities are needed:
>>>
>>> - Inter-technology handover support. The MN has initiated a
>>> communication over one interface and it needs to be able to move
>>> the established connection to a different interface of
>>> a possibly different technology. The reason for moving
>>> the communication to another interface is because of the MNs
>>> mobility and attaching via a different interface. Basically
>>> the ability to perform handovers that span different access
>>> technologies.
>>>
>>> - Multihoming support. The MN with multiple interfaces of possibly
>>> different technologies should be able to use them simultaneously to
>>> exchange data and manage the mobility of communications
>>> established through the different interfaces.
>>>
>>> - Flow mobility. A MN with multiple interfaces of possibly
>>> different technologies must be able to move a flow from
>>> one interface to another. Moreover, the MN should be able
>>> to inform the network through which interface it wishes
>>> to receive different types of flows.
>>>
>>> In order to provide the support for these capabilities, different
>>> approaches can be envisioned, namely:
>>> - L2 only approaches. In this type of approaches, the mechanisms
>>> to provide the required capabilities are fully L2 mechanisms and
>>> no modification of the IP layer is needed.
>>> - L3 only approaches. In this type of approaches, the mechanism to
>>> provide to required capabilities are located in the IP layer
>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>>> located in L2 and other mechanisms are located in L3.
>>> Now, the different possible approaches vary greatly in their nature
>>> and resulting capabilities. To understanding the benefits and
>>> suitability of these alternatives, the requirements have to be
>>> properly defined and understood.
>>>
>>> The main goal of the BOF is understanding the need for work in the
>>> IETF in this area. In order to do so, during the BOF, we will attempt 
>>> to:
>>>
>>> 1) Understand the applicable scenarios, and the problem statement 
>>> related
>>> to
>>> those
>>> 2) Understand the restrictions and requirement imposed to solutions to
>>> address the problem statement and scenarios
>>> 3) Get an overview of the proposed solutions
>>>
>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Mon Jun 29 15:29:13 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 30 Jun 2009 00:28:57 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description

Hi Frank,

Make-before-break is inherently supported in certain technologies such as
CDMA/WCDMA (which has soft HO features built in). The same is not possible
for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does have a
contorted mechansim for achieving the same but that's besides the point.
So IMO it is a capability of the Phy/Mac.
However it is possible to emulate soft-handovers and achieve
make-before-break in certain cases. For example it is possible to be
simultaneously connected to HSPA and WiFi and accomplish a make-before-brea=
k
HO. I guess the definition of the term depends on an access tchnology or th=
e
combination of access technologies in the context of a use-case.

-Raj

On 6/29/09 4:36 PM, "ext Frank Xia" <[email-masked]> wrote:

> Hi Raj
>=20
> IMHO Make-before-break is not a link-layer technology.
> , but  a concept (or a strategy).    Related to the topic we
> are discussing, making target interface ready before moving
> traffic to it is kind of make-before-break.
>=20
> BR
> Frank
>=20
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, June 29, 2009 3:43 PM
> Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof descripti=
on
>=20
>=20
>=20
> Hi Frank,
>=20
> Comments inline:
>=20
>=20
> On 6/29/09 2:57 PM, "ext Frank Xia" <[email-masked]> wrote:
>=20
>> Hi Raj
>>=20
>> My main point is make-before-break strategy
>> is the best way to solve multi-radio handover.
>=20
> The IETF cannot do anything about whether an MN has the ability to
> accomplish make-before-break connectivity. It depends on the link-layer
> technology, spectrum that they operate in, etc. So this approach is a
> non-starter. The IETF solution has to be agnostic to underlying access
> technologies.
>=20
>>=20
>> Please see my inline response.
>>=20
>> BR
>> ----- Original Message -----
>> From: <[email-masked]>
>> To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
>> <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; <[email-masked]>
>> Sent: Monday, June 29, 2009 11:50 AM
>> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description
>>=20
>>=20
>>=20
>> Frank,
>>=20
>>=20
>> On 6/29/09 11:16 AM, "ext Frank Xia" <[email-masked]> wrote:
>>=20
>>> Hi Guys
>>>=20
>>> I have comments on inter-technology handover.
>>>=20
>>> IMHO, flow mobility could solve problems
>>> which inter-tech handover is try to deal with.
>>=20
>> Flow mobility also includes the ability to move a flow from one mobility
>> session to another. Multiple mobility sessions could be established via =
a
>> single interface in which case flow mobility would be achieved within th=
e
>> scope of a single interface. Hence flow mobility and inter-technology
>> handovers are separate features.
>> Frank=3D>IMHO, inter-technology is trying to move all the traffic on
>> one interface to another interface.
>=20
> Right. I guess you answered the question about the difference between flo=
w
> mobility and inter-technology handovers. You could extrapolate and say th=
at
> inter-technology HO is the case where you move all flows from one interfa=
ce
> to another and hence a variant of flow mobility. While that is true, you
> should also recognize that the granularity of flow mobility is finer and
> does not have to necessarily be a relocation of a flow between physical
> interfaces.
>>=20
>>> I assume that two heterogeneous interfaces are
>>> all active during the handover.  It is easy to move
>>> a flow(or all flows) from an interface to another.
>>=20
>> Possibly.. But the point is to identify what extensions (possibly to the
>> MN)
>> are needed in order to achieve handovers across interfaces.
>> Frank=3D>If we see inter-tech handover as a subset of flow mobility,
>> there is one problem left, that is flow mobility.
>=20
> See above. Flow mobility is a feature that can work across multiple mobil=
ity
> sessions within the scope of a single interface as well.
>=20
>>=20
>>>=20
>>> This is probably the reason why there is no
>>> inter-tech handover solution standerdized
>>> for client MIP.
>>=20
>> Client MIP inherently supports handovers across multiple interfaces.
>> Performance improvements to the handovers are accomplished using solutio=
ns
>> such as FMIP.
>> Frank=3D>Maybe, I am missing something.  However FMIP  is not applicable
>> to PAR/NAR collocated scenario.  For example, a mobile node with two
>> interface connects to the same access router (ASN-GW for WiMAX,
>> PDN-GW for LTE).   Does FMIP work when mobile node handover from
>> one technology to another?
>=20
> Not sure I understand the question. In your example above, I believe the =
MN
> would connect to the ASN-GW via the WiMAX interface and to an S-GW via th=
e
> LTE interface. The P-GW (LMA) may be the same. If the question is, can yo=
u
> use FMIP to optimize handovers in such a scenario... Yes. Not FMIP, but
> PFMIP6 (ref. MIPSHOP WG I-D). But I don't think we are looking at optimiz=
ing
> handovers in this discussion.
> As per the current PMIP6 specification wherein no changes to the host are
> required, it is not possible to do an inter-technology handover. This is =
a
> limitation which implies that PMIP6 provides host mobility to an MN withi=
n
> the scope of a single access technology. Host based mobile IP does not ha=
ve
> this problem.
>=20
> -Raj
>=20
>>=20
>> -Raj
>>=20
>>>=20
>>> BR
>>> Frank
>>>=20
>>> ----- Original Message -----
>>> From: "marcelo bagnulo braun" <[email-masked]>
>>> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>>> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
>>> Sent: Sunday, June 28, 2009 1:16 PM
>>> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>>>=20
>>>=20
>>>> Hi,
>>>>=20
>>>> This is a first draft of the BOF description for your consideration. I=
t
>>>> is
>>>> still very open so, feel free to comment on whether the proposed
>>>> approach
>>>> seems appropriate or not.
>>>>=20
>>>> NETEXT2 BOF description
>>>> -----------------------
>>>>=20
>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>>>> IP hosts without requiring any protocol enhancements or additional
>>>> capabilities on the host.
>>>> Current PMIP6 specification fully defines how to provide mobility
>>>> support for mobile nodes with a single interface roaming in a PMIP6
>>>> domain. The goal of this BOF is gain understanding of how to support
>>>> nodes with multiple interfaces (of possible different technologies) in=
 a
>>>> PMIP6 network.
>>>>=20
>>>> In particular, this BOF assumes the following scenario:
>>>> We have a single PMIP6 domain that has deployed multiple
>>>> access technologies and needs to support nodes that have
>>>> multiple interfaces, possibly of different technologies.
>>>>=20
>>>> In particular, the following capabilities are needed:
>>>>=20
>>>> - Inter-technology handover support. The MN has initiated a
>>>> communication over one interface and it needs to be able to move
>>>> the established connection to a different interface of
>>>> a possibly different technology. The reason for moving
>>>> the communication to another interface is because of the MNs
>>>> mobility and attaching via a different interface. Basically
>>>> the ability to perform handovers that span different access
>>>> technologies.
>>>>=20
>>>> - Multihoming support. The MN with multiple interfaces of possibly
>>>> different technologies should be able to use them simultaneously to
>>>> exchange data and manage the mobility of communications
>>>> established through the different interfaces.
>>>>=20
>>>> - Flow mobility. A MN with multiple interfaces of possibly
>>>> different technologies must be able to move a flow from
>>>> one interface to another. Moreover, the MN should be able
>>>> to inform the network through which interface it wishes
>>>> to receive different types of flows.
>>>>=20
>>>> In order to provide the support for these capabilities, different
>>>> approaches can be envisioned, namely:
>>>> - L2 only approaches. In this type of approaches, the mechanisms
>>>> to provide the required capabilities are fully L2 mechanisms and
>>>> no modification of the IP layer is needed.
>>>> - L3 only approaches. In this type of approaches, the mechanism to
>>>> provide to required capabilities are located in the IP layer
>>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>>>> located in L2 and other mechanisms are located in L3.
>>>> Now, the different possible approaches vary greatly in their nature
>>>> and resulting capabilities. To understanding the benefits and
>>>> suitability of these alternatives, the requirements have to be
>>>> properly defined and understood.
>>>>=20
>>>> The main goal of the BOF is understanding the need for work in the
>>>> IETF in this area. In order to do so, during the BOF, we will attempt
>>>> to:
>>>>=20
>>>> 1) Understand the applicable scenarios, and the problem statement
>>>> related
>>>> to
>>>> those
>>>> 2) Understand the restrictions and requirement imposed to solutions to
>>>> address the problem statement and scenarios
>>>> 3) Get an overview of the proposed solutions
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> netlmm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>=20
>>=20
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>=20

From [email-masked]  Mon Jun 29 17:12:10 2009
Date: Tue, 30 Jun 2009 10:12:19 +1000
From: Hesham Soliman <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked], mext <[email-masked]>
Subject: [netext] Cross posting

It would be nice if postings are limited to one mailing list please!

Hesham

From [email-masked]  Mon Jun 29 20:27:48 2009
Date: Tue, 30 Jun 2009 11:27:51 +0800
From: Min Hui <[email-masked]>
To: [email-masked]
Subject: [netext] Fwd: New Version Notification for draft-hui-netext-service-flow-identifier-00

Hi, all

I have just submitted a new draft:
http://www.ietf.org/internet-drafts/draft-hui-netext-service-flow-identifie=
r-00.txt

This draft defines a new Service Flow Identifier option carrying the
service flow identifier and service flow attributes in the Proxy
Binding Update and Acknowledgement message, so that the granularity of
PMIPv6 becomes per service flow basis.

Any comment is welcomed.
Thanks a lot.

-Hui Min

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[email-masked]>
Date: 2009/6/30
Subject: New Version Notification for
draft-hui-netext-service-flow-identifier-00
To: [email-masked]
=B3=AD=CB=CD=A3=BA [email-masked], [email-masked]

A new version of I-D, draft-hui-netext-service-flow-identifier-00.txt
has been successfuly submitted by Min Hui and posted to the IETF
repository.

Filename:        draft-hui-netext-service-flow-identifier
Revision:        00
Title:           Service Flow Identifier in Proxy Mobile IPv6
Creation_date:   2009-06-29
WG ID:           Independent Submission
Number_of_pages: 18

Abstract:
Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
mobile node without requiring its participation in any mobility-
related signaling. This document introduces extensions to Proxy
Mobile IPv6 that allows network dynamically binding each service flow
to the mobile node, respectively. Therefore, multiple service flows
of the mobile node can be separately controlled based on the service
flow identifier in the Proxy Binding Update and Acknowledge messages.

The IETF Secretariat.

From [email-masked]  Mon Jun 29 21:09:14 2009
Date: Mon, 29 Jun 2009 23:09:19 -0500
From: Frank Xia <[email-masked]>
To: [email-masked]
Subject: [netext] Differentiated Services Support for Proxy Mobile IPv6

This is a multi-part message in MIME format.

--Boundary_(ID_n7rQatlqvpRFm5G8uwVh/Q)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi Folks

I just submitted the draft
http://www.ietf.org/internet-drafts/draft-xia-netext-qos-00.txt.

Comments are very welcome!

Abstract

   This document describes Quality of Service (QoS) provisioning in a
   Proxy Mobile IPv6 domain through enabling differentiated services.
   When a packet is encapsulated in a mobile access gateway (or a local
   mobility anchor), the differentiated services codepoint (DSCP) field
   in the outer header is mapped to the priority of a mobile node, or
   the precedence of an application of the mobile node.  Intermediary
   routers between the mobile access gateway and the local mobility
   anchor, which forward the packet based on the outer header of the
   packet, prioritize the packet according to the DSCP value of the
   outer header.

BR
Frank

--Boundary_(ID_n7rQatlqvpRFm5G8uwVh/Q)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.3562" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi Folks</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I just submitted the draft</FONT></DIV>
<DIV><FONT face=Arial size=2><A 
href="http://www.ietf.org/internet-drafts/draft-xia-netext-qos-00.txt">http://www.ietf.org/internet-drafts/draft-xia-netext-qos-00.txt</A>.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Comments are very welcome!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV>Abstract<BR><BR>&nbsp;&nbsp; This document describes Quality of Service 
(QoS) provisioning in a<BR>&nbsp;&nbsp; Proxy Mobile IPv6 domain through 
enabling differentiated services.<BR>&nbsp;&nbsp; When a packet is encapsulated 
in a mobile access gateway (or a local<BR>&nbsp;&nbsp; mobility anchor), the 
differentiated services codepoint (DSCP) field<BR>&nbsp;&nbsp; in the outer 
header is mapped to the priority of a mobile node, or<BR>&nbsp;&nbsp; the 
precedence of an application of the mobile node.&nbsp; 
Intermediary<BR>&nbsp;&nbsp; routers between the mobile access gateway and the 
local mobility<BR>&nbsp;&nbsp; anchor, which forward the packet based on the 
outer header of the<BR>&nbsp;&nbsp; packet, prioritize the packet according to 
the DSCP value of the<BR>&nbsp;&nbsp; outer header.<BR><BR><FONT face=Arial 
size=2>BR</FONT></DIV>
<DIV><FONT face=Arial size=2>Frank</FONT></DIV></BODY></HTML>

--Boundary_(ID_n7rQatlqvpRFm5G8uwVh/Q)--

From [email-masked]  Mon Jun 29 13:11:20 2009
Date: Mon, 29 Jun 2009 16:11:32 -0400
From: "Stuart W. Card" <[email-masked]>
Organization: Critical Technologies Inc.
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof description

IMHO, inter-technology handoff and flow mobility
overlap: neither is a strict subset of the other; but
neither are they entirely independent.

Make-before-break is certainly highly desirable,
but perhaps should not be specified as required.

Inter-technology handoff could be specified as
moving _all_ flows from one interface to another,
but that would needlessly over-constrain it: there
clearly are cases where one might wish to move
a sub-set of the flows (for instance, an old path
may be losing capacity while a new one is gaining
strength, but both are likely to remain usable for
some time, so just shift some of the load).

Frank Xia wrote:
> Hi Raj
>
> My main point is make-before-break strategy
> is the best way to solve multi-radio handover.
>
> Please see my inline response.
>
> BR
> ----- Original Message ----- From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, June 29, 2009 11:50 AM
> Subject: Re: [netlmm] NEXTEXT2: first draft of the bof description
>
>
>
> Frank,
>
>
> On 6/29/09 11:16 AM, "ext Frank Xia" <[email-masked]> wrote:
>
>> Hi Guys
>>
>> I have comments on inter-technology handover.
>>
>> IMHO, flow mobility could solve problems
>> which inter-tech handover is try to deal with.
>
> Flow mobility also includes the ability to move a flow from one mobility
> session to another. Multiple mobility sessions could be established via a
> single interface in which case flow mobility would be achieved within the
> scope of a single interface. Hence flow mobility and inter-technology
> handovers are separate features.
> Frank=>IMHO, inter-technology is trying to move all the traffic on
> one interface to another interface.
>
>> I assume that two heterogeneous interfaces are
>> all active during the handover.  It is easy to move
>> a flow(or all flows) from an interface to another.
>
> Possibly.. But the point is to identify what extensions (possibly to 
> the MN)
> are needed in order to achieve handovers across interfaces.
> Frank=>If we see inter-tech handover as a subset of flow mobility,
> there is one problem left, that is flow mobility.
>
>>
>> This is probably the reason why there is no
>> inter-tech handover solution standerdized
>> for client MIP.
>
> Client MIP inherently supports handovers across multiple interfaces.
> Performance improvements to the handovers are accomplished using 
> solutions
> such as FMIP.
> Frank=>Maybe, I am missing something.  However FMIP  is not applicable
> to PAR/NAR collocated scenario.  For example, a mobile node with two
> interface connects to the same access router (ASN-GW for WiMAX,
> PDN-GW for LTE).   Does FMIP work when mobile node handover from
> one technology to another?
>
> -Raj
>
>>
>> BR
>> Frank
>>
>> ----- Original Message -----
>> From: "marcelo bagnulo braun" <[email-masked]>
>> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
>> Sent: Sunday, June 28, 2009 1:16 PM
>> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>>
>>
>>> Hi,
>>>
>>> This is a first draft of the BOF description for your consideration. 
>>> It is
>>> still very open so, feel free to comment on whether the proposed 
>>> approach
>>> seems appropriate or not.
>>>
>>> NETEXT2 BOF description
>>> -----------------------
>>>
>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>>> IP hosts without requiring any protocol enhancements or additional
>>> capabilities on the host.
>>> Current PMIP6 specification fully defines how to provide mobility
>>> support for mobile nodes with a single interface roaming in a PMIP6
>>> domain. The goal of this BOF is gain understanding of how to support
>>> nodes with multiple interfaces (of possible different technologies) 
>>> in a
>>> PMIP6 network.
>>>
>>> In particular, this BOF assumes the following scenario:
>>> We have a single PMIP6 domain that has deployed multiple
>>> access technologies and needs to support nodes that have
>>> multiple interfaces, possibly of different technologies.
>>>
>>> In particular, the following capabilities are needed:
>>>
>>> - Inter-technology handover support. The MN has initiated a
>>> communication over one interface and it needs to be able to move
>>> the established connection to a different interface of
>>> a possibly different technology. The reason for moving
>>> the communication to another interface is because of the MNs
>>> mobility and attaching via a different interface. Basically
>>> the ability to perform handovers that span different access
>>> technologies.
>>>
>>> - Multihoming support. The MN with multiple interfaces of possibly
>>> different technologies should be able to use them simultaneously to
>>> exchange data and manage the mobility of communications
>>> established through the different interfaces.
>>>
>>> - Flow mobility. A MN with multiple interfaces of possibly
>>> different technologies must be able to move a flow from
>>> one interface to another. Moreover, the MN should be able
>>> to inform the network through which interface it wishes
>>> to receive different types of flows.
>>>
>>> In order to provide the support for these capabilities, different
>>> approaches can be envisioned, namely:
>>> - L2 only approaches. In this type of approaches, the mechanisms
>>> to provide the required capabilities are fully L2 mechanisms and
>>> no modification of the IP layer is needed.
>>> - L3 only approaches. In this type of approaches, the mechanism to
>>> provide to required capabilities are located in the IP layer
>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>>> located in L2 and other mechanisms are located in L3.
>>> Now, the different possible approaches vary greatly in their nature
>>> and resulting capabilities. To understanding the benefits and
>>> suitability of these alternatives, the requirements have to be
>>> properly defined and understood.
>>>
>>> The main goal of the BOF is understanding the need for work in the
>>> IETF in this area. In order to do so, during the BOF, we will 
>>> attempt to:
>>>
>>> 1) Understand the applicable scenarios, and the problem statement 
>>> related
>>> to
>>> those
>>> 2) Understand the restrictions and requirement imposed to solutions to
>>> address the problem statement and scenarios
>>> 3) Get an overview of the proposed solutions
>>>
>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

-- 
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email-masked]> www.critical.com

From [email-masked]  Mon Jun 29 19:12:46 2009
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 30 Jun 2009 09:02:30 +0700
Organization: Network Zen
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof	description

[email-masked] writes:

> Hi Frank,
> 
> Make-before-break is inherently supported in certain technologies such
> as
> CDMA/WCDMA (which has soft HO features built in). The same is not
> possible
> for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does
> have a
> contorted mechansim for achieving the same but that's besides the
> point.
> So IMO it is a capability of the Phy/Mac.
> However it is possible to emulate soft-handovers and achieve
> make-before-break in certain cases. For example it is possible to be
> simultaneously connected to HSPA and WiFi and accomplish a make-before-
> break
> HO. I guess the definition of the term depends on an access tchnology
> or the
> combination of access technologies in the context of a use-case.

I'm inclined to agree with you, though isn't the implementation of
make-before-break capability possible using any PHY & dual radios?  The
problem being the price of parts...

...

From [email-masked]  Mon Jun 29 21:53:15 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 30 Jun 2009 06:53:07 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked]
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the	bof	description

=20

>> Hi Frank,
>>=20
>> Make-before-break is inherently supported in certain technologies such=20
>> as CDMA/WCDMA (which has soft HO features built in). The same is not=20
>> possible for example in TDMA (GSM) or OFDMA (802.16e and WiFi).=20
>> 802.16e does have a contorted mechansim for achieving the same but=20
>> that's besides the point.
>> So IMO it is a capability of the Phy/Mac.
>> However it is possible to emulate soft-handovers and achieve=20
>> make-before-break in certain cases. For example it is possible to be=20
>> simultaneously connected to HSPA and WiFi and accomplish a=20
>> make-before- break HO. I guess the definition of the term depends on=20
>> an access tchnology or the combination of access technologies in the=20
>> context of a use-case.
>
>I'm inclined to agree with you, though isn't the implementation of make-be=
fore-break capability possible using any PHY & dual=20
>radios?  The problem being the price of parts...

There is always a price to pay for functionality.=20
But it is not always possible to have any dual-radio combination work (inte=
rference, proximity of antennas and other factors). So it is only some comb=
ination of dual-radios that can accomplish it.

...

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

From [email-masked]  Tue Jun 30 01:52:39 2009
Date: Tue, 30 Jun 2009 01:52:31 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: Marco Liebsch <[email-masked]>, [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi Marco,

>> I some how looked at RO and localized routing as two
> different problems.
>> I agree with this approach, if its about a basic localized
> routing, which
>> I assumed was the context of the discussion, going with a
> solution draft
>> is fine. If its for complete RO, may be a PS draft might help.
> The current individual PS draft specifies use cases taking
> the scope of
> NetExt into account, which includes setting up an optimized
> forwarding
> path between MAGs.
> I personally prefer the term route optimization, which is
> also the term
> being used
> in this context in the charter description. However, the chater mixes
> both terms, which
> should be ok if there is common understanding in that
> localized routing
> means 'local in the
> access of a PMIP domain', not 'local on a single MAG'.
>

I agree. There seems to be some confusion on the terminology and
the scenarios that are in scope for this work. May be we need to
discuss this and agree upon.

Regards
Sri

From [email-masked]  Tue Jun 30 07:34:39 2009
From: "Davis, Terry L" <[email-masked]>
To: "'Glen Zorn'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 30 Jun 2009 06:45:06 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of thebof	description

Glen

Right, cost, weight, and drag, in our case.  If you are using links to geos=
, it definitely takes two antenna's to do make before break. =20

However a single antenna, as Connexion by Boeing used, can move from one ge=
o and lock onto another and have layer 3 routing flowing in well under 30 s=
econds; a short enough time that almost none of the TCP timers trigger.  Th=
e user sees a short "loss of QOS" if they are actively typing or talking wh=
ich appears to be no more than a web server not responding for a few second=
s or your VoIP losing a few seconds of conversation.

As far as aviation goes, you will see both types of handoff's made with a m=
ake before break probably more common with air-to-ground links than satelli=
te.

Coordination capabilities between layer 2 and layer 3 for the handoffs thou=
gh are critical.

Take care
Terry

PS: Until the IPSec, PKI, and IKEv2 interoperability between vendors (I mea=
n dozens of different vendors!) progresses such that it actually can be dyn=
amically done, deciding which security associations belong to which link pr=
oviders and auto-configuring the links, I would expect that establishing li=
nk authentication and security will remain a primary challenge to mobility =
services.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Glen Zorn
> Sent: Monday, June 29, 2009 7:03 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of thebof
> description
>=20
> [email-masked] writes:
>=20
> > Hi Frank,
> >
> > Make-before-break is inherently supported in certain technologies such
> > as
> > CDMA/WCDMA (which has soft HO features built in). The same is not
> > possible
> > for example in TDMA (GSM) or OFDMA (802.16e and WiFi). 802.16e does
> > have a
> > contorted mechansim for achieving the same but that's besides the
> > point.
> > So IMO it is a capability of the Phy/Mac.
> > However it is possible to emulate soft-handovers and achieve
> > make-before-break in certain cases. For example it is possible to be
> > simultaneously connected to HSPA and WiFi and accomplish a make-before-
> > break
> > HO. I guess the definition of the term depends on an access tchnology
> > or the
> > combination of access technologies in the context of a use-case.
>=20
> I'm inclined to agree with you, though isn't the implementation of
> make-before-break capability possible using any PHY & dual radios?  The
> problem being the price of parts...
>=20
> ...
>=20
>=20
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

From [email-masked]  Tue Jun 30 08:42:30 2009
Date: Tue, 30 Jun 2009 17:17:51 +0200
From: Marco Liebsch <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Sri, all,

Sri Gundavelli wrote:
>
>
> Hi Marco,
>
>>> I some how looked at RO and localized routing as two
>> different problems.
>>> I agree with this approach, if its about a basic localized
>> routing, which
>>> I assumed was the context of the discussion, going with a
>> solution draft
>>> is fine. If its for complete RO, may be a PS draft might help.
>> The current individual PS draft specifies use cases taking
>> the scope of
>> NetExt into account, which includes setting up an optimized
>> forwarding
>> path between MAGs.
>> I personally prefer the term route optimization, which is
>> also the term
>> being used
>> in this context in the charter description. However, the chater mixes
>> both terms, which
>> should be ok if there is common understanding in that
>> localized routing
>> means 'local in the
>> access of a PMIP domain', not 'local on a single MAG'.
>>
>
> I agree. There seems to be some confusion on the terminology and
> the scenarios that are in scope for this work. May be we need to
> discuss this and agree upon.
I think there is more common understanding on the scope than on the 
term. The scope has been
discussed and presented in SF. This includes setting up an optimized 
route between MAGs
of a single PMIPv6 domain. The same solution should handle the case 
where both mobiles
connect to the same MAG. If you think the term Localized Routing is not 
appropriate to cover the
scope to optimize a forwarding path beyond a single MAG, I'd prefer to 
stick to the term Route Optimization.
I think that's rather unambiguous. Other opinions?

marco

>
> Regards
> Sri
>

From [email-masked]  Tue Jun 30 09:10:03 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 30 Jun 2009 18:04:37 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Hesham,

On 6/30/09 8:48 AM, "ext Hesham Soliman" <[email-masked]> wrote:

>=20
> =3D> I think the important question to ask is why this is an issue in the
> first place? If you have a solution for the superset (all link layers) an=
d
> there is a question about whether you need a solution for a subset, then =
the
> question we should ask is "why?". This has to be part of the discussion. =
"we
> want ....*because*..."
>=20
> Hesham
>=20

We (as in the people in NetExt) want PMIP6 to support inter-technology
handovers, flow binding/mobility and enhanced support for multihoming
*because* :
1. Not every host does or will include host based mobility protocols such a=
s
(DS)MIP
2. An operator may choose to deploy a network with only network based
mobility protocol support

-Raj

From [email-masked]  Tue Jun 30 09:14:27 2009
Date: Tue, 30 Jun 2009 17:13:18 +0100
From: George Tsirtsis <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

inline...

On Tue, Jun 30, 2009 at 4:52 PM, <[email-masked]> wrote:
>
>
> On 6/30/09 9:54 AM, "ext Hesham Soliman" <[email-masked]> wrote=
:
>
>>
>>
>>
>>>>
>>>> =3D> I think the important question to ask is why this is an issue in =
the
>>>> first place? If you have a solution for the superset (all link layers)
>>> you are assuming and answer here, i.e. that the answer is that the
>>> requirement is a subset, which i don't know if it is the case
>>>
>>>> =C2=A0and
>>>> there is a question about whether you need a solution for a subset, th=
en the
>>>> question we should ask is "why?". This has to be part of the discussio=
n. "we
>>>> want ....*because*..."
>>>>
>>>>
>>> sure, "why?" is a valid question, but before asking ourselves "why?", w=
e
>>> need to answer "what?"
>>>
>>> So, let's first provide an detailed answer of what is being required to
>>> support and and that point we will be in good shape to ask "why?"
>>> i don't think you can ask "why? until a proper answer has been provide
>>> to "what?"
>>>
>>> agree?
>>
>> =3D> Ok, you're right about my assumption about the answer but it's not =
coming
>> from vaccuum :), it's not the first time this is discussed. But ok, I'm
>> happy to go through this exercise from the beginning. Let's ask "what" a=
nd
>> regardless of the answer ask "why" as well. Because requirements always =
need
>> to be justified.
>
> I think there is a reasonably good understanding that for the problems (w=
hat
> aspects in the discussion here) that are being stated, (DS)MIP6 is able t=
o
> provide a solution already. I don't think that it is a surprise to anyone=
.
> So the question is : Why? If the IETF already has a solution for dealing
> with inter-technology handovers, flow binding/mobility and multihoming (R=
FCs
> 3775/5555 and related I-Ds in MEXT WG) why do we need to develop the same
> capabilities for network based mobility protocol (RFC5213)?
>
> Quite simply, the answer is that in certain deployments it is not feasibl=
e
> to expect DS(MIP6) capability on hosts. An operator cannot expect that ev=
ery
> host connecting to the network implements (DS)MIP6. The operator has no
> control of the hosts or their capabilities to a large extent. The only th=
ing
> the operator can and does control is the network, and hence the
> consideration to add such capabilities to a deployment which used network
> based mobility protocol.
>

GT> This is good justification answering the "why" and it leads to an
obvious set of options for the "what". It implies something about the
solution space that I would like this BOF to be specific about. i.e.,
if the reason to do this is to enable inter-tech and multi-homing
without client MIP in the mobile, does it mean:
a)  you do not want any mobility software in the mobile? (this seems
unrealistic)
b)  that you want L2 software in the client? (this is possible for
*some* technologies and I do not think that such work belongs to the
IETF...but the BOF could discuss this)
c)  that you want network layer software in the  mobile but not MIP;
(This clearly makes no sense given your "why")

Would you rather revise your "why" ? :-)

George

> One of the outcomes of this discussion is quite possibly the fact that th=
e
> IETF believes the use of host based mobile IP protocols is the right choi=
ce
> and recommends it as such. And that is fine. But I think we should also
> consider the approaches to providing these features for PMIP6 which would
> not necessarily result in reinventing host based mobile IP type of
> capabilities on the MNs.
>
> I don't know if the above justifies the reason why we are having this
> discussion (yet again :) ).
>
> -Raj
>
>>
>> Hesham
>>
>>>
>>> Regards, marcelo
>>>
>>>> Hesham
>>>>
>>>>
>>>>> Regards, marcelo
>>>>>
>>>>>
>>>>> Hesham Soliman escribi=C3=B3:
>>>>>
>>>>>> A quick comment.
>>>>>> I don't see any reason for an IETF WG to look for a solution that wo=
rks
>>>>>> for
>>>>>> a limited set of technologies and try to solve that on layer 2. This=
 is
>>>>>> clearly not our job. Similarly, there is little gain in solving this=
 for a
>>>>>> limited set of technologies on L3 given that we already have a layer=
 2
>>>>>> agnostic solution. Why would we want to develop another one for a li=
mited
>>>>>> set of link layers?
>>>>>>
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" <[email-masked]> w=
rote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> George,
>>>>>>>
>>>>>>>
>>>>>> great summary
>>>>>>
>>>>>> just one comment below...
>>>>>>
>>>>>>
>>>>>> George Tsirtsis
>>>>>>
>>>>>>
>>>>>>> escribi=C3=B3:
>>>>>>> With PMIP things are not so clear....it is not even clear we are
>>>>>>>
>>>>>>> talking about the *network layer*... and thus it is not so clear ho=
w
>>>>>>>
>>>>>>> "generic" solutions can be.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> right, so one relevant question is how
>>>>>>
>>>>>>
>>>>>>> generic we want this to be.
>>>>>>>
>>>>>>>
>>>>>> For instance, it may be also sufficient to support
>>>>>>
>>>>>>
>>>>>>> inter technology
>>>>>>>
>>>>>>>
>>>>>> handovers for a subset of L2 technologies that can support
>>>>>>
>>>>>>
>>>>>>> it at the L2
>>>>>>>
>>>>>>>
>>>>>> as you stated.
>>>>>> So, one thing that we need to define is whether
>>>>>>
>>>>>>
>>>>>>> we are looking for a
>>>>>>>
>>>>>>>
>>>>>> solution that supports inter technology handover with
>>>>>>
>>>>>>
>>>>>>> any two L2
>>>>>>>
>>>>>>>
>>>>>> combiantios or are we looking for a solution that supports inter
>>>>>>
>>>>>> technology handovers for a limited set of technologies?
>>>>>> I think this is a key
>>>>>>
>>>>>>
>>>>>>> requirements that we need to be explicit about.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> The challenge for the BOF
>>>>>>> is to throw some light on how PMIP can be
>>>>>>> compatible with this extended
>>>>>>> functionality, =C2=A0what type of additional
>>>>>>> signalling is needed, and at which
>>>>>>> layer they intend to implement such
>>>>>>> signalling. Let's see.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> while i
>>>>>>
>>>>>>
>>>>>>> agree with that, i think a first step that this bof needs to
>>>>>>>
>>>>>>>
>>>>>> throw some light
>>>>>>
>>>>>>
>>>>>>> on is what are the functional requirements for the
>>>>>>>
>>>>>>>
>>>>>> support of the required
>>>>>>
>>>>>>
>>>>>>> features. I think the previous is a good example
>>>>>>>
>>>>>>>
>>>>>> of one requirement that we
>>>>>>
>>>>>>
>>>>>>> need to flesh out. There are many others.
>>>>>>>
>>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> George
>>>>>>>
>>>>>>> On
>>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>>>>>>>
>>>>>>> Perkins<[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hello Basavaraj,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Isn't make-before-break a function performed
>>>>>>>
>>>>>>>
>>>>>>>> at the link layer?
>>>>>>>>
>>>>>>>> It
>>>>>>>>
>>>>>>>>
>>>>>>> certainly isn't PHY, and I wouldn't think it
>>>>>>>
>>>>>>>
>>>>>>>> qualifies as MAC (i.e., it
>>>>>>>>
>>>>>>>>
>>>>>>> doesn't control the
>>>>>>>
>>>>>>>
>>>>>>>> device's access to the medium).
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Charlie P.
>>>>>>>
>>>>>>>
>>>>>>>> PS. Which is the proper mailing list for this
>>>>>>>>
>>>>>>>>
>>>>>>> discussion?
>>>>>>>
>>>>>>>
>>>>>>>> [email-masked] wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>>
>>>>>>> Frank,
>>>>>>>
>>>>>>>
>>>>>>>>> Make-before-break is inherently supported in certain
>>>>>>>>>
>>>>>>>>>
>>>>>>> technologies such as
>>>>>>>
>>>>>>>
>>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>>>>>>>>>
>>>>>>>>>
>>>>>>> same is not possible
>>>>>>>
>>>>>>>
>>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>>>>>>>>>
>>>>>>>>>
>>>>>>> WiFi). 802.16e does have a
>>>>>>>
>>>>>>>
>>>>>>>>> contorted mechansim for achieving the same but
>>>>>>>>>
>>>>>>>>>
>>>>>>> that's besides the point.
>>>>>>>
>>>>>>>
>>>>>>>>> So IMO it is a capability of the Phy/Mac.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> However it is possible to emulate soft-handovers and achieve
>>>>>>>
>>>>>>> make-before-break in certain cases. For example it is possible to b=
e
>>>>>>>
>>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>>>>>>>
>>>>>>> make-before-break
>>>>>>>
>>>>>>>
>>>>>>>>> HO. I guess the definition of the term depends on an
>>>>>>>>>
>>>>>>>>>
>>>>>>> access tchnology or
>>>>>>>
>>>>>>>
>>>>>>>>> the
>>>>>>>>> combination of access technologies in the
>>>>>>>>>
>>>>>>>>>
>>>>>>> context of a use-case.
>>>>>>>
>>>>>>>
>>>>>>>>> -Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>>>>>>>>>
>>>>>>>>>
>>>>>>> Xia" <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Raj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> IMHO Make-before-break is not a link-layer technology.
>>>>>>>
>>>>>>>
>>>>>>>>>> , but =C2=A0a concept
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> (or a strategy). =C2=A0 =C2=A0Related to the topic we
>>>>>>>
>>>>>>>
>>>>>>>>>> are discussing, making target
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> interface ready before moving
>>>>>>>
>>>>>>>
>>>>>>>>>> traffic to it is kind of
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> make-before-break.
>>>>>>>
>>>>>>>
>>>>>>>>>> BR
>>>>>>>>>> Frank
>>>>>>>>>>
>>>>>>>>>> ----- Original Message
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> -----
>>>>>>>
>>>>>>>
>>>>>>>>>> From: <[email-masked]>
>>>>>>>>>> To:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <[email-masked]>; <[email-masked]>; <[email-masked]>;
>>>>>>>
>>>>>>> <[email-masked]>; <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>>>>>>>>>> Subject: Re:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>>>>>>>
>>>>>>> description
>>>>>>>
>>>>>>>
>>>>>>>>>> Hi Frank,
>>>>>>>>>>
>>>>>>>>>> Comments
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> inline:
>>>>>>>
>>>>>>>
>>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> Raj
>>>>>>>
>>>>>>>
>>>>>>>>>>> My main point is make-before-break strategy
>>>>>>>>>>> is the best
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> way to solve multi-radio handover.
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> The IETF cannot
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> do anything about whether an MN has the ability to
>>>>>>>
>>>>>>>
>>>>>>>>>> accomplish
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> make-before-break connectivity. It depends on the link-layer
>>>>>>>
>>>>>>>
>>>>>>>>>> technology,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> spectrum that they operate in, etc. So this approach is a
>>>>>>>
>>>>>>>
>>>>>>>>>> non-starter.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> The IETF solution has to be agnostic to underlying access
>>>>>>>
>>>>>>> technologies.
>>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Please see my inline
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> response.
>>>>>>>
>>>>>>>
>>>>>>>>>>> BR
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>>> To: <[email-masked]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[email-masked]>; <[email-masked]>;
>>>>>>>
>>>>>>>
>>>>>>>>>>> <[email-masked]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>>>>>>>>>>> Subject:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>>>>>>> description
>>>>>>>
>>>>>>>
>>>>>>>>>>> Frank,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 6/29/09 11:16
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Guys
>>>>>>>>>>>>
>>>>>>>>>>>> I have comments on inter-technology
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> handover.
>>>>>>>
>>>>>>>
>>>>>>>>>>>> IMHO, flow mobility could solve problems
>>>>>>>>>>>> which
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> inter-tech handover is try to deal with.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Flow
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> mobility also includes the ability to move a flow from one mobility
>>>>>>>
>>>>>>> session to another. Multiple mobility sessions could be established=
 via
>>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>
>>>>>>>>>>> single interface in which case flow mobility would be achieved
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> within
>>>>>>>
>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>> scope of a single interface. Hence flow mobility and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> inter-technology
>>>>>>>
>>>>>>>
>>>>>>>>>>> handovers are separate features.
>>>>>>>>>>> Frank=3D>IMHO,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> inter-technology is trying to move all the traffic on
>>>>>>>
>>>>>>>
>>>>>>>>>>> one interface to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> another interface.
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Right. I guess you answered the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> question about the difference between
>>>>>>>
>>>>>>>
>>>>>>>>>> flow
>>>>>>>>>> mobility and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> inter-technology handovers. You could extrapolate and say
>>>>>>>
>>>>>>>
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> inter-technology HO is the case where you move all flows from one
>>>>>>>
>>>>>>> interface
>>>>>>>
>>>>>>>
>>>>>>>>>> to another and hence a variant of flow mobility. While that is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> true, you
>>>>>>>
>>>>>>>
>>>>>>>>>> should also recognize that the granularity of flow mobility is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> finer and
>>>>>>>
>>>>>>>
>>>>>>>>>> does not have to necessarily be a relocation of a flow between
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> physical
>>>>>>>
>>>>>>>
>>>>>>>>>> interfaces.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> I assume that two
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> heterogeneous interfaces are
>>>>>>>
>>>>>>>
>>>>>>>>>>>> all active during the handover. =C2=A0It is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> easy to move
>>>>>>>
>>>>>>>
>>>>>>>>>>>> a flow(or all flows) from an interface to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> another.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Possibly.. But the point is to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> identify what extensions (possibly to the
>>>>>>>
>>>>>>>
>>>>>>>>>>> MN)
>>>>>>>>>>> are needed in order
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> to achieve handovers across interfaces.
>>>>>>>
>>>>>>>
>>>>>>>>>>> Frank=3D>If we see inter-tech
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> handover as a subset of flow mobility,
>>>>>>>
>>>>>>>
>>>>>>>>>>> there is one problem left, that
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> is flow mobility.
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> See above. Flow mobility is a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> feature that can work across multiple
>>>>>>>
>>>>>>>
>>>>>>>>>> mobility
>>>>>>>>>> sessions within the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> scope of a single interface as well.
>>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> This is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> probably the reason why there is no
>>>>>>>
>>>>>>>
>>>>>>>>>>>> inter-tech handover solution
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> standerdized
>>>>>>>
>>>>>>>
>>>>>>>>>>>> for client MIP.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Client
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> MIP inherently supports handovers across multiple interfaces.
>>>>>>>
>>>>>>> Performance improvements to the handovers are accomplished using
>>>>>>>
>>>>>>> solutions
>>>>>>>
>>>>>>>
>>>>>>>>>>> such as FMIP.
>>>>>>>>>>> Frank=3D>Maybe, I am missing something.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> However FMIP =C2=A0is not applicable
>>>>>>>
>>>>>>>
>>>>>>>>>>> to PAR/NAR collocated scenario. =C2=A0For
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> example, a mobile node with two
>>>>>>>
>>>>>>>
>>>>>>>>>>> interface connects to the same access
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> router (ASN-GW for WiMAX,
>>>>>>>
>>>>>>>
>>>>>>>>>>> PDN-GW for LTE). =C2=A0 Does FMIP work when mobile
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> node handover from
>>>>>>>
>>>>>>>
>>>>>>>>>>> one technology to another?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Not sure I understand the question. In your example above, I bel=
ieve
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>
>>>>>>>>>> MN
>>>>>>>>>> would connect to the ASN-GW via the WiMAX interface and to an
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> S-GW via
>>>>>>>
>>>>>>>
>>>>>>>>>> the
>>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> question is, can
>>>>>>>
>>>>>>>
>>>>>>>>>> you
>>>>>>>>>> use FMIP to optimize handovers in such a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> scenario... Yes. Not FMIP, but
>>>>>>>
>>>>>>>
>>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> think we are looking at
>>>>>>>
>>>>>>>
>>>>>>>>>> optimizing
>>>>>>>>>> handovers in this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> discussion.
>>>>>>>
>>>>>>>
>>>>>>>>>> As per the current PMIP6 specification wherein no changes to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> the host are
>>>>>>>
>>>>>>>
>>>>>>>>>> required, it is not possible to do an inter-technology
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> handover. This is
>>>>>>>
>>>>>>>
>>>>>>>>>> a
>>>>>>>>>> limitation which implies that PMIP6 provides
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> host mobility to an MN
>>>>>>>
>>>>>>>
>>>>>>>>>> within
>>>>>>>>>> the scope of a single access
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> technology. Host based mobile IP does not
>>>>>>>
>>>>>>>
>>>>>>>>>> have
>>>>>>>>>> this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> problem.
>>>>>>>
>>>>>>>
>>>>>>>>>> -Raj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -Raj
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> BR
>>>>>>>>>>>> Frank
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> To:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> Cc:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> <[email-masked]>; "Ralph Droms" <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> Sent:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> Sunday, June 28, 2009 1:16 PM
>>>>>>>
>>>>>>>
>>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> of the bof description
>>>>>>>
>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> This is a first draft of the BOF description for your
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> consideration.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> It
>>>>>>>>>>>>> is
>>>>>>>>>>>>> still very open so, feel free to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> comment on whether the proposed
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> approach
>>>>>>>>>>>>> seems appropriate or
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> not.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> NETEXT2 BOF description
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> -----------------------
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> a network based mobility
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> PMIP6 provides mobility to
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> IP hosts without requiring any protocol
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> enhancements or additional
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> capabilities on the host.
>>>>>>>>>>>>> Current
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> PMIP6 specification fully defines how to provide mobility
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> support for
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> mobile nodes with a single interface roaming in a PMIP6
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> domain. The
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> goal of this BOF is gain understanding of how to support
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> nodes with
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> multiple interfaces (of possible different technologies) in
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> a
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> PMIP6 network.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> In particular, this BOF assumes the following
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> scenario:
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> multiple
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> access technologies and needs to support nodes that
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> have
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> multiple interfaces, possibly of different
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> technologies.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> In particular, the following capabilities are
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> needed:
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> - Inter-technology handover support. The MN has
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> initiated a
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> communication over one interface and it needs to be able
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> to move
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> the established connection to a different interface of
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> a possibly different technology. The reason for moving
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> communication to another interface is because of the MNs
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> mobility and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> attaching via a different interface. Basically
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> the ability to perform
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> handovers that span different access
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> technologies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> Multihoming support. The MN with multiple interfaces of possibly
>>>>>>>
>>>>>>> different technologies should be able to use them simultaneously to
>>>>>>>
>>>>>>> exchange data and manage the mobility of communications
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> established
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> through the different interfaces.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> - Flow mobility. A MN with
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> multiple interfaces of possibly
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> different technologies must be able to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> move a flow from
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> able
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> to inform the network through which interface it wishes
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> to receive different types of flows.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> In order to provide the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> support for these capabilities, different
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> approaches can be
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> envisioned, namely:
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> the mechanisms
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> to provide the required capabilities are fully L2
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> mechanisms and
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> no modification of the IP layer is needed.
>>>>>>>>>>>>> - L3
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> only approaches. In this type of approaches, the mechanism to
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> provide
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> to required capabilities are located in the IP layer
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> - Hybrid L2/L3
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> approaches. In this case, some mechanisms are
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> located in L2 and other
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> mechanisms are located in L3.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> Now, the different possible approaches
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> vary greatly in their nature
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> and resulting capabilities. To
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> understanding the benefits and
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> suitability of these alternatives, the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> requirements have to be
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> properly defined and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> understood.
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> The main goal of the BOF is understanding the need
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> for work in the
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> we will attempt
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> to:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Understand the applicable
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> scenarios, and the problem statement
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> related
>>>>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> those
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> 2) Understand the restrictions and requirement imposed to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> solutions to
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> address the problem statement and scenarios
>>>>>>>>>>>>> 3)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> Get an overview of the proposed solutions
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> netlmm mailing
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> netext mailing
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>>>>> [email-masked]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>
>>>>>>>>> MEXT mailing list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> [email-masked]
>>>>>>>
>>>>>>>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> [email-masked]
>>>>>>>
>>>>>>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>>
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> netlmm mailing
>>>>>>
>>>>>>
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

From [email-masked]  Tue Jun 30 09:22:26 2009
Content-class: urn:content-classes:message
Date: Tue, 30 Jun 2009 18:21:34 +0200
From: "MELIA TELEMACO" <[email-masked]>
To: "Marco Liebsch" <[email-masked]>, "Frank Xia" <[email-masked]>
Cc: mext <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hello,

Please see below.

>
>  This is a rare case.  If   "inter-technology handover"
>  focuses on dealing with this scenario, I am fine.
Still inter-tech handover is different from flow mobility. Also=20
complexity-wise.
For inter-technology handover the mobile may only provide hints about=20
the nature of
the handover (inter-tech HO etc), maybe about handover target or source=20
to the network.
If you want flow mobility, you need to handle flow descriptions and=20
signal appropriate
filters, hence much more to be done by the mobile and by the network.
Not sure the PMIPv6 protocol should handle flow filters..

If you move all flows during a handover, we're back at inter-tech=20
handover, say we
move the complete mobility session with the intention to shut down the=20
previous
mobility session (and with mobility session I mean the MN's binding=20
between the
HNP and the pMAG at the LMA). Moving the associated flows is implicit.

Hence, requirement on the mobile is very different for flow mobility and =

inter-tech handover
(shouldn't we say dual radio handover here?)

TELE: pretty much agree
Telemaco

marco

>
> BR
> Frank
>
> ----- Original Message ----- From: "MELIA TELEMACO"=20
> <[email-masked]>
> To: "Frank Xia" <[email-masked]>; "George Tsirtsis"=20
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>;=20
> <[email-masked]>; "mext" <[email-masked]>
> Sent: Monday, June 29, 2009 1:03 PM
> Subject: RE: [netlmm] [MEXT] NEXTEXT2: first draft of the bof =
description
>
>
> Frank,
>
> I think you should not mix flow mobility and inter-tech handover. A MN =

> might or might now use multiple connections at the same time...
>
> telemaco
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la=20
> part de Frank Xia
> Envoy=E9 : lundi 29 juin 2009 19:20
> =C0 : George Tsirtsis
> Cc : [email-masked]; [email-masked]; [email-masked]; =
mext
> Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof =
description
>
> Hi Gorge
>
> It seems that  I did not make me clear.
>
> 1)Single radio handover.
>   MN should disconnect from one BS , and connect
>   to a second BS.   MN can't connect to the two BS
>   at the same time.  Handover solutions (FMIP/PMIP)
>   are needed.
>
> 2)Dual radio handover
>   MN connects to the two BS'  at the same time.
>   Flow mobility is sufficient when move a flow( or  all
>   flows)  from  one interface to another.
>
> BR
> Frank
>
> ----- Original Message ----- From: "George Tsirtsis"=20
> <[email-masked]>
> To: "Frank Xia" <[email-masked]>
> Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>;=20
> "mext"
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, June 29, 2009 11:48 AM
> Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof =
description
>
>
> Frank, your comment below is strange to say the least.
>
> MIP handoffs can be between interfaces of the same or different
> technologies. Since client MIP works at the IP layer (above the Link
> Layer of any specific technology) there is nothing that client MIP
> (and any of its features) need to specifically define for
> inter-technology handoffs.
>
>  >Did you so far think that this means that client MIP only works
> intra-technology?<
>
> For PMIP, this is an issue because currently there is no defined
> protocol (on any layer) between MN and MAG...which is one of the
> issues to be discussed in netext2 bof.
>
> George
>
> On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia<[email-masked]> =
wrote:
>> Hi Guys
>>
>> I have comments on inter-technology handover.
>>
>> IMHO, flow mobility could solve problems
>> which inter-tech handover is try to deal with.
>> I assume that two heterogeneous interfaces are
>> all active during the handover. It is easy to move
>> a flow(or all flows) from an interface to another.
>>
>> This is probably the reason why there is no
>> inter-tech handover solution standerdized
>> for client MIP.
>>
>> BR
>> Frank
>>
>> ----- Original Message ----- From: "marcelo bagnulo braun"
>> <[email-masked]>
>> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
>> Sent: Sunday, June 28, 2009 1:16 PM
>> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>>
>>
>>> Hi,
>>>
>>> This is a first draft of the BOF description for your consideration. =
It
>>> is
>>> still very open so, feel free to comment on whether the proposed=20
>>> approach
>>> seems appropriate or not.
>>>
>>> NETEXT2 BOF description
>>> -----------------------
>>>
>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>>> IP hosts without requiring any protocol enhancements or additional
>>> capabilities on the host.
>>> Current PMIP6 specification fully defines how to provide mobility
>>> support for mobile nodes with a single interface roaming in a PMIP6
>>> domain. The goal of this BOF is gain understanding of how to support
>>> nodes with multiple interfaces (of possible different technologies)=20
>>> in a
>>> PMIP6 network.
>>>
>>> In particular, this BOF assumes the following scenario:
>>> We have a single PMIP6 domain that has deployed multiple
>>> access technologies and needs to support nodes that have
>>> multiple interfaces, possibly of different technologies.
>>>
>>> In particular, the following capabilities are needed:
>>>
>>> - Inter-technology handover support. The MN has initiated a
>>> communication over one interface and it needs to be able to move
>>> the established connection to a different interface of
>>> a possibly different technology. The reason for moving
>>> the communication to another interface is because of the MNs
>>> mobility and attaching via a different interface. Basically
>>> the ability to perform handovers that span different access
>>> technologies.
>>>
>>> - Multihoming support. The MN with multiple interfaces of possibly
>>> different technologies should be able to use them simultaneously to
>>> exchange data and manage the mobility of communications
>>> established through the different interfaces.
>>>
>>> - Flow mobility. A MN with multiple interfaces of possibly
>>> different technologies must be able to move a flow from
>>> one interface to another. Moreover, the MN should be able
>>> to inform the network through which interface it wishes
>>> to receive different types of flows.
>>>
>>> In order to provide the support for these capabilities, different
>>> approaches can be envisioned, namely:
>>> - L2 only approaches. In this type of approaches, the mechanisms
>>> to provide the required capabilities are fully L2 mechanisms and
>>> no modification of the IP layer is needed.
>>> - L3 only approaches. In this type of approaches, the mechanism to
>>> provide to required capabilities are located in the IP layer
>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>>> located in L2 and other mechanisms are located in L3.
>>> Now, the different possible approaches vary greatly in their nature
>>> and resulting capabilities. To understanding the benefits and
>>> suitability of these alternatives, the requirements have to be
>>> properly defined and understood.
>>>
>>> The main goal of the BOF is understanding the need for work in the
>>> IETF in this area. In order to do so, during the BOF, we will=20
>>> attempt to:
>>>
>>> 1) Understand the applicable scenarios, and the problem statement=20
>>> related
>>> to
>>> those
>>> 2) Understand the restrictions and requirement imposed to solutions =
to
>>> address the problem statement and scenarios
>>> 3) Get an overview of the proposed solutions
>>>
>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

From [email-masked]  Tue Jun 30 09:22:58 2009
Date: Tue, 30 Jun 2009 18:22:43 +0200
From: marcelo bagnulo braun <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

[email-masked] escribi�:
> Hi Hesham,
>
>
> On 6/30/09 8:48 AM, "ext Hesham Soliman" <[email-masked]> wrote:
>
>
>   
>> => I think the important question to ask is why this is an issue in the
>> first place? If you have a solution for the superset (all link layers) and
>> there is a question about whether you need a solution for a subset, then the
>> question we should ask is "why?". This has to be part of the discussion. "we
>> want ....*because*..."
>>
>> Hesham
>>
>>     
>
> We (as in the people in NetExt) want PMIP6 to support inter-technology
> handovers, flow binding/mobility and enhanced support for multihoming
> *because* :
> 1. Not every host does or will include host based mobility protocols such as
> (DS)MIP
>   
so what is the assumption requiremnent here?
Is the requriemnent that the solution must work wihtout requiring any 
host support? Or is there some level of host support that is acceptble? 
If so, why? (i mena, why some level of host support is accpetbale and 
other is not)

> 2. An operator may choose to deploy a network with only network based
> mobility protocol support
>
>   
right, what are the required functions that are provided by a network 
based mobility that are lacking in a host based mobility approach?

Regards, marcelo

> -Raj
>
>
>   

From [email-masked]  Tue Jun 30 09:24:56 2009
Date: Tue, 30 Jun 2009 09:24:32 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

>
> We (as in the people in NetExt) want PMIP6 to support inter-technology
> handovers, flow binding/mobility and enhanced support for multihoming
> *because* :
> 1. Not every host does or will include host based mobility protocols such as
> (DS)MIP
> 2. An operator may choose to deploy a network with only network based
> mobility protocol support
>
> -Raj
>

Absolutely. These features enable many practical usecases and we should
be able to allow them in a network that has deployed only network-based
mobility management protocol, with simple clients.

Sri

From [email-masked]  Tue Jun 30 09:32:01 2009
Content-class: urn:content-classes:message
Date: Tue, 30 Jun 2009 12:31:45 -0400
From: "Koodli, Rajeev" <[email-masked]>
To: "George Tsirtsis" <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription

Hi George, Raj,
=20

>=20
> GT> This is good justification answering the "why" and it leads to an
> obvious set of options for the "what". It implies something=20
> about the solution space that I would like this BOF to be=20
> specific about. i.e., if the reason to do this is to enable=20
> inter-tech and multi-homing without client MIP in the mobile,=20
> does it mean:
> a)  you do not want any mobility software in the mobile? (this seems
> unrealistic)

What constitutes "mobility software" without which the above features =
are unrealistic?

> b)  that you want L2 software in the client? (this is possible for
> *some* technologies and I do not think that such work belongs=20
> to the IETF...but the BOF could discuss this)

Agree. Part of this exercise is to identify what is feasible in L2, so =
that we don't spend our time on such things.

> c)  that you want network layer software in the  mobile but=20
> not MIP; (This clearly makes no sense given your "why")
>=20

We can start by saying that MIP has the ingredients you need to support =
the features of interest. For an operator, it is one of the options.

We also need to look at supporting mobile nodes without MIP. In other =
words, we can say for a feature X, 1) MIP is one of the options, and 2) =
use PMIP-extensions if your particular deployment does not permit you to =
use option 1).=20

Regards,

-Rajeev
=20

> Would you rather revise your "why" ? :-)
>=20
> George
>=20
> > One of the outcomes of this discussion is quite possibly=20
> the fact that=20
> > the IETF believes the use of host based mobile IP protocols is the=20
> > right choice and recommends it as such. And that is fine.=20
> But I think=20
> > we should also consider the approaches to providing these=20
> features for=20
> > PMIP6 which would not necessarily result in reinventing host based=20
> > mobile IP type of capabilities on the MNs.
> >
> > I don't know if the above justifies the reason why we are=20
> having this=20
> > discussion (yet again :) ).
> >
> > -Raj
> >
> >>
> >> Hesham
> >>
> >>>
> >>> Regards, marcelo
> >>>
> >>>> Hesham
> >>>>
> >>>>
> >>>>> Regards, marcelo
> >>>>>
> >>>>>
> >>>>> Hesham Soliman escribi=F3:
> >>>>>
> >>>>>> A quick comment.
> >>>>>> I don't see any reason for an IETF WG to look for a=20
> solution that=20
> >>>>>> works for a limited set of technologies and try to=20
> solve that on=20
> >>>>>> layer 2. This is clearly not our job. Similarly, there=20
> is little=20
> >>>>>> gain in solving this for a limited set of technologies on L3=20
> >>>>>> given that we already have a layer 2 agnostic=20
> solution. Why would=20
> >>>>>> we want to develop another one for a limited set of=20
> link layers?
> >>>>>>
> >>>>>> Hesham
> >>>>>>
> >>>>>>
> >>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun"=20
> <[email-masked]> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> George,
> >>>>>>>
> >>>>>>>
> >>>>>> great summary
> >>>>>>
> >>>>>> just one comment below...
> >>>>>>
> >>>>>>
> >>>>>> George Tsirtsis
> >>>>>>
> >>>>>>
> >>>>>>> escribi=F3:
> >>>>>>> With PMIP things are not so clear....it is not even=20
> clear we are
> >>>>>>>
> >>>>>>> talking about the *network layer*... and thus it is=20
> not so clear=20
> >>>>>>> how
> >>>>>>>
> >>>>>>> "generic" solutions can be.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> right, so one relevant question is how
> >>>>>>
> >>>>>>
> >>>>>>> generic we want this to be.
> >>>>>>>
> >>>>>>>
> >>>>>> For instance, it may be also sufficient to support
> >>>>>>
> >>>>>>
> >>>>>>> inter technology
> >>>>>>>
> >>>>>>>
> >>>>>> handovers for a subset of L2 technologies that can support
> >>>>>>
> >>>>>>
> >>>>>>> it at the L2
> >>>>>>>
> >>>>>>>
> >>>>>> as you stated.
> >>>>>> So, one thing that we need to define is whether
> >>>>>>
> >>>>>>
> >>>>>>> we are looking for a
> >>>>>>>
> >>>>>>>
> >>>>>> solution that supports inter technology handover with
> >>>>>>
> >>>>>>
> >>>>>>> any two L2
> >>>>>>>
> >>>>>>>
> >>>>>> combiantios or are we looking for a solution that=20
> supports inter
> >>>>>>
> >>>>>> technology handovers for a limited set of technologies?
> >>>>>> I think this is a key
> >>>>>>
> >>>>>>
> >>>>>>> requirements that we need to be explicit about.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> The challenge for the BOF
> >>>>>>> is to throw some light on how PMIP can be compatible=20
> with this=20
> >>>>>>> extended functionality, =A0what type of additional=20
> signalling is=20
> >>>>>>> needed, and at which layer they intend to implement such=20
> >>>>>>> signalling. Let's see.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> while i
> >>>>>>
> >>>>>>
> >>>>>>> agree with that, i think a first step that this bof needs to
> >>>>>>>
> >>>>>>>
> >>>>>> throw some light
> >>>>>>
> >>>>>>
> >>>>>>> on is what are the functional requirements for the
> >>>>>>>
> >>>>>>>
> >>>>>> support of the required
> >>>>>>
> >>>>>>
> >>>>>>> features. I think the previous is a good example
> >>>>>>>
> >>>>>>>
> >>>>>> of one requirement that we
> >>>>>>
> >>>>>>
> >>>>>>> need to flesh out. There are many others.
> >>>>>>>
> >>>>>>>
> >>>>>> Regards, marcelo
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> George
> >>>>>>>
> >>>>>>> On
> >>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
> >>>>>>>
> >>>>>>> Perkins<[email-masked]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hello Basavaraj,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Isn't make-before-break a function performed
> >>>>>>>
> >>>>>>>
> >>>>>>>> at the link layer?
> >>>>>>>>
> >>>>>>>> It
> >>>>>>>>
> >>>>>>>>
> >>>>>>> certainly isn't PHY, and I wouldn't think it
> >>>>>>>
> >>>>>>>
> >>>>>>>> qualifies as MAC (i.e., it
> >>>>>>>>
> >>>>>>>>
> >>>>>>> doesn't control the
> >>>>>>>
> >>>>>>>
> >>>>>>>> device's access to the medium).
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Charlie P.
> >>>>>>>
> >>>>>>>
> >>>>>>>> PS. Which is the proper mailing list for this
> >>>>>>>>
> >>>>>>>>
> >>>>>>> discussion?
> >>>>>>>
> >>>>>>>
> >>>>>>>> [email-masked] wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Hi
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> Frank,
> >>>>>>>
> >>>>>>>
> >>>>>>>>> Make-before-break is inherently supported in certain
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> technologies such as
> >>>>>>>
> >>>>>>>
> >>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> same is not possible
> >>>>>>>
> >>>>>>>
> >>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> WiFi). 802.16e does have a
> >>>>>>>
> >>>>>>>
> >>>>>>>>> contorted mechansim for achieving the same but
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> that's besides the point.
> >>>>>>>
> >>>>>>>
> >>>>>>>>> So IMO it is a capability of the Phy/Mac.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> However it is possible to emulate soft-handovers and achieve
> >>>>>>>
> >>>>>>> make-before-break in certain cases. For example it is=20
> possible=20
> >>>>>>> to be
> >>>>>>>
> >>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
> >>>>>>>
> >>>>>>> make-before-break
> >>>>>>>
> >>>>>>>
> >>>>>>>>> HO. I guess the definition of the term depends on an
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> access tchnology or
> >>>>>>>
> >>>>>>>
> >>>>>>>>> the
> >>>>>>>>> combination of access technologies in the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> context of a use-case.
> >>>>>>>
> >>>>>>>
> >>>>>>>>> -Raj
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> Xia" <[email-masked]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Hi Raj
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> IMHO Make-before-break is not a link-layer technology.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> , but =A0a concept
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> (or a strategy). =A0 =A0Related to the topic we
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> are discussing, making target
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> interface ready before moving
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> traffic to it is kind of
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> make-before-break.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> BR
> >>>>>>>>>> Frank
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> -----
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> From: <[email-masked]>
> >>>>>>>>>> To:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> <[email-masked]>; <[email-masked]>;=20
> >>>>>>> <[email-masked]>;
> >>>>>>>
> >>>>>>> <[email-masked]>; <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> Cc: <[email-masked]>;
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
> >>>>>>>>>> Subject: Re:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
> >>>>>>>
> >>>>>>> description
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> Hi Frank,
> >>>>>>>>>>
> >>>>>>>>>> Comments
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> inline:
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> <[email-masked]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Hi
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> Raj
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> My main point is make-before-break strategy is the best
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> way to solve multi-radio handover.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> The IETF cannot
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> do anything about whether an MN has the ability to
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> accomplish
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> make-before-break connectivity. It depends on the link-layer
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> technology,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> spectrum that they operate in, etc. So this approach is a
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> non-starter.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> The IETF solution has to be agnostic to underlying access
> >>>>>>>
> >>>>>>> technologies.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Please see my inline
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> response.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> BR
> >>>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> To: <[email-masked]>;
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[email-masked]>; <[email-masked]>;
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> <[email-masked]>;
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> Cc: <[email-masked]>;
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
> >>>>>>>>>>> Subject:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
> >>>>>>> description
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> Frank,
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 6/29/09 11:16
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Guys
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have comments on inter-technology
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> handover.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> IMHO, flow mobility could solve problems
> >>>>>>>>>>>> which
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> inter-tech handover is try to deal with.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> Flow
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> mobility also includes the ability to move a flow=20
> from one mobility
> >>>>>>>
> >>>>>>> session to another. Multiple mobility sessions could=20
> be established via
> >>>>>>>
> >>>>>>> a
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> single interface in which case flow mobility=20
> would be achieved
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> within
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> the
> >>>>>>>>>>> scope of a single interface. Hence flow mobility and
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> inter-technology
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> handovers are separate features.
> >>>>>>>>>>> Frank=3D>IMHO,
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> inter-technology is trying to move all the traffic on
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> one interface to
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> another interface.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Right. I guess you answered the
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> question about the difference between
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> flow
> >>>>>>>>>> mobility and
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> inter-technology handovers. You could extrapolate and say
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> that
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> inter-technology HO is the case where you move all=20
> flows from one
> >>>>>>>
> >>>>>>> interface
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> to another and hence a variant of flow mobility.=20
> While that is
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> true, you
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> should also recognize that the granularity of flow=20
> mobility is
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> finer and
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> does not have to necessarily be a relocation of a=20
> flow between
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> physical
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> interfaces.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>> I assume that two
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> heterogeneous interfaces are
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> all active during the handover. =A0It is
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> easy to move
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> a flow(or all flows) from an interface to
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> another.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> Possibly.. But the point is to
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> identify what extensions (possibly to the
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> MN)
> >>>>>>>>>>> are needed in order
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> to achieve handovers across interfaces.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> Frank=3D>If we see inter-tech
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> handover as a subset of flow mobility,
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> there is one problem left, that
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> is flow mobility.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> See above. Flow mobility is a
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> feature that can work across multiple
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> mobility
> >>>>>>>>>> sessions within the
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> scope of a single interface as well.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>> This is
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> probably the reason why there is no
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> inter-tech handover solution
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> standerdized
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> for client MIP.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> Client
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> MIP inherently supports handovers across multiple interfaces.
> >>>>>>>
> >>>>>>> Performance improvements to the handovers are=20
> accomplished using
> >>>>>>>
> >>>>>>> solutions
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> such as FMIP.
> >>>>>>>>>>> Frank=3D>Maybe, I am missing something.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> However FMIP =A0is not applicable
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> to PAR/NAR collocated scenario. =A0For
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> example, a mobile node with two
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> interface connects to the same access
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> router (ASN-GW for WiMAX,
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> PDN-GW for LTE). =A0 Does FMIP work when mobile
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> node handover from
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> one technology to another?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Not sure I understand the question. In your=20
> example above, I believe
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> MN
> >>>>>>>>>> would connect to the ASN-GW via the WiMAX=20
> interface and to an
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> S-GW via
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> the
> >>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> question is, can
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> you
> >>>>>>>>>> use FMIP to optimize handovers in such a
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> scenario... Yes. Not FMIP, but
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> think we are looking at
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> optimizing
> >>>>>>>>>> handovers in this
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> discussion.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> As per the current PMIP6 specification wherein no=20
> changes to
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> the host are
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> required, it is not possible to do an inter-technology
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> handover. This is
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> a
> >>>>>>>>>> limitation which implies that PMIP6 provides
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> host mobility to an MN
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> within
> >>>>>>>>>> the scope of a single access
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> technology. Host based mobile IP does not
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> have
> >>>>>>>>>> this
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> problem.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> -Raj
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -Raj
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> BR
> >>>>>>>>>>>> Frank
> >>>>>>>>>>>>
> >>>>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> To:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> Cc:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> <[email-masked]>; "Ralph Droms"=20
> <[email-masked]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> Sent:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> Sunday, June 28, 2009 1:16 PM
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> of the bof description
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> This is a first draft of the BOF description for your
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> consideration.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> It
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>> still very open so, feel free to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> comment on whether the proposed
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> approach
> >>>>>>>>>>>>> seems appropriate or
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> not.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> NETEXT2 BOF description
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> -----------------------
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> a network based mobility
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> PMIP6 provides mobility to
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> IP hosts without requiring any protocol
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> enhancements or additional
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> capabilities on the host.
> >>>>>>>>>>>>> Current
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> PMIP6 specification fully defines how to provide mobility
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> support for
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> mobile nodes with a single interface roaming in a PMIP6
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> domain. The
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> goal of this BOF is gain understanding of how to support
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> nodes with
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> multiple interfaces (of possible different technologies) in
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> a
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> PMIP6 network.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> In particular, this BOF assumes the following
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> scenario:
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> multiple
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> access technologies and needs to support nodes that
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> have
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> multiple interfaces, possibly of different
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> technologies.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> In particular, the following capabilities are
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> needed:
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> - Inter-technology handover support. The MN has
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> initiated a
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> communication over one interface and it needs to be able
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> to move
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> the established connection to a different interface of
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> a possibly different technology. The reason for moving
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> communication to another interface is because of the MNs
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> mobility and
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> attaching via a different interface. Basically
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> the ability to perform
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> handovers that span different access
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> technologies.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> Multihoming support. The MN with multiple interfaces=20
> of possibly
> >>>>>>>
> >>>>>>> different technologies should be able to use them=20
> simultaneously to
> >>>>>>>
> >>>>>>> exchange data and manage the mobility of communications
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> established
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> through the different interfaces.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> - Flow mobility. A MN with
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> multiple interfaces of possibly
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> different technologies must be able to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> move a flow from
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> one interface to another. Moreover, the MN should be
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> able
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> to inform the network through which interface it wishes
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> to receive different types of flows.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> In order to provide the
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> support for these capabilities, different
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> approaches can be
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> envisioned, namely:
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> the mechanisms
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> to provide the required capabilities are fully L2
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> mechanisms and
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> no modification of the IP layer is needed.
> >>>>>>>>>>>>> - L3
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> only approaches. In this type of approaches, the mechanism to
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> provide
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> to required capabilities are located in the IP layer
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> - Hybrid L2/L3
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> approaches. In this case, some mechanisms are
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> located in L2 and other
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> mechanisms are located in L3.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> Now, the different possible approaches
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> vary greatly in their nature
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> and resulting capabilities. To
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> understanding the benefits and
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> suitability of these alternatives, the
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> requirements have to be
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> properly defined and
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> understood.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> The main goal of the BOF is understanding the need
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> for work in the
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> we will attempt
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> to:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1) Understand the applicable
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> scenarios, and the problem statement
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> related
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> those
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> 2) Understand the restrictions and requirement=20
> imposed to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> solutions to
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> address the problem statement and scenarios
> >>>>>>>>>>>>> 3)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> Get an overview of the proposed solutions
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> netlmm mailing
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> list
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> [email-masked]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> netext mailing
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> list
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> [email-masked]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>>
> >>>>>>>
> >>>>>>>>> MEXT mailing list
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> [email-masked]
> >>>>>>>
> >>>>>>>
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> MEXT mailing list
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> [email-masked]
> >>>>>>>
> >>>>>>>
> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> netlmm mailing list
> >>>>>>>
> >>>>>>> [email-masked]
> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> netlmm mailing
> >>>>>>
> >>>>>>
> >>>>>>> list
> >>>>>>>
> >>>>>>>
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>=20

From [email-masked]  Tue Jun 30 09:38:41 2009
Date: Tue, 30 Jun 2009 09:36:07 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Marcelo,

On Tue, 30 Jun 2009, marcelo bagnulo braun wrote:

>> 
> so what is the assumption requiremnent here?
> Is the requriemnent that the solution must work wihtout requiring any host 
> support? Or is there some level of host support that is acceptble? If so, 
> why? (i mena, why some level of host support is accpetbale and other is not)
>
>

The requirement is to have that intelligence on the network for supporting
these features, while allowing the mobile node to only express preferences
on network attachment/multihoming or flow mobility. The participation of
the client will be to minimal proportions. The goal is to have a simple
client, with a minimal software component such as for managing these
aspects and not require an extensive set of protocol stacks.

>>  2. An operator may choose to deploy a network with only network based
>>  mobility protocol support
>>
>> 
> right, what are the required functions that are provided by a network based 
> mobility that are lacking in a host based mobility approach?
>

I'm not sure, if we want to compare the missing features and say they
will be available in host mobility protocols and so we go that route.
We could have said that even before we standardized network-based
mobility approaches. But, there is interest to support network-based
mobility protocols and so we need to ensure we do that job completly.

Industry has accepted network-based mobility approaches in the form of
GTP/PMIPv6. We have to add the missing features and support that
accepted model completly. This is about completing the work.

Regards
Sri

> Regards, marcelo
>
>
>>  -Raj
>> 
>>
>> 
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>
>

From [email-masked]  Tue Jun 30 09:41:41 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 30 Jun 2009 17:52:07 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

On 6/30/09 9:54 AM, "ext Hesham Soliman" <[email-masked]> wrote:

>
>
>
>>>
>>> =3D> I think the important question to ask is why this is an issue in t=
he
>>> first place? If you have a solution for the superset (all link layers)
>> you are assuming and answer here, i.e. that the answer is that the
>> requirement is a subset, which i don't know if it is the case
>>
>>>  and
>>> there is a question about whether you need a solution for a subset, the=
n the
>>> question we should ask is "why?". This has to be part of the discussion=
. "we
>>> want ....*because*..."
>>>
>>>
>> sure, "why?" is a valid question, but before asking ourselves "why?", we
>> need to answer "what?"
>>
>> So, let's first provide an detailed answer of what is being required to
>> support and and that point we will be in good shape to ask "why?"
>> i don't think you can ask "why? until a proper answer has been provide
>> to "what?"
>>
>> agree?
>
> =3D> Ok, you're right about my assumption about the answer but it's not c=
oming
> from vaccuum :), it's not the first time this is discussed. But ok, I'm
> happy to go through this exercise from the beginning. Let's ask "what" an=
d
> regardless of the answer ask "why" as well. Because requirements always n=
eed
> to be justified.

I think there is a reasonably good understanding that for the problems (wha=
t
aspects in the discussion here) that are being stated, (DS)MIP6 is able to
provide a solution already. I don't think that it is a surprise to anyone.
So the question is : Why? If the IETF already has a solution for dealing
with inter-technology handovers, flow binding/mobility and multihoming (RFC=
s
3775/5555 and related I-Ds in MEXT WG) why do we need to develop the same
capabilities for network based mobility protocol (RFC5213)?

Quite simply, the answer is that in certain deployments it is not feasible
to expect DS(MIP6) capability on hosts. An operator cannot expect that ever=
y
host connecting to the network implements (DS)MIP6. The operator has no
control of the hosts or their capabilities to a large extent. The only thin=
g
the operator can and does control is the network, and hence the
consideration to add such capabilities to a deployment which used network
based mobility protocol.

One of the outcomes of this discussion is quite possibly the fact that the
IETF believes the use of host based mobile IP protocols is the right choice
and recommends it as such. And that is fine. But I think we should also
consider the approaches to providing these features for PMIP6 which would
not necessarily result in reinventing host based mobile IP type of
capabilities on the MNs.

I don't know if the above justifies the reason why we are having this
discussion (yet again :) ).

-Raj

>
> Hesham
>
>>
>> Regards, marcelo
>>
>>> Hesham
>>>
>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>> Hesham Soliman escribi=F3:
>>>>
>>>>> A quick comment.
>>>>> I don't see any reason for an IETF WG to look for a solution that wor=
ks
>>>>> for
>>>>> a limited set of technologies and try to solve that on layer 2. This =
is
>>>>> clearly not our job. Similarly, there is little gain in solving this =
for a
>>>>> limited set of technologies on L3 given that we already have a layer =
2
>>>>> agnostic solution. Why would we want to develop another one for a lim=
ited
>>>>> set of link layers?
>>>>>
>>>>> Hesham
>>>>>
>>>>>
>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" <[email-masked]> wr=
ote:
>>>>>
>>>>>
>>>>>
>>>>>> George,
>>>>>>
>>>>>>
>>>>> great summary
>>>>>
>>>>> just one comment below...
>>>>>
>>>>>
>>>>> George Tsirtsis
>>>>>
>>>>>
>>>>>> escribi=F3:
>>>>>> With PMIP things are not so clear....it is not even clear we are
>>>>>>
>>>>>> talking about the *network layer*... and thus it is not so clear how
>>>>>>
>>>>>> "generic" solutions can be.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> right, so one relevant question is how
>>>>>
>>>>>
>>>>>> generic we want this to be.
>>>>>>
>>>>>>
>>>>> For instance, it may be also sufficient to support
>>>>>
>>>>>
>>>>>> inter technology
>>>>>>
>>>>>>
>>>>> handovers for a subset of L2 technologies that can support
>>>>>
>>>>>
>>>>>> it at the L2
>>>>>>
>>>>>>
>>>>> as you stated.
>>>>> So, one thing that we need to define is whether
>>>>>
>>>>>
>>>>>> we are looking for a
>>>>>>
>>>>>>
>>>>> solution that supports inter technology handover with
>>>>>
>>>>>
>>>>>> any two L2
>>>>>>
>>>>>>
>>>>> combiantios or are we looking for a solution that supports inter
>>>>>
>>>>> technology handovers for a limited set of technologies?
>>>>> I think this is a key
>>>>>
>>>>>
>>>>>> requirements that we need to be explicit about.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>> The challenge for the BOF
>>>>>> is to throw some light on how PMIP can be
>>>>>> compatible with this extended
>>>>>> functionality,  what type of additional
>>>>>> signalling is needed, and at which
>>>>>> layer they intend to implement such
>>>>>> signalling. Let's see.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> while i
>>>>>
>>>>>
>>>>>> agree with that, i think a first step that this bof needs to
>>>>>>
>>>>>>
>>>>> throw some light
>>>>>
>>>>>
>>>>>> on is what are the functional requirements for the
>>>>>>
>>>>>>
>>>>> support of the required
>>>>>
>>>>>
>>>>>> features. I think the previous is a good example
>>>>>>
>>>>>>
>>>>> of one requirement that we
>>>>>
>>>>>
>>>>>> need to flesh out. There are many others.
>>>>>>
>>>>>>
>>>>> Regards, marcelo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> George
>>>>>>
>>>>>> On
>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>>>>>>
>>>>>> Perkins<[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hello Basavaraj,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Isn't make-before-break a function performed
>>>>>>
>>>>>>
>>>>>>> at the link layer?
>>>>>>>
>>>>>>> It
>>>>>>>
>>>>>>>
>>>>>> certainly isn't PHY, and I wouldn't think it
>>>>>>
>>>>>>
>>>>>>> qualifies as MAC (i.e., it
>>>>>>>
>>>>>>>
>>>>>> doesn't control the
>>>>>>
>>>>>>
>>>>>>> device's access to the medium).
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Charlie P.
>>>>>>
>>>>>>
>>>>>>> PS. Which is the proper mailing list for this
>>>>>>>
>>>>>>>
>>>>>> discussion?
>>>>>>
>>>>>>
>>>>>>> [email-masked] wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>>
>>>>>> Frank,
>>>>>>
>>>>>>
>>>>>>>> Make-before-break is inherently supported in certain
>>>>>>>>
>>>>>>>>
>>>>>> technologies such as
>>>>>>
>>>>>>
>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>>>>>>>>
>>>>>>>>
>>>>>> same is not possible
>>>>>>
>>>>>>
>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>>>>>>>>
>>>>>>>>
>>>>>> WiFi). 802.16e does have a
>>>>>>
>>>>>>
>>>>>>>> contorted mechansim for achieving the same but
>>>>>>>>
>>>>>>>>
>>>>>> that's besides the point.
>>>>>>
>>>>>>
>>>>>>>> So IMO it is a capability of the Phy/Mac.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> However it is possible to emulate soft-handovers and achieve
>>>>>>
>>>>>> make-before-break in certain cases. For example it is possible to be
>>>>>>
>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>>>>>>
>>>>>> make-before-break
>>>>>>
>>>>>>
>>>>>>>> HO. I guess the definition of the term depends on an
>>>>>>>>
>>>>>>>>
>>>>>> access tchnology or
>>>>>>
>>>>>>
>>>>>>>> the
>>>>>>>> combination of access technologies in the
>>>>>>>>
>>>>>>>>
>>>>>> context of a use-case.
>>>>>>
>>>>>>
>>>>>>>> -Raj
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>>>>>>>>
>>>>>>>>
>>>>>> Xia" <[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> IMHO Make-before-break is not a link-layer technology.
>>>>>>
>>>>>>
>>>>>>>>> , but  a concept
>>>>>>>>>
>>>>>>>>>
>>>>>> (or a strategy).    Related to the topic we
>>>>>>
>>>>>>
>>>>>>>>> are discussing, making target
>>>>>>>>>
>>>>>>>>>
>>>>>> interface ready before moving
>>>>>>
>>>>>>
>>>>>>>>> traffic to it is kind of
>>>>>>>>>
>>>>>>>>>
>>>>>> make-before-break.
>>>>>>
>>>>>>
>>>>>>>>> BR
>>>>>>>>> Frank
>>>>>>>>>
>>>>>>>>> ----- Original Message
>>>>>>>>>
>>>>>>>>>
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>>>> From: <[email-masked]>
>>>>>>>>> To:
>>>>>>>>>
>>>>>>>>>
>>>>>> <[email-masked]>; <[email-masked]>; <[email-masked]>;
>>>>>>
>>>>>> <[email-masked]>; <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>
>>>>>>>>>
>>>>>> <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>>>>>>>>> Subject: Re:
>>>>>>>>>
>>>>>>>>>
>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>>>>>>
>>>>>> description
>>>>>>
>>>>>>
>>>>>>>>> Hi Frank,
>>>>>>>>>
>>>>>>>>> Comments
>>>>>>>>>
>>>>>>>>>
>>>>>> inline:
>>>>>>
>>>>>>
>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>>>>>>>>>
>>>>>>>>>
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>>
>>>>>> Raj
>>>>>>
>>>>>>
>>>>>>>>>> My main point is make-before-break strategy
>>>>>>>>>> is the best
>>>>>>>>>>
>>>>>>>>>>
>>>>>> way to solve multi-radio handover.
>>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> The IETF cannot
>>>>>>>>>
>>>>>>>>>
>>>>>> do anything about whether an MN has the ability to
>>>>>>
>>>>>>
>>>>>>>>> accomplish
>>>>>>>>>
>>>>>>>>>
>>>>>> make-before-break connectivity. It depends on the link-layer
>>>>>>
>>>>>>
>>>>>>>>> technology,
>>>>>>>>>
>>>>>>>>>
>>>>>> spectrum that they operate in, etc. So this approach is a
>>>>>>
>>>>>>
>>>>>>>>> non-starter.
>>>>>>>>>
>>>>>>>>>
>>>>>> The IETF solution has to be agnostic to underlying access
>>>>>>
>>>>>> technologies.
>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Please see my inline
>>>>>>>>>>
>>>>>>>>>>
>>>>>> response.
>>>>>>
>>>>>>
>>>>>>>>>> BR
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From:
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>>> To: <[email-masked]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[email-masked]>; <[email-masked]>;
>>>>>>
>>>>>>
>>>>>>>>>> <[email-masked]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>>>>>>>>>> Subject:
>>>>>>>>>>
>>>>>>>>>>
>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>>>>>> description
>>>>>>
>>>>>>
>>>>>>>>>> Frank,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6/29/09 11:16
>>>>>>>>>>
>>>>>>>>>>
>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Guys
>>>>>>>>>>>
>>>>>>>>>>> I have comments on inter-technology
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> handover.
>>>>>>
>>>>>>
>>>>>>>>>>> IMHO, flow mobility could solve problems
>>>>>>>>>>> which
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> inter-tech handover is try to deal with.
>>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Flow
>>>>>>>>>>
>>>>>>>>>>
>>>>>> mobility also includes the ability to move a flow from one mobility
>>>>>>
>>>>>> session to another. Multiple mobility sessions could be established =
via
>>>>>>
>>>>>> a
>>>>>>
>>>>>>
>>>>>>>>>> single interface in which case flow mobility would be achieved
>>>>>>>>>>
>>>>>>>>>>
>>>>>> within
>>>>>>
>>>>>>
>>>>>>>>>> the
>>>>>>>>>> scope of a single interface. Hence flow mobility and
>>>>>>>>>>
>>>>>>>>>>
>>>>>> inter-technology
>>>>>>
>>>>>>
>>>>>>>>>> handovers are separate features.
>>>>>>>>>> Frank=3D>IMHO,
>>>>>>>>>>
>>>>>>>>>>
>>>>>> inter-technology is trying to move all the traffic on
>>>>>>
>>>>>>
>>>>>>>>>> one interface to
>>>>>>>>>>
>>>>>>>>>>
>>>>>> another interface.
>>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Right. I guess you answered the
>>>>>>>>>
>>>>>>>>>
>>>>>> question about the difference between
>>>>>>
>>>>>>
>>>>>>>>> flow
>>>>>>>>> mobility and
>>>>>>>>>
>>>>>>>>>
>>>>>> inter-technology handovers. You could extrapolate and say
>>>>>>
>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> inter-technology HO is the case where you move all flows from one
>>>>>>
>>>>>> interface
>>>>>>
>>>>>>
>>>>>>>>> to another and hence a variant of flow mobility. While that is
>>>>>>>>>
>>>>>>>>>
>>>>>> true, you
>>>>>>
>>>>>>
>>>>>>>>> should also recognize that the granularity of flow mobility is
>>>>>>>>>
>>>>>>>>>
>>>>>> finer and
>>>>>>
>>>>>>
>>>>>>>>> does not have to necessarily be a relocation of a flow between
>>>>>>>>>
>>>>>>>>>
>>>>>> physical
>>>>>>
>>>>>>
>>>>>>>>> interfaces.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> I assume that two
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> heterogeneous interfaces are
>>>>>>
>>>>>>
>>>>>>>>>>> all active during the handover.  It is
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> easy to move
>>>>>>
>>>>>>
>>>>>>>>>>> a flow(or all flows) from an interface to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> another.
>>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Possibly.. But the point is to
>>>>>>>>>>
>>>>>>>>>>
>>>>>> identify what extensions (possibly to the
>>>>>>
>>>>>>
>>>>>>>>>> MN)
>>>>>>>>>> are needed in order
>>>>>>>>>>
>>>>>>>>>>
>>>>>> to achieve handovers across interfaces.
>>>>>>
>>>>>>
>>>>>>>>>> Frank=3D>If we see inter-tech
>>>>>>>>>>
>>>>>>>>>>
>>>>>> handover as a subset of flow mobility,
>>>>>>
>>>>>>
>>>>>>>>>> there is one problem left, that
>>>>>>>>>>
>>>>>>>>>>
>>>>>> is flow mobility.
>>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> See above. Flow mobility is a
>>>>>>>>>
>>>>>>>>>
>>>>>> feature that can work across multiple
>>>>>>
>>>>>>
>>>>>>>>> mobility
>>>>>>>>> sessions within the
>>>>>>>>>
>>>>>>>>>
>>>>>> scope of a single interface as well.
>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> This is
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> probably the reason why there is no
>>>>>>
>>>>>>
>>>>>>>>>>> inter-tech handover solution
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> standerdized
>>>>>>
>>>>>>
>>>>>>>>>>> for client MIP.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Client
>>>>>>>>>>
>>>>>>>>>>
>>>>>> MIP inherently supports handovers across multiple interfaces.
>>>>>>
>>>>>> Performance improvements to the handovers are accomplished using
>>>>>>
>>>>>> solutions
>>>>>>
>>>>>>
>>>>>>>>>> such as FMIP.
>>>>>>>>>> Frank=3D>Maybe, I am missing something.
>>>>>>>>>>
>>>>>>>>>>
>>>>>> However FMIP  is not applicable
>>>>>>
>>>>>>
>>>>>>>>>> to PAR/NAR collocated scenario.  For
>>>>>>>>>>
>>>>>>>>>>
>>>>>> example, a mobile node with two
>>>>>>
>>>>>>
>>>>>>>>>> interface connects to the same access
>>>>>>>>>>
>>>>>>>>>>
>>>>>> router (ASN-GW for WiMAX,
>>>>>>
>>>>>>
>>>>>>>>>> PDN-GW for LTE).   Does FMIP work when mobile
>>>>>>>>>>
>>>>>>>>>>
>>>>>> node handover from
>>>>>>
>>>>>>
>>>>>>>>>> one technology to another?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Not sure I understand the question. In your example above, I beli=
eve
>>>>>>>>>
>>>>>>>>>
>>>>>> the
>>>>>>
>>>>>>
>>>>>>>>> MN
>>>>>>>>> would connect to the ASN-GW via the WiMAX interface and to an
>>>>>>>>>
>>>>>>>>>
>>>>>> S-GW via
>>>>>>
>>>>>>
>>>>>>>>> the
>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>>>>>>>>>
>>>>>>>>>
>>>>>> question is, can
>>>>>>
>>>>>>
>>>>>>>>> you
>>>>>>>>> use FMIP to optimize handovers in such a
>>>>>>>>>
>>>>>>>>>
>>>>>> scenario... Yes. Not FMIP, but
>>>>>>
>>>>>>
>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>>>>>>>>>
>>>>>>>>>
>>>>>> think we are looking at
>>>>>>
>>>>>>
>>>>>>>>> optimizing
>>>>>>>>> handovers in this
>>>>>>>>>
>>>>>>>>>
>>>>>> discussion.
>>>>>>
>>>>>>
>>>>>>>>> As per the current PMIP6 specification wherein no changes to
>>>>>>>>>
>>>>>>>>>
>>>>>> the host are
>>>>>>
>>>>>>
>>>>>>>>> required, it is not possible to do an inter-technology
>>>>>>>>>
>>>>>>>>>
>>>>>> handover. This is
>>>>>>
>>>>>>
>>>>>>>>> a
>>>>>>>>> limitation which implies that PMIP6 provides
>>>>>>>>>
>>>>>>>>>
>>>>>> host mobility to an MN
>>>>>>
>>>>>>
>>>>>>>>> within
>>>>>>>>> the scope of a single access
>>>>>>>>>
>>>>>>>>>
>>>>>> technology. Host based mobile IP does not
>>>>>>
>>>>>>
>>>>>>>>> have
>>>>>>>>> this
>>>>>>>>>
>>>>>>>>>
>>>>>> problem.
>>>>>>
>>>>>>
>>>>>>>>> -Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -Raj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> BR
>>>>>>>>>>> Frank
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>>>> To:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>>>> Cc:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> <[email-masked]>; "Ralph Droms" <[email-masked]>
>>>>>>
>>>>>>
>>>>>>>>>>> Sent:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> Sunday, June 28, 2009 1:16 PM
>>>>>>
>>>>>>
>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> of the bof description
>>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>>>>>>> This is a first draft of the BOF description for your
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> consideration.
>>>>>>
>>>>>>
>>>>>>>>>>>> It
>>>>>>>>>>>> is
>>>>>>>>>>>> still very open so, feel free to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> comment on whether the proposed
>>>>>>
>>>>>>
>>>>>>>>>>>> approach
>>>>>>>>>>>> seems appropriate or
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> not.
>>>>>>
>>>>>>
>>>>>>>>>>>> NETEXT2 BOF description
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> -----------------------
>>>>>>
>>>>>>
>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> a network based mobility
>>>>>>
>>>>>>
>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> PMIP6 provides mobility to
>>>>>>
>>>>>>
>>>>>>>>>>>> IP hosts without requiring any protocol
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> enhancements or additional
>>>>>>
>>>>>>
>>>>>>>>>>>> capabilities on the host.
>>>>>>>>>>>> Current
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> PMIP6 specification fully defines how to provide mobility
>>>>>>
>>>>>>
>>>>>>>>>>>> support for
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> mobile nodes with a single interface roaming in a PMIP6
>>>>>>
>>>>>>
>>>>>>>>>>>> domain. The
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> goal of this BOF is gain understanding of how to support
>>>>>>
>>>>>>
>>>>>>>>>>>> nodes with
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> multiple interfaces (of possible different technologies) in
>>>>>>
>>>>>>
>>>>>>>>>>>> a
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> PMIP6 network.
>>>>>>
>>>>>>
>>>>>>>>>>>> In particular, this BOF assumes the following
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> scenario:
>>>>>>
>>>>>>
>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> multiple
>>>>>>
>>>>>>
>>>>>>>>>>>> access technologies and needs to support nodes that
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> have
>>>>>>
>>>>>>
>>>>>>>>>>>> multiple interfaces, possibly of different
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> technologies.
>>>>>>
>>>>>>
>>>>>>>>>>>> In particular, the following capabilities are
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> needed:
>>>>>>
>>>>>>
>>>>>>>>>>>> - Inter-technology handover support. The MN has
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> initiated a
>>>>>>
>>>>>>
>>>>>>>>>>>> communication over one interface and it needs to be able
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> to move
>>>>>>
>>>>>>
>>>>>>>>>>>> the established connection to a different interface of
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> a possibly different technology. The reason for moving
>>>>>>
>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> communication to another interface is because of the MNs
>>>>>>
>>>>>>
>>>>>>>>>>>> mobility and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> attaching via a different interface. Basically
>>>>>>
>>>>>>
>>>>>>>>>>>> the ability to perform
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> handovers that span different access
>>>>>>
>>>>>>
>>>>>>>>>>>> technologies.
>>>>>>>>>>>>
>>>>>>>>>>>> -
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> Multihoming support. The MN with multiple interfaces of possibly
>>>>>>
>>>>>> different technologies should be able to use them simultaneously to
>>>>>>
>>>>>> exchange data and manage the mobility of communications
>>>>>>
>>>>>>
>>>>>>>>>>>> established
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> through the different interfaces.
>>>>>>
>>>>>>
>>>>>>>>>>>> - Flow mobility. A MN with
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> multiple interfaces of possibly
>>>>>>
>>>>>>
>>>>>>>>>>>> different technologies must be able to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> move a flow from
>>>>>>
>>>>>>
>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> able
>>>>>>
>>>>>>
>>>>>>>>>>>> to inform the network through which interface it wishes
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> to receive different types of flows.
>>>>>>
>>>>>>
>>>>>>>>>>>> In order to provide the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> support for these capabilities, different
>>>>>>
>>>>>>
>>>>>>>>>>>> approaches can be
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> envisioned, namely:
>>>>>>
>>>>>>
>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> the mechanisms
>>>>>>
>>>>>>
>>>>>>>>>>>> to provide the required capabilities are fully L2
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> mechanisms and
>>>>>>
>>>>>>
>>>>>>>>>>>> no modification of the IP layer is needed.
>>>>>>>>>>>> - L3
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> only approaches. In this type of approaches, the mechanism to
>>>>>>
>>>>>>
>>>>>>>>>>>> provide
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> to required capabilities are located in the IP layer
>>>>>>
>>>>>>
>>>>>>>>>>>> - Hybrid L2/L3
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> approaches. In this case, some mechanisms are
>>>>>>
>>>>>>
>>>>>>>>>>>> located in L2 and other
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> mechanisms are located in L3.
>>>>>>
>>>>>>
>>>>>>>>>>>> Now, the different possible approaches
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> vary greatly in their nature
>>>>>>
>>>>>>
>>>>>>>>>>>> and resulting capabilities. To
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> understanding the benefits and
>>>>>>
>>>>>>
>>>>>>>>>>>> suitability of these alternatives, the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> requirements have to be
>>>>>>
>>>>>>
>>>>>>>>>>>> properly defined and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> understood.
>>>>>>
>>>>>>
>>>>>>>>>>>> The main goal of the BOF is understanding the need
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> for work in the
>>>>>>
>>>>>>
>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> we will attempt
>>>>>>
>>>>>>
>>>>>>>>>>>> to:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Understand the applicable
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> scenarios, and the problem statement
>>>>>>
>>>>>>
>>>>>>>>>>>> related
>>>>>>>>>>>> to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> those
>>>>>>
>>>>>>
>>>>>>>>>>>> 2) Understand the restrictions and requirement imposed to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> solutions to
>>>>>>
>>>>>>
>>>>>>>>>>>> address the problem statement and scenarios
>>>>>>>>>>>> 3)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> Get an overview of the proposed solutions
>>>>>>
>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>>
>>>>>>>>>>>> netlmm mailing
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> list
>>>>>>
>>>>>>
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netext mailing
>>>>>>>>>>
>>>>>>>>>>
>>>>>> list
>>>>>>
>>>>>>
>>>>>>>>>> [email-masked]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>>
>>>>>>>> MEXT mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> [email-masked]
>>>>>>
>>>>>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> MEXT mailing list
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> [email-masked]
>>>>>>
>>>>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> netlmm mailing list
>>>>>>
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> netlmm mailing
>>>>>
>>>>>
>>>>>> list
>>>>>>
>>>>>>
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>
>
>

From [email-masked]  Tue Jun 30 09:47:17 2009
Date: Tue, 30 Jun 2009 17:45:24 +0100
From: George Tsirtsis <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription

inline

On Tue, Jun 30, 2009 at 5:31 PM, Koodli,
Rajeev<[email-masked]> wrote:
>
> Hi George, Raj,
>
>
>>
>> GT> This is good justification answering the "why" and it leads to an
>> obvious set of options for the "what". It implies something
>> about the solution space that I would like this BOF to be
>> specific about. i.e., if the reason to do this is to enable
>> inter-tech and multi-homing without client MIP in the mobile,
>> does it mean:
>> a) =C2=A0you do not want any mobility software in the mobile? (this seem=
s
>> unrealistic)
>
> What constitutes "mobility software" without which the above features are=
 unrealistic?
>

GT2> Any software that enables an MN to signal to the MAG (or the PMIP
network) anything about inter-tech or flow movement.
I claim (see draft-tsirtsis-netext-controversy) that these features
are unrealistic without such MN signalling.
If you think that these features are realizable without signalling
from the mobile then by all means lets charter these items with a
"no-MN-changes" clause. Otherwise lets identify what kind of
signalling this  group intends to define.

>
>> b) =C2=A0that you want L2 software in the client? (this is possible for
>> *some* technologies and I do not think that such work belongs
>> to the IETF...but the BOF could discuss this)
>
> Agree. Part of this exercise is to identify what is feasible in L2, so th=
at we don't spend our time on such things.

GT> Which means that you do not think L2 signalling based solutions
should be worked on in the IETF?

>
>> c) =C2=A0that you want network layer software in the =C2=A0mobile but
>> not MIP; (This clearly makes no sense given your "why")
>>
>
> We can start by saying that MIP has the ingredients you need to support t=
he features of interest. For an operator, it is one of the options.
>
> We also need to look at supporting mobile nodes without MIP. In other wor=
ds, we can say for a feature X, 1) MIP is one of the options, and 2) use PM=
IP-extensions if your particular deployment does not permit you to use opti=
on 1).
>

GT> Which means that you think these PMIP-extensions involve L3
signalling from the MN or not?

> Regards,
>
> -Rajeev
>
>
>
>> Would you rather revise your "why" ? :-)
>>
>> George
>>
>> > One of the outcomes of this discussion is quite possibly
>> the fact that
>> > the IETF believes the use of host based mobile IP protocols is the
>> > right choice and recommends it as such. And that is fine.
>> But I think
>> > we should also consider the approaches to providing these
>> features for
>> > PMIP6 which would not necessarily result in reinventing host based
>> > mobile IP type of capabilities on the MNs.
>> >
>> > I don't know if the above justifies the reason why we are
>> having this
>> > discussion (yet again :) ).
>> >
>> > -Raj
>> >
>> >>
>> >> Hesham
>> >>
>> >>>
>> >>> Regards, marcelo
>> >>>
>> >>>> Hesham
>> >>>>
>> >>>>
>> >>>>> Regards, marcelo
>> >>>>>
>> >>>>>
>> >>>>> Hesham Soliman escribi=C3=B3:
>> >>>>>
>> >>>>>> A quick comment.
>> >>>>>> I don't see any reason for an IETF WG to look for a
>> solution that
>> >>>>>> works for a limited set of technologies and try to
>> solve that on
>> >>>>>> layer 2. This is clearly not our job. Similarly, there
>> is little
>> >>>>>> gain in solving this for a limited set of technologies on L3
>> >>>>>> given that we already have a layer 2 agnostic
>> solution. Why would
>> >>>>>> we want to develop another one for a limited set of
>> link layers?
>> >>>>>>
>> >>>>>> Hesham
>> >>>>>>
>> >>>>>>
>> >>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun"
>> <[email-masked]> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> George,
>> >>>>>>>
>> >>>>>>>
>> >>>>>> great summary
>> >>>>>>
>> >>>>>> just one comment below...
>> >>>>>>
>> >>>>>>
>> >>>>>> George Tsirtsis
>> >>>>>>
>> >>>>>>
>> >>>>>>> escribi=C3=B3:
>> >>>>>>> With PMIP things are not so clear....it is not even
>> clear we are
>> >>>>>>>
>> >>>>>>> talking about the *network layer*... and thus it is
>> not so clear
>> >>>>>>> how
>> >>>>>>>
>> >>>>>>> "generic" solutions can be.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> right, so one relevant question is how
>> >>>>>>
>> >>>>>>
>> >>>>>>> generic we want this to be.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> For instance, it may be also sufficient to support
>> >>>>>>
>> >>>>>>
>> >>>>>>> inter technology
>> >>>>>>>
>> >>>>>>>
>> >>>>>> handovers for a subset of L2 technologies that can support
>> >>>>>>
>> >>>>>>
>> >>>>>>> it at the L2
>> >>>>>>>
>> >>>>>>>
>> >>>>>> as you stated.
>> >>>>>> So, one thing that we need to define is whether
>> >>>>>>
>> >>>>>>
>> >>>>>>> we are looking for a
>> >>>>>>>
>> >>>>>>>
>> >>>>>> solution that supports inter technology handover with
>> >>>>>>
>> >>>>>>
>> >>>>>>> any two L2
>> >>>>>>>
>> >>>>>>>
>> >>>>>> combiantios or are we looking for a solution that
>> supports inter
>> >>>>>>
>> >>>>>> technology handovers for a limited set of technologies?
>> >>>>>> I think this is a key
>> >>>>>>
>> >>>>>>
>> >>>>>>> requirements that we need to be explicit about.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> The challenge for the BOF
>> >>>>>>> is to throw some light on how PMIP can be compatible
>> with this
>> >>>>>>> extended functionality, =C2=A0what type of additional
>> signalling is
>> >>>>>>> needed, and at which layer they intend to implement such
>> >>>>>>> signalling. Let's see.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> while i
>> >>>>>>
>> >>>>>>
>> >>>>>>> agree with that, i think a first step that this bof needs to
>> >>>>>>>
>> >>>>>>>
>> >>>>>> throw some light
>> >>>>>>
>> >>>>>>
>> >>>>>>> on is what are the functional requirements for the
>> >>>>>>>
>> >>>>>>>
>> >>>>>> support of the required
>> >>>>>>
>> >>>>>>
>> >>>>>>> features. I think the previous is a good example
>> >>>>>>>
>> >>>>>>>
>> >>>>>> of one requirement that we
>> >>>>>>
>> >>>>>>
>> >>>>>>> need to flesh out. There are many others.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> Regards, marcelo
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> George
>> >>>>>>>
>> >>>>>>> On
>> >>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>> >>>>>>>
>> >>>>>>> Perkins<[email-masked]> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> Hello Basavaraj,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> Isn't make-before-break a function performed
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> at the link layer?
>> >>>>>>>>
>> >>>>>>>> It
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> certainly isn't PHY, and I wouldn't think it
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> qualifies as MAC (i.e., it
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> doesn't control the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> device's access to the medium).
>> >>>>>>>>
>> >>>>>>>> Regards,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> Charlie P.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> PS. Which is the proper mailing list for this
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> discussion?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> [email-masked] wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> Hi
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> Frank,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> Make-before-break is inherently supported in certain
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> technologies such as
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> same is not possible
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> WiFi). 802.16e does have a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> contorted mechansim for achieving the same but
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> that's besides the point.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> So IMO it is a capability of the Phy/Mac.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> However it is possible to emulate soft-handovers and achieve
>> >>>>>>>
>> >>>>>>> make-before-break in certain cases. For example it is
>> possible
>> >>>>>>> to be
>> >>>>>>>
>> >>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>> >>>>>>>
>> >>>>>>> make-before-break
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> HO. I guess the definition of the term depends on an
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> access tchnology or
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> the
>> >>>>>>>>> combination of access technologies in the
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> context of a use-case.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> -Raj
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> Xia" <[email-masked]> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> Hi Raj
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> IMHO Make-before-break is not a link-layer technology.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> , but =C2=A0a concept
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> (or a strategy). =C2=A0 =C2=A0Related to the topic we
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> are discussing, making target
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> interface ready before moving
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> traffic to it is kind of
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> make-before-break.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> BR
>> >>>>>>>>>> Frank
>> >>>>>>>>>>
>> >>>>>>>>>> ----- Original Message
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> -----
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> From: <[email-masked]>
>> >>>>>>>>>> To:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <[email-masked]>; <[email-masked]>;
>> >>>>>>> <[email-masked]>;
>> >>>>>>>
>> >>>>>>> <[email-masked]>; <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> Cc: <[email-masked]>;
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>> >>>>>>>>>> Subject: Re:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>> >>>>>>>
>> >>>>>>> description
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> Hi Frank,
>> >>>>>>>>>>
>> >>>>>>>>>> Comments
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> inline:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <[email-masked]> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> Raj
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> My main point is make-before-break strategy is the best
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> way to solve multi-radio handover.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> The IETF cannot
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> do anything about whether an MN has the ability to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> accomplish
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> make-before-break connectivity. It depends on the link-layer
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> technology,
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> spectrum that they operate in, etc. So this approach is a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> non-starter.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> The IETF solution has to be agnostic to underlying access
>> >>>>>>>
>> >>>>>>> technologies.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> Please see my inline
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> response.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> BR
>> >>>>>>>>>>> ----- Original Message -----
>> >>>>>>>>>>> From:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> To: <[email-masked]>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[email-masked]>; <[email-masked]>;
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> <[email-masked]>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Cc: <[email-masked]>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>> >>>>>>>>>>> Subject:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>> >>>>>>> description
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Frank,
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On 6/29/09 11:16
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Hi Guys
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I have comments on inter-technology
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> handover.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> IMHO, flow mobility could solve problems
>> >>>>>>>>>>>> which
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> inter-tech handover is try to deal with.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Flow
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> mobility also includes the ability to move a flow
>> from one mobility
>> >>>>>>>
>> >>>>>>> session to another. Multiple mobility sessions could
>> be established via
>> >>>>>>>
>> >>>>>>> a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> single interface in which case flow mobility
>> would be achieved
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> within
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> the
>> >>>>>>>>>>> scope of a single interface. Hence flow mobility and
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> inter-technology
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> handovers are separate features.
>> >>>>>>>>>>> Frank=3D>IMHO,
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> inter-technology is trying to move all the traffic on
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> one interface to
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> another interface.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> Right. I guess you answered the
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> question about the difference between
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> flow
>> >>>>>>>>>> mobility and
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> inter-technology handovers. You could extrapolate and say
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> that
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> inter-technology HO is the case where you move all
>> flows from one
>> >>>>>>>
>> >>>>>>> interface
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> to another and hence a variant of flow mobility.
>> While that is
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> true, you
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> should also recognize that the granularity of flow
>> mobility is
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> finer and
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> does not have to necessarily be a relocation of a
>> flow between
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> physical
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> interfaces.
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>> I assume that two
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> heterogeneous interfaces are
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> all active during the handover. =C2=A0It is
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> easy to move
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> a flow(or all flows) from an interface to
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> another.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Possibly.. But the point is to
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> identify what extensions (possibly to the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> MN)
>> >>>>>>>>>>> are needed in order
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> to achieve handovers across interfaces.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Frank=3D>If we see inter-tech
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> handover as a subset of flow mobility,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> there is one problem left, that
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> is flow mobility.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> See above. Flow mobility is a
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> feature that can work across multiple
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> mobility
>> >>>>>>>>>> sessions within the
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> scope of a single interface as well.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>> This is
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> probably the reason why there is no
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> inter-tech handover solution
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> standerdized
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> for client MIP.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>> Client
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> MIP inherently supports handovers across multiple interfaces.
>> >>>>>>>
>> >>>>>>> Performance improvements to the handovers are
>> accomplished using
>> >>>>>>>
>> >>>>>>> solutions
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> such as FMIP.
>> >>>>>>>>>>> Frank=3D>Maybe, I am missing something.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> However FMIP =C2=A0is not applicable
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> to PAR/NAR collocated scenario. =C2=A0For
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> example, a mobile node with two
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> interface connects to the same access
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> router (ASN-GW for WiMAX,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> PDN-GW for LTE). =C2=A0 Does FMIP work when mobile
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> node handover from
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> one technology to another?
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>> Not sure I understand the question. In your
>> example above, I believe
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> MN
>> >>>>>>>>>> would connect to the ASN-GW via the WiMAX
>> interface and to an
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> S-GW via
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> the
>> >>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> question is, can
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> you
>> >>>>>>>>>> use FMIP to optimize handovers in such a
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> scenario... Yes. Not FMIP, but
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> think we are looking at
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> optimizing
>> >>>>>>>>>> handovers in this
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> discussion.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> As per the current PMIP6 specification wherein no
>> changes to
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> the host are
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> required, it is not possible to do an inter-technology
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> handover. This is
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> a
>> >>>>>>>>>> limitation which implies that PMIP6 provides
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> host mobility to an MN
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> within
>> >>>>>>>>>> the scope of a single access
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> technology. Host based mobile IP does not
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> have
>> >>>>>>>>>> this
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> problem.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> -Raj
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> -Raj
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> BR
>> >>>>>>>>>>>> Frank
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> ----- Original Message -----
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> To:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> Cc:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> <[email-masked]>; "Ralph Droms"
>> <[email-masked]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> Sent:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> Sunday, June 28, 2009 1:16 PM
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> of the bof description
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> This is a first draft of the BOF description for your
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> consideration.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> It
>> >>>>>>>>>>>>> is
>> >>>>>>>>>>>>> still very open so, feel free to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> comment on whether the proposed
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> approach
>> >>>>>>>>>>>>> seems appropriate or
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> not.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> NETEXT2 BOF description
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> -----------------------
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> a network based mobility
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> PMIP6 provides mobility to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> IP hosts without requiring any protocol
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> enhancements or additional
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> capabilities on the host.
>> >>>>>>>>>>>>> Current
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> PMIP6 specification fully defines how to provide mobility
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> support for
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> mobile nodes with a single interface roaming in a PMIP6
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> domain. The
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> goal of this BOF is gain understanding of how to support
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> nodes with
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> multiple interfaces (of possible different technologies) in
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> a
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> PMIP6 network.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> In particular, this BOF assumes the following
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> scenario:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> multiple
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> access technologies and needs to support nodes that
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> have
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> multiple interfaces, possibly of different
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> technologies.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> In particular, the following capabilities are
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> needed:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - Inter-technology handover support. The MN has
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> initiated a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> communication over one interface and it needs to be able
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> to move
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> the established connection to a different interface of
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> a possibly different technology. The reason for moving
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> communication to another interface is because of the MNs
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> mobility and
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> attaching via a different interface. Basically
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> the ability to perform
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> handovers that span different access
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> technologies.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> -
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> Multihoming support. The MN with multiple interfaces
>> of possibly
>> >>>>>>>
>> >>>>>>> different technologies should be able to use them
>> simultaneously to
>> >>>>>>>
>> >>>>>>> exchange data and manage the mobility of communications
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> established
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> through the different interfaces.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - Flow mobility. A MN with
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> multiple interfaces of possibly
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> different technologies must be able to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> move a flow from
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> able
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> to inform the network through which interface it wishes
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> to receive different types of flows.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> In order to provide the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> support for these capabilities, different
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> approaches can be
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> envisioned, namely:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> the mechanisms
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> to provide the required capabilities are fully L2
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> mechanisms and
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> no modification of the IP layer is needed.
>> >>>>>>>>>>>>> - L3
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> only approaches. In this type of approaches, the mechanism to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> provide
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> to required capabilities are located in the IP layer
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> - Hybrid L2/L3
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> approaches. In this case, some mechanisms are
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> located in L2 and other
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> mechanisms are located in L3.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> Now, the different possible approaches
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> vary greatly in their nature
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> and resulting capabilities. To
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> understanding the benefits and
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> suitability of these alternatives, the
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> requirements have to be
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> properly defined and
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> understood.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> The main goal of the BOF is understanding the need
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> for work in the
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> we will attempt
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> to:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> 1) Understand the applicable
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> scenarios, and the problem statement
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> related
>> >>>>>>>>>>>>> to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> those
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> 2) Understand the restrictions and requirement
>> imposed to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> solutions to
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> address the problem statement and scenarios
>> >>>>>>>>>>>>> 3)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> Get an overview of the proposed solutions
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> netlmm mailing
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> [email-masked]
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> netext mailing
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> [email-masked]
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> MEXT mailing list
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> [email-masked]
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> MEXT mailing list
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> [email-masked]
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> netlmm mailing list
>> >>>>>>>
>> >>>>>>> [email-masked]
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> netlmm mailing
>> >>>>>>
>> >>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>> [email-masked]
>> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>
>
> This email and any attachments may contain legally privileged and/or conf=
idential information of Starent Networks, Corp. and is intended only for th=
e individual or entity named in the message. =C2=A0The information transmit=
ted may not be used to create or change any contractual obligations of Star=
ent Networks, Corp. =C2=A0Any review, retransmission, dissemination or othe=
r use of, or taking of any action in reliance upon this e-mail and its atta=
chments by persons or entities other than the intended recipient is prohibi=
ted. If you are not the intended recipient, please notify the sender immedi=
ately -- by replying to this message or by sending an email to postmaster@s=
tarentnetworks.com -- and destroy all copies of this message and any attach=
ments without reading or disclosing their contents. Thank you.
>

From [email-masked]  Tue Jun 30 10:05:54 2009
Date: Tue, 30 Jun 2009 18:05:17 +0100
From: George Tsirtsis <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hey Sri,

So let me see if I understand.
You think that the MN will only have to signal during network
attachment, so, essentially out-of-band from PMIP perspective; is that
correct?
I assume by network attachment you mean on a per technology basis?
i.e., when WiFi IF attached to a given network, and when a 3G IF
attaches it signals again?

If yes, then what kind of network attachment signalling do you intend
to define in the IETF?  Could you elaborate a bit, keeping in mind
that network attachment is typically an L2 process (except PANA I
guess?)?

Also, if you only signal during attachment; does it mean that
multi-homing feature in PMIP will ONLY apply to different technologies
(i.e., you exclude multihoming on the same technology)?

Thanks

On Tue, Jun 30, 2009 at 5:36 PM, Sri Gundavelli<[email-masked]> wrote:
> Hi Marcelo,
>
>
> On Tue, 30 Jun 2009, marcelo bagnulo braun wrote:
>
>>>
>> so what is the assumption requiremnent here?
>> Is the requriemnent that the solution must work wihtout requiring any ho=
st
>> support? Or is there some level of host support that is acceptble? If so=
,
>> why? (i mena, why some level of host support is accpetbale and other is =
not)
>>
>>
>
> The requirement is to have that intelligence on the network for supportin=
g
> these features, while allowing the mobile node to only express preference=
s
> on network attachment/multihoming or flow mobility. The participation of
> the client will be to minimal proportions. The goal is to have a simple
> client, with a minimal software component such as for managing these
> aspects and not require an extensive set of protocol stacks.
>
>
>
>>> =C2=A02. An operator may choose to deploy a network with only network b=
ased
>>> =C2=A0mobility protocol support
>>>
>>>
>> right, what are the required functions that are provided by a network
>> based mobility that are lacking in a host based mobility approach?
>>
>
> I'm not sure, if we want to compare the missing features and say they
> will be available in host mobility protocols and so we go that route.
> We could have said that even before we standardized network-based
> mobility approaches. But, there is interest to support network-based
> mobility protocols and so we need to ensure we do that job completly.
>
> Industry has accepted network-based mobility approaches in the form of
> GTP/PMIPv6. We have to add the missing features and support that
> accepted model completly. This is about completing the work.
>
> Regards
> Sri
>
>
>
>
>> Regards, marcelo
>>
>>
>>> =C2=A0-Raj
>>>
>>>
>>>
>>
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

From [email-masked]  Tue Jun 30 10:06:26 2009
Date: Tue, 30 Jun 2009 17:37:25 +0200
From: Marco Liebsch <[email-masked]>
To: Frank Xia <[email-masked]>
Cc: [email-masked], [email-masked], MELIA TELEMACO <[email-masked]>, [email-masked], mext <[email-masked]>
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Frank,

Frank Xia wrote:
> Hi Telemaco
>
> There are three use cases in my mind:
>
> 1)Two interfaces are active at the same time.
>
>  This is the most common case.  Flow mobility
>  can handle all the problems relating to handover.
>
> 2)One interafce is active while the other is dormant.
>
>  The dormant interface is activated before handover.
>  Flow mobility can also do with it.
>
> 3)One interafce is active while the other is dormant, and
>  traffic must be offloaded from the active one even though
>  the dormant one is not ready.
>
>  This is a rare case.  If   "inter-technology handover"
>  focuses on dealing with this scenario, I am fine.
Still inter-tech handover is different from flow mobility. Also 
complexity-wise.
For inter-technology handover the mobile may only provide hints about 
the nature of
the handover (inter-tech HO etc), maybe about handover target or source 
to the network.
If you want flow mobility, you need to handle flow descriptions and 
signal appropriate
filters, hence much more to be done by the mobile and by the network.
Not sure the PMIPv6 protocol should handle flow filters..

If you move all flows during a handover, we're back at inter-tech 
handover, say we
move the complete mobility session with the intention to shut down the 
previous
mobility session (and with mobility session I mean the MN's binding 
between the
HNP and the pMAG at the LMA). Moving the associated flows is implicit.

Hence, requirement on the mobile is very different for flow mobility and 
inter-tech handover
(shouldn't we say dual radio handover here?)

marco

>
> BR
> Frank
>
> ----- Original Message ----- From: "MELIA TELEMACO" 
> <[email-masked]>
> To: "Frank Xia" <[email-masked]>; "George Tsirtsis" 
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; "mext" <[email-masked]>
> Sent: Monday, June 29, 2009 1:03 PM
> Subject: RE: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
>
>
> Frank,
>
> I think you should not mix flow mobility and inter-tech handover. A MN 
> might or might now use multiple connections at the same time...
>
> telemaco
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de Frank Xia
> Envoy� : lundi 29 juin 2009 19:20
> � : George Tsirtsis
> Cc : [email-masked]; [email-masked]; [email-masked]; mext
> Objet : Re: [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
>
> Hi Gorge
>
> It seems that  I did not make me clear.
>
> 1)Single radio handover.
>   MN should disconnect from one BS , and connect
>   to a second BS.   MN can't connect to the two BS
>   at the same time.  Handover solutions (FMIP/PMIP)
>   are needed.
>
> 2)Dual radio handover
>   MN connects to the two BS'  at the same time.
>   Flow mobility is sufficient when move a flow( or  all
>   flows)  from  one interface to another.
>
> BR
> Frank
>
> ----- Original Message ----- From: "George Tsirtsis" 
> <[email-masked]>
> To: "Frank Xia" <[email-masked]>
> Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>; 
> "mext"
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, June 29, 2009 11:48 AM
> Subject: Re: [MEXT] [netlmm] NEXTEXT2: first draft of the bof description
>
>
> Frank, your comment below is strange to say the least.
>
> MIP handoffs can be between interfaces of the same or different
> technologies. Since client MIP works at the IP layer (above the Link
> Layer of any specific technology) there is nothing that client MIP
> (and any of its features) need to specifically define for
> inter-technology handoffs.
>
>  >Did you so far think that this means that client MIP only works
> intra-technology?<
>
> For PMIP, this is an issue because currently there is no defined
> protocol (on any layer) between MN and MAG...which is one of the
> issues to be discussed in netext2 bof.
>
> George
>
> On Mon, Jun 29, 2009 at 5:16 PM, Frank Xia<[email-masked]> wrote:
>> Hi Guys
>>
>> I have comments on inter-technology handover.
>>
>> IMHO, flow mobility could solve problems
>> which inter-tech handover is try to deal with.
>> I assume that two heterogeneous interfaces are
>> all active during the handover. It is easy to move
>> a flow(or all flows) from an interface to another.
>>
>> This is probably the reason why there is no
>> inter-tech handover solution standerdized
>> for client MIP.
>>
>> BR
>> Frank
>>
>> ----- Original Message ----- From: "marcelo bagnulo braun"
>> <[email-masked]>
>> To: <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>> Cc: <[email-masked]>; "Ralph Droms" <[email-masked]>
>> Sent: Sunday, June 28, 2009 1:16 PM
>> Subject: [netlmm] NEXTEXT2: first draft of the bof description
>>
>>
>>> Hi,
>>>
>>> This is a first draft of the BOF description for your consideration. It
>>> is
>>> still very open so, feel free to comment on whether the proposed 
>>> approach
>>> seems appropriate or not.
>>>
>>> NETEXT2 BOF description
>>> -----------------------
>>>
>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility
>>> protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to
>>> IP hosts without requiring any protocol enhancements or additional
>>> capabilities on the host.
>>> Current PMIP6 specification fully defines how to provide mobility
>>> support for mobile nodes with a single interface roaming in a PMIP6
>>> domain. The goal of this BOF is gain understanding of how to support
>>> nodes with multiple interfaces (of possible different technologies) 
>>> in a
>>> PMIP6 network.
>>>
>>> In particular, this BOF assumes the following scenario:
>>> We have a single PMIP6 domain that has deployed multiple
>>> access technologies and needs to support nodes that have
>>> multiple interfaces, possibly of different technologies.
>>>
>>> In particular, the following capabilities are needed:
>>>
>>> - Inter-technology handover support. The MN has initiated a
>>> communication over one interface and it needs to be able to move
>>> the established connection to a different interface of
>>> a possibly different technology. The reason for moving
>>> the communication to another interface is because of the MNs
>>> mobility and attaching via a different interface. Basically
>>> the ability to perform handovers that span different access
>>> technologies.
>>>
>>> - Multihoming support. The MN with multiple interfaces of possibly
>>> different technologies should be able to use them simultaneously to
>>> exchange data and manage the mobility of communications
>>> established through the different interfaces.
>>>
>>> - Flow mobility. A MN with multiple interfaces of possibly
>>> different technologies must be able to move a flow from
>>> one interface to another. Moreover, the MN should be able
>>> to inform the network through which interface it wishes
>>> to receive different types of flows.
>>>
>>> In order to provide the support for these capabilities, different
>>> approaches can be envisioned, namely:
>>> - L2 only approaches. In this type of approaches, the mechanisms
>>> to provide the required capabilities are fully L2 mechanisms and
>>> no modification of the IP layer is needed.
>>> - L3 only approaches. In this type of approaches, the mechanism to
>>> provide to required capabilities are located in the IP layer
>>> - Hybrid L2/L3 approaches. In this case, some mechanisms are
>>> located in L2 and other mechanisms are located in L3.
>>> Now, the different possible approaches vary greatly in their nature
>>> and resulting capabilities. To understanding the benefits and
>>> suitability of these alternatives, the requirements have to be
>>> properly defined and understood.
>>>
>>> The main goal of the BOF is understanding the need for work in the
>>> IETF in this area. In order to do so, during the BOF, we will 
>>> attempt to:
>>>
>>> 1) Understand the applicable scenarios, and the problem statement 
>>> related
>>> to
>>> those
>>> 2) Understand the restrictions and requirement imposed to solutions to
>>> address the problem statement and scenarios
>>> 3) Get an overview of the proposed solutions
>>>
>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

From [email-masked]  Tue Jun 30 10:24:37 2009
Content-class: urn:content-classes:message
Date: Tue, 30 Jun 2009 19:23:31 +0200
From: "MELIA TELEMACO" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

>
> We (as in the people in NetExt) want PMIP6 to support inter-technology
> handovers, flow binding/mobility and enhanced support for multihoming
> *because* :
> 1. Not every host does or will include host based mobility protocols
such as
> (DS)MIP
> 2. An operator may choose to deploy a network with only network based
> mobility protocol support
>
> -Raj
>

>Absolutely. These features enable many practical usecases and we should
>be able to allow them in a network that has deployed only network-based
>mobility management protocol, with simple clients.

Especially considering that some Mobile Operators are not planning to
seriously deploy DSMIPv6

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

From [email-masked]  Tue Jun 30 10:26:28 2009
Content-class: urn:content-classes:message
Date: Tue, 30 Jun 2009 13:07:28 -0400
From: "Koodli, Rajeev" <[email-masked]>
To: "George Tsirtsis" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription

=20

> > What constitutes "mobility software" without which the=20
> above features are unrealistic?
> >
>=20
> GT2> Any software that enables an MN to signal to the MAG (or the PMIP
> network) anything about inter-tech or flow movement.
> I claim (see draft-tsirtsis-netext-controversy) that these=20
> features are unrealistic without such MN signalling.
> If you think that these features are realizable without=20
> signalling from the mobile then by all means lets charter=20
> these items with a "no-MN-changes" clause. Otherwise lets=20
> identify what kind of signalling this  group intends to define.
>=20

Okay.

> >
> > Agree. Part of this exercise is to identify what is=20
> feasible in L2, so that we don't spend our time on such things.
>=20
> GT> Which means that you do not think L2 signalling based solutions
> should be worked on in the IETF?

I do not think we should work any L2 signaling here; perhaps this is =
obvious.

> > We also need to look at supporting mobile nodes without=20
> MIP. In other words, we can say for a feature X, 1) MIP is=20
> one of the options, and 2) use PMIP-extensions if your=20
> particular deployment does not permit you to use option 1).
> >
>=20
> GT> Which means that you think these PMIP-extensions involve L3
> signalling from the MN or not?
>=20

Some extensions may be done with L2. Others may need host configurations =
(such as use of virtual interfaces). If we cannot do away with =
L2/host-configurations alone, we need to look at L3 signaling - =
obviously we need to scope this carefully.

-Rajeev

> > Regards,
> >
> > -Rajeev
> >
> >
> >
> >> Would you rather revise your "why" ? :-)
> >>
> >> George
> >>
> >> > One of the outcomes of this discussion is quite possibly
> >> the fact that
> >> > the IETF believes the use of host based mobile IP=20
> protocols is the=20
> >> > right choice and recommends it as such. And that is fine.
> >> But I think
> >> > we should also consider the approaches to providing these
> >> features for
> >> > PMIP6 which would not necessarily result in reinventing=20
> host based=20
> >> > mobile IP type of capabilities on the MNs.
> >> >
> >> > I don't know if the above justifies the reason why we are
> >> having this
> >> > discussion (yet again :) ).
> >> >
> >> > -Raj
> >> >
> >> >>
> >> >> Hesham
> >> >>
> >> >>>
> >> >>> Regards, marcelo
> >> >>>
> >> >>>> Hesham
> >> >>>>
> >> >>>>
> >> >>>>> Regards, marcelo
> >> >>>>>
> >> >>>>>
> >> >>>>> Hesham Soliman escribi=F3:
> >> >>>>>
> >> >>>>>> A quick comment.
> >> >>>>>> I don't see any reason for an IETF WG to look for a
> >> solution that
> >> >>>>>> works for a limited set of technologies and try to
> >> solve that on
> >> >>>>>> layer 2. This is clearly not our job. Similarly, there
> >> is little
> >> >>>>>> gain in solving this for a limited set of=20
> technologies on L3=20
> >> >>>>>> given that we already have a layer 2 agnostic
> >> solution. Why would
> >> >>>>>> we want to develop another one for a limited set of
> >> link layers?
> >> >>>>>>
> >> >>>>>> Hesham
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun"
> >> <[email-masked]> wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> George,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> great summary
> >> >>>>>>
> >> >>>>>> just one comment below...
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> George Tsirtsis
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> escribi=F3:
> >> >>>>>>> With PMIP things are not so clear....it is not even
> >> clear we are
> >> >>>>>>>
> >> >>>>>>> talking about the *network layer*... and thus it is
> >> not so clear
> >> >>>>>>> how
> >> >>>>>>>
> >> >>>>>>> "generic" solutions can be.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> right, so one relevant question is how
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> generic we want this to be.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> For instance, it may be also sufficient to support
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> inter technology
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> handovers for a subset of L2 technologies that can support
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> it at the L2
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> as you stated.
> >> >>>>>> So, one thing that we need to define is whether
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> we are looking for a
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> solution that supports inter technology handover with
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> any two L2
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> combiantios or are we looking for a solution that
> >> supports inter
> >> >>>>>>
> >> >>>>>> technology handovers for a limited set of technologies?
> >> >>>>>> I think this is a key
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> requirements that we need to be explicit about.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> The challenge for the BOF
> >> >>>>>>> is to throw some light on how PMIP can be compatible
> >> with this
> >> >>>>>>> extended functionality, =A0what type of additional
> >> signalling is
> >> >>>>>>> needed, and at which layer they intend to implement such=20
> >> >>>>>>> signalling. Let's see.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> while i
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> agree with that, i think a first step that this=20
> bof needs to
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> throw some light
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> on is what are the functional requirements for the
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> support of the required
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> features. I think the previous is a good example
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> of one requirement that we
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> need to flesh out. There are many others.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> Regards, marcelo
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> George
> >> >>>>>>>
> >> >>>>>>> On
> >> >>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
> >> >>>>>>>
> >> >>>>>>> Perkins<[email-masked]> wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> Hello Basavaraj,
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> Isn't make-before-break a function performed
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> at the link layer?
> >> >>>>>>>>
> >> >>>>>>>> It
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> certainly isn't PHY, and I wouldn't think it
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> qualifies as MAC (i.e., it
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> doesn't control the
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> device's access to the medium).
> >> >>>>>>>>
> >> >>>>>>>> Regards,
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> Charlie P.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> PS. Which is the proper mailing list for this
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> discussion?
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> [email-masked] wrote:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>> Hi
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> Frank,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> Make-before-break is inherently supported in certain
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> technologies such as
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> same is not possible
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> WiFi). 802.16e does have a
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> contorted mechansim for achieving the same but
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> that's besides the point.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> So IMO it is a capability of the Phy/Mac.
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> However it is possible to emulate soft-handovers=20
> and achieve
> >> >>>>>>>
> >> >>>>>>> make-before-break in certain cases. For example it is
> >> possible
> >> >>>>>>> to be
> >> >>>>>>>
> >> >>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
> >> >>>>>>>
> >> >>>>>>> make-before-break
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> HO. I guess the definition of the term depends on an
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> access tchnology or
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> the
> >> >>>>>>>>> combination of access technologies in the
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> context of a use-case.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> -Raj
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> Xia" <[email-masked]> wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>> Hi Raj
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> IMHO Make-before-break is not a link-layer technology.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> , but =A0a concept
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> (or a strategy). =A0 =A0Related to the topic we
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> are discussing, making target
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> interface ready before moving
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> traffic to it is kind of
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> make-before-break.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> BR
> >> >>>>>>>>>> Frank
> >> >>>>>>>>>>
> >> >>>>>>>>>> ----- Original Message
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> -----
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> From: <[email-masked]>
> >> >>>>>>>>>> To:
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[email-masked]>; <[email-masked]>;=20
> >> >>>>>>> <[email-masked]>;
> >> >>>>>>>
> >> >>>>>>> <[email-masked]>; <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> Cc: <[email-masked]>;
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
> >> >>>>>>>>>> Subject: Re:
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
> >> >>>>>>>
> >> >>>>>>> description
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> Hi Frank,
> >> >>>>>>>>>>
> >> >>>>>>>>>> Comments
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> inline:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[email-masked]> wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>> Hi
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> Raj
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> My main point is make-before-break strategy is the best
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> way to solve multi-radio handover.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> The IETF cannot
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> do anything about whether an MN has the ability to
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> accomplish
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> make-before-break connectivity. It depends on the=20
> link-layer
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> technology,
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> spectrum that they operate in, etc. So this approach is a
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> non-starter.
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> The IETF solution has to be agnostic to underlying access
> >> >>>>>>>
> >> >>>>>>> technologies.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>> Please see my inline
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> response.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> BR
> >> >>>>>>>>>>> ----- Original Message -----
> >> >>>>>>>>>>> From:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> To: <[email-masked]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[email-masked]>; <[email-masked]>;
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> <[email-masked]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> Cc: <[email-masked]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
> >> >>>>>>>>>>> Subject:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof description
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> Frank,
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> On 6/29/09 11:16
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> Hi Guys
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I have comments on inter-technology
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> handover.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> IMHO, flow mobility could solve problems
> >> >>>>>>>>>>>> which
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> inter-tech handover is try to deal with.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> Flow
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> mobility also includes the ability to move a flow
> >> from one mobility
> >> >>>>>>>
> >> >>>>>>> session to another. Multiple mobility sessions could
> >> be established via
> >> >>>>>>>
> >> >>>>>>> a
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> single interface in which case flow mobility
> >> would be achieved
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> within
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> the
> >> >>>>>>>>>>> scope of a single interface. Hence flow mobility and
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> inter-technology
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> handovers are separate features.
> >> >>>>>>>>>>> Frank=3D>IMHO,
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> inter-technology is trying to move all the traffic on
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> one interface to
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> another interface.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> Right. I guess you answered the
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> question about the difference between
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> flow
> >> >>>>>>>>>> mobility and
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> inter-technology handovers. You could extrapolate and say
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> that
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> inter-technology HO is the case where you move all
> >> flows from one
> >> >>>>>>>
> >> >>>>>>> interface
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> to another and hence a variant of flow mobility.
> >> While that is
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> true, you
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> should also recognize that the granularity of flow
> >> mobility is
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> finer and
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> does not have to necessarily be a relocation of a
> >> flow between
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> physical
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> interfaces.
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>>> I assume that two
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> heterogeneous interfaces are
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> all active during the handover. =A0It is
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> easy to move
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> a flow(or all flows) from an interface to
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> another.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> Possibly.. But the point is to
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> identify what extensions (possibly to the
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> MN)
> >> >>>>>>>>>>> are needed in order
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> to achieve handovers across interfaces.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> Frank=3D>If we see inter-tech
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> handover as a subset of flow mobility,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> there is one problem left, that
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> is flow mobility.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> See above. Flow mobility is a
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> feature that can work across multiple
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> mobility
> >> >>>>>>>>>> sessions within the
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> scope of a single interface as well.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>>> This is
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> probably the reason why there is no
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> inter-tech handover solution
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> standerdized
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> for client MIP.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> Client
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> MIP inherently supports handovers across multiple=20
> interfaces.
> >> >>>>>>>
> >> >>>>>>> Performance improvements to the handovers are
> >> accomplished using
> >> >>>>>>>
> >> >>>>>>> solutions
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> such as FMIP.
> >> >>>>>>>>>>> Frank=3D>Maybe, I am missing something.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> However FMIP =A0is not applicable
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> to PAR/NAR collocated scenario. =A0For
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> example, a mobile node with two
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> interface connects to the same access
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> router (ASN-GW for WiMAX,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> PDN-GW for LTE). =A0 Does FMIP work when mobile
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> node handover from
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> one technology to another?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>> Not sure I understand the question. In your
> >> example above, I believe
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> the
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> MN
> >> >>>>>>>>>> would connect to the ASN-GW via the WiMAX
> >> interface and to an
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> S-GW via
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> the
> >> >>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> question is, can
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> you
> >> >>>>>>>>>> use FMIP to optimize handovers in such a
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> scenario... Yes. Not FMIP, but
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> think we are looking at
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> optimizing
> >> >>>>>>>>>> handovers in this
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> discussion.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> As per the current PMIP6 specification wherein no
> >> changes to
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> the host are
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> required, it is not possible to do an inter-technology
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> handover. This is
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> a
> >> >>>>>>>>>> limitation which implies that PMIP6 provides
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> host mobility to an MN
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> within
> >> >>>>>>>>>> the scope of a single access
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> technology. Host based mobile IP does not
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> have
> >> >>>>>>>>>> this
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> problem.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> -Raj
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>> -Raj
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> BR
> >> >>>>>>>>>>>> Frank
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> ----- Original Message -----
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> To:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> <[email-masked]>; "mext" <[email-masked]>;=20
> <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> Cc:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> <[email-masked]>; "Ralph Droms"
> >> <[email-masked]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> Sent:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> Sunday, June 28, 2009 1:16 PM
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> of the bof description
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> Hi,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> This is a first draft of the BOF description for your
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> consideration.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> It
> >> >>>>>>>>>>>>> is
> >> >>>>>>>>>>>>> still very open so, feel free to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> comment on whether the proposed
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> approach
> >> >>>>>>>>>>>>> seems appropriate or
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> not.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> NETEXT2 BOF description
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> -----------------------
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> a network based mobility
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> PMIP6 provides mobility to
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> IP hosts without requiring any protocol
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> enhancements or additional
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> capabilities on the host.
> >> >>>>>>>>>>>>> Current
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> PMIP6 specification fully defines how to provide mobility
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> support for
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> mobile nodes with a single interface roaming in a PMIP6
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> domain. The
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> goal of this BOF is gain understanding of how to support
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> nodes with
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> multiple interfaces (of possible different technologies) in
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> a
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> PMIP6 network.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> In particular, this BOF assumes the following
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> scenario:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> multiple
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> access technologies and needs to support nodes that
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> have
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> multiple interfaces, possibly of different
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> technologies.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> In particular, the following capabilities are
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> needed:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> - Inter-technology handover support. The MN has
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> initiated a
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> communication over one interface and it=20
> needs to be able
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> to move
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> the established connection to a different=20
> interface of
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> a possibly different technology. The reason for moving
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> the
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> communication to another interface is because of the MNs
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> mobility and
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> attaching via a different interface. Basically
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> the ability to perform
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> handovers that span different access
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> technologies.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> -
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> Multihoming support. The MN with multiple interfaces
> >> of possibly
> >> >>>>>>>
> >> >>>>>>> different technologies should be able to use them
> >> simultaneously to
> >> >>>>>>>
> >> >>>>>>> exchange data and manage the mobility of communications
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> established
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> through the different interfaces.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> - Flow mobility. A MN with
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> multiple interfaces of possibly
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> different technologies must be able to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> move a flow from
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> one interface to another. Moreover, the MN should be
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> able
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> to inform the network through which=20
> interface it wishes
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> to receive different types of flows.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> In order to provide the
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> support for these capabilities, different
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> approaches can be
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> envisioned, namely:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> the mechanisms
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> to provide the required capabilities are fully L2
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> mechanisms and
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> no modification of the IP layer is needed.
> >> >>>>>>>>>>>>> - L3
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> only approaches. In this type of approaches, the=20
> mechanism to
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> provide
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> to required capabilities are located in the IP layer
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> - Hybrid L2/L3
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> approaches. In this case, some mechanisms are
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> located in L2 and other
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> mechanisms are located in L3.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> Now, the different possible approaches
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> vary greatly in their nature
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> and resulting capabilities. To
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> understanding the benefits and
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> suitability of these alternatives, the
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> requirements have to be
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> properly defined and
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> understood.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> The main goal of the BOF is understanding the need
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> for work in the
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> we will attempt
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> to:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> 1) Understand the applicable
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> scenarios, and the problem statement
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> related
> >> >>>>>>>>>>>>> to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> those
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> 2) Understand the restrictions and requirement
> >> imposed to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> solutions to
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> address the problem statement and scenarios
> >> >>>>>>>>>>>>> 3)
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> Get an overview of the proposed solutions
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> netlmm mailing
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> list
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> [email-masked]
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>> _______________________________________________
> >> >>>>>>>>>>> netext mailing
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> list
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> [email-masked]
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> MEXT mailing list
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> [email-masked]
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>> _______________________________________________
> >> >>>>>>>> MEXT mailing list
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> [email-masked]
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> netlmm mailing list
> >> >>>>>>>
> >> >>>>>>> [email-masked]
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> netlmm mailing
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> list
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> [email-masked]
> >> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >> _______________________________________________
> >> netext mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/netext
> >>
> >
> >
> > This email and any attachments may contain legally=20
> privileged and/or confidential information of Starent=20
> Networks, Corp. and is intended only for the individual or=20
> entity named in the message. =A0The information transmitted may=20
> not be used to create or change any contractual obligations=20
> of Starent Networks, Corp. =A0Any review, retransmission,=20
> dissemination or other use of, or taking of any action in=20
> reliance upon this e-mail and its attachments by persons or=20
> entities other than the intended recipient is prohibited. If=20
> you are not the intended recipient, please notify the sender=20
> immediately -- by replying to this message or by sending an=20
> email to [email-masked] -- and destroy all=20
> copies of this message and any attachments without reading or=20
> disclosing their contents. Thank you.
> >
>=20

From [email-masked]  Tue Jun 30 10:40:34 2009
Date: Tue, 30 Jun 2009 12:11:02 -0500
From: Frank Xia <[email-masked]>
To: Min Hui <[email-masked]>, [email-masked]
Subject: Re: [netext] Fwd: New Version Notification fordraft-hui-netext-service-flow-identifier-00

Hi Min

I had a quick look at the document which
looks clear. Some comments are below.

1)"multiple service flows of the mobile node can
   be separately controlled based on the service
   flow identifier in the Proxy Binding Update
   and Acknowledge messages"
  I could not find the motivation of separate
  controlling of a service.  It is for traffic
  engineering, QoS enforcement or something else?

2)it is also not clear to me how the mobile
  node notifies the MAG the service type.
  It seems that the MAG identifies the service
  through data packets from the mobile node.
  Deep Packet Inspection technology is required
  for MAG?

3)What is the relationship between this draft
 and flow mobility being discussed in Netext BoF 2?
 They both have key words "flow" :-).

BR
Frank

----- Original Message ----- 
From: "Min Hui" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 29, 2009 10:27 PM
Subject: [netext] Fwd: New Version Notification 
fordraft-hui-netext-service-flow-identifier-00

> Hi, all
>
> I have just submitted a new draft:
> http://www.ietf.org/internet-drafts/draft-hui-netext-service-flow-identifier-00.txt
>
> This draft defines a new Service Flow Identifier option carrying the
> service flow identifier and service flow attributes in the Proxy
> Binding Update and Acknowledgement message, so that the granularity of
> PMIPv6 becomes per service flow basis.
>
> Any comment is welcomed.
> Thanks a lot.
>
> -Hui Min
>
>
>
> ---------- Forwarded message ----------
> From: IETF I-D Submission Tool <[email-masked]>
> Date: 2009/6/30
> Subject: New Version Notification for
> draft-hui-netext-service-flow-identifier-00
> To: [email-masked]
> ���ͣ� [email-masked], [email-masked]
>
>
>
> A new version of I-D, draft-hui-netext-service-flow-identifier-00.txt
> has been successfuly submitted by Min Hui and posted to the IETF
> repository.
>
> Filename:        draft-hui-netext-service-flow-identifier
> Revision:        00
> Title:           Service Flow Identifier in Proxy Mobile IPv6
> Creation_date:   2009-06-29
> WG ID:           Independent Submission
> Number_of_pages: 18
>
> Abstract:
> Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
> mobile node without requiring its participation in any mobility-
> related signaling. This document introduces extensions to Proxy
> Mobile IPv6 that allows network dynamically binding each service flow
> to the mobile node, respectively. Therefore, multiple service flows
> of the mobile node can be separately controlled based on the service
> flow identifier in the Proxy Binding Update and Acknowledge messages.
>
>
>
> The IETF Secretariat.
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
> 

From [email-masked]  Tue Jun 30 10:46:08 2009
Date: Tue, 30 Jun 2009 10:33:31 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: George Tsirtsis <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-1514014542-1246383211=:29873
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi George,

On Tue, 30 Jun 2009, George Tsirtsis wrote:

> Hey Sri,
>
> So let me see if I understand.
> You think that the MN will only have to signal during network
> attachment, so, essentially out-of-band from PMIP perspective; is that
> correct?

They can be  out-of-band from PMIP perspective, but act as triggers to
PMIP signaling.

> I assume by network attachment you mean on a per technology basis?
> i.e., when WiFi IF attached to a given network, and when a 3G IF
> attaches it signals again?
>

Yes. When the mobile attaches to the network over a given interface,
it can identify the type of attachment (Handoff from Int-X, New
Attachment). It can be on a per-interface basis, on every attach event.

Lets take this example of host with 3G and WiFI interafaces. Possible
scenarios:

Host initially attaches over WiFI=20
a.) Later brings up 3G interface for multihoming
b.) or, performs an handoff to 3G

Host attaches through 3G and Wifi interfaces and performs
an handoff from multihoming to single attach.
a.) WiFI=20
b.) 3G

In all these cases, I need the host to be able to suggest the
following:

Event-1: NEW ATTACHMENT, Interface Type: WiFI, IfId: 1
Event-2: HANDOFF, FROM: 3G, IfIf:2   TO: WiFI, IfId: 1

Do I need more extensive attach preferences ?

> If yes, then what kind of network attachment signalling do you intend
> to define in the IETF?  Could you elaborate a bit, keeping in mind
> that network attachment is typically an L2 process (except PANA I
> guess?)?
>

Its too early to discuss the semantics of the signaling. Its at a L2
layer or L3-layer ... that leads to the solution discussion. I'm sure,
we can have detailed discussions on the semantics.

> Also, if you only signal during attachment; does it mean that
> multi-homing feature in PMIP will ONLY apply to different technologies
> (i.e., you exclude multihoming on the same technology)?
>

I dont follow completly.

Between multihoming and inter-tech handoff, we need the host to be
able to specify if a given attachment is as a result of bringup of
a new interface (simultaneous attach) or a result of a handoff. The
host and the network has the complete view of the hosts attachment
over all its interfaces. So, not sure why the multihoming features
will appear only across technologies.

Regards
Sri

> Thanks
>
> On Tue, Jun 30, 2009 at 5:36 PM, Sri Gundavelli<[email-masked]> wrote=
:
>> Hi Marcelo,
>>
>>
>> On Tue, 30 Jun 2009, marcelo bagnulo braun wrote:
>>
>>>>
>>> so what is the assumption requiremnent here?
>>> Is the requriemnent that the solution must work wihtout requiring any h=
ost
>>> support? Or is there some level of host support that is acceptble? If s=
o,
>>> why? (i mena, why some level of host support is accpetbale and other is=
 not)
>>>
>>>
>>
>> The requirement is to have that intelligence on the network for supporti=
ng
>> these features, while allowing the mobile node to only express preferenc=
es
>> on network attachment/multihoming or flow mobility. The participation of
>> the client will be to minimal proportions. The goal is to have a simple
>> client, with a minimal software component such as for managing these
>> aspects and not require an extensive set of protocol stacks.
>>
>>
>>
>>>> =C2=A02. An operator may choose to deploy a network with only network =
based
>>>> =C2=A0mobility protocol support
>>>>
>>>>
>>> right, what are the required functions that are provided by a network
>>> based mobility that are lacking in a host based mobility approach?
>>>
>>
>> I'm not sure, if we want to compare the missing features and say they
>> will be available in host mobility protocols and so we go that route.
>> We could have said that even before we standardized network-based
>> mobility approaches. But, there is interest to support network-based
>> mobility protocols and so we need to ensure we do that job completly.
>>
>> Industry has accepted network-based mobility approaches in the form of
>> GTP/PMIPv6. We have to add the missing features and support that
>> accepted model completly. This is about completing the work.
>>
>> Regards
>> Sri
>>
>>
>>
>>
>>> Regards, marcelo
>>>
>>>
>>>> =C2=A0-Raj
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> netext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netext
>>>
>>>
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>
---559023410-1514014542-1246383211=:29873--

From [email-masked]  Tue Jun 30 10:50:35 2009
Date: Tue, 30 Jun 2009 19:50:43 +0200
From: marcelo bagnulo braun <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Sri Gundavelli escribi�:
>>
>> We (as in the people in NetExt) want PMIP6 to support inter-technology
>> handovers, flow binding/mobility and enhanced support for multihoming
>> *because* :
>> 1. Not every host does or will include host based mobility protocols 
>> such as
>> (DS)MIP
>> 2. An operator may choose to deploy a network with only network based
>> mobility protocol support
>>
>> -Raj
>>
>
> Absolutely. These features enable many practical usecases and we should
> be able to allow them in a network that has deployed only network-based
> mobility management protocol,
define what are the features that are fundamental to network mobilit 
management that must be required to a solution

> with simple clients.

please define what do you mena by simple clients

Regards, marcelo

>
>
> Sri
>

From [email-masked]  Tue Jun 30 10:52:40 2009
Date: Tue, 30 Jun 2009 19:52:47 +0200
From: marcelo bagnulo braun <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the	bofdescription

Koodli, Rajeev escribi�:
> Hi George, Raj,
>  
>
>   
>> GT> This is good justification answering the "why" and it leads to an
>> obvious set of options for the "what". It implies something 
>> about the solution space that I would like this BOF to be 
>> specific about. i.e., if the reason to do this is to enable 
>> inter-tech and multi-homing without client MIP in the mobile, 
>> does it mean:
>> a)  you do not want any mobility software in the mobile? (this seems
>> unrealistic)
>>     
>
> What constitutes "mobility software" without which the above features are unrealistic?
>
>
>   
>> b)  that you want L2 software in the client? (this is possible for
>> *some* technologies and I do not think that such work belongs 
>> to the IETF...but the BOF could discuss this)
>>     
>
> Agree. Part of this exercise is to identify what is feasible in L2, so that we don't spend our time on such things.
>
>   
>> c)  that you want network layer software in the  mobile but 
>> not MIP; (This clearly makes no sense given your "why")
>>
>>     
>
> We can start by saying that MIP has the ingredients you need to support the features of interest. For an operator, it is one of the options.
>
> We also need to look at supporting mobile nodes without MIP. In other words, we can say for a feature X, 1) MIP is one of the options, and 2) use PMIP-extensions if your particular deployment does not permit you to use option 1). 
>
>   
pleas describe what are the characteristics of the particular deployment 
that would not allow you to use option 1
these are the required features that need to be supported that will 
justify to make the work on an altenrative option

Regards, marcelo

> Regards,
>
> -Rajeev
>  
>
>
>   
>> Would you rather revise your "why" ? :-)
>>
>> George
>>
>>     
>>> One of the outcomes of this discussion is quite possibly 
>>>       
>> the fact that 
>>     
>>> the IETF believes the use of host based mobile IP protocols is the 
>>> right choice and recommends it as such. And that is fine. 
>>>       
>> But I think 
>>     
>>> we should also consider the approaches to providing these 
>>>       
>> features for 
>>     
>>> PMIP6 which would not necessarily result in reinventing host based 
>>> mobile IP type of capabilities on the MNs.
>>>
>>> I don't know if the above justifies the reason why we are 
>>>       
>> having this 
>>     
>>> discussion (yet again :) ).
>>>
>>> -Raj
>>>
>>>       
>>>> Hesham
>>>>
>>>>         
>>>>> Regards, marcelo
>>>>>
>>>>>           
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Regards, marcelo
>>>>>>>
>>>>>>>
>>>>>>> Hesham Soliman escribi�:
>>>>>>>
>>>>>>>               
>>>>>>>> A quick comment.
>>>>>>>> I don't see any reason for an IETF WG to look for a 
>>>>>>>>                 
>> solution that 
>>     
>>>>>>>> works for a limited set of technologies and try to 
>>>>>>>>                 
>> solve that on 
>>     
>>>>>>>> layer 2. This is clearly not our job. Similarly, there 
>>>>>>>>                 
>> is little 
>>     
>>>>>>>> gain in solving this for a limited set of technologies on L3 
>>>>>>>> given that we already have a layer 2 agnostic 
>>>>>>>>                 
>> solution. Why would 
>>     
>>>>>>>> we want to develop another one for a limited set of 
>>>>>>>>                 
>> link layers?
>>     
>>>>>>>> Hesham
>>>>>>>>
>>>>>>>>
>>>>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" 
>>>>>>>>                 
>> <[email-masked]> wrote:
>>     
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> George,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> great summary
>>>>>>>>
>>>>>>>> just one comment below...
>>>>>>>>
>>>>>>>>
>>>>>>>> George Tsirtsis
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> escribi�:
>>>>>>>>> With PMIP things are not so clear....it is not even 
>>>>>>>>>                   
>> clear we are
>>     
>>>>>>>>> talking about the *network layer*... and thus it is 
>>>>>>>>>                   
>> not so clear 
>>     
>>>>>>>>> how
>>>>>>>>>
>>>>>>>>> "generic" solutions can be.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> right, so one relevant question is how
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> generic we want this to be.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> For instance, it may be also sufficient to support
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> inter technology
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> handovers for a subset of L2 technologies that can support
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> it at the L2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> as you stated.
>>>>>>>> So, one thing that we need to define is whether
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> we are looking for a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> solution that supports inter technology handover with
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> any two L2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> combiantios or are we looking for a solution that 
>>>>>>>>                 
>> supports inter
>>     
>>>>>>>> technology handovers for a limited set of technologies?
>>>>>>>> I think this is a key
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> requirements that we need to be explicit about.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>                 
>>>>>>>>> The challenge for the BOF
>>>>>>>>> is to throw some light on how PMIP can be compatible 
>>>>>>>>>                   
>> with this 
>>     
>>>>>>>>> extended functionality,  what type of additional 
>>>>>>>>>                   
>> signalling is 
>>     
>>>>>>>>> needed, and at which layer they intend to implement such 
>>>>>>>>> signalling. Let's see.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> while i
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> agree with that, i think a first step that this bof needs to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> throw some light
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> on is what are the functional requirements for the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> support of the required
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> features. I think the previous is a good example
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> of one requirement that we
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> need to flesh out. There are many others.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Regards, marcelo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> George
>>>>>>>>>
>>>>>>>>> On
>>>>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>>>>>>>>>
>>>>>>>>> Perkins<[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> Hello Basavaraj,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> Isn't make-before-break a function performed
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> at the link layer?
>>>>>>>>>>
>>>>>>>>>> It
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> certainly isn't PHY, and I wouldn't think it
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> qualifies as MAC (i.e., it
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> doesn't control the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> device's access to the medium).
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> Charlie P.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> PS. Which is the proper mailing list for this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> discussion?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> [email-masked] wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> Frank,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> Make-before-break is inherently supported in certain
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> technologies such as
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> same is not possible
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> WiFi). 802.16e does have a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> contorted mechansim for achieving the same but
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> that's besides the point.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> So IMO it is a capability of the Phy/Mac.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> However it is possible to emulate soft-handovers and achieve
>>>>>>>>>
>>>>>>>>> make-before-break in certain cases. For example it is 
>>>>>>>>>                   
>> possible 
>>     
>>>>>>>>> to be
>>>>>>>>>
>>>>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>>>>>>>>>
>>>>>>>>> make-before-break
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> HO. I guess the definition of the term depends on an
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> access tchnology or
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> the
>>>>>>>>>>> combination of access technologies in the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> context of a use-case.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> -Raj
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> Xia" <[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>> Hi Raj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> IMHO Make-before-break is not a link-layer technology.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> , but  a concept
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> (or a strategy).    Related to the topic we
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> are discussing, making target
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> interface ready before moving
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> traffic to it is kind of
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> make-before-break.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> BR
>>>>>>>>>>>> Frank
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> From: <[email-masked]>
>>>>>>>>>>>> To:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> <[email-masked]>; <[email-masked]>; 
>>>>>>>>> <[email-masked]>;
>>>>>>>>>
>>>>>>>>> <[email-masked]>; <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>>>>>>>>>>>> Subject: Re:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>>>>>>>>>
>>>>>>>>> description
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> Hi Frank,
>>>>>>>>>>>>
>>>>>>>>>>>> Comments
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> inline:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> My main point is make-before-break strategy is the best
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> way to solve multi-radio handover.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>> The IETF cannot
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> do anything about whether an MN has the ability to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> accomplish
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> make-before-break connectivity. It depends on the link-layer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> technology,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> spectrum that they operate in, etc. So this approach is a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> non-starter.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> The IETF solution has to be agnostic to underlying access
>>>>>>>>>
>>>>>>>>> technologies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> Please see my inline
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> response.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> BR
>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> To: <[email-masked]>;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[email-masked]>; <[email-masked]>;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> <[email-masked]>;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>>>>>>>>>>>>> Subject:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>>>>>>>>> description
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> Frank,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/29/09 11:16
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> Hi Guys
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have comments on inter-technology
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> handover.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> IMHO, flow mobility could solve problems
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> inter-tech handover is try to deal with.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> Flow
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> mobility also includes the ability to move a flow 
>>>>>>>>>                   
>> from one mobility
>>     
>>>>>>>>> session to another. Multiple mobility sessions could 
>>>>>>>>>                   
>> be established via
>>     
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> single interface in which case flow mobility 
>>>>>>>>>>>>>                           
>> would be achieved
>>     
>>>>>>>>>>>>>                           
>>>>>>>>> within
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> the
>>>>>>>>>>>>> scope of a single interface. Hence flow mobility and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> inter-technology
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> handovers are separate features.
>>>>>>>>>>>>> Frank=>IMHO,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> inter-technology is trying to move all the traffic on
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> one interface to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> another interface.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>> Right. I guess you answered the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> question about the difference between
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> flow
>>>>>>>>>>>> mobility and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> inter-technology handovers. You could extrapolate and say
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> inter-technology HO is the case where you move all 
>>>>>>>>>                   
>> flows from one
>>     
>>>>>>>>> interface
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> to another and hence a variant of flow mobility. 
>>>>>>>>>>>>                         
>> While that is
>>     
>>>>>>>>>>>>                         
>>>>>>>>> true, you
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> should also recognize that the granularity of flow 
>>>>>>>>>>>>                         
>> mobility is
>>     
>>>>>>>>>>>>                         
>>>>>>>>> finer and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> does not have to necessarily be a relocation of a 
>>>>>>>>>>>>                         
>> flow between
>>     
>>>>>>>>>>>>                         
>>>>>>>>> physical
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> interfaces.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>>> I assume that two
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> heterogeneous interfaces are
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> all active during the handover.  It is
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> easy to move
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> a flow(or all flows) from an interface to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> another.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> Possibly.. But the point is to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> identify what extensions (possibly to the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> MN)
>>>>>>>>>>>>> are needed in order
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> to achieve handovers across interfaces.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> Frank=>If we see inter-tech
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> handover as a subset of flow mobility,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> there is one problem left, that
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> is flow mobility.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>> See above. Flow mobility is a
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> feature that can work across multiple
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> mobility
>>>>>>>>>>>> sessions within the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> scope of a single interface as well.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>>> This is
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> probably the reason why there is no
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> inter-tech handover solution
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> standerdized
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> for client MIP.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> Client
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> MIP inherently supports handovers across multiple interfaces.
>>>>>>>>>
>>>>>>>>> Performance improvements to the handovers are 
>>>>>>>>>                   
>> accomplished using
>>     
>>>>>>>>> solutions
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> such as FMIP.
>>>>>>>>>>>>> Frank=>Maybe, I am missing something.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> However FMIP  is not applicable
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> to PAR/NAR collocated scenario.  For
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> example, a mobile node with two
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> interface connects to the same access
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> router (ASN-GW for WiMAX,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> PDN-GW for LTE).   Does FMIP work when mobile
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> node handover from
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> one technology to another?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>> Not sure I understand the question. In your 
>>>>>>>>>>>>                         
>> example above, I believe
>>     
>>>>>>>>>>>>                         
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> MN
>>>>>>>>>>>> would connect to the ASN-GW via the WiMAX 
>>>>>>>>>>>>                         
>> interface and to an
>>     
>>>>>>>>>>>>                         
>>>>>>>>> S-GW via
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> the
>>>>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> question is, can
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> you
>>>>>>>>>>>> use FMIP to optimize handovers in such a
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> scenario... Yes. Not FMIP, but
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> think we are looking at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> optimizing
>>>>>>>>>>>> handovers in this
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> discussion.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> As per the current PMIP6 specification wherein no 
>>>>>>>>>>>>                         
>> changes to
>>     
>>>>>>>>>>>>                         
>>>>>>>>> the host are
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> required, it is not possible to do an inter-technology
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> handover. This is
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> a
>>>>>>>>>>>> limitation which implies that PMIP6 provides
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> host mobility to an MN
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> within
>>>>>>>>>>>> the scope of a single access
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> technology. Host based mobile IP does not
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> have
>>>>>>>>>>>> this
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> -Raj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> -Raj
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> BR
>>>>>>>>>>>>>> Frank
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> To:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> <[email-masked]>; "Ralph Droms" 
>>>>>>>>>                   
>> <[email-masked]>
>>     
>>>>>>>>>                   
>>>>>>>>>>>>>> Sent:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> Sunday, June 28, 2009 1:16 PM
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> of the bof description
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> This is a first draft of the BOF description for your
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> consideration.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> still very open so, feel free to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> comment on whether the proposed
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>> seems appropriate or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> not.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> NETEXT2 BOF description
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> -----------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> a network based mobility
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> PMIP6 provides mobility to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> IP hosts without requiring any protocol
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> enhancements or additional
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> capabilities on the host.
>>>>>>>>>>>>>>> Current
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> PMIP6 specification fully defines how to provide mobility
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> support for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> mobile nodes with a single interface roaming in a PMIP6
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> domain. The
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> goal of this BOF is gain understanding of how to support
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> nodes with
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> multiple interfaces (of possible different technologies) in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> PMIP6 network.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> In particular, this BOF assumes the following
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> scenario:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> multiple
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> access technologies and needs to support nodes that
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> have
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> multiple interfaces, possibly of different
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> technologies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> In particular, the following capabilities are
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> needed:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> - Inter-technology handover support. The MN has
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> initiated a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> communication over one interface and it needs to be able
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> to move
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> the established connection to a different interface of
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> a possibly different technology. The reason for moving
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> communication to another interface is because of the MNs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> mobility and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> attaching via a different interface. Basically
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> the ability to perform
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> handovers that span different access
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> technologies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> Multihoming support. The MN with multiple interfaces 
>>>>>>>>>                   
>> of possibly
>>     
>>>>>>>>> different technologies should be able to use them 
>>>>>>>>>                   
>> simultaneously to
>>     
>>>>>>>>> exchange data and manage the mobility of communications
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> established
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> through the different interfaces.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> - Flow mobility. A MN with
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> multiple interfaces of possibly
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> different technologies must be able to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> move a flow from
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> able
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> to inform the network through which interface it wishes
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> to receive different types of flows.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> In order to provide the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> support for these capabilities, different
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> approaches can be
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> envisioned, namely:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> the mechanisms
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> to provide the required capabilities are fully L2
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> mechanisms and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> no modification of the IP layer is needed.
>>>>>>>>>>>>>>> - L3
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> only approaches. In this type of approaches, the mechanism to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> to required capabilities are located in the IP layer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> - Hybrid L2/L3
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> approaches. In this case, some mechanisms are
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> located in L2 and other
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> mechanisms are located in L3.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> Now, the different possible approaches
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> vary greatly in their nature
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> and resulting capabilities. To
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> understanding the benefits and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> suitability of these alternatives, the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> requirements have to be
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> properly defined and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> understood.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> The main goal of the BOF is understanding the need
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> for work in the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> we will attempt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> to:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) Understand the applicable
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> scenarios, and the problem statement
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> related
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> those
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> 2) Understand the restrictions and requirement 
>>>>>>>>>>>>>>>                               
>> imposed to
>>     
>>>>>>>>>>>>>>>                               
>>>>>>>>> solutions to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> address the problem statement and scenarios
>>>>>>>>>>>>>>> 3)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> Get an overview of the proposed solutions
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>>                               
>>>>>>>>> _______________________________________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> netlmm mailing
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> netext mailing
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> _______________________________________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> MEXT mailing list
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> [email-masked]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> _______________________________________________
>>>>>>>>>> MEXT mailing list
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> [email-masked]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> _______________________________________________
>>>>>>>>> netlmm mailing list
>>>>>>>>>
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> _______________________________________________
>>>>>>>> netlmm mailing
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>
>>>>>>
>>>>>>             
>>>>         
>>>       
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>>     
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>
>   

From [email-masked]  Tue Jun 30 10:59:13 2009
Content-class: urn:content-classes:message
Date: Tue, 30 Jun 2009 13:36:21 -0400
From: "Koodli, Rajeev" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription

Hi Marcelo,
=20

> > We (as in the people in NetExt) want PMIP6 to support
inter-technology=20
> > handovers, flow binding/mobility and enhanced support for
multihoming
> > *because* :
> > 1. Not every host does or will include host based mobility protocols

> > such as (DS)MIP
> >  =20
> so what is the assumption requiremnent here?
> Is the requriemnent that the solution must work wihtout=20
> requiring any host support? Or is there some level of host=20
> support that is acceptble?=20

IMO, solutions that work without any new protocol extensions at the host
should be clearly preferred - note that this allows host configuration
changes (such as configuring a virtual interface).=20

We should not rule out protocol extensions, but must be "very
parsimonious".=20

> If so, why? (i mena, why some level of host support is=20
> accpetbale and other is not)
>=20

The extension must not dictate a change in paradigm of mobility. When we
say "use MIP if you need feature X" to an operator whose network is
based on PMIP, that represents a change of paradigm. A PMIP operator who
wishes to support features should be made aware that 1) MIP may already
have the capabilities, 2) that extensions are necessary to PMIP. Beyond
that, it is up to the operator.  =20

>=20
> > 2. An operator may choose to deploy a network with only network
based=20
> > mobility protocol support
> >
> >  =20
> right, what are the required functions that are provided by a=20
> network based mobility that are lacking in a host based=20
> mobility approach?

As a starting point, the host is not involved in mobility management
(aka, managing persistence and reachability).

What we are looking at here is not to change the mobility management
model (i.e., host does not know anything about mobility at L3), but to
consider MN - Network (MAG) interactions which *may* need L3 extensions.
 =20
Regards,

-Rajeev

>=20
> Regards, marcelo
>=20
>=20
> > -Raj
> >
> >
> >  =20
>=20
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>=20

From [email-masked]  Tue Jun 30 11:02:59 2009
Date: Tue, 30 Jun 2009 11:03:09 -0700
From: Rajeev Koodli <[email-masked]>
To: Marco Liebsch <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi Marco, Sri,

please, let's stick with Localized Routing for both (intra-MAG,
inter-MAG). Basically, there is no LMA involved in the data-path.

Thanks,

-Rajeev

On Tue, Jun 30, 2009 at 8:17 AM, Marco Liebsch<[email-masked]> wrote:
> Sri, all,
>
> Sri Gundavelli wrote:
>>
>>
>> Hi Marco,
>>
>>>> I some how looked at RO and localized routing as two
>>>
>>> different problems.
>>>>
>>>> I agree with this approach, if its about a basic localized
>>>
>>> routing, which
>>>>
>>>> I assumed was the context of the discussion, going with a
>>>
>>> solution draft
>>>>
>>>> is fine. If its for complete RO, may be a PS draft might help.
>>>
>>> The current individual PS draft specifies use cases taking
>>> the scope of
>>> NetExt into account, which includes setting up an optimized
>>> forwarding
>>> path between MAGs.
>>> I personally prefer the term route optimization, which is
>>> also the term
>>> being used
>>> in this context in the charter description. However, the chater mixes
>>> both terms, which
>>> should be ok if there is common understanding in that
>>> localized routing
>>> means 'local in the
>>> access of a PMIP domain', not 'local on a single MAG'.
>>>
>>
>> I agree. There seems to be some confusion on the terminology and
>> the scenarios that are in scope for this work. May be we need to
>> discuss this and agree upon.
>
> I think there is more common understanding on the scope than on the term.
> The scope has been
> discussed and presented in SF. This includes setting up an optimized route
> between MAGs
> of a single PMIPv6 domain. The same solution should handle the case where
> both mobiles
> connect to the same MAG. If you think the term Localized Routing is not
> appropriate to cover the
> scope to optimize a forwarding path beyond a single MAG, I'd prefer to stick
> to the term Route Optimization.
> I think that's rather unambiguous. Other opinions?
>
> marco
>
>
>
>>
>> Regards
>> Sri
>>
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

From [email-masked]  Tue Jun 30 11:14:35 2009
Date: Tue, 30 Jun 2009 11:13:19 -0700 (PDT)
From: Sri Gundavelli <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Marcelo,

>
>>  with simple clients.
>
> please define what do you mena by simple clients
>

Difficult question.

A simple client, not a client which takes the efforts equivalent
to designing a mother board for columbia rocket.

Quantification is difficult, its easy to argue, even though the
difference is huge, a client that only expresses attach/flow
preferences to some thing that requires MCOA/DSMIP6/MIP6 stacks,
performs tunnel management and all aspects of mobility signaling
with the home agent. But, I'm sure George can argue on this.

Regards
Sri

From [email-masked]  Tue Jun 30 11:23:02 2009
Date: Tue, 30 Jun 2009 18:09:08 +0200
From: marcelo bagnulo braun <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

[email-masked] escribi�:
> On 6/30/09 9:54 AM, "ext Hesham Soliman" <[email-masked]> wrote:
>
>   
>>
>>     
>>>> => I think the important question to ask is why this is an issue in the
>>>> first place? If you have a solution for the superset (all link layers)
>>>>         
>>> you are assuming and answer here, i.e. that the answer is that the
>>> requirement is a subset, which i don't know if it is the case
>>>
>>>       
>>>>  and
>>>> there is a question about whether you need a solution for a subset, then the
>>>> question we should ask is "why?". This has to be part of the discussion. "we
>>>> want ....*because*..."
>>>>
>>>>
>>>>         
>>> sure, "why?" is a valid question, but before asking ourselves "why?", we
>>> need to answer "what?"
>>>
>>> So, let's first provide an detailed answer of what is being required to
>>> support and and that point we will be in good shape to ask "why?"
>>> i don't think you can ask "why? until a proper answer has been provide
>>> to "what?"
>>>
>>> agree?
>>>       
>> => Ok, you're right about my assumption about the answer but it's not coming
>> from vaccuum :), it's not the first time this is discussed. But ok, I'm
>> happy to go through this exercise from the beginning. Let's ask "what" and
>> regardless of the answer ask "why" as well. Because requirements always need
>> to be justified.
>>     
>
> I think there is a reasonably good understanding that for the problems (what
> aspects in the discussion here) that are being stated, (DS)MIP6 is able to
> provide a solution already. I don't think that it is a surprise to anyone.
> So the question is : Why? If the IETF already has a solution for dealing
> with inter-technology handovers, flow binding/mobility and multihoming (RFCs
> 3775/5555 and related I-Ds in MEXT WG) why do we need to develop the same
> capabilities for network based mobility protocol (RFC5213)?
>
> Quite simply, the answer is that in certain deployments it is not feasible
> to expect DS(MIP6) capability on hosts. An operator cannot expect that every
> host connecting to the network implements (DS)MIP6. The operator has no
> control of the hosts or their capabilities to a large extent. The only thing
> the operator can and does control is the network, and hence the
> consideration to add such capabilities to a deployment which used network
> based mobility protocol.
>   
so, does the requirement for the solution you are looking for is "No 
host changes"?

(i mean, if the problem is that the operator has no control of the hosts 
so it cannot require the host to support a particular appraoch, i guess 
that no host changes would be the requirement that a solution would need 
to fullfill in order to comply with what you are looking for?

Regards, marcelo

> One of the outcomes of this discussion is quite possibly the fact that the
> IETF believes the use of host based mobile IP protocols is the right choice
> and recommends it as such. And that is fine. But I think we should also
> consider the approaches to providing these features for PMIP6 which would
> not necessarily result in reinventing host based mobile IP type of
> capabilities on the MNs.
>
> I don't know if the above justifies the reason why we are having this
> discussion (yet again :) ).
>
> -Raj
>
>   
>> Hesham
>>
>>     
>>> Regards, marcelo
>>>
>>>       
>>>> Hesham
>>>>
>>>>
>>>>         
>>>>> Regards, marcelo
>>>>>
>>>>>
>>>>> Hesham Soliman escribi�:
>>>>>
>>>>>           
>>>>>> A quick comment.
>>>>>> I don't see any reason for an IETF WG to look for a solution that works
>>>>>> for
>>>>>> a limited set of technologies and try to solve that on layer 2. This is
>>>>>> clearly not our job. Similarly, there is little gain in solving this for a
>>>>>> limited set of technologies on L3 given that we already have a layer 2
>>>>>> agnostic solution. Why would we want to develop another one for a limited
>>>>>> set of link layers?
>>>>>>
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" <[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> George,
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> great summary
>>>>>>
>>>>>> just one comment below...
>>>>>>
>>>>>>
>>>>>> George Tsirtsis
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> escribi�:
>>>>>>> With PMIP things are not so clear....it is not even clear we are
>>>>>>>
>>>>>>> talking about the *network layer*... and thus it is not so clear how
>>>>>>>
>>>>>>> "generic" solutions can be.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> right, so one relevant question is how
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> generic we want this to be.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> For instance, it may be also sufficient to support
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> inter technology
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> handovers for a subset of L2 technologies that can support
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> it at the L2
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> as you stated.
>>>>>> So, one thing that we need to define is whether
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> we are looking for a
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> solution that supports inter technology handover with
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> any two L2
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> combiantios or are we looking for a solution that supports inter
>>>>>>
>>>>>> technology handovers for a limited set of technologies?
>>>>>> I think this is a key
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> requirements that we need to be explicit about.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>             
>>>>>>> The challenge for the BOF
>>>>>>> is to throw some light on how PMIP can be
>>>>>>> compatible with this extended
>>>>>>> functionality,  what type of additional
>>>>>>> signalling is needed, and at which
>>>>>>> layer they intend to implement such
>>>>>>> signalling. Let's see.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> while i
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> agree with that, i think a first step that this bof needs to
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> throw some light
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> on is what are the functional requirements for the
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> support of the required
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> features. I think the previous is a good example
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> of one requirement that we
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> need to flesh out. There are many others.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> George
>>>>>>>
>>>>>>> On
>>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>>>>>>>
>>>>>>> Perkins<[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> Hello Basavaraj,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> Isn't make-before-break a function performed
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> at the link layer?
>>>>>>>>
>>>>>>>> It
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> certainly isn't PHY, and I wouldn't think it
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> qualifies as MAC (i.e., it
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> doesn't control the
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> device's access to the medium).
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> Charlie P.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> PS. Which is the proper mailing list for this
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> discussion?
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> [email-masked] wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> Frank,
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> Make-before-break is inherently supported in certain
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> technologies such as
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> same is not possible
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> WiFi). 802.16e does have a
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> contorted mechansim for achieving the same but
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> that's besides the point.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> So IMO it is a capability of the Phy/Mac.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> However it is possible to emulate soft-handovers and achieve
>>>>>>>
>>>>>>> make-before-break in certain cases. For example it is possible to be
>>>>>>>
>>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>>>>>>>
>>>>>>> make-before-break
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> HO. I guess the definition of the term depends on an
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> access tchnology or
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> the
>>>>>>>>> combination of access technologies in the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> context of a use-case.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> -Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> Xia" <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> Hi Raj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> IMHO Make-before-break is not a link-layer technology.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> , but  a concept
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> (or a strategy).    Related to the topic we
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> are discussing, making target
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> interface ready before moving
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> traffic to it is kind of
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> make-before-break.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> BR
>>>>>>>>>> Frank
>>>>>>>>>>
>>>>>>>>>> ----- Original Message
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> -----
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> From: <[email-masked]>
>>>>>>>>>> To:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> <[email-masked]>; <[email-masked]>; <[email-masked]>;
>>>>>>>
>>>>>>> <[email-masked]>; <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>>>>>>>>>> Subject: Re:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>>>>>>>
>>>>>>> description
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> Hi Frank,
>>>>>>>>>>
>>>>>>>>>> Comments
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> inline:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> Raj
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> My main point is make-before-break strategy
>>>>>>>>>>> is the best
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> way to solve multi-radio handover.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> The IETF cannot
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> do anything about whether an MN has the ability to
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> accomplish
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> make-before-break connectivity. It depends on the link-layer
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> technology,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> spectrum that they operate in, etc. So this approach is a
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> non-starter.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> The IETF solution has to be agnostic to underlying access
>>>>>>>
>>>>>>> technologies.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> Please see my inline
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> response.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> BR
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> To: <[email-masked]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[email-masked]>; <[email-masked]>;
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> <[email-masked]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>>>>>>>>>>> Subject:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>>>>>>> description
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> Frank,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 6/29/09 11:16
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>                       
>>>>>>>>>>>> Hi Guys
>>>>>>>>>>>>
>>>>>>>>>>>> I have comments on inter-technology
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> handover.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> IMHO, flow mobility could solve problems
>>>>>>>>>>>> which
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> inter-tech handover is try to deal with.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>> Flow
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> mobility also includes the ability to move a flow from one mobility
>>>>>>>
>>>>>>> session to another. Multiple mobility sessions could be established via
>>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> single interface in which case flow mobility would be achieved
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> within
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> the
>>>>>>>>>>> scope of a single interface. Hence flow mobility and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> inter-technology
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> handovers are separate features.
>>>>>>>>>>> Frank=>IMHO,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> inter-technology is trying to move all the traffic on
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> one interface to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> another interface.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> Right. I guess you answered the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> question about the difference between
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> flow
>>>>>>>>>> mobility and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> inter-technology handovers. You could extrapolate and say
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> inter-technology HO is the case where you move all flows from one
>>>>>>>
>>>>>>> interface
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> to another and hence a variant of flow mobility. While that is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> true, you
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> should also recognize that the granularity of flow mobility is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> finer and
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> does not have to necessarily be a relocation of a flow between
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> physical
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> interfaces.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>>> I assume that two
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> heterogeneous interfaces are
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> all active during the handover.  It is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> easy to move
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> a flow(or all flows) from an interface to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> another.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>> Possibly.. But the point is to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> identify what extensions (possibly to the
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> MN)
>>>>>>>>>>> are needed in order
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> to achieve handovers across interfaces.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> Frank=>If we see inter-tech
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> handover as a subset of flow mobility,
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> there is one problem left, that
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> is flow mobility.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> See above. Flow mobility is a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> feature that can work across multiple
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> mobility
>>>>>>>>>> sessions within the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> scope of a single interface as well.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>>> This is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> probably the reason why there is no
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> inter-tech handover solution
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> standerdized
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> for client MIP.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>> Client
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> MIP inherently supports handovers across multiple interfaces.
>>>>>>>
>>>>>>> Performance improvements to the handovers are accomplished using
>>>>>>>
>>>>>>> solutions
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> such as FMIP.
>>>>>>>>>>> Frank=>Maybe, I am missing something.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> However FMIP  is not applicable
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> to PAR/NAR collocated scenario.  For
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> example, a mobile node with two
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> interface connects to the same access
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> router (ASN-GW for WiMAX,
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> PDN-GW for LTE).   Does FMIP work when mobile
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> node handover from
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> one technology to another?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> Not sure I understand the question. In your example above, I believe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> the
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> MN
>>>>>>>>>> would connect to the ASN-GW via the WiMAX interface and to an
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> S-GW via
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> the
>>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> question is, can
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> you
>>>>>>>>>> use FMIP to optimize handovers in such a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> scenario... Yes. Not FMIP, but
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> think we are looking at
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> optimizing
>>>>>>>>>> handovers in this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> discussion.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> As per the current PMIP6 specification wherein no changes to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> the host are
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> required, it is not possible to do an inter-technology
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> handover. This is
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> a
>>>>>>>>>> limitation which implies that PMIP6 provides
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> host mobility to an MN
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> within
>>>>>>>>>> the scope of a single access
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> technology. Host based mobile IP does not
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> have
>>>>>>>>>> this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> problem.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> -Raj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> -Raj
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>>>> BR
>>>>>>>>>>>> Frank
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> To:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> Cc:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> <[email-masked]>; "Ralph Droms" <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> Sent:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> Sunday, June 28, 2009 1:16 PM
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> of the bof description
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> This is a first draft of the BOF description for your
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> consideration.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> It
>>>>>>>>>>>>> is
>>>>>>>>>>>>> still very open so, feel free to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> comment on whether the proposed
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> approach
>>>>>>>>>>>>> seems appropriate or
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> not.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> NETEXT2 BOF description
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> -----------------------
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> a network based mobility
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> PMIP6 provides mobility to
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> IP hosts without requiring any protocol
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> enhancements or additional
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> capabilities on the host.
>>>>>>>>>>>>> Current
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> PMIP6 specification fully defines how to provide mobility
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> support for
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> mobile nodes with a single interface roaming in a PMIP6
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> domain. The
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> goal of this BOF is gain understanding of how to support
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> nodes with
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> multiple interfaces (of possible different technologies) in
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> a
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> PMIP6 network.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> In particular, this BOF assumes the following
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> scenario:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> multiple
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> access technologies and needs to support nodes that
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> have
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> multiple interfaces, possibly of different
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> technologies.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> In particular, the following capabilities are
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> needed:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> - Inter-technology handover support. The MN has
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> initiated a
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> communication over one interface and it needs to be able
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> to move
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> the established connection to a different interface of
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> a possibly different technology. The reason for moving
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> communication to another interface is because of the MNs
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> mobility and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> attaching via a different interface. Basically
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> the ability to perform
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> handovers that span different access
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> technologies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> Multihoming support. The MN with multiple interfaces of possibly
>>>>>>>
>>>>>>> different technologies should be able to use them simultaneously to
>>>>>>>
>>>>>>> exchange data and manage the mobility of communications
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> established
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> through the different interfaces.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> - Flow mobility. A MN with
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> multiple interfaces of possibly
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> different technologies must be able to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> move a flow from
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> able
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> to inform the network through which interface it wishes
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> to receive different types of flows.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> In order to provide the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> support for these capabilities, different
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> approaches can be
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> envisioned, namely:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> the mechanisms
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> to provide the required capabilities are fully L2
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> mechanisms and
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> no modification of the IP layer is needed.
>>>>>>>>>>>>> - L3
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> only approaches. In this type of approaches, the mechanism to
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> provide
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> to required capabilities are located in the IP layer
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> - Hybrid L2/L3
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> approaches. In this case, some mechanisms are
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> located in L2 and other
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> mechanisms are located in L3.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> Now, the different possible approaches
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> vary greatly in their nature
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> and resulting capabilities. To
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> understanding the benefits and
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> suitability of these alternatives, the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> requirements have to be
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> properly defined and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> understood.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> The main goal of the BOF is understanding the need
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> for work in the
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> we will attempt
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> to:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Understand the applicable
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> scenarios, and the problem statement
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> related
>>>>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> those
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> 2) Understand the restrictions and requirement imposed to
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> solutions to
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> address the problem statement and scenarios
>>>>>>>>>>>>> 3)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> Get an overview of the proposed solutions
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>>                           
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> netlmm mailing
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>>                           
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> netext mailing
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> [email-masked]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> MEXT mailing list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> [email-masked]
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> [email-masked]
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>>
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> _______________________________________________
>>>>>> netlmm mailing
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>
>>>>
>>>>         
>>     
>
>
>   

From [email-masked]  Tue Jun 30 11:34:33 2009
Date: Tue, 30 Jun 2009 11:34:37 -0700 (PDT)
From: Behcet Sarikaya <[email-masked]>
To: MELIA TELEMACO <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
Reply-To: Behcet Sarikaya <[email-masked]>

Hi all,=0A=A0 I agree with Hesham we should use a single, e.g. netext ML fo=
r this discussion.=0APlease see below my views on Telemaco's mail.=0A=0AReg=
ards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: MELIA TE=
LEMACO <[email-masked]>=0A> To: Sri Gundavelli <sgundave=
@cisco.com>; [email-masked]=0A> Cc: [email-masked]; netlmm@ietf=
..org; [email-masked]=0A> Sent: Tuesday, June 30, 2009 12:23:31 PM=
=0A> Subject: Re: [netlmm] [netext] [MEXT] NEXTEXT2: first draft of the bof=
 description=0A> =0A> =0A> >=0A> > We (as in the people in NetExt) want PMI=
P6 to support inter-technology=0A> > handovers, flow binding/mobility and e=
nhanced support for multihoming=0A> > *because* :=0A> > 1. Not every host d=
oes or will include host based mobility protocols=0A> such as=0A> > (DS)MIP=
=0A> > 2. An operator may choose to deploy a network with only network base=
d=0A> > mobility protocol support=0A> >=0A> > -Raj=0A> >=0A> =0A> >Absolute=
ly. These features enable many practical usecases and we should=0A> >be abl=
e to allow them in a network that has deployed only network-based=0A> >mobi=
lity management protocol, with simple clients.=0A> =0A> =0A> Especially con=
sidering that some Mobile Operators are not planning to=0A> seriously deplo=
y DSMIPv6=0A> =0AMaybe so. But there are other facts like GTPv2 which was e=
xpected to be PMIP based but it did not happen.=0A=0AI think we should stop=
 second guessing operators.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A      

From [email-masked]  Tue Jun 30 12:54:50 2009
From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 30 Jun 2009 21:54:50 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Marcelo,

On 6/30/09 11:22 AM, "Marcelo Bagnulo" <[email-masked]> wrote:

> [email-masked] escribi=F3:
>> Hi Hesham,
>>=20
>>=20
>> On 6/30/09 8:48 AM, "ext Hesham Soliman" <[email-masked]> wrot=
e:
>>=20
>>=20
>> =20
>>> =3D> I think the important question to ask is why this is an issue in t=
he
>>> first place? If you have a solution for the superset (all link layers) =
and
>>> there is a question about whether you need a solution for a subset, the=
n the
>>> question we should ask is "why?". This has to be part of the discussion=
. "we
>>> want ....*because*..."
>>>=20
>>> Hesham
>>>=20
>>>   =20
>>=20
>> We (as in the people in NetExt) want PMIP6 to support inter-technology
>> handovers, flow binding/mobility and enhanced support for multihoming
>> *because* :
>> 1. Not every host does or will include host based mobility protocols suc=
h as
>> (DS)MIP
>> =20
> so what is the assumption requiremnent here?

I think the actual requirement on the host is to be

> Is the requriemnent that the solution must work wihtout requiring any
> host support? Or is there some level of host support that is acceptble?

In order to solve the listed problems, I think there is a need to have some
level of host support. So host support is not ruled out. However it is the
degree of changes on the host which are debatable? Implementing new protoco=
l
software on the host for example is on one extreme vs configuring the host =
n
certain ways being the other.

> If so, why? (i mena, why some level of host support is accpetbale and
> other is not)

Because of the fact that adding some level of capabilities on the host is
easier to accomplish than others.

>=20
>=20
>> 2. An operator may choose to deploy a network with only network based
>> mobility protocol support
>>=20
>> =20
> right, what are the required functions that are provided by a network
> based mobility that are lacking in a host based mobility approach?

Well, I am not sure I understand what you are asking here.
Obviously with a network based mobility approach, there are no protocol
changes expected on the host.
But if what you are asking is the functionality that is missing in the case
of a network based mobility approach as compared to a host based solution,
then the features such as flow binding/mobility and ability to indicate
handovers from one access to another etc. are missing.

-Raj

>=20
> Regards, marcelo
>=20
>=20
>> -Raj
>>=20
>>=20
>> =20
>=20

From [email-masked]  Tue Jun 30 13:01:48 2009
From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 30 Jun 2009 20:43:29 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

On 6/30/09 11:13 AM, "ext George Tsirtsis" <[email-masked]> wrote:

> inline...
>=20
> On Tue, Jun 30, 2009 at 4:52 PM, <[email-masked]> wrote:
>>> =3D> Ok, you're right about my assumption about the answer but it's not=
 coming
>>> from vaccuum :), it's not the first time this is discussed. But ok, I'm
>>> happy to go through this exercise from the beginning. Let's ask "what" =
and
>>> regardless of the answer ask "why" as well. Because requirements always=
 need
>>> to be justified.
>>=20
>> I think there is a reasonably good understanding that for the problems (=
what
>> aspects in the discussion here) that are being stated, (DS)MIP6 is able =
to
>> provide a solution already. I don't think that it is a surprise to anyon=
e.
>> So the question is : Why? If the IETF already has a solution for dealing
>> with inter-technology handovers, flow binding/mobility and multihoming (=
RFCs
>> 3775/5555 and related I-Ds in MEXT WG) why do we need to develop the sam=
e
>> capabilities for network based mobility protocol (RFC5213)?
>>=20
>> Quite simply, the answer is that in certain deployments it is not feasib=
le
>> to expect DS(MIP6) capability on hosts. An operator cannot expect that e=
very
>> host connecting to the network implements (DS)MIP6. The operator has no
>> control of the hosts or their capabilities to a large extent. The only t=
hing
>> the operator can and does control is the network, and hence the
>> consideration to add such capabilities to a deployment which used networ=
k
>> based mobility protocol.
>>=20
>=20
> GT> This is good justification answering the "why" and it leads to an
> obvious set of options for the "what". It implies something about the
> solution space that I would like this BOF to be specific about. i.e.,
> if the reason to do this is to enable inter-tech and multi-homing
> without client MIP in the mobile, does it mean:
> a)  you do not want any mobility software in the mobile? (this seems
> unrealistic)

I think this is one of the things to be investigated. Obviously we do not
intend to develop something equivalent to a MIP client which would perform
signaling with the MAG. That does not make sense. But I think there are
possibilities other than a MIP client approach which would be worthwhile to
consider.=20

> b)  that you want L2 software in the client? (this is possible for
> *some* technologies and I do not think that such work belongs to the
> IETF...but the BOF could discuss this)

One of the possibile outcomes is that in order to accomplish the stated
functionality, there is a need for certain L2 capabilities. Obviously the
IETF is not going to be able to do anything about that. But the IETF could
state that in order to support inter-technology handovers (and others) in
the context of PMIP6, certain layer 2 capabilities are expected. It is upto
SDOs and others that design and standardize L2s if these capabilities are
relevant to them.=20

> c)  that you want network layer software in the  mobile but not MIP;
> (This clearly makes no sense given your "why")

Again, I don't think I said that what I said equates to creating new networ=
k
layer software in the host other than MIP. If the conclusion of the
discussion results in the understanding that to accomplish these features
the only option is to develop network layer protocols/software, then I thin=
k
it would be logical to say "Use MIP". But I don't know if we are there yet.
At least there is a view that there are things other than developing new
network layer protocols/SW to achieve this functionality.

>=20
> Would you rather revise your "why" ? :-)

Not yet... But I am keeping an open mind :)

-Raj

>=20
> George
>=20

From [email-masked]  Tue Jun 30 14:09:17 2009
Date: Tue, 30 Jun 2009 14:09:24 -0700 (PDT)
From: Behcet Sarikaya <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
Reply-To: Behcet Sarikaya <[email-masked]>

Hi Raj,=0A=0A=0A=0A----- Original Message ----=0A> From: "Basavaraj.Patil@n=
okia.com" <[email-masked]>=0A> To: [email-masked]=0A> Cc: ne=
[email-masked]; [email-masked]=0A> Sent: Tuesday, June 30, 2009 2:54:50 PM=
=0A> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof=
 description=0A> =0A> =0A> Hi Marcelo,=0A> =0A> =0A> On 6/30/09 11:22 AM, "=
Marcelo Bagnulo" wrote:=0A> =0A> > [email-masked] escribi=F3:=0A=
> >> Hi Hesham,=0A> >> =0A> >> =0A> >> On 6/30/09 8:48 AM, "ext Hesham Soli=
man" wrote:=0A> >> =0A> >> =0A> >>=A0 =0A> >>> =3D> I think the important q=
uestion to ask is why this is an issue in the=0A> >>> first place? If you h=
ave a solution for the superset (all link layers) and=0A> >>> there is a qu=
estion about whether you need a solution for a subset, then the=0A> >>> que=
stion we should ask is "why?". This has to be part of the discussion. "we=
=0A> >>> want ....*because*..."=0A> >>> =0A> >>> Hesham=0A> >>> =0A> >>>=A0=
 =A0 =0A> >> =0A> >> We (as in the people in NetExt) want PMIP6 to support =
inter-technology=0A> >> handovers, flow binding/mobility and enhanced suppo=
rt for multihoming=0A> >> *because* :=0A> >> 1. Not every host does or will=
 include host based mobility protocols such as=0A> >> (DS)MIP=0A> >>=A0 =0A=
> > so what is the assumption requiremnent here?=0A> =0A> I think the actua=
l requirement on the host is to be=0A> =0A> > Is the requriemnent that the =
solution must work wihtout requiring any=0A> > host support? Or is there so=
me level of host support that is acceptble?=0A> =0A> In order to solve the =
listed problems, I think there is a need to have some=0A> level of host sup=
port. So host support is not ruled out. However it is the=0A> degree of cha=
nges on the host which are debatable? Implementing new protocol=0A> softwar=
e on the host for example is on one extreme vs configuring the host n=0A> c=
ertain ways being the other.=0A=0AMy view on this is that if host support i=
s not ruled out the resulting protocol can no longer be called Proxied Mobi=
le IPv6 or PMIPv6 as defined in RFC 5213.=0A=0AThe resulting protocol is no=
t going to be Mobile IPv6 as defined in RFC 3775 either. So what you are pr=
oposing is something in between, let's call it quasi-proxied Mobile IPv6 or=
 QPMIPv6. =0A=0AIt si clear that QPMIPv6 will be close to MIPv6 in terms of=
 its strength in handling inter-technology handover, flow mobility, and you=
 name it, not maybe as strong as MIPv6 but it will be close.=0A=0AI hear pe=
ople saying there is a lot of enthusiasm on PMIPv6 by the operators, and pl=
ans to deploy, several trials are happening, etc. This could be true but re=
member that PMIPv6 has the attractive features of no host involvement and w=
ireless link bandwidth savings.=0A=0AOne should ask if QPMIPv6 will preserv=
e those beauties? And therefore the charm on the operators will still conti=
nue? =0A=0AI think that the BoF should debate this: does IETF wish/need to =
develop a third kind of IP level mobility protocol?=0A=0A=0ARegards,=0A=0AB=
ehcet=0A=0A=0A      

From [email-masked]  Tue Jun 30 14:19:26 2009
Date: Tue, 30 Jun 2009 14:19:45 -0700
From: Rajeev Koodli <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Raj,

>> c) =A0that you want network layer software in the =A0mobile but not MIP;
>> (This clearly makes no sense given your "why")
>
> Again, I don't think I said that what I said equates to creating new netw=
ork
> layer software in the host other than MIP. If the conclusion of the
> discussion results in the understanding that to accomplish these features
> the only option is to develop network layer protocols/software, then I th=
ink
> it would be logical to say "Use MIP". But I don't know if we are there ye=
t.
> At least there is a view that there are things other than developing new
> network layer protocols/SW to achieve this functionality.

Are you saying that if we do develop an extension in L3, that would
equate to MIP?

You could have a functionality in L3 independent of the actual
mobility model, no?

-Rajeev

>
>>
>> Would you rather revise your "why" ? :-)
>
> Not yet... But I am keeping an open mind :)
>
> -Raj
>
>>
>> George
>>
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

From [email-masked]  Tue Jun 30 14:34:43 2009
Date: Tue, 30 Jun 2009 14:34:11 -0700
From: Rajeev Koodli <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

(limiting to NetExt only)

On Tue, Jun 30, 2009 at 9:09 AM, marcelo bagnulo
braun<[email-masked]> wrote:

> so, does the requirement for the solution you are
> looking for is "No host changes"? (i mean, if the problem is that the
> operator has no control of the hosts so it cannot require the host to
> support a particular appraoch, i guess that no host changes would be the
> requirement that a solution would need to fullfill in order to comply with
> what you are looking for?

"No host changes" is ill-defined. Perhaps we should use "no host
protocol extensions" to state this.

As I mentioned earlier, it would be premature to rule out L3
extensions IF L2 capabilities and host configurations alone cannot
support the feature. If we are forced to support L3 extensions, it
would be up to the operator to decide.

-Rajeev

> Regards, marcelo

From [email-masked]  Tue Jun 30 17:57:33 2009
Date: Wed, 01 Jul 2009 10:34:01 +1000
From: Hesham Soliman <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Raj,=20

I told Marcelo I'll go through the exercise from the beginning again, but I
can't help respond to this comment.

>> =3D> Ok, you're right about my assumption about the answer but it's not co=
ming
>> from vaccuum :), it's not the first time this is discussed. But ok, I'm
>> happy to go through this exercise from the beginning. Let's ask "what" a=
nd
>> regardless of the answer ask "why" as well. Because requirements always =
need
>> to be justified.
>=20
> Quite simply, the answer is that in certain deployments it is not feasibl=
e
> to expect DS(MIP6) capability on hosts. An operator cannot expect that ev=
ery
> host connecting to the network implements (DS)MIP6. The operator has no
> control of the hosts or their capabilities to a large extent. The only th=
ing
> the operator can and does control is the network, and hence the
> consideration to add such capabilities to a deployment which used network
> based mobility protocol.

=3D> No one I know can get a 3G data card to access the Internet from their P=
C
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).

Hesham

>=20
> One of the outcomes of this discussion is quite possibly the fact that th=
e
> IETF believes the use of host based mobile IP protocols is the right choi=
ce
> and recommends it as such. And that is fine. But I think we should also
> consider the approaches to providing these features for PMIP6 which would
> not necessarily result in reinventing host based mobile IP type of
> capabilities on the MNs.
>=20
> I don't know if the above justifies the reason why we are having this
> discussion (yet again :) ).
>=20
> -Raj
>=20
>>=20
>> Hesham
>>=20
>>>=20
>>> Regards, marcelo
>>>=20
>>>> Hesham
>>>>=20
>>>>=20
>>>>> Regards, marcelo
>>>>>=20
>>>>>=20
>>>>> Hesham Soliman escribi=F3:
>>>>>=20
>>>>>> A quick comment.
>>>>>> I don't see any reason for an IETF WG to look for a solution that wo=
rks
>>>>>> for
>>>>>> a limited set of technologies and try to solve that on layer 2. This=
 is
>>>>>> clearly not our job. Similarly, there is little gain in solving this=
 for
>>>>>> a
>>>>>> limited set of technologies on L3 given that we already have a layer=
 2
>>>>>> agnostic solution. Why would we want to develop another one for a li=
mited
>>>>>> set of link layers?
>>>>>>=20
>>>>>> Hesham
>>>>>>=20
>>>>>>=20
>>>>>> On 30/06/09 10:39 PM, "marcelo bagnulo braun" <[email-masked]> w=
rote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> George,
>>>>>>>=20
>>>>>>>=20
>>>>>> great summary
>>>>>>=20
>>>>>> just one comment below...
>>>>>>=20
>>>>>>=20
>>>>>> George Tsirtsis
>>>>>>=20
>>>>>>=20
>>>>>>> escribi=F3:
>>>>>>> With PMIP things are not so clear....it is not even clear we are
>>>>>>>=20
>>>>>>> talking about the *network layer*... and thus it is not so clear ho=
w
>>>>>>>=20
>>>>>>> "generic" solutions can be.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>> right, so one relevant question is how
>>>>>>=20
>>>>>>=20
>>>>>>> generic we want this to be.
>>>>>>>=20
>>>>>>>=20
>>>>>> For instance, it may be also sufficient to support
>>>>>>=20
>>>>>>=20
>>>>>>> inter technology
>>>>>>>=20
>>>>>>>=20
>>>>>> handovers for a subset of L2 technologies that can support
>>>>>>=20
>>>>>>=20
>>>>>>> it at the L2
>>>>>>>=20
>>>>>>>=20
>>>>>> as you stated.
>>>>>> So, one thing that we need to define is whether
>>>>>>=20
>>>>>>=20
>>>>>>> we are looking for a
>>>>>>>=20
>>>>>>>=20
>>>>>> solution that supports inter technology handover with
>>>>>>=20
>>>>>>=20
>>>>>>> any two L2
>>>>>>>=20
>>>>>>>=20
>>>>>> combiantios or are we looking for a solution that supports inter
>>>>>>=20
>>>>>> technology handovers for a limited set of technologies?
>>>>>> I think this is a key
>>>>>>=20
>>>>>>=20
>>>>>>> requirements that we need to be explicit about.
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> The challenge for the BOF
>>>>>>> is to throw some light on how PMIP can be
>>>>>>> compatible with this extended
>>>>>>> functionality,  what type of additional
>>>>>>> signalling is needed, and at which
>>>>>>> layer they intend to implement such
>>>>>>> signalling. Let's see.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>> while i
>>>>>>=20
>>>>>>=20
>>>>>>> agree with that, i think a first step that this bof needs to
>>>>>>>=20
>>>>>>>=20
>>>>>> throw some light
>>>>>>=20
>>>>>>=20
>>>>>>> on is what are the functional requirements for the
>>>>>>>=20
>>>>>>>=20
>>>>>> support of the required
>>>>>>=20
>>>>>>=20
>>>>>>> features. I think the previous is a good example
>>>>>>>=20
>>>>>>>=20
>>>>>> of one requirement that we
>>>>>>=20
>>>>>>=20
>>>>>>> need to flesh out. There are many others.
>>>>>>>=20
>>>>>>>=20
>>>>>> Regards, marcelo
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> George
>>>>>>>=20
>>>>>>> On
>>>>>>> Tue, Jun 30, 2009 at 1:43 AM, Charles E.
>>>>>>>=20
>>>>>>> Perkins<[email-masked]> wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Hello Basavaraj,
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> Isn't make-before-break a function performed
>>>>>>>=20
>>>>>>>=20
>>>>>>>> at the link layer?
>>>>>>>>=20
>>>>>>>> It
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> certainly isn't PHY, and I wouldn't think it
>>>>>>>=20
>>>>>>>=20
>>>>>>>> qualifies as MAC (i.e., it
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> doesn't control the
>>>>>>>=20
>>>>>>>=20
>>>>>>>> device's access to the medium).
>>>>>>>>=20
>>>>>>>> Regards,
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> Charlie P.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> PS. Which is the proper mailing list for this
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> discussion?
>>>>>>>=20
>>>>>>>=20
>>>>>>>> [email-masked] wrote:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> Hi
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> Frank,
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> Make-before-break is inherently supported in certain
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> technologies such as
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> CDMA/WCDMA (which has soft HO features built in). The
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> same is not possible
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> for example in TDMA (GSM) or OFDMA (802.16e and
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> WiFi). 802.16e does have a
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> contorted mechansim for achieving the same but
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> that's besides the point.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> So IMO it is a capability of the Phy/Mac.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> However it is possible to emulate soft-handovers and achieve
>>>>>>>=20
>>>>>>> make-before-break in certain cases. For example it is possible to b=
e
>>>>>>>=20
>>>>>>> simultaneously connected to HSPA and WiFi and accomplish a
>>>>>>>=20
>>>>>>> make-before-break
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> HO. I guess the definition of the term depends on an
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> access tchnology or
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> the
>>>>>>>>> combination of access technologies in the
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> context of a use-case.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> -Raj
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 6/29/09 4:36 PM, "ext Frank
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> Xia" <[email-masked]> wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> Hi Raj
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> IMHO Make-before-break is not a link-layer technology.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> , but  a concept
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> (or a strategy).    Related to the topic we
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> are discussing, making target
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> interface ready before moving
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> traffic to it is kind of
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> make-before-break.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> BR
>>>>>>>>>> Frank
>>>>>>>>>>=20
>>>>>>>>>> ----- Original Message
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> -----
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> From: <[email-masked]>
>>>>>>>>>> To:
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> <[email-masked]>; <[email-masked]>; <[email-masked]>;
>>>>>>>=20
>>>>>>> <[email-masked]>; <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> Sent: Monday, June 29, 2009 3:43 PM
>>>>>>>>>> Subject: Re:
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> [netext] [netlmm] NEXTEXT2: first draft of the bof
>>>>>>>=20
>>>>>>> description
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> Hi Frank,
>>>>>>>>>>=20
>>>>>>>>>> Comments
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> inline:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> On 6/29/09 2:57 PM, "ext Frank Xia"
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> <[email-masked]> wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> Hi
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> Raj
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> My main point is make-before-break strategy
>>>>>>>>>>> is the best
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> way to solve multi-radio handover.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>> The IETF cannot
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> do anything about whether an MN has the ability to
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> accomplish
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> make-before-break connectivity. It depends on the link-layer
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> technology,
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> spectrum that they operate in, etc. So this approach is a
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> non-starter.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> The IETF solution has to be agnostic to underlying access
>>>>>>>=20
>>>>>>> technologies.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> Please see my inline
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> response.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> BR
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From:
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> To: <[email-masked]>;
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> <[email-masked]>; <[email-masked]>;
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> <[email-masked]>;
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> Cc: <[email-masked]>;
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> Sent: Monday, June 29, 2009 11:50 AM
>>>>>>>>>>> Subject:
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> Re: [netlmm] NEXTEXT2: first draft of the bof
>>>>>>> description
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> Frank,
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On 6/29/09 11:16
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> AM, "ext Frank Xia" <[email-masked]> wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> Hi Guys
>>>>>>>>>>>>=20
>>>>>>>>>>>> I have comments on inter-technology
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> handover.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> IMHO, flow mobility could solve problems
>>>>>>>>>>>> which
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> inter-tech handover is try to deal with.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>> Flow
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> mobility also includes the ability to move a flow from one mobility
>>>>>>>=20
>>>>>>> session to another. Multiple mobility sessions could be established=
 via
>>>>>>>=20
>>>>>>> a
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> single interface in which case flow mobility would be achieved
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> within
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> the
>>>>>>>>>>> scope of a single interface. Hence flow mobility and
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> inter-technology
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> handovers are separate features.
>>>>>>>>>>> Frank=3D>IMHO,
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> inter-technology is trying to move all the traffic on
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> one interface to
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> another interface.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>> Right. I guess you answered the
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> question about the difference between
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> flow
>>>>>>>>>> mobility and
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> inter-technology handovers. You could extrapolate and say
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> that
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> inter-technology HO is the case where you move all flows from one
>>>>>>>=20
>>>>>>> interface
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> to another and hence a variant of flow mobility. While that is
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> true, you
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> should also recognize that the granularity of flow mobility is
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> finer and
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> does not have to necessarily be a relocation of a flow between
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> physical
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> interfaces.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>> I assume that two
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> heterogeneous interfaces are
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> all active during the handover.  It is
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> easy to move
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> a flow(or all flows) from an interface to
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> another.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>> Possibly.. But the point is to
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> identify what extensions (possibly to the
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> MN)
>>>>>>>>>>> are needed in order
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> to achieve handovers across interfaces.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> Frank=3D>If we see inter-tech
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> handover as a subset of flow mobility,
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> there is one problem left, that
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> is flow mobility.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>> See above. Flow mobility is a
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> feature that can work across multiple
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> mobility
>>>>>>>>>> sessions within the
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> scope of a single interface as well.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>> This is
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> probably the reason why there is no
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> inter-tech handover solution
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> standerdized
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> for client MIP.
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>> Client
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> MIP inherently supports handovers across multiple interfaces.
>>>>>>>=20
>>>>>>> Performance improvements to the handovers are accomplished using
>>>>>>>=20
>>>>>>> solutions
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> such as FMIP.
>>>>>>>>>>> Frank=3D>Maybe, I am missing something.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> However FMIP  is not applicable
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> to PAR/NAR collocated scenario.  For
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> example, a mobile node with two
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> interface connects to the same access
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> router (ASN-GW for WiMAX,
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> PDN-GW for LTE).   Does FMIP work when mobile
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> node handover from
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> one technology to another?
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>> Not sure I understand the question. In your example above, I bel=
ieve
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> the
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> MN
>>>>>>>>>> would connect to the ASN-GW via the WiMAX interface and to an
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> S-GW via
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> the
>>>>>>>>>> LTE interface. The P-GW (LMA) may be the same. If the
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> question is, can
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> you
>>>>>>>>>> use FMIP to optimize handovers in such a
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> scenario... Yes. Not FMIP, but
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> PFMIP6 (ref. MIPSHOP WG I-D). But I don't
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> think we are looking at
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> optimizing
>>>>>>>>>> handovers in this
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> discussion.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> As per the current PMIP6 specification wherein no changes to
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> the host are
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> required, it is not possible to do an inter-technology
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> handover. This is
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> a
>>>>>>>>>> limitation which implies that PMIP6 provides
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> host mobility to an MN
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> within
>>>>>>>>>> the scope of a single access
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> technology. Host based mobile IP does not
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> have
>>>>>>>>>> this
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> problem.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> -Raj
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> -Raj
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> BR
>>>>>>>>>>>> Frank
>>>>>>>>>>>>=20
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> From: "marcelo bagnulo braun" <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> To:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> <[email-masked]>; "mext" <[email-masked]>; <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> Cc:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> <[email-masked]>; "Ralph Droms" <[email-masked]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> Sent:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> Sunday, June 28, 2009 1:16 PM
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> Subject: [netlmm] NEXTEXT2: first draft
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> of the bof description
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> This is a first draft of the BOF description for your
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> consideration.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> It
>>>>>>>>>>>> is
>>>>>>>>>>>> still very open so, feel free to
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> comment on whether the proposed
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> approach
>>>>>>>>>>>> seems appropriate or
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> not.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> NETEXT2 BOF description
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> -----------------------
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> Proxy Mobile IPv6 (PMIP6) [RFC5213] is
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> a network based mobility
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> protocol built on Mobile IPv6 [RFC3775].
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> PMIP6 provides mobility to
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> IP hosts without requiring any protocol
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> enhancements or additional
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> capabilities on the host.
>>>>>>>>>>>> Current
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> PMIP6 specification fully defines how to provide mobility
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> support for
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> mobile nodes with a single interface roaming in a PMIP6
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> domain. The
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> goal of this BOF is gain understanding of how to support
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> nodes with
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> multiple interfaces (of possible different technologies) in
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> a
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> PMIP6 network.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> In particular, this BOF assumes the following
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> scenario:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> We have a single PMIP6 domain that has deployed
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> multiple
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> access technologies and needs to support nodes that
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> have
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> multiple interfaces, possibly of different
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> technologies.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> In particular, the following capabilities are
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> needed:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> - Inter-technology handover support. The MN has
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> initiated a
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> communication over one interface and it needs to be able
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> to move
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> the established connection to a different interface of
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> a possibly different technology. The reason for moving
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> the
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> communication to another interface is because of the MNs
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> mobility and
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> attaching via a different interface. Basically
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> the ability to perform
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> handovers that span different access
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> technologies.
>>>>>>>>>>>>=20
>>>>>>>>>>>> -
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> Multihoming support. The MN with multiple interfaces of possibly
>>>>>>>=20
>>>>>>> different technologies should be able to use them simultaneously to
>>>>>>>=20
>>>>>>> exchange data and manage the mobility of communications
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> established
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> through the different interfaces.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> - Flow mobility. A MN with
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> multiple interfaces of possibly
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> different technologies must be able to
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> move a flow from
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> one interface to another. Moreover, the MN should be
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> able
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> to inform the network through which interface it wishes
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> to receive different types of flows.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> In order to provide the
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> support for these capabilities, different
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> approaches can be
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> envisioned, namely:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> - L2 only approaches. In this type of approaches,
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> the mechanisms
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> to provide the required capabilities are fully L2
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> mechanisms and
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> no modification of the IP layer is needed.
>>>>>>>>>>>> - L3
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> only approaches. In this type of approaches, the mechanism to
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> provide
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> to required capabilities are located in the IP layer
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> - Hybrid L2/L3
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> approaches. In this case, some mechanisms are
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> located in L2 and other
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> mechanisms are located in L3.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> Now, the different possible approaches
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> vary greatly in their nature
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> and resulting capabilities. To
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> understanding the benefits and
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> suitability of these alternatives, the
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> requirements have to be
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> properly defined and
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> understood.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> The main goal of the BOF is understanding the need
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> for work in the
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> IETF in this area. In order to do so, during the BOF,
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> we will attempt
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> to:
>>>>>>>>>>>>=20
>>>>>>>>>>>> 1) Understand the applicable
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> scenarios, and the problem statement
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> related
>>>>>>>>>>>> to
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> those
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> 2) Understand the restrictions and requirement imposed to
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> solutions to
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> address the problem statement and scenarios
>>>>>>>>>>>> 3)
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> Get an overview of the proposed solutions
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> netlmm mailing
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> list
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> netext mailing
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> list
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> [email-masked]
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> MEXT mailing list
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> [email-masked]
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> [email-masked]
>>>>>>>=20
>>>>>>>=20
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>>=20
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> netlmm mailing
>>>>>>=20
>>>>>>=20
>>>>>>> list
>>>>>>>=20
>>>>>>>=20
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>>=20
>=20

From [email-masked]  Tue Jun 30 17:59:12 2009
Date: Wed, 01 Jul 2009 10:59:17 +1000
From: Hesham Soliman <[email-masked]>
To: Rajeev Koodli <[email-masked]>, marcelo bagnulo braun <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

On 1/07/09 7:34 AM, "Rajeev Koodli" <[email-masked]> wrote:

> (limiting to NetExt only)
> 
> On Tue, Jun 30, 2009 at 9:09 AM, marcelo bagnulo
> braun<[email-masked]> wrote:
> 
>> so, does the requirement for the solution you are
>> looking for is "No host changes"? (i mean, if the problem is that the
>> operator has no control of the hosts so it cannot require the host to
>> support a particular appraoch, i guess that no host changes would be the
>> requirement that a solution would need to fullfill in order to comply with
>> what you are looking for?
> 
> "No host changes" is ill-defined. Perhaps we should use "no host
> protocol extensions" to state this.

=> That sort of makes sense. Or it's consistent with what you stated
earlier. 

> 
> As I mentioned earlier, it would be premature to rule out L3
> extensions IF L2 capabilities and host configurations alone cannot
> support the feature.

=> That's 180 diversion from the above statement. Are L3 protocols allowed
or not? I don't call them extensions because it's not clear which protocol
is being extended. 

If we are forced to support L3 extensions, it
> would be up to the operator to decide.

=> I don't understand this sentence. Why "forced" to support L3? Do you mean
the operator will decide to use it or not?

Hesham

> 
> -Rajeev
> 
> 
>> Regards, marcelo
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Tue Jun 30 18:48:35 2009
Date: Wed, 01 Jul 2009 09:48:44 +0800
From: Qin Wu <[email-masked]>
To: Marco Liebsch <[email-masked]>, Sri Gundavelli <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] WG view about problem statement I-D for localized routing

Hi, all:
To well reflect the scope and address the concern in discussion, I would like to 
suggest to use "local routing optimization" or "localized routing optimization" to
be a compromise choice. Any thoughts!

Regards!
-Qin 
----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 30, 2009 11:17 PM
Subject: Re: [netext] WG view about problem statement I-D for localized routing

> Sri, all,
> 
> Sri Gundavelli wrote:
>>
>>
>> Hi Marco,
>>
>>>> I some how looked at RO and localized routing as two
>>> different problems.
>>>> I agree with this approach, if its about a basic localized
>>> routing, which
>>>> I assumed was the context of the discussion, going with a
>>> solution draft
>>>> is fine. If its for complete RO, may be a PS draft might help.
>>> The current individual PS draft specifies use cases taking
>>> the scope of
>>> NetExt into account, which includes setting up an optimized
>>> forwarding
>>> path between MAGs.
>>> I personally prefer the term route optimization, which is
>>> also the term
>>> being used
>>> in this context in the charter description. However, the chater mixes
>>> both terms, which
>>> should be ok if there is common understanding in that
>>> localized routing
>>> means 'local in the
>>> access of a PMIP domain', not 'local on a single MAG'.
>>>
>>
>> I agree. There seems to be some confusion on the terminology and
>> the scenarios that are in scope for this work. May be we need to
>> discuss this and agree upon.
> I think there is more common understanding on the scope than on the 
> term. The scope has been
> discussed and presented in SF. This includes setting up an optimized 
> route between MAGs
> of a single PMIPv6 domain. The same solution should handle the case 
> where both mobiles
> connect to the same MAG. If you think the term Localized Routing is not 
> appropriate to cover the
> scope to optimize a forwarding path beyond a single MAG, I'd prefer to 
> stick to the term Route Optimization.
> I think that's rather unambiguous. Other opinions?
> 
> marco
> 
> 
> 
>>
>> Regards
>> Sri
>>
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

From [email-masked]  Tue Jun 30 20:44:15 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Wed, 1 Jul 2009 05:43:40 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description

Hi Hesham,

>Hi Raj,
>
>I told Marcelo I'll go through the exercise from the beginning again, but =
I
>can't help respond to this comment.

>> Quite simply, the answer is that in certain deployments it is not feasib=
le
>> to expect DS(MIP6) capability on hosts. An operator cannot expect that e=
very
>> host connecting to the network implements (DS)MIP6. The operator has no
>> control of the hosts or their capabilities to a large extent. The only t=
hing
>> the operator can and does control is the network, and hence the
>> consideration to add such capabilities to a deployment which used networ=
k
>> based mobility protocol.

>=3D> No one I know can get a 3G data card to access the Internet from thei=
r 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 th=
e
>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=20
wifi now being an integral part of the notebook computers.=20
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 o=
n these but at least the end user
is not installing anything else.=20
Does it imply that such hosts will include the software that would enable h=
ost mobility? Its an open question (i.e unknown)
and will depend largely on operator choices and vendors.=20

-Raj

>Hesham

From [email-masked]  Tue Jun 30 20:59:42 2009
Date: Wed, 01 Jul 2009 13:59:00 +1000
From: Hesham Soliman <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [netext] [netlmm] [MEXT] 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

From [email-masked]  Tue Jun 30 22:21:40 2009
Date: Wed, 01 Jul 2009 13:21:56 +0800
From: Xiangsong Cui <[email-masked]>
To: [email-masked], Jari Arkko <[email-masked]>, Hui Deng <[email-masked]>
Subject: [netext] A consideration for NETEXT2

Hello all,

I see a lot of discussion, may we look at the question
in another way?

In my mind, there are four fields exist, as following:

                  |
Field A:          |    Field B:
                  |
Simple IP and     |    Simple IP and
one interface     |    multiple interfaces
                  |
------------------------------------------
                  |
Field C:          |    Field D:
                  |   
NETLMM IP and     |    NETEXT2 IP and
one interface     |    multiple interfaces
                  |

Field A focuses normal IP topics.
Field B focuses multiple interface, i.e. MIF.
Field C focuses network-based mobility, i.e. NETLMM.
Field D, i.e. NETEXT2 is the focus we are discussing.

If we compare the adjacent fields, we can find:
A is the baseline;
B is MIF WG, enhancing the interface management from A;
C is NETLMM WG, enhancing the mobility from A;

For field D,
compare to C, NETEXT2 enhances the interface management;
compare to B, NETEXT2 enhances the mobility management.
I think for mobile nodes in field B, there is no any
additional modification need to go into field D.
This is actually the purpose of NETEXT2.
Or anybody can tell me the impact?

We MUST notice the fact that lots of mobile nodes have already
had the ability of multi-interface for different radio 
technology.
Yes, if you compare D to A, the mobile node must be modified,
But we can not ignore the mobile nodes in field B.
NETEXT2 is for the nodes from field B, but not for the nodes from field A.

More and more mobile nodes have evolved to field B.
I believe we must do something for them, maybe just the 
mobility enhancement based on network.

Regards

Xiangsong

From [email-masked]  Tue Jun 30 22:24:52 2009
Date: Wed, 01 Jul 2009 13:25:01 +0800
From: Xiangsong Cui <[email-masked]>
To: Xiangsong Cui <[email-masked]>, [email-masked], Jari Arkko <[email-masked]>, Hui Deng <[email-masked]>
Subject: Re: [netext] A consideration for NETEXT2

Sorry the figure is confusing.
I fix it in the mail.

Regards/Xiangsong

----- Original Message ----- 
From: "Xiangsong Cui" <[email-masked]>
To: <[email-masked]>; "Jari Arkko" <[email-masked]>; "Hui Deng" 
<[email-masked]>
Sent: Wednesday, July 01, 2009 1:21 PM
Subject: [netext] A consideration for NETEXT2

> Hello all,
>
> I see a lot of discussion, may we look at the question
> in another way?
>
>
> In my mind, there are four fields exist, as following:
>
>                                 |
> Field A:                    |    Field B:
>                                 |
> Simple IP and           |    Simple IP and
> one interface             |    multiple interfaces
>                                 |
> ------------------------------------------
>                                 |
> Field C:                    |    Field D:
>                                 |   NETLMM IP and    |    NETEXT2 IP and
> one interface             |     multiple interfaces
>                                 |
>
> Field A focuses normal IP topics.
> Field B focuses multiple interface, i.e. MIF.
> Field C focuses network-based mobility, i.e. NETLMM.
> Field D, i.e. NETEXT2 is the focus we are discussing.
>
> If we compare the adjacent fields, we can find:
> A is the baseline;
> B is MIF WG, enhancing the interface management from A;
> C is NETLMM WG, enhancing the mobility from A;
>
> For field D,
> compare to C, NETEXT2 enhances the interface management;
> compare to B, NETEXT2 enhances the mobility management.
> I think for mobile nodes in field B, there is no any
> additional modification need to go into field D.
> This is actually the purpose of NETEXT2.
> Or anybody can tell me the impact?
>
>
> We MUST notice the fact that lots of mobile nodes have already
> had the ability of multi-interface for different radio technology.
> Yes, if you compare D to A, the mobile node must be modified,
> But we can not ignore the mobile nodes in field B.
> NETEXT2 is for the nodes from field B, but not for the nodes from field A.
>
> More and more mobile nodes have evolved to field B.
> I believe we must do something for them, maybe just the mobility 
> enhancement based on network.
>
>
> Regards
>
> Xiangsong
>
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext 

From [email-masked]  Tue Jun 30 22:54:53 2009
Date: Wed, 01 Jul 2009 13:55:03 +0800
From: Xiangsong Cui <[email-masked]>
To: [email-masked], Jari Arkko <[email-masked]>, Hui Deng <[email-masked]>
Subject: [netext]  A consideration for NETEXT2/update

I update the format, sorry for the disturbance.
-------------------

Hello all,

I see a lot of discussion, may we look at the question
in another way?

In my mind, there are four fields exist, as following:

                  |
Field A:          |    Field B:
                  |
Simple IP and     |    Simple IP and
one interface     |    multiple interfaces
                  |
------------------------------------------
                  |
Field C:          |    Field D:
                  |
NETLMM IP and     |    NETEXT2 IP and
one interface     |    multiple interfaces
                  |

Field A focuses normal IP topics.
Field B focuses multiple interface, i.e. MIF.
Field C focuses network-based mobility, i.e. NETLMM.
Field D, i.e. NETEXT2 is the focus we are discussing.

If we compare the adjacent fields, we can find:
A is the baseline;
B is MIF WG, enhancing the interface management from A;
C is NETLMM WG, enhancing the mobility from A;

For field D,
compare to C, NETEXT2 enhances the interface management;
compare to B, NETEXT2 enhances the mobility management.
I think for mobile nodes in field B, there is no any
additional modification need to go into field D.
This is actually the purpose of NETEXT2.
Or anybody can tell me the impact?

We MUST notice the fact that lots of mobile nodes have already
had the ability of multi-interface for different radio 
technology.
Yes, if you compare D to A, the mobile node must be modified,
But we can not ignore the mobile nodes in field B.
NETEXT2 is for the nodes from field B, but not for the nodes from field A.

More and more mobile nodes have evolved to field B.
I believe we must do something for them, maybe just the 
mobility enhancement based on network.

Regards

Xiangsong

From [email-masked]  Tue Jun 30 23:08:03 2009
Date: Wed, 1 Jul 2009 14:08:21 +0800
From: Min Hui <[email-masked]>
To: Frank Xia <[email-masked]>
Cc: [email-masked]
Subject: Re: [netext] Fwd: New Version Notification fordraft-hui-netext-service-flow-identifier-00

Hi, Frank Xia

Thanks for your comments, please see my reply in line.

- Hui Min

2009/7/1 Frank Xia <[email-masked]>:
> Hi Min
>
> I had a quick look at the document which
> looks clear. Some comments are below.
>
> 1)"multiple service flows of the mobile node can
>  be separately controlled based on the service
>  flow identifier in the Proxy Binding Update
>  and Acknowledge messages"
>  I could not find the motivation of separate
>  controlling of a service.  It is for traffic
>  engineering, QoS enforcement or something else?
>

It is used for content charging, QoS enforcement, etc. It is important
for operators to treat services  separately.

> 2)it is also not clear to me how the mobile
>  node notifies the MAG the service type.
>  It seems that the MAG identifies the service
>  through data packets from the mobile node.
>  Deep Packet Inspection technology is required
>  for MAG?

Yes, MAG is required to know the transport layer information. But I
guess the service type you mentioned refer to the "TOS" in the service
flow description. TOS is a field in the IP header, so DPI is not
necessary in this respect.

>
> 3)What is the relationship between this draft
> and flow mobility being discussed in Netext BoF 2?
> They both have key words "flow" :-).
>

We considered this question as well. This draft is about the
granularity of PMIPv6, it is an important part of PMIPv6, although it
is independent of flow mobility. So we are wondering whether the
NETEXT BOF can add the granularity issue into the scope.

>
> BR
> Frank
>
>
> ----- Original Message ----- From: "Min Hui" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, June 29, 2009 10:27 PM
> Subject: [netext] Fwd: New Version Notification
> fordraft-hui-netext-service-flow-identifier-00
>
>
>> Hi, all
>>
>> I have just submitted a new draft:
>>
>> http://www.ietf.org/internet-drafts/draft-hui-netext-service-flow-identi=
fier-00.txt
>>
>> This draft defines a new Service Flow Identifier option carrying the
>> service flow identifier and service flow attributes in the Proxy
>> Binding Update and Acknowledgement message, so that the granularity of
>> PMIPv6 becomes per service flow basis.
>>
>> Any comment is welcomed.
>> Thanks a lot.
>>
>> -Hui Min
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: IETF I-D Submission Tool <[email-masked]>
>> Date: 2009/6/30
>> Subject: New Version Notification for
>> draft-hui-netext-service-flow-identifier-00
>> To: [email-masked]
>> =B3=AD=CB=CD=A3=BA [email-masked], [email-masked]
>>
>>
>>
>> A new version of I-D, draft-hui-netext-service-flow-identifier-00.txt
>> has been successfuly submitted by Min Hui and posted to the IETF
>> repository.
>>
>> Filename:        draft-hui-netext-service-flow-identifier
>> Revision:        00
>> Title:           Service Flow Identifier in Proxy Mobile IPv6
>> Creation_date:   2009-06-29
>> WG ID:           Independent Submission
>> Number_of_pages: 18
>>
>> Abstract:
>> Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
>> mobile node without requiring its participation in any mobility-
>> related signaling. This document introduces extensions to Proxy
>> Mobile IPv6 that allows network dynamically binding each service flow
>> to the mobile node, respectively. Therefore, multiple service flows
>> of the mobile node can be separately controlled based on the service
>> flow identifier in the Proxy Binding Update and Acknowledge messages.
>>
>>
>>
>> The IETF Secretariat.
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>
>