[Netext] PMIPv6 localized routing - IPv4 aspects

[marco.liebsch at nw.neclab.eu (Marco Liebsch)]

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 [e-mail]  Thu Jun 18 12:04:24 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C683A68BD for <[e-mail]>; Thu, 18 Jun 2009 12:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.433
X-Spam-Level: 
X-Spam-Status: No, score=-5.433 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOJoMmwP4Cp0 for <[e-mail]>; Thu, 18 Jun 2009 12:04:24 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E4AA53A69F9 for <[e-mail]>; Thu, 18 Jun 2009 12:04:20 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5IJ4PcG026718 for <[e-mail]>; Thu, 18 Jun 2009 22:04:27 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 18 Jun 2009 22:03:57 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 18 Jun 2009 22:03:52 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 18 Jun 2009 21:03:52 +0200
From: <[e-mail]>
To: <[e-mail]>
Date: Thu, 18 Jun 2009 21:04:01 +0200
Thread-Topic: Test 
Thread-Index: AcnwR4pG+qn2guaI202Vk4CNG/p9ig==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jun 2009 19:03:52.0966 (UTC) FILETIME=[857CC260:01C9F047]
X-Nokia-AV: Clean
Subject: [netext] Test
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 19:04:25 -0000

Pls. ignore


From [e-mail]  Mon Jun 22 15:44:06 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0063A6825 for <[e-mail]>; Mon, 22 Jun 2009 15:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.487
X-Spam-Level: 
X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHaUZMyQhL92 for <[e-mail]>; Mon, 22 Jun 2009 15:44:06 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0C30D3A68BB for <[e-mail]>; Mon, 22 Jun 2009 15:44:05 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5MMhZQq007969 for <[e-mail]>; Mon, 22 Jun 2009 17:44:23 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Jun 2009 01:44:13 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Jun 2009 01:44:12 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 23 Jun 2009 00:44:12 +0200
From: <[e-mail]>
To: <[e-mail]>
Date: Tue, 23 Jun 2009 00:44:22 +0200
Thread-Topic: Solicitations for agenda items
Thread-Index: AcnzivxC61+jN2dLQUmPraRThFoneQ==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 22 Jun 2009 22:44:12.0807 (UTC) FILETIME=[F6C76970:01C9F38A]
X-Nokia-AV: Clean
Subject: [netext] Solicitations for agenda items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2009 22:44:06 -0000

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 [e-mail]  Mon Jun 22 15:47:06 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83ABE28C258 for <[e-mail]>; Mon, 22 Jun 2009 15:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.493
X-Spam-Level: 
X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9UbQGHPHD16 for <[e-mail]>; Mon, 22 Jun 2009 15:47:05 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 67ED028C1A0 for <[e-mail]>; Mon, 22 Jun 2009 15:47:04 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5MMl6O7015631 for <[e-mail]>; Tue, 23 Jun 2009 01:47:10 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Jun 2009 01:47:10 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Jun 2009 01:47:05 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 23 Jun 2009 00:47:05 +0200
From: <[e-mail]>
To: <[e-mail]>
Date: Tue, 23 Jun 2009 00:47:15 +0200
Thread-Topic: Netext meetings at IETF75
Thread-Index: Acnzi2NfGPcsobYhEUCO2zFodQv0KA==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 22 Jun 2009 22:47:06.0029 (UTC) FILETIME=[5E06FDD0:01C9F38B]
X-Nokia-AV: Clean
Subject: [netext] Netext meetings at IETF75
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2009 22:47:06 -0000

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 [e-mail]  Mon Jun 22 23:44:59 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068B43A68B3 for <[e-mail]>; Mon, 22 Jun 2009 23:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV1I3dZjfxnf for <[e-mail]>; Mon, 22 Jun 2009 23:44:58 -0700 (PDT)
Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by core3.amsl.com (Postfix) with ESMTP id 05ACA3A68A5 for <[e-mail]>; Mon, 22 Jun 2009 23:44:57 -0700 (PDT)
Received: by fxm24 with SMTP id 24so1286005fxm.37 for <[e-mail]>; Mon, 22 Jun 2009 23:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=EYhQbmXDVj+1qtqhiT5t8q+iZZAInwYyD1zFBZFsKe4=; b=hKJbuivkfs7YKqz+m0y3aUJ72MJHvaARF86BzRxb78l1wq1x43RHito/hVrEja7RBK yhL6xYlx1zjfnyVoZr2rNsLsCYlQna4GMkUHFZWM+O8MrPY/zvqZre1xBfvOigkqnzEw taw7Y5V1ySZnt8TTZYvXuo520gSRyEJPRgDXI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Fn1oyZXsOz94RsTnUkjz+p+lm5ir9NpXxt1H5cstgLsOszEM9dYf10fY9Bp6vmFKXR zHvPIc7xhfR/qLt+hoyNP+zHmzD3ZAj8TfxPLgT3LelYo2OQyX7K0UAVAO+3EOCdRvCT 2xTGPwkZOMI0Yu+uZ+Drw4TIJ77RpGLIFKPIw=
Received: by 10.103.215.15 with SMTP id s15mr2686688muq.118.1245739510824; Mon, 22 Jun 2009 23:45:10 -0700 (PDT)
Received: from a88-114-64-243.elisa-laajakaista.fi (a88-114-64-243.elisa-laajakaista.fi [88.114.64.243]) by mx.google.com with ESMTPS id 23sm22161168mun.46.2009.06.22.23.45.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 23:45:10 -0700 (PDT)
Message-Id: <[e-mail]>
From: jouni korhonen <[e-mail]>
To: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 23 Jun 2009 09:45:09 +0300
References: <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
Cc: [e-mail]
Subject: Re: [netext] Solicitations for agenda items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 06:44:59 -0000

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, <[e-mail]> <[e-mail] 
 > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext


From [e-mail]  Mon Jun 22 23:54:06 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053963A6822 for <[e-mail]>; Mon, 22 Jun 2009 23:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level: 
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pQx90hDipaO for <[e-mail]>; Mon, 22 Jun 2009 23:54:05 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0B2443A6B5F for <[e-mail]>; Mon, 22 Jun 2009 23:53:41 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 23 Jun 2009 14:53:46 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 23 Jun 2009 14:53:46 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 23 Jun 2009 14:53:45 +0800 (CST)
Date: Tue, 23 Jun 2009 14:53:45 +0800
From: Qin Wu <[e-mail]>
To: [e-mail]
Message-id: <03dc01c9f3cf$5a989a20$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Cc: [e-mail]
Subject: Re: [netext] I-D Action:draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 06:54:06 -0000

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: <[e-mail]>
To: <[e-mail]>
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
> [e-mail]
> 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 [e-mail]  Tue Jun 23 08:50:05 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFFE28C34B for <[e-mail]>; Tue, 23 Jun 2009 08:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.751
X-Spam-Level: 
X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpH4z0rj14jV for <[e-mail]>; Tue, 23 Jun 2009 08:50:04 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 93FC628C333 for <[e-mail]>; Tue, 23 Jun 2009 08:50:04 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 23 Jun 2009 23:50:10 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 23 Jun 2009 23:50:10 +0800 (CST)
Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 23 Jun 2009 23:50:10 +0800 (CST)
Date: Tue, 23 Jun 2009 10:50:07 -0500
From: Frank Xia <[e-mail]>
To: [e-mail], [e-mail]
Message-id: <007d01c9f41a$4985ead0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Subject: Re: [netext] Solicitations for agenda items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 15:50:05 -0000

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: <[e-mail]>
To: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext

From [e-mail]  Tue Jun 23 08:54:45 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5AE28C387 for <[e-mail]>; Tue, 23 Jun 2009 08:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCsuhiCp-3Wn for <[e-mail]>; Tue, 23 Jun 2009 08:54:44 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4EF7728C36B for <[e-mail]>; Tue, 23 Jun 2009 08:54:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,276,1243814400"; d="scan'208";a="172254549"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2009 15:55:00 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5NFt0ev018146;  Tue, 23 Jun 2009 08:55:00 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n5NFt0ll016731; Tue, 23 Jun 2009 15:55:00 GMT
Date: Tue, 23 Jun 2009 08:55:00 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=865; t=1245772500; x=1246636500; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20Solicitations=20for=20agenda =20items |Sender:=20; bh=gyStkdKOOitv6BjQiU6k/3YA/ZJSPM3i7mGrbnuEBNs=; b=Gc9xmlRdulGKfkREtNOydTlZKB0Ml2JEDzYRn21Ygq+OUE+ioxRUCZQjDs 1vgqP50EQqnYkJuE4WncDPrXDQLAM7LnwdZpt/cAKxLW01qc54HH/yB/NIHS lFfJ6VfzDP;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: [e-mail]
Subject: Re: [netext] Solicitations for agenda items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 15:54:45 -0000

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>

From [e-mail]  Wed Jun 24 20:16:15 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531783A6F1F for <[e-mail]>; Wed, 24 Jun 2009 20:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8LRbgYpGQ5p for <[e-mail]>; Wed, 24 Jun 2009 20:16:14 -0700 (PDT)
Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id 650213A67DA for <[e-mail]>; Wed, 24 Jun 2009 20:16:14 -0700 (PDT)
Received: from [68.142.237.90] by n7.bullet.re3.yahoo.com with NNFMP; 25 Jun 2009 03:15:39 -0000
Received: from [67.195.9.82] by t6.bullet.re3.yahoo.com with NNFMP; 25 Jun 2009 03:15:39 -0000
Received: from [67.195.9.108] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jun 2009 03:15:39 -0000
Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 25 Jun 2009 03:15:39 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: [e-mail]
Received: (qmail 3878 invoked by uid 60001); 25 Jun 2009 03:15:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245899738; bh=J2G8dPAchR8P2Ca4BM7rHycE/8qVFgK0IVXwzzERimY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fz8Z7zxvw0hTkiLKmT+GGeLWrmXQ2IdWah+oTqpKvnvfX6EnswZpskFtFTtycmxUybPcvgWVLNzD7GSHpaYbJTxifcJVVaIdg25HPSIolsy59ytFgU24zSn/BFNueUv62alUwzQtSsqHQeU4HvSWJmDHxbAGogE377B7oe7FOpw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6lNwh1+sWtxQp2o0p7renUIXKnxfDrodZ0cZwJJ9wnkTKg1w3oWLZkvduvcdAjdFJne14tsD1EmrqOBKpjI4f6aY61APMtGw/9o3kp6vOB5pyI5BRaWR5EKijJ/UEGi4Mad5Crfz76r4hsy6oQgDk/BYrCmdUajfjvk6Z2jVRS8=;
Message-ID: <[e-mail]>
X-YMail-OSG: bH91oUEVM1ksAdIn2dq_ZLUuPGWhMERwPrnwYfnMMNqRunXjftLOyoHuwXWoNk2DPGr98XepZZXV0hUlvv0bErIiI95lMRIQu3D5lTLeLmeZcgPeOMJzPg54oRgVAJf2w2Ys9ydpFjJrT0X_YUTMJyX9tBEv0bVrcosJ3NxvSX0fmpcRMumO9DEFUqjk.xr_eFhc.D53rMfads0FX_lug85I6JATvja_nbh_lTpNLUkR1avvRGkRI7Hl3m8VXwFAA5P19y6mcxocwEclTPaAU9Ab5HU0oTVu0Q8hLKwE8THA6yAeeQpEES0Dd4g8oBVD9aqTjXIhJPi5J70wOo25mr59
Received: from [71.170.139.250] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 24 Jun 2009 20:15:38 PDT
X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15
References: <[e-mail]>
Date: Wed, 24 Jun 2009 20:15:38 -0700 (PDT)
From: Behcet Sarikaya <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netext] Solicitations for agenda items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Behcet Sarikaya <[e-mail]>
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 03:16:15 -0000

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: "[e-mail]" <[e-mail]>
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext



      


From [e-mail]  Thu Jun 25 01:41:29 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE93F3A6896 for <[e-mail]>; Thu, 25 Jun 2009 01:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.148
X-Spam-Level: 
X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.451,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8oL6CSKmoRr for <[e-mail]>; Thu, 25 Jun 2009 01:41:28 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B58453A6856 for <[e-mail]>; Thu, 25 Jun 2009 01:41:28 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5P8eYc15084; Thu, 25 Jun 2009 08:40:34 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Jun 2009 03:35:57 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netext] Solicitations for agenda items
thread-index: AcnzivxC61+jN2dLQUmPraRThFoneQB5LgUg
References: <[e-mail]>
From: "Ahmad Muhanna" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: [netext] Solicitations for agenda items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 08:41:29 -0000

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: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of=20
> [e-mail]
> Sent: Monday, June 22, 2009 5:44 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>=20

From [e-mail]  Thu Jun 25 01:41:45 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966783A6896 for <[e-mail]>; Thu, 25 Jun 2009 01:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.193
X-Spam-Level: 
X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.406,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57lR-OfkW9R4 for <[e-mail]>; Thu, 25 Jun 2009 01:41:44 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 89B093A6856 for <[e-mail]>; Thu, 25 Jun 2009 01:41:44 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5P8eWc15073; Thu, 25 Jun 2009 08:40:32 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9F56F.9BA1F180"
Date: Thu, 25 Jun 2009 03:33:25 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-muhanna-netext-mobility-session-suspend-00.txt 
thread-index: Acn1b0VrZNaCcc0tRBCJfGjqKASyrAAAA6WA
From: "Ahmad Muhanna" <[e-mail]>
To: <[e-mail]>
Subject: [netext] FW: I-D Action:draft-muhanna-netext-mobility-session-suspend-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 08:41:45 -0000

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: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Thursday, June 25, 2009 3:30 AM
To: [e-mail]
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 [e-mail]  Fri Jun 26 09:04:11 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD583A6A6D for <[e-mail]>; Fri, 26 Jun 2009 09:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.296
X-Spam-Level: 
X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.304,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BMXLW-Gw766 for <[e-mail]>; Fri, 26 Jun 2009 09:04:10 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6B6B73A6B38 for <[e-mail]>; Fri, 26 Jun 2009 09:03:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,297,1243814400"; d="scan'208";a="48613906"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2009 16:04:00 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5QG40wa001585;  Fri, 26 Jun 2009 12:04:00 -0400
Received: from [161.44.65.104] ([161.44.65.104]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5QG40WA014091; Fri, 26 Jun 2009 16:04:00 GMT
Message-Id: <[e-mail]>
From: Ralph Droms <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Fri, 26 Jun 2009 12:04:00 -0400
X-Mailer: Apple Mail (2.935.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=401; t=1246032240; x=1246896240; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Ralph=20Droms=20<[e-mail]> |Subject:=20netext2=20BOF=20at=20IETF=2075 |Sender:=20 |To:=[e-mail]; bh=yaZKvo8vczfOTIwNA5qF1q6LclIiRmwJeN+z8+izdPY=; b=TowrN1dmarn5ZsKRBdQQHNHMagZ+6gdkr2g4t7+/yWXKycjvi/38xa8caP SYRDUWYgpp+zvyi4tplZXQ92UxZkxYbtxAuSOqnOdSxXENEx4GOOg1eV0C2P wnfCHtWlOp;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
X-Mailman-Approved-At: Fri, 26 Jun 2009 09:08:24 -0700
Cc: "Jonne \(NSN - FI/Espoo\) Soininen" <[e-mail]>
Subject: [netext] netext2 BOF at IETF 75
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 16:04:11 -0000

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 [e-mail]  Fri Jun 26 09:20:56 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032983A6B92 for <[e-mail]>; Fri, 26 Jun 2009 09:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.508
X-Spam-Level: 
X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FytygkkQE0z for <[e-mail]>; Fri, 26 Jun 2009 09:20:55 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CE5F13A6BBB for <[e-mail]>; Fri, 26 Jun 2009 09:20:54 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5QGL1Rs024463 for <[e-mail]>; Fri, 26 Jun 2009 19:21:05 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 26 Jun 2009 19:20:50 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 26 Jun 2009 19:20:46 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 26 Jun 2009 18:20:45 +0200
From: <[e-mail]>
To: <[e-mail]>
Date: Fri, 26 Jun 2009 18:20:55 +0200
Thread-Topic: WG view about problem statement I-D for localized routing
Thread-Index: Acn2ehSrDjbmuUyz+0yfhOUVKpOSpw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jun 2009 16:20:46.0385 (UTC) FILETIME=[0F890210:01C9F67A]
X-Nokia-AV: Clean
Subject: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 16:20:56 -0000

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 [e-mail]  Fri Jun 26 09:31:54 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F0F3A6922 for <[e-mail]>; Fri, 26 Jun 2009 09:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rgsQ9m0rcHV for <[e-mail]>; Fri, 26 Jun 2009 09:31:53 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E05C03A67A6 for <[e-mail]>; Fri, 26 Jun 2009 09:31:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,297,1243814400"; d="scan'208";a="332496050"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2009 16:32:03 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5QGW33v016457;  Fri, 26 Jun 2009 09:32:03 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5QGW3mR017702; Fri, 26 Jun 2009 16:32:03 GMT
Date: Fri, 26 Jun 2009 09:32:02 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1597; t=1246033923; x=1246897923; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20WG=20view=20about=20problem= 20statement=20I-D=20for=20localized=0A=20routing |Sender:=20; bh=jY/lYxQJ5IeYAfFcZXQ58f3tnsSdQ7oel/85G+hLpps=; b=VEExqAWa+DIC/QFovpsoBG0xkpgS8E8wD8nvr4lAjVv6J1hF+hovXcLpbj MO35IuiXJI+EiTlefEE035jgKH3+JjaCStawppIaamTQIcGPdgqLOOskQvb/ cHjJw/hNyn;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 16:31:54 -0000

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>

From [e-mail]  Fri Jun 26 11:32:42 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10AF3A67C0 for <[e-mail]>; Fri, 26 Jun 2009 11:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.532
X-Spam-Level: 
X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vSysu0DZXDn for <[e-mail]>; Fri, 26 Jun 2009 11:32:42 -0700 (PDT)
Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id D74C33A67AA for <[e-mail]>; Fri, 26 Jun 2009 11:32:41 -0700 (PDT)
Received: from 12.204.153.98 ([12.204.153.98]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jun 2009 18:31:48 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Fri, 26 Jun 2009 11:31:48 -0700
From: Vijay Devarapalli <[e-mail]>
To: Sri Gundavelli <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [netext] WG view about problem statement I-D for localized routing
Thread-Index: Acn2jF1sysjxY/EUs0+nHRIDolrsaw==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 18:32:42 -0000

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, [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext


From [e-mail]  Fri Jun 26 11:45:03 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CFE03A67C0 for <[e-mail]>; Fri, 26 Jun 2009 11:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEtxa-uci1ft for <[e-mail]>; Fri, 26 Jun 2009 11:45:02 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 402733A67AA for <[e-mail]>; Fri, 26 Jun 2009 11:45:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,297,1243814400"; d="scan'208";a="206265827"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2009 18:44:00 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5QIi0Dq000469;  Fri, 26 Jun 2009 11:44:00 -0700
Received: from sgundave-sb100.cisco.com (sgundave-sb100.cisco.com [128.107.163.1]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5QIi0eF007306; Fri, 26 Jun 2009 18:44:00 GMT
Date: Fri, 26 Jun 2009 11:44:00 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: Vijay Devarapalli <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1630; t=1246041840; x=1246905840; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20WG=20view=20about=20problem= 20statement=20I-D=20for=20localized=0A=20routing |Sender:=20; bh=DdN1A5b8PyU+nxCaLLaMdj6hpBHSxRney4qJgMTbcY0=; b=jzc65eVcSCrp+MG4en/e1The0Q2SPox4dWsALTFwMBvkqypH8lL/9Be9Kh QsdAaUJ5QDY3yK8u3H9iwNeJAzqSk3dzeLw5bHnT1wwo8OQxX74TNgMPWrYh lc3xE6WTcP;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: [e-mail], [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 18:45:03 -0000

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 [e-mail]  Fri Jun 26 12:49:44 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2F13A696C for <[e-mail]>; Fri, 26 Jun 2009 12:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.512
X-Spam-Level: 
X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGiafTOeu+My for <[e-mail]>; Fri, 26 Jun 2009 12:49:43 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2EF2B3A6BC8 for <[e-mail]>; Fri, 26 Jun 2009 12:49:42 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5QJnQPS030645; Fri, 26 Jun 2009 22:49:48 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 26 Jun 2009 22:49:50 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 26 Jun 2009 22:49:46 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 26 Jun 2009 21:49:46 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Date: Fri, 26 Jun 2009 21:49:54 +0200
Thread-Topic: [netext] WG view about problem statement I-D for localized routing
Thread-Index: Acn2jhfQacJSXMuxR9WNdQH+3UjFZAACS6tS
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Jun 2009 19:49:46.0167 (UTC) FILETIME=[41D3E470:01C9F697]
X-Nokia-AV: Clean
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 19:49:44 -0000

Hi Sri/Vijay,


On 6/26/09 1:44 PM, "Sri Gundavelli" <[e-mail]> 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 [e-mail]  Fri Jun 26 13:04:57 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6A63A6BA7 for <[e-mail]>; Fri, 26 Jun 2009 13:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTyKnAbzdG7O for <[e-mail]>; Fri, 26 Jun 2009 13:04:56 -0700 (PDT)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 781283A6B07 for <[e-mail]>; Fri, 26 Jun 2009 13:04:56 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3079C90160 for <[e-mail]>; Fri, 26 Jun 2009 16:05:11 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28295-09 for <[e-mail]>; Fri, 26 Jun 2009 16:05:09 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for <[e-mail]>; Fri, 26 Jun 2009 16:05:09 -0400 (EDT)
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 16:05:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Jun 2009 16:03:43 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netext] WG view about problem statement I-D for localizedrouting
Thread-Index: Acn2jhfQacJSXMuxR9WNdQH+3UjFZAACS6tSAAB7o6M=
References: <[e-mail]>
From: "Koodli, Rajeev" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Jun 2009 20:05:09.0227 (UTC) FILETIME=[6803ABB0:01C9F699]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 20:04:57 -0000

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
[e-mail]
https://www.ietf.org/mailman/listinfo/netext


From [e-mail]  Fri Jun 26 13:37:35 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27E83A6C40 for <[e-mail]>; Fri, 26 Jun 2009 13:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.532
X-Spam-Level: 
X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnGGvPVrj5XM for <[e-mail]>; Fri, 26 Jun 2009 13:37:34 -0700 (PDT)
Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B117B3A6861 for <[e-mail]>; Fri, 26 Jun 2009 13:37:34 -0700 (PDT)
Received: from 12.204.153.98 ([12.204.153.98]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Jun 2009 20:36:24 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Fri, 26 Jun 2009 13:36:23 -0700
From: Vijay Devarapalli <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [netext] WG view about problem statement I-D for localized routing
Thread-Index: Acn2jhfQacJSXMuxR9WNdQH+3UjFZAACS6tSAAGfmPY=
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 20:37:35 -0000

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, "[e-mail]" wrote:

> 
> Hi Sri/Vijay,
> 
> 
> On 6/26/09 1:44 PM, "Sri Gundavelli" <[e-mail]> 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 [e-mail]  Fri Jun 26 14:22:12 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94C63A6C6D for <[e-mail]>; Fri, 26 Jun 2009 14:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTqUhSCrmGkd for <[e-mail]>; Fri, 26 Jun 2009 14:22:12 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0482A3A6BB3 for <[e-mail]>; Fri, 26 Jun 2009 14:22:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,298,1243814400"; d="scan'208";a="173309470"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2009 21:22:30 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5QLMUIO008126;  Fri, 26 Jun 2009 14:22:30 -0700
Received: from sgundave-sb100.cisco.com (sgundave-sb100.cisco.com [128.107.163.1]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5QLMUAS020554; Fri, 26 Jun 2009 21:22:30 GMT
Date: Fri, 26 Jun 2009 14:22:30 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=889; t=1246051350; x=1246915350; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20WG=20view=20about=20problem= 20statement=20I-D=20for=20localized=0A=20routing |Sender:=20; bh=2m8ordC0kk2VvS6sxAK+YVCqXHbH8+2YJXAdcjHLIkU=; b=Sz+5qAzt1viUmF05ZfiSy+vrs9c0Y/LRkRFVLIEyR1vVPaXbwSTAOyDUHc D9VabrDVcW9HL9mt5NCWBM+HAoIOGDPhgAYigRROSX0eEp3PvKsugjRhjFOS s3wgXx0TXK;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 21:22:13 -0000

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 [e-mail]  Fri Jun 26 18:31:40 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6253A6BC8 for <[e-mail]>; Fri, 26 Jun 2009 18:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Level: 
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP-tuleZDj0h for <[e-mail]>; Fri, 26 Jun 2009 18:31:39 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B5C2128C135 for <[e-mail]>; Fri, 26 Jun 2009 18:31:39 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 09:31:46 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 09:31:45 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 09:31:45 +0800 (CST)
Date: Sat, 27 Jun 2009 09:31:45 +0800
From: Qin Wu <[e-mail]>
To: Vijay Devarapalli <[e-mail]>, Sri Gundavelli <[e-mail]>, [e-mail]
Message-id: <01c501c9f6c7$08580200$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 01:31:40 -0000

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" <[e-mail]>
To: "Sri Gundavelli" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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, [e-mail] 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netext
>>> 
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext

From [e-mail]  Fri Jun 26 18:39:32 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09ED3A6C79 for <[e-mail]>; Fri, 26 Jun 2009 18:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.52
X-Spam-Level: 
X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=1.079,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kCumo-mklkL for <[e-mail]>; Fri, 26 Jun 2009 18:39:31 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C1B433A6C6E for <[e-mail]>; Fri, 26 Jun 2009 18:39:31 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 09:39:49 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 09:39:49 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 09:39:49 +0800 (CST)
Date: Sat, 27 Jun 2009 09:39:48 +0800
From: Qin Wu <[e-mail]>
To: "Koodli, Rajeev" <[e-mail]>, [e-mail],  [e-mail], [e-mail]
Message-id: <01d301c9f6c8$286b1bd0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 01:39:32 -0000

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext

From [e-mail]  Fri Jun 26 19:33:49 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE9C28C1E1 for <[e-mail]>; Fri, 26 Jun 2009 19:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.516
X-Spam-Level: 
X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwTqgSkgK0z3 for <[e-mail]>; Fri, 26 Jun 2009 19:33:49 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 50FBD28C1E4 for <[e-mail]>; Fri, 26 Jun 2009 19:33:47 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 10:33:55 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 10:33:55 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 10:33:55 +0800 (CST)
Date: Sat, 27 Jun 2009 10:33:54 +0800
From: Qin Wu <[e-mail]>
To: [e-mail], [e-mail]
Message-id: <024c01c9f6cf$b74bc870$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 02:33:50 -0000

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: <[e-mail]>
To: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext

From [e-mail]  Sat Jun 27 01:44:55 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157663A6848 for <[e-mail]>; Sat, 27 Jun 2009 01:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.14
X-Spam-Level: *
X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[AWL=2.656, BAYES_00=-2.599, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BDX-byxQHao for <[e-mail]>; Sat, 27 Jun 2009 01:44:54 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E22413A6820 for <[e-mail]>; Sat, 27 Jun 2009 01:44:53 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 16:45:09 +0800 (CST)
Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 27 Jun 2009 16:45:09 +0800 (CST)
Date: Sat, 27 Jun 2009 16:45:08 +0800
From: Xiangsong Cui <[e-mail]>
To: Sri Gundavelli <[e-mail]>, [e-mail]
Message-id: <00df01c9f703$936ce680$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Cc: [e-mail]
Subject: Re: [netext] Solicitations for agenda items
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 08:44:55 -0000

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" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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, [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>>
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext 


From [e-mail]  Sat Jun 27 09:10:16 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E2C3A6C64 for <[e-mail]>; Sat, 27 Jun 2009 09:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.058
X-Spam-Level: 
X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57VgM7P-cLQj for <[e-mail]>; Sat, 27 Jun 2009 09:10:16 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A4DD13A6C37 for <[e-mail]>; Sat, 27 Jun 2009 09:10:15 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9855B2C019196; Sat, 27 Jun 2009 18:10:33 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlxlfxhQcf1H; Sat, 27 Jun 2009 18:10:33 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 6514D2C0004E5; Sat, 27 Jun 2009 18:10:13 +0200 (CEST)
Received: from [127.0.0.1] ([10.7.0.140]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 18:10:13 +0200
Message-ID: <[e-mail]>
Date: Sat, 27 Jun 2009 18:10:11 +0200
From: Marco Liebsch <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Sri Gundavelli <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jun 2009 16:10:13.0523 (UTC) FILETIME=[C0BBAE30:01C9F741]
Cc: [e-mail], [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 16:10:16 -0000

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext



From [e-mail]  Sun Jun 28 11:15:57 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7437E3A6AFD; Sun, 28 Jun 2009 11:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.557
X-Spam-Level: 
X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIq-Ko-W6xQy; Sun, 28 Jun 2009 11:15:56 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B50903A6AF1; Sun, 28 Jun 2009 11:15:54 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (133.pool85-53-136.dynamic.orange.es [85.53.136.133]) by smtp03.uc3m.es (Postfix) with ESMTP id 046A3731E0F; Sun, 28 Jun 2009 20:16:11 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 28 Jun 2009 20:16:11 +0200
From: marcelo bagnulo braun <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [e-mail], mext <[e-mail]>, [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16732.001
Cc: "Soininen Jonne \(NSN FI/Espoo\)" <[e-mail]>, [e-mail], Ralph Droms <[e-mail]>
Subject: [netext] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2009 18:15:57 -0000

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 [e-mail]  Sun Jun 28 18:26:43 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051E73A68F1; Sun, 28 Jun 2009 18:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.219
X-Spam-Level: 
X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=2.818,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwz73NNqfJHy; Sun, 28 Jun 2009 18:26:41 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B2D1F3A68C9; Sun, 28 Jun 2009 18:26:41 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Mon, 29 Jun 2009 09:27:00 +0800 (CST)
Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Mon, 29 Jun 2009 09:26:59 +0800 (CST)
Date: Mon, 29 Jun 2009 09:27:01 +0800
From: Xiangsong Cui <[e-mail]>
To: marcelo bagnulo braun <[e-mail]>, [e-mail], mext <[e-mail]>, [e-mail]
Message-id: <004101c9f858$b3f68d60$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Cc: "Soininen Jonne \(NSN FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [netext] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 01:26:43 -0000

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" <[e-mail]>
To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
Cc: "Soininen Jonne (NSN FI/Espoo)" <[e-mail]>; "Jari Arkko" 
<[e-mail]>; <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext 


From [e-mail]  Sun Jun 28 23:41:53 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB213A67E5; Sun, 28 Jun 2009 23:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.558
X-Spam-Level: 
X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm6lD+VGckcv; Sun, 28 Jun 2009 23:41:52 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B582C3A6AC6; Sun, 28 Jun 2009 23:41:50 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (133.pool85-53-136.dynamic.orange.es [85.53.136.133]) by smtp03.uc3m.es (Postfix) with ESMTP id D133872D159; Mon, 29 Jun 2009 08:42:07 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 29 Jun 2009 08:42:07 +0200
From: marcelo bagnulo braun <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Xiangsong Cui <[e-mail]>
References: <[e-mail]> <004101c9f858$b3f68d60$[e-mail]>
In-Reply-To: <004101c9f858$b3f68d60$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16732.004
Cc: [e-mail], mext <[e-mail]>, [e-mail], "Soininen Jonne \(NSN FI/Espoo\)" <[e-mail]>, [e-mail]
Subject: Re: [netext] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 06:41:53 -0000

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" 
> <[e-mail]>
> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> Cc: "Soininen Jonne (NSN FI/Espoo)" <[e-mail]>; "Jari 
> Arkko" <[e-mail]>; <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext 
>
>


From [e-mail]  Mon Jun 29 09:17:15 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228C03A6DCB; Mon, 29 Jun 2009 09:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.439
X-Spam-Level: 
X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=0.560,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nidyxTUlZZoo; Mon, 29 Jun 2009 09:17:14 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 046C03A6A32; Mon, 29 Jun 2009 09:17:14 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 00:16:46 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 00:16:45 +0800 (CST)
Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Tue, 30 Jun 2009 00:16:45 +0800 (CST)
Date: Mon, 29 Jun 2009 11:16:42 -0500
From: Frank Xia <[e-mail]>
To: marcelo bagnulo braun <[e-mail]>, [e-mail], mext <[e-mail]>, [e-mail]
Message-id: <000e01c9f8d4$ff2bde30$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Cc: [e-mail], Ralph Droms <[e-mail]>
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 16:17:15 -0000

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" <[e-mail]>
To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm 


From [e-mail]  Mon Jun 29 09:47:51 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E20D3A6BBB; Mon, 29 Jun 2009 09:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level: 
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc2tQnysNpxA; Mon, 29 Jun 2009 09:47:50 -0700 (PDT)
Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 5EC2A3A6A67; Mon, 29 Jun 2009 09:47:49 -0700 (PDT)
Received: by mail-bw0-f213.google.com with SMTP id 9so3380511bwz.37 for <multiple recipients>; Mon, 29 Jun 2009 09:48:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=okonUw1/I2LIPWZjhQ2wq8NBRhqVgVxIemJxOj31zhM=; b=t5FXC4doWK5MOz/pljMQGrsPSzMWaLbRAxjKYZJOd9A+iFcqZK+3hpDFRFaJ4R1mjC Z0K7iAxHZgfhKVx+69/HqehMhVBsAAW7YHG/ktihE4sBL0RLggD+krxTnw8dAWGzgi+W Ja6bb8dGc7Hp2V6VLzZ5IBS2gvq3KRD5Nk1uI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SBaXoPBNdsynYKvyjHyTDp9EvO1xV0HnxRvA/yngh2Mq5aMn3cCqUdPsEpX0GedGy9 PLUIYCp/CPWbdaB784Aq54aBFRePH89Is+0/tHJTBovfFVBlWIDp+h15aRiij+a3O0Eu xgQJJb+pUnUVtIQ/j8WqxCp+5NHFSfxMFgXIQ=
MIME-Version: 1.0
Received: by 10.223.107.199 with SMTP id c7mr4590961fap.31.1246294089723; Mon,  29 Jun 2009 09:48:09 -0700 (PDT)
In-Reply-To: <000e01c9f8d4$ff2bde30$[e-mail]>
References: <[e-mail]> <000e01c9f8d4$ff2bde30$[e-mail]>
Date: Mon, 29 Jun 2009 17:48:09 +0100
Message-ID: <[e-mail]>
From: George Tsirtsis <[e-mail]>
To: Frank Xia <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail], [e-mail], [e-mail], mext <[e-mail]>
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 16:47:51 -0000

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<[e-mail]> 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"
> <[e-mail]>
> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>

From [e-mail]  Mon Jun 29 09:50:09 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE2928C2A7; Mon, 29 Jun 2009 09:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.219
X-Spam-Level: 
X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpZ7uUXyjodd; Mon, 29 Jun 2009 09:50:06 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F00733A6B61; Mon, 29 Jun 2009 09:50:05 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5TGlQBn013309; Mon, 29 Jun 2009 11:50:04 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 29 Jun 2009 19:49:59 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 29 Jun 2009 19:49:55 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 29 Jun 2009 18:49:54 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Date: Mon, 29 Jun 2009 18:50:02 +0200
Thread-Topic: [netlmm] NEXTEXT2: first draft of the bof description
Thread-Index: Acn41RA+6tliGzrvT+KNALbUqm+P/gABJT0/
Message-ID: <[e-mail]>
In-Reply-To: <000e01c9f8d4$ff2bde30$[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Jun 2009 16:49:55.0066 (UTC) FILETIME=[A111CDA0:01C9F8D9]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 16:50:09 -0000

Frank,


On 6/29/09 11:16 AM, "ext Frank Xia" <[e-mail]> 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" <[e-mail]>
> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>=20


From [e-mail]  Mon Jun 29 10:19:55 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BBF28C2C6; Mon, 29 Jun 2009 10:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.417
X-Spam-Level: 
X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3xSvcbPVZY0; Mon, 29 Jun 2009 10:19:54 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id D270328C2B6; Mon, 29 Jun 2009 10:19:53 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 01:20:03 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 01:20:03 +0800 (CST)
Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Tue, 30 Jun 2009 01:20:03 +0800 (CST)
Date: Mon, 29 Jun 2009 12:20:00 -0500
From: Frank Xia <[e-mail]>
To: George Tsirtsis <[e-mail]>
Message-id: <001401c9f8dd$d6c16830$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=utf-8; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <000e01c9f8d4$ff2bde30$[e-mail]> <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], mext <[e-mail]>
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 17:19:55 -0000

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" <[e-mail]>
To: "Frank Xia" <[e-mail]>
Cc: "marcelo bagnulo braun" <[e-mail]>; <[e-mail]>; "mext" 
<[e-mail]>; <[e-mail]>; <[e-mail]>
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<[e-mail]> 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"
> <[e-mail]>
> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
> 


From [e-mail]  Mon Jun 29 11:03:38 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785BF3A693F; Mon, 29 Jun 2009 11:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyCcT5Eqbxmq; Mon, 29 Jun 2009 11:03:37 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 0B9CA3A6B6A; Mon, 29 Jun 2009 11:03:36 -0700 (PDT)
Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5TI3VoG030199;  Mon, 29 Jun 2009 20:03:39 +0200
Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 20:03:33 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 29 Jun 2009 20:03:31 +0200
Message-ID: <[e-mail]>
In-Reply-To: <001401c9f8dd$d6c16830$[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netlmm] [MEXT]  NEXTEXT2: first draft of the bof description
Thread-Index: Acn43e6XWrsspNs7SrmbP2Hrq1aAdgABX97Q
References: <[e-mail]><000e01c9f8d4$ff2bde30$[e-mail]><[e-mail]> <001401c9f8dd$d6c16830$[e-mail]>
From: "MELIA TELEMACO" <[e-mail]>
To: "Frank Xia" <[e-mail]>, "George Tsirtsis" <[e-mail]>
X-OriginalArrivalTime: 29 Jun 2009 18:03:33.0192 (UTC) FILETIME=[EA7A5480:01C9F8E3]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80
Cc: [e-mail], [e-mail], [e-mail], mext <[e-mail]>
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 18:03:38 -0000

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: [e-mail] [mailto:[e-mail]] De la =
part de Frank Xia
Envoy=E9=A0: lundi 29 juin 2009 19:20
=C0=A0: George Tsirtsis
Cc=A0: [e-mail]; [e-mail]; [e-mail]; =
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" <[e-mail]>
To: "Frank Xia" <[e-mail]>
Cc: "marcelo bagnulo braun" <[e-mail]>; <[e-mail]>; =
"mext"=20
<[e-mail]>; <[e-mail]>; <[e-mail]>
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<[e-mail]> =
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"
> <[e-mail]>
> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>=20

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

From [e-mail]  Mon Jun 29 12:56:48 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FB33A6BCC; Mon, 29 Jun 2009 12:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.442
X-Spam-Level: 
X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.556,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTU8NvVu9i-U; Mon, 29 Jun 2009 12:56:47 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CFE253A6B00; Mon, 29 Jun 2009 12:56:46 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 03:57:04 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 03:57:04 +0800 (CST)
Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Tue, 30 Jun 2009 03:57:04 +0800 (CST)
Date: Mon, 29 Jun 2009 14:57:00 -0500
From: Frank Xia <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <002701c9f8f3$c6007570$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 19:56:48 -0000

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: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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" <[e-mail]> 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" <[e-mail]>
> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>


From [e-mail]  Mon Jun 29 13:22:21 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2234228C2E6; Mon, 29 Jun 2009 13:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.47
X-Spam-Level: 
X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.528,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enl4jeFDq+XG; Mon, 29 Jun 2009 13:22:20 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B6B633A6BAB; Mon, 29 Jun 2009 13:22:19 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 04:22:35 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 04:22:35 +0800 (CST)
Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Tue, 30 Jun 2009 04:22:35 +0800 (CST)
Date: Mon, 29 Jun 2009 15:22:31 -0500
From: Frank Xia <[e-mail]>
To: MELIA TELEMACO <[e-mail]>, George Tsirtsis <[e-mail]>
Message-id: <004b01c9f8f7$56779d60$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 8BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <000e01c9f8d4$ff2bde30$[e-mail]> <[e-mail]> <001401c9f8dd$d6c16830$[e-mail]> <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], mext <[e-mail]>
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 20:22:21 -0000

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" <[e-mail]>
To: "Frank Xia" <[e-mail]>; "George Tsirtsis" 
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
"mext" <[e-mail]>
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 : [e-mail] [mailto:[e-mail]] De la part de 
Frank Xia
Envoyé : lundi 29 juin 2009 19:20
À : George Tsirtsis
Cc : [e-mail]; [e-mail]; [e-mail]; 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" <[e-mail]>
To: "Frank Xia" <[e-mail]>
Cc: "marcelo bagnulo braun" <[e-mail]>; <[e-mail]>; "mext"
<[e-mail]>; <[e-mail]>; <[e-mail]>
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<[e-mail]> 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"
> <[e-mail]>
> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>

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


From [e-mail]  Mon Jun 29 13:44:36 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9E628C2CB; Mon, 29 Jun 2009 13:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.21
X-Spam-Level: 
X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=-0.211,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5ZS8iTiTnLJ; Mon, 29 Jun 2009 13:44:35 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 62EB128C144; Mon, 29 Jun 2009 13:44:34 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5TKiKWG004728; Mon, 29 Jun 2009 23:44:26 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 29 Jun 2009 23:43:18 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 29 Jun 2009 23:43:13 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 29 Jun 2009 22:43:12 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Date: Mon, 29 Jun 2009 22:43:18 +0200
Thread-Topic: [netext] [netlmm] NEXTEXT2: first draft of the bof description
Thread-Index: Acn488zJEmhaC8GVSp+YJU0zJscx5gABm6uT
Message-ID: <[e-mail]>
In-Reply-To: <002701c9f8f3$c6007570$[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Jun 2009 20:43:13.0952 (UTC) FILETIME=[390E4A00:01C9F8FA]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 20:44:36 -0000

Hi Frank,

Comments inline:


On 6/29/09 2:57 PM, "ext Frank Xia" <[e-mail]> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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" <[e-mail]> 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" <[e-mail]>
>> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>=20
>=20
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext


From [e-mail]  Mon Jun 29 14:36:34 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE4228C305; Mon, 29 Jun 2009 14:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.495
X-Spam-Level: 
X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.503,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP8lrir3OhZP; Mon, 29 Jun 2009 14:36:33 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CC7663A6C27; Mon, 29 Jun 2009 14:36:32 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 05:36:24 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 30 Jun 2009 05:36:24 +0800 (CST)
Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Tue, 30 Jun 2009 05:36:24 +0800 (CST)
Date: Mon, 29 Jun 2009 16:36:20 -0500
From: Frank Xia <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-id: <00b701c9f901$a61c8420$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 21:36:34 -0000

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: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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" <[e-mail]> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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" <[e-mail]> 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" <[e-mail]>
>> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext


From [e-mail]  Mon Jun 29 15:29:13 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4783A6C05; Mon, 29 Jun 2009 15:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.202
X-Spam-Level: 
X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw7pVn0rI2aL; Mon, 29 Jun 2009 15:29:12 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DDF4E3A6B64; Mon, 29 Jun 2009 15:29:06 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5TMT1Pw023455; Tue, 30 Jun 2009 01:29:07 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 01:28:55 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 01:28:50 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 30 Jun 2009 00:28:49 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Date: Tue, 30 Jun 2009 00:28:57 +0200
Thread-Topic: [netext] [netlmm] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5Aay986hKNg67SFaq1F9+Bv5PQAAB1ERK
Message-ID: <[e-mail]>
In-Reply-To: <00b701c9f901$a61c8420$[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Jun 2009 22:28:50.0175 (UTC) FILETIME=[F9BD30F0:01C9F908]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 22:29:14 -0000

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" <[e-mail]> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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" <[e-mail]> 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: <[e-mail]>
>> To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
>> <[e-mail]>; <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>
>> 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" <[e-mail]> 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" <[e-mail]>
>>> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>>> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>=20
>>=20
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>=20


From [e-mail]  Mon Jun 29 17:12:10 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5765F3A6A89; Mon, 29 Jun 2009 17:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.457
X-Spam-Level: 
X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-E4+qvH--+F; Mon, 29 Jun 2009 17:12:09 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 934CD3A6927; Mon, 29 Jun 2009 17:12:08 -0700 (PDT)
Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLQxW-0007Z6-W5; Tue, 30 Jun 2009 10:12:27 +1000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Tue, 30 Jun 2009 10:12:19 +1000
From: Hesham Soliman <[e-mail]>
To: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Cross posting
Thread-Index: Acn5F2581YkmsRcwh0eDxPYkagxsmQ==
In-Reply-To: <001401c9f8dd$d6c16830$[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: [e-mail], [e-mail], mext <[e-mail]>
Subject: [netext] Cross posting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 00:12:10 -0000

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

Hesham



From [e-mail]  Mon Jun 29 20:27:48 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848633A68F2 for <[e-mail]>; Mon, 29 Jun 2009 20:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.149
X-Spam-Level: 
X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpBKEp29wTFL for <[e-mail]>; Mon, 29 Jun 2009 20:27:36 -0700 (PDT)
Received: from mail-px0-f178.google.com (mail-px0-f178.google.com [209.85.216.178]) by core3.amsl.com (Postfix) with ESMTP id 647DC3A695D for <[e-mail]>; Mon, 29 Jun 2009 20:27:33 -0700 (PDT)
Received: by pxi8 with SMTP id 8so1808212pxi.29 for <[e-mail]>; Mon, 29 Jun 2009 20:27:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=kx7rMJ5DQK1MD3xtXrfdGyIEQ0fLSbqvUo7zknNODRY=; b=NMeAmK9OxBSotvXeUsSmRxwRlGcx27fsUz/ivOzX7mY+N59j7pCkQVtzkHWV6A22kq LQTAgtx5607xMOiruPcZA4Yc1z78f/97lr7gf4PqqQf8lcwFSYu+/v+bf/B3ojLvfQKc pTqjZrbJcbkqG7QRAc1QK1KuzUsPJHk9azb7Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mhYCRij1YJVDahpwdAyd8VNCR814yKbflUU2jzf9DHqaRStjeGlLsYl2VKQROz597w praPv4V0mYOcHk2kFGHwcyQtr7jTOFGZ6R+KwMxn1JnrSf8Im4UPRjahAzA39HKxurRz vr2nxhe86ffctCvHvc0eeZ0fy2nPsttALB77Y=
MIME-Version: 1.0
Received: by 10.114.58.20 with SMTP id g20mr12599859waa.130.1246332471431;  Mon, 29 Jun 2009 20:27:51 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 30 Jun 2009 11:27:51 +0800
Message-ID: <[e-mail]>
From: Min Hui <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Subject: [netext] Fwd: New Version Notification for draft-hui-netext-service-flow-identifier-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 03:27:49 -0000

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 <[e-mail]>
Date: 2009/6/30
Subject: New Version Notification for
draft-hui-netext-service-flow-identifier-00
To: [e-mail]
=B3=AD=CB=CD=A3=BA [e-mail], [e-mail]



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 [e-mail]  Mon Jun 29 21:09:14 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FAC28C1D0 for <[e-mail]>; Mon, 29 Jun 2009 21:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.754
X-Spam-Level: 
X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns+s66ixurJE for <[e-mail]>; Mon, 29 Jun 2009 21:09:14 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0F5DD3A6A62 for <[e-mail]>; Mon, 29 Jun 2009 21:09:14 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 30 Jun 2009 12:09:24 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 30 Jun 2009 12:09:24 +0800 (CST)
Received: from X24512z ([10.51.0.82]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 30 Jun 2009 12:09:24 +0800 (CST)
Date: Mon, 29 Jun 2009 23:09:19 -0500
From: Frank Xia <[e-mail]>
To: [e-mail]
Message-id: <007c01c9f938$8c0bd400$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: multipart/alternative; boundary="Boundary_(ID_n7rQatlqvpRFm5G8uwVh/Q)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [netext] Differentiated Services Support for Proxy Mobile IPv6
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 04:09:15 -0000

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 [e-mail]  Mon Jun 29 13:11:20 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8D728C167; Mon, 29 Jun 2009 13:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bza-2qY7S8A; Mon, 29 Jun 2009 13:11:19 -0700 (PDT)
Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by core3.amsl.com (Postfix) with ESMTP id 3593D3A6B0E; Mon, 29 Jun 2009 13:11:19 -0700 (PDT)
Received: by mail.critical.com (Postfix, from userid 99) id 2AEE438012; Mon, 29 Jun 2009 16:11:39 -0400 (EDT)
Received: from [192.168.1.3] (unknown [64.246.137.24]) by mail.critical.com (Postfix) with ESMTP id 9452D49B8; Mon, 29 Jun 2009 16:11:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 29 Jun 2009 16:11:32 -0400
From: "Stuart W. Card" <[e-mail]>
Organization: Critical Technologies Inc.
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]> <002701c9f8f3$c6007570$[e-mail]>
In-Reply-To: <002701c9f8f3$c6007570$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 29 Jun 2009 21:16:25 -0700
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 20:11:20 -0000

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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
> <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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" <[e-mail]> 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" <[e-mail]>
>> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> 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 <[e-mail]> www.critical.com


From [e-mail]  Mon Jun 29 19:12:46 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22C23A6C29 for <[e-mail]>; Mon, 29 Jun 2009 19:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level: 
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVV6VhNFCkrf for <[e-mail]>; Mon, 29 Jun 2009 19:12:45 -0700 (PDT)
Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 611A73A6C45 for <[e-mail]>; Mon, 29 Jun 2009 19:12:45 -0700 (PDT)
Received: (qmail 24737 invoked from network); 30 Jun 2009 02:06:25 -0000
Received: from unknown (124.121.210.22) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 30 Jun 2009 02:06:25 -0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <00b701c9f901$a61c8420$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 30 Jun 2009 09:02:30 +0700
Organization: Network Zen
Message-ID: <016901c9f926$d6afaac0$840f0040$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acn5Aay986hKNg67SFaq1F9+Bv5PQAAB1ERKAAcyqUA=
Content-Language: en-us
X-Mailman-Approved-At: Mon, 29 Jun 2009 21:16:25 -0700
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the bof	description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 02:12:46 -0000

[e-mail] 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 [e-mail]  Mon Jun 29 21:53:15 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4815F3A6DE3 for <[e-mail]>; Mon, 29 Jun 2009 21:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.495
X-Spam-Level: 
X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZaI01zNU6+p for <[e-mail]>; Mon, 29 Jun 2009 21:53:13 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B90A93A68E8 for <[e-mail]>; Mon, 29 Jun 2009 21:53:12 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5U4rKrr031867; Mon, 29 Jun 2009 23:53:31 -0500
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 07:53:17 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 07:53:09 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 30 Jun 2009 06:53:08 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Date: Tue, 30 Jun 2009 06:53:07 +0200
Thread-Topic: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of the	bof description
Thread-Index: Acn5Aay986hKNg67SFaq1F9+Bv5PQAAB1ERKAAcyqUAABJLEIA==
Message-ID: <[e-mail]>
References: <00b701c9f901$a61c8420$[e-mail]> <[e-mail]> <016901c9f926$d6afaac0$840f0040$@net>
In-Reply-To: <016901c9f926$d6afaac0$840f0040$@net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Jun 2009 04:53:09.0060 (UTC) FILETIME=[A9E7D040:01C9F93E]
X-Nokia-AV: Clean
Cc: [e-mail]
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of the	bof	description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 04:53:15 -0000

=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
[e-mail]
https://www.ietf.org/mailman/listinfo/mext

From [e-mail]  Tue Jun 30 01:52:39 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3242B28C32E for <[e-mail]>; Tue, 30 Jun 2009 01:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krNtJ6CwJomy for <[e-mail]>; Tue, 30 Jun 2009 01:52:38 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3C45628C340 for <[e-mail]>; Tue, 30 Jun 2009 01:52:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,315,1243814400"; d="scan'208";a="207485789"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2009 08:52:31 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5U8qVcp011123;  Tue, 30 Jun 2009 01:52:31 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n5U8qV06002243; Tue, 30 Jun 2009 08:52:31 GMT
Date: Tue, 30 Jun 2009 01:52:31 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: Marco Liebsch <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1030; t=1246351951; x=1247215951; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20RE=3A=20[netext]=20WG=20view=20about=20problem= 20statement=20I-D=20for=20localized=0A=20routing=20 |Sender:=20; bh=KcW2HxaEMbGKcf65PbZFraJ/X5/2Sxcw0/yM6TzRpB4=; b=V/4PxBxKSLmkN//fai3wWTrGrAwZ/CHtSi4oUi68t4RyTgi8lOm7elPlr1 G6zsmVMlrb78vDK8QG5r622NgXVGNeN4Z1+lz7fo9EDJqq4TDcp0yy9DnhGq mFeF2u3jq1FEz2+rnBXLwW6upNoAUZZ6fWFA2yLQQAkc/hECrbiSw=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 08:52:39 -0000

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 [e-mail]  Tue Jun 30 07:34:39 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9695B28C3EB; Tue, 30 Jun 2009 07:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlMa1PCfFKOy; Tue, 30 Jun 2009 07:34:38 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 4D66328C3F2; Tue, 30 Jun 2009 07:34:25 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n5UDj79O013326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jun 2009 08:45:07 -0500 (CDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n5UDj7ZI024095; Tue, 30 Jun 2009 08:45:07 -0500 (CDT)
Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n5UDj64a024057 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 30 Jun 2009 08:45:07 -0500 (CDT)
Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 30 Jun 2009 06:45:07 -0700
From: "Davis, Terry L" <[e-mail]>
To: "'Glen Zorn'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 30 Jun 2009 06:45:06 -0700
Thread-Topic: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of 	thebof description
Thread-Index: Acn5Aay986hKNg67SFaq1F9+Bv5PQAAB1ERKAAcyqUAAGAvUYA==
Message-ID: <[e-mail]>
References: <00b701c9f901$a61c8420$[e-mail]><[e-mail]> <016901c9f926$d6afaac0$840f0040$@net>
In-Reply-To: <016901c9f926$d6afaac0$840f0040$@net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 30 Jun 2009 08:36:49 -0700
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [netext] [MEXT] [netlmm] NEXTEXT2: first draft of thebof	description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 14:34:39 -0000

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Glen Zorn
> Sent: Monday, June 29, 2009 7:03 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [MEXT] [netext] [netlmm] NEXTEXT2: first draft of thebof
> description
>=20
> [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext

From [e-mail]  Tue Jun 30 08:42:30 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E2928C405 for <[e-mail]>; Tue, 30 Jun 2009 08:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I12R2a9s+TxH for <[e-mail]>; Tue, 30 Jun 2009 08:42:30 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BB1E028C401 for <[e-mail]>; Tue, 30 Jun 2009 08:42:29 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C79272C020483; Tue, 30 Jun 2009 17:18:04 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DEEsfGrLNhf; Tue, 30 Jun 2009 17:18:04 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id A9DBB2C00C51C; Tue, 30 Jun 2009 17:17:54 +0200 (CEST)
Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 17:17:51 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 Jun 2009 17:17:51 +0200
From: Marco Liebsch <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Sri Gundavelli <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jun 2009 15:17:51.0493 (UTC) FILETIME=[EF2D3350:01C9F995]
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 15:42:30 -0000

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 [e-mail]  Tue Jun 30 09:10:03 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C233A685B; Tue, 30 Jun 2009 09:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfG9WMPsA+ia; Tue, 30 Jun 2009 09:10:02 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 326D33A6767; Tue, 30 Jun 2009 09:10:00 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5UG5N1D006500; Tue, 30 Jun 2009 19:05:38 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 19:04:39 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 19:04:34 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 19:04:29 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 30 Jun 2009 18:04:29 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Date: Tue, 30 Jun 2009 18:04:37 +0200
Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5iXlwnAOxL7OgU0eyLJZ4+zf3JwAEv3xr
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Jun 2009 16:04:29.0505 (UTC) FILETIME=[72EBF310:01C9F99C]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:10:03 -0000

Hi Hesham,


On 6/30/09 8:48 AM, "ext Hesham Soliman" <[e-mail]> 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 [e-mail]  Tue Jun 30 09:14:27 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8123A685B; Tue, 30 Jun 2009 09:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.163
X-Spam-Level: 
X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXVUEY20w9vB; Tue, 30 Jun 2009 09:14:24 -0700 (PDT)
Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 9F07D3A6B48; Tue, 30 Jun 2009 09:13:41 -0700 (PDT)
Received: by bwz9 with SMTP id 9so244006bwz.37 for <multiple recipients>; Tue, 30 Jun 2009 09:13:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=daPC19wMvAK7DzQPdLG5ApWmlDmIopTsz5vyM3nsdo4=; b=GEpeN2RKIgL8ACV1e0WruRjqvHzVsEq98pTNMr+abpsbrk4Wj7zlouXvgclZvbcah0 70aJbYaV4rlXemqp92om/Fa3A2OeF2KK8bgCy7RxN7eiiGiVyMamhu7zl9VaORZhT4Hy Sl/yoxfDqEEa4ZE/LYj2IOBk+F+vJ2c6pSwtc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=m9n2PoSoWGzHz2ymB5EgNRNnvsF66sHepv1hnepXoHenGZDecks4DCy5RlhykDO5Vv 5ojXMeX+JRT5dYeReQhBOzHAP82w1rzKffqR7R2nvN5RGp8Sith3mc5bAZZgSgnk8Ck4 PNO2yNLwAIkYVQ6dhTQ42FUy+um9OAHGN4I9U=
MIME-Version: 1.0
Received: by 10.223.126.69 with SMTP id b5mr5474011fas.34.1246378398273; Tue,  30 Jun 2009 09:13:18 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 30 Jun 2009 17:13:18 +0100
Message-ID: <[e-mail]>
From: George Tsirtsis <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:14:27 -0000

inline...

On Tue, Jun 30, 2009 at 4:52 PM, <[e-mail]> wrote:
>
>
> On 6/30/09 9:54 AM, "ext Hesham Soliman" <[e-mail]> 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" <[e-mail]> 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<[e-mail]> 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?
>>>>>>>
>>>>>>>
>>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
>>>>>>>>>> To:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <[e-mail]>; <[e-mail]>; <[e-mail]>;
>>>>>>>
>>>>>>> <[e-mail]>; <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>> 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"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <[e-mail]> 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:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>>> To: <[e-mail]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[e-mail]>; <[e-mail]>;
>>>>>>>
>>>>>>>
>>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> To:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> Cc:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> <[e-mail]>; "Ralph Droms" <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> netext mailing
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>>>>> [e-mail]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>
>>>>>>>>> MEXT mailing list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> [e-mail]
>>>>>>>
>>>>>>>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> [e-mail]
>>>>>>>
>>>>>>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>>
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> netlmm mailing
>>>>>>
>>>>>>
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

From [e-mail]  Tue Jun 30 09:22:26 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D183A69D5; Tue, 30 Jun 2009 09:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.649
X-Spam-Level: 
X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=2.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdNzqKufU0WZ; Tue, 30 Jun 2009 09:22:25 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CE0CF3A6767; Tue, 30 Jun 2009 09:22:24 -0700 (PDT)
Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5UGLZYG023645;  Tue, 30 Jun 2009 18:21:35 +0200
Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 18:21:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jun 2009 18:21:34 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netlmm] [MEXT]  NEXTEXT2: first draft of the bof description
Thread-Index: Acn5mMVeUUTcpRDgQgW6OsAnumzt7AABeTKw
References: <[e-mail]>	<000e01c9f8d4$ff2bde30$[e-mail]>	<[e-mail]>	<001401c9f8dd$d6c16830$[e-mail]>	<[e-mail]> <004b01c9f8f7$56779d60$[e-mail]> <[e-mail]>
From: "MELIA TELEMACO" <[e-mail]>
To: "Marco Liebsch" <[e-mail]>, "Frank Xia" <[e-mail]>
X-OriginalArrivalTime: 30 Jun 2009 16:21:35.0231 (UTC) FILETIME=[D64D50F0:01C9F99E]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83
Cc: mext <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:22:26 -0000

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
> <[e-mail]>
> To: "Frank Xia" <[e-mail]>; "George Tsirtsis"=20
> <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;=20
> <[e-mail]>; "mext" <[e-mail]>
> 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 : [e-mail] [mailto:[e-mail]] De la=20
> part de Frank Xia
> Envoy=E9 : lundi 29 juin 2009 19:20
> =C0 : George Tsirtsis
> Cc : [e-mail]; [e-mail]; [e-mail]; =
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
> <[e-mail]>
> To: "Frank Xia" <[e-mail]>
> Cc: "marcelo bagnulo braun" <[e-mail]>; <[e-mail]>;=20
> "mext"
> <[e-mail]>; <[e-mail]>; <[e-mail]>
> 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<[e-mail]> =
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"
>> <[e-mail]>
>> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm


From [e-mail]  Tue Jun 30 09:22:58 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD7C3A6C9E; Tue, 30 Jun 2009 09:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.532
X-Spam-Level: 
X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8cD3fm86L1J; Tue, 30 Jun 2009 09:22:57 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6ED143A6C0B; Tue, 30 Jun 2009 09:22:57 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp03.uc3m.es (Postfix) with ESMTP id BA3D87F30FD; Tue, 30 Jun 2009 18:22:43 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 30 Jun 2009 18:22:43 +0200
From: marcelo bagnulo braun <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16736.000
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:22:58 -0000

[e-mail] escribió:
> Hi Hesham,
>
>
> On 6/30/09 8:48 AM, "ext Hesham Soliman" <[e-mail]> 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 [e-mail]  Tue Jun 30 09:24:56 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D383A6CCC; Tue, 30 Jun 2009 09:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri831CAHVNuR; Tue, 30 Jun 2009 09:24:53 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CC4BC3A6E88; Tue, 30 Jun 2009 09:24:39 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,317,1243814400"; d="scan'208";a="334807485"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2009 16:24:32 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5UGOWtB028943;  Tue, 30 Jun 2009 09:24:32 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5UGOWYT014551; Tue, 30 Jun 2009 16:24:32 GMT
Date: Tue, 30 Jun 2009 09:24:32 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=581; t=1246379072; x=1247243072; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20[netlmm]=20[MEXT]=20NEXTEXT2 =3A=20first=20draft=20of=20the=20bof=0A=20description |Sender:=20; bh=DiGyTH3o7MQSUvLO4XKiWMy1wElZ/2yW6fDCah0SQSw=; b=PdFwIZJoRNHzdRDVywBuGrWgzXRZeHK9EZCnuk6OsxXw75c8v6vtvq9NUQ HMvCXqk+zHOv7ZTLcbPAIlL4umcgKyJLKbZfbd2ZFJUKVAgyVNF+qUqinIEl 8xypHaA7+/d3rrVJNMweioQ1kCLdoeMhDThb4Csd1iQURmigv7ESo=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:24:56 -0000

>
> 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 [e-mail]  Tue Jun 30 09:32:01 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC9A3A6E84; Tue, 30 Jun 2009 09:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xod2pR2fI4Q7; Tue, 30 Jun 2009 09:31:59 -0700 (PDT)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 5C1733A6973; Tue, 30 Jun 2009 09:31:59 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 01BED9001E; Tue, 30 Jun 2009 12:31:51 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32376-09; Tue, 30 Jun 2009 12:31:46 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 30 Jun 2009 12:31:46 -0400 (EDT)
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 12:31:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jun 2009 12:31:45 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription
Thread-Index: Acn5neuvAZePinJuQJazJN5+QEx3ggAAddJA
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Koodli, Rajeev" <[e-mail]>
To: "George Tsirtsis" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Jun 2009 16:31:46.0186 (UTC) FILETIME=[4275A6A0:01C9F9A0]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:32:02 -0000

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
> <[e-mail]> 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<[e-mail]> 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?
> >>>>>>>
> >>>>>>>
> >>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
> >>>>>>>>>> To:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> <[e-mail]>; <[e-mail]>;=20
> >>>>>>> <[e-mail]>;
> >>>>>>>
> >>>>>>> <[e-mail]>; <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> Cc: <[e-mail]>;
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> 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"
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> <[e-mail]> 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:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> To: <[e-mail]>;
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[e-mail]>; <[e-mail]>;
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> <[e-mail]>;
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> Cc: <[e-mail]>;
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> To:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> Cc:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>> <[e-mail]>; "Ralph Droms"=20
> <[e-mail]>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> netext mailing
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> list
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>> [e-mail]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>>
> >>>>>>>
> >>>>>>>>> MEXT mailing list
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> [e-mail]
> >>>>>>>
> >>>>>>>
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> MEXT mailing list
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> [e-mail]
> >>>>>>>
> >>>>>>>
> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> netlmm mailing list
> >>>>>>>
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> netlmm mailing
> >>>>>>
> >>>>>>
> >>>>>>> list
> >>>>>>>
> >>>>>>>
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>=20

From [e-mail]  Tue Jun 30 09:38:41 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7153A6973; Tue, 30 Jun 2009 09:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrc1sVgOCKkE; Tue, 30 Jun 2009 09:38:40 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9EE763A6B72; Tue, 30 Jun 2009 09:38:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,317,1243814400"; d="scan'208";a="334814759"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2009 16:36:07 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5UGa7PI021494;  Tue, 30 Jun 2009 09:36:07 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n5UGa7eG010572; Tue, 30 Jun 2009 16:36:07 GMT
Date: Tue, 30 Jun 2009 09:36:07 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: marcelo bagnulo braun <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1845; t=1246379767; x=1247243767; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20[netlmm]=20[MEXT]=20NEXTEXT2 =3A=20first=20draft=20of=20the=20bof=0A=20description |Sender:=20; bh=neDt4TVtBKDTvsm+bEe+ownNTSVer7K7ThJccftDIVI=; b=URBR+xFzkbfFlIgrUm1IE61xrZiXexBqhraH4yvQG+UF339/UjVZw/r9zT /KCyW3PnisyR7bwyhnL1kxF0drVjzKDMibf6+A7gs39Hi3a8gzNo/evYZHDm rLM/Uw0gnP;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:38:41 -0000

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>
>

From [e-mail]  Tue Jun 30 09:41:41 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924753A68E5; Tue, 30 Jun 2009 09:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.195
X-Spam-Level: 
X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8CArJ3akMSg; Tue, 30 Jun 2009 09:41:39 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C3D903A6A1E; Tue, 30 Jun 2009 09:41:37 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5UFq404022073; Tue, 30 Jun 2009 18:52:05 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 18:52:09 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 18:52:04 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 30 Jun 2009 17:52:01 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Date: Tue, 30 Jun 2009 17:52:07 +0200
Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+Cb
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Jun 2009 15:52:04.0268 (UTC) FILETIME=[B6B9CEC0:01C9F99A]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:41:41 -0000

On 6/30/09 9:54 AM, "ext Hesham Soliman" <[e-mail]> 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" <[e-mail]> 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<[e-mail]> 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?
>>>>>>
>>>>>>
>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
>>>>>>>>> To:
>>>>>>>>>
>>>>>>>>>
>>>>>> <[e-mail]>; <[e-mail]>; <[e-mail]>;
>>>>>>
>>>>>> <[e-mail]>; <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>
>>>>>>>>>
>>>>>> <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>> 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"
>>>>>>>>>
>>>>>>>>>
>>>>>> <[e-mail]> 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:
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>>> To: <[e-mail]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[e-mail]>; <[e-mail]>;
>>>>>>
>>>>>>
>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>> <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>>>> To:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>>>> Cc:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> <[e-mail]>; "Ralph Droms" <[e-mail]>
>>>>>>
>>>>>>
>>>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netext mailing
>>>>>>>>>>
>>>>>>>>>>
>>>>>> list
>>>>>>
>>>>>>
>>>>>>>>>> [e-mail]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>>
>>>>>>>> MEXT mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> [e-mail]
>>>>>>
>>>>>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> MEXT mailing list
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> [e-mail]
>>>>>>
>>>>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> netlmm mailing list
>>>>>>
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> netlmm mailing
>>>>>
>>>>>
>>>>>> list
>>>>>>
>>>>>>
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>
>
>


From [e-mail]  Tue Jun 30 09:47:17 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3454328C3F2; Tue, 30 Jun 2009 09:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.065
X-Spam-Level: 
X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KSo6fIDSTHG; Tue, 30 Jun 2009 09:47:14 -0700 (PDT)
Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id B6DF53A68E5; Tue, 30 Jun 2009 09:47:13 -0700 (PDT)
Received: by fxm18 with SMTP id 18so268258fxm.37 for <multiple recipients>; Tue, 30 Jun 2009 09:45:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0IXGzXk8dky5SjAgCHKkrnSDG/hEl9rFdXCY6dqmiT4=; b=t4tLq271Htti9+98xo84y13Vzr/HRRblFk5K+oM6k30It0wjELi+EN0VHvxsIh0zEl hvYdDSq/Gb3302HsEmCJuKXNSQCenOgKgG7hc8enaSLQ2fRUd5v5r0txjvuW/IUL5M2t ZwosA/8csdVN7n9/NMNSVDHaBoVHZatrWtXP4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=focS2uVzFxvHlU1pnk9xOIkf5NnAQGjhqOFGGQWSMTJBa0KVBXNsSVVLQ6owukbVXm wUFoABw3slIEFWabcdfAFnXgMu2Ui+XmvCzX8rdkJczYPMkgYMtY0W/Vq4GjW2SsNVSp Lct+aO08xHZDTIZUrgM5yxEeh+ZzEvD0ixWoI=
MIME-Version: 1.0
Received: by 10.223.107.199 with SMTP id c7mr5478136fap.31.1246380324579; Tue,  30 Jun 2009 09:45:24 -0700 (PDT)
In-Reply-To: <4D35478224365146822AE9E3AD4A266609E3BE2D$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <4D35478224365146822AE9E3AD4A266609E3BE2D$[e-mail]>
Date: Tue, 30 Jun 2009 17:45:24 +0100
Message-ID: <[e-mail]>
From: George Tsirtsis <[e-mail]>
To: "Koodli, Rajeev" <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 16:47:17 -0000

inline

On Tue, Jun 30, 2009 at 5:31 PM, Koodli,
Rajeev<[e-mail]> 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"
>> <[e-mail]> 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<[e-mail]> 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?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
>> >>>>>>>>>> To:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <[e-mail]>; <[e-mail]>;
>> >>>>>>> <[e-mail]>;
>> >>>>>>>
>> >>>>>>> <[e-mail]>; <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> Cc: <[e-mail]>;
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>> 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"
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>> <[e-mail]> 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:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> To: <[e-mail]>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[e-mail]>; <[e-mail]>;
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> <[e-mail]>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> Cc: <[e-mail]>;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> To:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> Cc:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>> <[e-mail]>; "Ralph Droms"
>> <[e-mail]>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>> 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
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>> [e-mail]
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> netext mailing
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>> [e-mail]
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> MEXT mailing list
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>> [e-mail]
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> MEXT mailing list
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> [e-mail]
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> netlmm mailing list
>> >>>>>>>
>> >>>>>>> [e-mail]
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> netlmm mailing
>> >>>>>>
>> >>>>>>
>> >>>>>>> list
>> >>>>>>>
>> >>>>>>>
>> >>>>>> [e-mail]
>> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> 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 [e-mail]  Tue Jun 30 10:05:54 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9324B3A6C5D; Tue, 30 Jun 2009 10:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level: 
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfL4TdKFw6Gh; Tue, 30 Jun 2009 10:05:53 -0700 (PDT)
Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id DEC2F3A6C5B; Tue, 30 Jun 2009 10:05:52 -0700 (PDT)
Received: by fxm18 with SMTP id 18so280465fxm.37 for <multiple recipients>; Tue, 30 Jun 2009 10:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mTrAG0bIbqi6rISNrSsAs/bXQfKTB6DLsT2kw+AqKlk=; b=QpUym8SJEV3Fe75uqzaUqONjyBAcHpDPH3qsFEf3fh0JBbv4l6cqFywjQWoqpk0s/i IdGZGs6N902fxoffS/xKUh10tJ+4WR+yCuT39L9PEB2x99Jbnbwgz4qY+6xVw8Xt4qsJ voq5DNW0Ed+Mi1ykZIluyyw4P5AMyvPnAEgYU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jkj4VBg4Aush2vJDCSRUCjFDDh3xPvq3s/gzKtRCzb6CmCuTE4NjMnFa0v00yL7hto ccchItoO921SuR21rOAiDStjLj+/ejYMq/TnM9BcV8W7Plu+yrWOfqfV1bA76G5mq0Zm cVobLjftvfMMVQMmVar85/mLYmSJRSx5mwYp8=
MIME-Version: 1.0
Received: by 10.223.108.15 with SMTP id d15mr5377723fap.105.1246381518765;  Tue, 30 Jun 2009 10:05:18 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 30 Jun 2009 18:05:17 +0100
Message-ID: <[e-mail]>
From: George Tsirtsis <[e-mail]>
To: Sri Gundavelli <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:05:54 -0000

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<[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>>
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>

From [e-mail]  Tue Jun 30 10:06:26 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A0828C42A; Tue, 30 Jun 2009 10:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsrzI4wHYRw8; Tue, 30 Jun 2009 10:06:25 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2134E3A6A3E; Tue, 30 Jun 2009 10:06:25 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C4AC42C00C51C; Tue, 30 Jun 2009 17:38:00 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JarY01huqImg; Tue, 30 Jun 2009 17:38:00 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 914932C020493; Tue, 30 Jun 2009 17:37:25 +0200 (CEST)
Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 17:37:25 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 Jun 2009 17:37:25 +0200
From: Marco Liebsch <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Frank Xia <[e-mail]>
References: <[e-mail]>	<000e01c9f8d4$ff2bde30$[e-mail]>	<[e-mail]>	<001401c9f8dd$d6c16830$[e-mail]>	<[e-mail]> <004b01c9f8f7$56779d60$[e-mail]>
In-Reply-To: <004b01c9f8f7$56779d60$[e-mail]>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 30 Jun 2009 15:37:25.0882 (UTC) FILETIME=[AB2ABDA0:01C9F998]
Cc: [e-mail], [e-mail], MELIA TELEMACO <[e-mail]>, [e-mail], mext <[e-mail]>
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:06:26 -0000

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" 
> <[e-mail]>
> To: "Frank Xia" <[e-mail]>; "George Tsirtsis" 
> <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>; "mext" <[e-mail]>
> 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 : [e-mail] [mailto:[e-mail]] De la 
> part de Frank Xia
> Envoyé : lundi 29 juin 2009 19:20
> À : George Tsirtsis
> Cc : [e-mail]; [e-mail]; [e-mail]; 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" 
> <[e-mail]>
> To: "Frank Xia" <[e-mail]>
> Cc: "marcelo bagnulo braun" <[e-mail]>; <[e-mail]>; 
> "mext"
> <[e-mail]>; <[e-mail]>; <[e-mail]>
> 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<[e-mail]> 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"
>> <[e-mail]>
>> To: <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>> Cc: <[e-mail]>; "Ralph Droms" <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm


From [e-mail]  Tue Jun 30 10:24:37 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA653A6CF1; Tue, 30 Jun 2009 10:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level: 
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL4RH7KclyIf; Tue, 30 Jun 2009 10:24:36 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 784923A6A3E; Tue, 30 Jun 2009 10:24:36 -0700 (PDT)
Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5UHNWeX028529;  Tue, 30 Jun 2009 19:23:32 +0200
Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 19:23:32 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jun 2009 19:23:31 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netlmm] [netext] [MEXT] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5n2YM4M/Xxr3iTnyk0X3HcdUWWgAB8U7g
References: <[e-mail]> <[e-mail]>
From: "MELIA TELEMACO" <[e-mail]>
To: "Sri Gundavelli" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Jun 2009 17:23:32.0437 (UTC) FILETIME=[7DEDF050:01C9F9A7]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:24:37 -0000

>
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/netlmm

From [e-mail]  Tue Jun 30 10:26:28 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C995528C419; Tue, 30 Jun 2009 10:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.929
X-Spam-Level: 
X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XRzS6054B5f; Tue, 30 Jun 2009 10:26:23 -0700 (PDT)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 2459F28C404; Tue, 30 Jun 2009 10:26:23 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1CB7A9012D; Tue, 30 Jun 2009 13:07:31 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03766-03; Tue, 30 Jun 2009 13:07:29 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 30 Jun 2009 13:07:29 -0400 (EDT)
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 13:07:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jun 2009 13:07:28 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription
Thread-Index: Acn5oi/NyRioNlmgRq+k8YPIuFh0JgAAcHnA
References: <[e-mail]> <[e-mail]> <[e-mail]> <4D35478224365146822AE9E3AD4A266609E3BE2D$[e-mail]> <[e-mail]>
From: "Koodli, Rajeev" <[e-mail]>
To: "George Tsirtsis" <[e-mail]>
X-OriginalArrivalTime: 30 Jun 2009 17:07:28.0978 (UTC) FILETIME=[3FA9C320:01C9F9A5]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:26:29 -0000

=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"
> >> <[e-mail]> 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<[e-mail]> 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?
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
> >> >>>>>>>>>> To:
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[e-mail]>; <[e-mail]>;=20
> >> >>>>>>> <[e-mail]>;
> >> >>>>>>>
> >> >>>>>>> <[e-mail]>; <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> Cc: <[e-mail]>;
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>> 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"
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>> <[e-mail]> 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:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> To: <[e-mail]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>; <[e-mail]>;
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> <[e-mail]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> Cc: <[e-mail]>;
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> To:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> <[e-mail]>; "mext" <[e-mail]>;=20
> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> Cc:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>> <[e-mail]>; "Ralph Droms"
> >> <[e-mail]>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>> 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
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>> [e-mail]
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>> _______________________________________________
> >> >>>>>>>>>>> netext mailing
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> list
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>> [e-mail]
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netext
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> MEXT mailing list
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>> [e-mail]
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>> _______________________________________________
> >> >>>>>>>> MEXT mailing list
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> [e-mail]
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> netlmm mailing list
> >> >>>>>>>
> >> >>>>>>> [e-mail]
> >> >>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> netlmm mailing
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> list
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>> [e-mail]
> >> >>>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >> _______________________________________________
> >> netext mailing list
> >> [e-mail]
> >> 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 [e-mail] -- and destroy all=20
> copies of this message and any attachments without reading or=20
> disclosing their contents. Thank you.
> >
>=20

From [e-mail]  Tue Jun 30 10:40:34 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A120B28C419 for <[e-mail]>; Tue, 30 Jun 2009 10:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.524
X-Spam-Level: 
X-Spam-Status: No, score=0.524 tagged_above=-999 required=5 tests=[AWL=-1.432,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLv-8eGN5BzC for <[e-mail]>; Tue, 30 Jun 2009 10:40:33 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id ABCB93A63CB for <[e-mail]>; Tue, 30 Jun 2009 10:40:33 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 01:11:05 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 01:11:05 +0800 (CST)
Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 01:11:05 +0800 (CST)
Date: Tue, 30 Jun 2009 12:11:02 -0500
From: Frank Xia <[e-mail]>
To: Min Hui <[e-mail]>, [e-mail]
Message-id: <009301c9f9a5$c03b6d90$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original
Content-transfer-encoding: 8BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Subject: Re: [netext] Fwd: New Version Notification fordraft-hui-netext-service-flow-identifier-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:40:34 -0000

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" <[e-mail]>
To: <[e-mail]>
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 <[e-mail]>
> Date: 2009/6/30
> Subject: New Version Notification for
> draft-hui-netext-service-flow-identifier-00
> To: [e-mail]
> ³­ËÍ£º [e-mail], [e-mail]
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
> 


From [e-mail]  Tue Jun 30 10:46:08 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153BC3A6A19; Tue, 30 Jun 2009 10:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51mptXZHz-Tn; Tue, 30 Jun 2009 10:46:07 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 02AC428C0F4; Tue, 30 Jun 2009 10:46:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,317,1243814400"; d="scan'208";a="207708664"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2009 17:33:31 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5UHXVVr013525;  Tue, 30 Jun 2009 10:33:31 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5UHXVkF002433; Tue, 30 Jun 2009 17:33:31 GMT
Date: Tue, 30 Jun 2009 10:33:31 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: George Tsirtsis <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1514014542-1246383211=:29873"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4936; t=1246383211; x=1247247211; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20[netlmm]=20[MEXT]=20NEXTEXT2 =3A=20first=20draft=20of=20the=20bof=20=0A=20description |Sender:=20; bh=kbZqjkikAQ4+CuWOpTorMA9p8D8X85DIo5WSYsdw+Go=; b=M5RtEeqcdXhzECJ3QjOXHjkVn4zzx2osq0otj1VRLujsphLH5C/LXmXLzj UnrMmAtCqiWcuHJ+cO6A13dXf8hD7jVinAigODm6kDheU5hmqJgYJ+sAeB7Y C5xidrBsIg;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:46:08 -0000

  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<[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netext
>>>
>>>
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>
---559023410-1514014542-1246383211=:29873--

From [e-mail]  Tue Jun 30 10:50:35 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2413A6A19; Tue, 30 Jun 2009 10:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.534
X-Spam-Level: 
X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcFt2DbLNEjb; Tue, 30 Jun 2009 10:50:34 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 536BD3A68E5; Tue, 30 Jun 2009 10:50:33 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp01.uc3m.es (Postfix) with ESMTP id 62AABBA5B83; Tue, 30 Jun 2009 19:50:43 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 30 Jun 2009 19:50:43 +0200
From: marcelo bagnulo braun <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Sri Gundavelli <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16736.001
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:50:35 -0000

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 [e-mail]  Tue Jun 30 10:52:40 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F803A63CB; Tue, 30 Jun 2009 10:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11tu88BpybOP; Tue, 30 Jun 2009 10:52:38 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7EC7E3A6A19; Tue, 30 Jun 2009 10:52:37 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp03.uc3m.es (Postfix) with ESMTP id 9E9BA7F3123; Tue, 30 Jun 2009 19:52:47 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 30 Jun 2009 19:52:47 +0200
From: marcelo bagnulo braun <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: "Koodli, Rajeev" <[e-mail]>
References: <[e-mail]><[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16736.001
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the	bofdescription
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:52:40 -0000

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" 
>>>>>>>>                 
>> <[e-mail]> 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<[e-mail]> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
>>>>>>>>>>>> To:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> <[e-mail]>; <[e-mail]>; 
>>>>>>>>> <[e-mail]>;
>>>>>>>>>
>>>>>>>>> <[e-mail]>; <[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> <[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>> 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"
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>> <[e-mail]> 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:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> To: <[e-mail]>;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[e-mail]>; <[e-mail]>;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> <[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> To:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>> Cc:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>> <[e-mail]>; "Ralph Droms" 
>>>>>>>>>                   
>> <[e-mail]>
>>     
>>>>>>>>>                   
>>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                               
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> netext mailing
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>>>> _______________________________________________
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> MEXT mailing list
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>> [e-mail]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> _______________________________________________
>>>>>>>>>> MEXT mailing list
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> [e-mail]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> _______________________________________________
>>>>>>>>> netlmm mailing list
>>>>>>>>>
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> _______________________________________________
>>>>>>>> netlmm mailing
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>
>>>>>>
>>>>>>             
>>>>         
>>>       
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>>     
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm
>
>   


From [e-mail]  Tue Jun 30 10:59:13 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD193A68E5; Tue, 30 Jun 2009 10:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level: 
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5UlAXWFV906; Tue, 30 Jun 2009 10:59:12 -0700 (PDT)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 3931D3A6A19; Tue, 30 Jun 2009 10:59:09 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7435D90049; Tue, 30 Jun 2009 13:36:25 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10202-04; Tue, 30 Jun 2009 13:36:21 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 30 Jun 2009 13:36:21 -0400 (EDT)
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 13:36:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jun 2009 13:36:21 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription
Thread-Index: Acn5ny7ZNCZMzB0NS0KRkP8rq3CehQAB9BnQ
References: <[e-mail]> <[e-mail]>
From: "Koodli, Rajeev" <[e-mail]>
To: "marcelo bagnulo braun" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Jun 2009 17:36:21.0658 (UTC) FILETIME=[486BBFA0:01C9F9A9]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 17:59:13 -0000

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>=20

From [e-mail]  Tue Jun 30 11:02:59 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF183A6E8A for <[e-mail]>; Tue, 30 Jun 2009 11:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btzTuS6kpFFR for <[e-mail]>; Tue, 30 Jun 2009 11:02:58 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 3945A3A6E86 for <[e-mail]>; Tue, 30 Jun 2009 11:02:58 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id v27so64584wah.5 for <[e-mail]>; Tue, 30 Jun 2009 11:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rjsKQf6c1VVvp+SzCKbEsuDOM+Zm3cRmofLJPkbSaLQ=; b=YmmHAXyKJNYR6E/AnrT4sNMaTzQLWMgKrhAhQ2NE7G1QbnwS7I0CxV12sue3hbBCQ/ hQf2BLtPYM6s9Et/rsl2etMKzjDUs2y4udH00vaSr683BlyK9XWeJbEql7T/5DK+B66e 3PSoIK3R239rwn8Vf4bitssv6pe/RmzxPamVQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=E+EgSHOVlS8LhU9ebjmCtxAO34hvhtw/6VXkGtUnW9JN1SoWAS1v5tko40oq0Zyvpe DA20kk4YplTehCeaGqMwkGGS2Bgpq5zOcvup3dXmJPn34WjscZNV5TGSYFp9yBBAbL7q zJfwKVXFEM0nUmguEf48JIiDkzB2HE7FBgOIo=
MIME-Version: 1.0
Received: by 10.114.158.1 with SMTP id g1mr13647609wae.18.1246384989584; Tue,  30 Jun 2009 11:03:09 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 30 Jun 2009 11:03:09 -0700
Message-ID: <[e-mail]>
From: Rajeev Koodli <[e-mail]>
To: Marco Liebsch <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 18:02:59 -0000

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<[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>

From [e-mail]  Tue Jun 30 11:14:35 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC6528C210; Tue, 30 Jun 2009 11:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61NNSred+O+2; Tue, 30 Jun 2009 11:14:34 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5C3C828C3F3; Tue, 30 Jun 2009 11:14:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,317,1243814400"; d="scan'208";a="181770824"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2009 18:13:21 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5UIDKcs010597;  Tue, 30 Jun 2009 11:13:20 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5UIDKLS015526; Tue, 30 Jun 2009 18:13:20 GMT
Date: Tue, 30 Jun 2009 11:13:19 -0700 (PDT)
From: Sri Gundavelli <[e-mail]>
To: marcelo bagnulo braun <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=584; t=1246385600; x=1247249600; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sri=20Gundavelli=20<[e-mail]> |Subject:=20Re=3A=20[netext]=20[netlmm]=20[MEXT]=20NEXTEXT2 =3A=20first=20draft=20of=20the=20bof=0A=20description |Sender:=20; bh=H2WVX9hjGVF2U81OBldQHEhKyKv/2MxihHEbWLuS2lY=; b=Vq+GFT8qANE0HHUAkvjgYY8I0pfcDPGO59rgxgxAkA2ihvxHQFTnxGVKsJ Payy6lnXoXuA5tg/e2rMPGCw5+XfrkAmbC8WZ2WsHFKlqjpQYZZ6zoNIRcJZ 2jTrauwufg;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 18:14:35 -0000

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 [e-mail]  Tue Jun 30 11:23:02 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5867A28C20F; Tue, 30 Jun 2009 11:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.229
X-Spam-Level: 
X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQfgDeMjMXR2; Tue, 30 Jun 2009 11:23:00 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 625ED28C0D0; Tue, 30 Jun 2009 11:22:59 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp01.uc3m.es (Postfix) with ESMTP id 5A503BA5BE7; Tue, 30 Jun 2009 18:09:09 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 30 Jun 2009 18:09:08 +0200
From: marcelo bagnulo braun <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16736.000
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 18:23:02 -0000

[e-mail] escribió:
> On 6/30/09 9:54 AM, "ext Hesham Soliman" <[e-mail]> 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" <[e-mail]> 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<[e-mail]> 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?
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
>>>>>>>>>> To:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> <[e-mail]>; <[e-mail]>; <[e-mail]>;
>>>>>>>
>>>>>>> <[e-mail]>; <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>> 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"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>> <[e-mail]> 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:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> To: <[e-mail]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[e-mail]>; <[e-mail]>;
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> 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" <[e-mail]> 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" <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> To:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> Cc:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>> <[e-mail]>; "Ralph Droms" <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                           
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>>>                           
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> netext mailing
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>> [e-mail]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> MEXT mailing list
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> [e-mail]
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> [e-mail]
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>>
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> _______________________________________________
>>>>>> netlmm mailing
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> list
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>
>>>>
>>>>         
>>     
>
>
>   


From [e-mail]  Tue Jun 30 11:34:33 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFC03A6CCC for <[e-mail]>; Tue, 30 Jun 2009 11:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.776
X-Spam-Level: 
X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYfPUilQQ-f2 for <[e-mail]>; Tue, 30 Jun 2009 11:34:32 -0700 (PDT)
Received: from n77.bullet.mail.sp1.yahoo.com (n77.bullet.mail.sp1.yahoo.com [98.136.44.45]) by core3.amsl.com (Postfix) with SMTP id 389873A6E7E for <[e-mail]>; Tue, 30 Jun 2009 11:34:31 -0700 (PDT)
Received: from [216.252.122.219] by n77.bullet.mail.sp1.yahoo.com with NNFMP; 30 Jun 2009 18:34:38 -0000
Received: from [67.195.9.83] by t4.bullet.sp1.yahoo.com with NNFMP; 30 Jun 2009 18:34:37 -0000
Received: from [67.195.9.99] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 18:34:37 -0000
Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 30 Jun 2009 18:34:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: [e-mail]
Received: (qmail 31051 invoked by uid 60001); 30 Jun 2009 18:34:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246386877; bh=k1xcF3ERmeTSGeo+0v1Dx1udRBJnErLjw300G0+gVxk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AjAPJV4DT8mwx6tO71balbUnzziwMrroR70QS5682tzRDEDzFdD2TPPNg87d/HBQDgv8IcCRvy2B/1m6EP7SKlLZdLfWbw0Hzfsi4h/StBGMG3KQPQLFEUz0FuuEchQYYf/VI7BqhTAN4l+XixJZ+pQcTr1u+oXj8r6+QwXgwW8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BwgVXZNp9MTNprdozgN5s2OIgR4y+ibnlpuHmgCL+Qr7ODZEFO6nnGO+7Bgefnui2eocnp5934/EVhCkAUzPOXMdMNjvAPQjEb1ZfEkXIud8Uomei0lvV94U1LAYxTIUIGZj6FpW+Y76Y7wCZZEHlPFpcdGOxEt9pkKGTkO+1ww=;
Message-ID: <[e-mail]>
X-YMail-OSG: 3CZe.LMVM1nzGJMqaxvbOovvpwNcU9uz5YgbqIrqUNikJyR_3dEm2S_EnWrZx7eQ9SlJodxSmgCNmhvM6rzewytCNhSlTTulZCbDSJ_RVtjQjWzqPhS74ruLDBXriZrXiiXg52z4.DKqQfUGHnvMr9J18tdJ6fByHtcVIUglj0QDI_EyEY.VXHCUNBAL78GJ1QUetKfWq15egINGI4dCaQCrN7IzShZ.11Rl65Pj.f4TySi1JNs1_iXeHyikTQ8sonz5Bac_xu6gVtGVv0b01syaZMWE_VKblEx93JP61OZB7ZFXXrY3w8InoyGmZMxXmadVcIcDybMc3D8HDICWJKU-
Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Tue, 30 Jun 2009 11:34:37 PDT
X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 30 Jun 2009 11:34:37 -0700 (PDT)
From: Behcet Sarikaya <[e-mail]>
To: MELIA TELEMACO <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Behcet Sarikaya <[e-mail]>
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 18:34:33 -0000

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 <[e-mail]>=0A> To: Sri Gundavelli <sgundave=
@cisco.com>; [e-mail]=0A> Cc: [e-mail]; netlmm@ietf=
..org; [e-mail]=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 [e-mail]  Tue Jun 30 12:54:50 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5061C3A6EC2; Tue, 30 Jun 2009 12:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.489
X-Spam-Level: 
X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmxShcZ3x2JZ; Tue, 30 Jun 2009 12:54:49 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6D5DA3A6BE6; Tue, 30 Jun 2009 12:54:49 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5UJsWJ9011105; Tue, 30 Jun 2009 14:54:55 -0500
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 22:54:47 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 22:54:42 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 30 Jun 2009 21:54:42 +0200
From: <[e-mail]>
To: <[e-mail]>
Date: Tue, 30 Jun 2009 21:54:50 +0200
Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5nwj1SzNo9rf8QsSOsjm/aOljegAHZedG
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Jun 2009 19:54:42.0985 (UTC) FILETIME=[9C65B990:01C9F9BC]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 19:54:50 -0000

Hi Marcelo,


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

> [e-mail] escribi=F3:
>> Hi Hesham,
>>=20
>>=20
>> On 6/30/09 8:48 AM, "ext Hesham Soliman" <[e-mail]> 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 [e-mail]  Tue Jun 30 13:01:48 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B912D3A6EE2; Tue, 30 Jun 2009 13:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.144
X-Spam-Level: 
X-Spam-Status: No, score=-5.144 tagged_above=-999 required=5 tests=[AWL=-1.242, BAYES_00=-2.599, FRT_POSSIBLE=2.697, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyBpbzp7YOft; Tue, 30 Jun 2009 13:01:47 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3410E3A6ECF; Tue, 30 Jun 2009 13:01:47 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5UIhKri015739; Tue, 30 Jun 2009 21:43:23 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 21:43:25 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 30 Jun 2009 21:43:25 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 30 Jun 2009 20:43:24 +0200
From: <[e-mail]>
To: <[e-mail]>
Date: Tue, 30 Jun 2009 20:43:29 +0200
Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5nbCSQK1jbgxhQcau+dkDxfiL1gAFPhXh
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Jun 2009 18:43:25.0182 (UTC) FILETIME=[A6A0C9E0:01C9F9B2]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 20:01:48 -0000

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

> inline...
>=20
> On Tue, Jun 30, 2009 at 4:52 PM, <[e-mail]> 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 [e-mail]  Tue Jun 30 14:09:17 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97F93A6A5E for <[e-mail]>; Tue, 30 Jun 2009 14:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level: 
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfQfS2LbPkQo for <[e-mail]>; Tue, 30 Jun 2009 14:09:17 -0700 (PDT)
Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 538043A6869 for <[e-mail]>; Tue, 30 Jun 2009 14:09:05 -0700 (PDT)
Received: (qmail 73216 invoked by uid 60001); 30 Jun 2009 21:09:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246396164; bh=uUphDDTwRHVpHzdXl3F4/23UKodWKO1hxdvS6yB5gvU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xmqYSPkspMIBYNGs8z3wAlg0OsKXwyjDOilsvIz9upra6xcKfEID77QiFJkwcRHIyfHwWF3GX1xd5HHSPqbYcF6Tf/hMLLIYz6hPuK8d8j6eriTUmowkeRZBAgJPQC41EfMdYDZrgDhCSX8rfd2o6NiUMQw9P8QZq2fteQ3K2yM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TMhra9M/l5v/cCukdFqsq4EezCJDFxb+p79npHavEL6d5Q/1IeYCQ8NCI9mFoPVJLD+2T+X29oyzCnDr7+s/QrhuAV8nlLC/3tNydlcw6PpeBxSLePPZY3dnP49gCRVFwWkwsznO1dKOgg1Fwp3bC+cp9QQzTFdOLyA9YerqJgY=;
Message-ID: <[e-mail]>
X-YMail-OSG: 6fvb4mIVM1kdPQu.BBtJLQgXozE0a28D8yFOOQbg5_jbKgmGHR2b5MZzcFm9Y.3Lj7ccC_ZWQP9FiFQrwenulGK6YoCxxbljGH94bpF_IEjmBeDigtiJ57h7qOall7ARMPuHrilS6QhVAh3cvlwbgOkdUcy_XH_dAnFn5rgu2z_okaT_aqITKi559Dt6QePEuTfIftHhcxtUAHq2IiiLrBKowbCUkIPwwcsmg2.hOlHJUCfIeh0q24TiYPw23Ng1knf6fiG7zqS5_ExB64a6fozJpnJKeoAiedHScxrb3oaAJxnW7eGGlCgy3mvS1vmTs376JXvtXqB8sCzqSSSsytM-
Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 30 Jun 2009 14:09:24 PDT
X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.15
References: <[e-mail]>
Date: Tue, 30 Jun 2009 14:09:24 -0700 (PDT)
From: Behcet Sarikaya <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Behcet Sarikaya <[e-mail]>
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 21:09:18 -0000

Hi Raj,=0A=0A=0A=0A----- Original Message ----=0A> From: "Basavaraj.Patil@n=
okia.com" <[e-mail]>=0A> To: [e-mail]=0A> Cc: ne=
[e-mail]; [e-mail]=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> > [e-mail] 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 [e-mail]  Tue Jun 30 14:19:26 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735F328C442; Tue, 30 Jun 2009 14:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCvSpHjkWrE0; Tue, 30 Jun 2009 14:19:25 -0700 (PDT)
Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id A3FEB28C43E; Tue, 30 Jun 2009 14:19:25 -0700 (PDT)
Received: by pzk36 with SMTP id 36so473092pzk.29 for <multiple recipients>; Tue, 30 Jun 2009 14:19:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SGLuxOM/WYZdELDbDEKv0LvmwFACu7ChMJjWAVZK9Bo=; b=eNMvjd4mI0AE1y4ppSn1FVidKi6O0DWUd+bzSTOaQQqBY6rvqYX/4ZBJehjZ6+oVHQ TARY21A4Cc6gr4ZaBQ98qZk1ag9s85t5F2k3xIZFUD9Ymuh2EUAarJUFBrqkEZPUnE4Z Xm8BSKIEu4a9IY/8h36f4/f/vETky0dvBfKyI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dg1BdECDD/vd/rIcyPtOuEBNdH5chjoc6BQ7qx8D+cLWmBS/F45ye9eFDB9JM2ukzx uoD1cxVR7pWfcxFn7fL5p2iXKQTaVLEgFYMA7fNOSANHOt3JymzahxFvbDpUFmukTXMA JMdPU77VIMBVyUqQxYQEpQUWo3ZGIG1FSaPP4=
MIME-Version: 1.0
Received: by 10.114.202.15 with SMTP id z15mr13855960waf.67.1246396785340;  Tue, 30 Jun 2009 14:19:45 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 30 Jun 2009 14:19:45 -0700
Message-ID: <[e-mail]>
From: Rajeev Koodli <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 21:19:26 -0000

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>

From [e-mail]  Tue Jun 30 14:34:43 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EAD28C4A0 for <[e-mail]>; Tue, 30 Jun 2009 14:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Eup3MsWkw-3 for <[e-mail]>; Tue, 30 Jun 2009 14:34:42 -0700 (PDT)
Received: from mail-px0-f178.google.com (mail-px0-f178.google.com [209.85.216.178]) by core3.amsl.com (Postfix) with ESMTP id F1B0128C472 for <[e-mail]>; Tue, 30 Jun 2009 14:33:52 -0700 (PDT)
Received: by pxi8 with SMTP id 8so508770pxi.29 for <[e-mail]>; Tue, 30 Jun 2009 14:34:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cOtIL8RLY/FHhMRbvzOeRgBkF3l4m3w9/zTjmLtHH4A=; b=Nml2jEix95Xo2tbTyQ53RvX7zSravZVI/ejTRialS+yfL7wIWiTtvnhhv1BGYRXeH6 J3qetDjzojw8glA0d6RlrHu87gxg0U1hxc3UoWP1KeRuR8o2ZtqDw/8vmpyobilIigo1 foWV8yst7pabXs4jL+Gy8F5Py69tNei1MKSAg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XNb1/eNVA2A+fuRDCSTa/UTIYEGGmaIG8gk7j5F/5PWEZjdFeYV0tq48sRcl8viLu1 3eBXFxQfty352SWG0PxIKR0ud4SptZ568JvkYCb7ovqht/xUp41jucvzHIdq5QA1xk6q mFAt1p0c54YtcVp7GkiaM84TT0YgYmwE7BB2Q=
MIME-Version: 1.0
Received: by 10.115.89.18 with SMTP id r18mr13991365wal.111.1246397651176;  Tue, 30 Jun 2009 14:34:11 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 30 Jun 2009 14:34:11 -0700
Message-ID: <[e-mail]>
From: Rajeev Koodli <[e-mail]>
To: marcelo bagnulo braun <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 21:34:43 -0000

(limiting to NetExt only)

On Tue, Jun 30, 2009 at 9:09 AM, marcelo bagnulo
braun<[e-mail]> 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 [e-mail]  Tue Jun 30 17:57:33 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0C53A6E81; Tue, 30 Jun 2009 17:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=-1.015, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThoyTVoVwfTD; Tue, 30 Jun 2009 17:57:31 -0700 (PDT)
Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id DF4E33A680E; Tue, 30 Jun 2009 17:57:29 -0700 (PDT)
Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLnm7-0008Ro-6a; Wed, 01 Jul 2009 10:34:13 +1000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 01 Jul 2009 10:34:01 +1000
From: Hesham Soliman <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3s=
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 00:57:33 -0000

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" <[e-mail]> 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<[e-mail]> 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
>>>>>>>> [e-mail] 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" <[e-mail]> 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: <[e-mail]>
>>>>>>>>>> To:
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> <[e-mail]>; <[e-mail]>; <[e-mail]>;
>>>>>>>=20
>>>>>>> <[e-mail]>; <[e-mail]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>> <[e-mail]>
>>>>>>>=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
>>>>>>> <[e-mail]> 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
>>>>>>> <[e-mail]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> To: <[e-mail]>;
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> <[e-mail]>; <[e-mail]>;
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> <[e-mail]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> Cc: <[e-mail]>;
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> <[e-mail]>
>>>>>>>=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" <[e-mail]> 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" <[e-mail]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> To:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> <[e-mail]>; "mext" <[e-mail]>; <[e-mail]>
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>> Cc:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> <[e-mail]>; "Ralph Droms" <[e-mail]>
>>>>>>>=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
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> netext mailing
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> list
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>> [e-mail]
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> MEXT mailing list
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>> [e-mail]
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> [e-mail]
>>>>>>>=20
>>>>>>>=20
>>>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>>=20
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> netlmm mailing
>>>>>>=20
>>>>>>=20
>>>>>>> list
>>>>>>>=20
>>>>>>>=20
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>>=20
>=20



From [e-mail]  Tue Jun 30 17:59:12 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686523A6861 for <[e-mail]>; Tue, 30 Jun 2009 17:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLxTdLh-eb-f for <[e-mail]>; Tue, 30 Jun 2009 17:59:11 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9BE3E3A680E for <[e-mail]>; Tue, 30 Jun 2009 17:59:09 -0700 (PDT)
Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLoAU-0006k9-5m; Wed, 01 Jul 2009 10:59:22 +1000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 01 Jul 2009 10:59:17 +1000
From: Hesham Soliman <[e-mail]>
To: Rajeev Koodli <[e-mail]>, marcelo bagnulo braun <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtw==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 00:59:12 -0000

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

> (limiting to NetExt only)
> 
> On Tue, Jun 30, 2009 at 9:09 AM, marcelo bagnulo
> braun<[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext



From [e-mail]  Tue Jun 30 18:48:35 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A85D3A69D3 for <[e-mail]>; Tue, 30 Jun 2009 18:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.481
X-Spam-Level: 
X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSEJnr1LwOw0 for <[e-mail]>; Tue, 30 Jun 2009 18:48:34 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 120C83A6877 for <[e-mail]>; Tue, 30 Jun 2009 18:48:34 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 09:48:45 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 09:48:45 +0800 (CST)
Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 09:48:45 +0800 (CST)
Date: Wed, 01 Jul 2009 09:48:44 +0800
From: Qin Wu <[e-mail]>
To: Marco Liebsch <[e-mail]>, Sri Gundavelli <[e-mail]>
Message-id: <00db01c9f9ee$11845e30$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Cc: [e-mail]
Subject: Re: [netext] WG view about problem statement I-D for localized routing
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 01:48:35 -0000

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" <[e-mail]>
To: "Sri Gundavelli" <[e-mail]>
Cc: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext

From [e-mail]  Tue Jun 30 20:44:15 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D263A6B18; Tue, 30 Jun 2009 20:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.456
X-Spam-Level: 
X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9s9WBo1a334; Tue, 30 Jun 2009 20:44:14 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 338713A68BD; Tue, 30 Jun 2009 20:44:13 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n613hleC018317; Wed, 1 Jul 2009 06:44:07 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 1 Jul 2009 06:43:45 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 1 Jul 2009 06:43:40 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 1 Jul 2009 05:43:39 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Date: Wed, 1 Jul 2009 05:43:40 +0200
Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQ==
Message-ID: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Jul 2009 03:43:40.0588 (UTC) FILETIME=[1FB736C0:01C9F9FE]
X-Nokia-AV: Clean
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 03:44:15 -0000

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 [e-mail]  Tue Jun 30 20:59:42 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7F428C49C; Tue, 30 Jun 2009 20:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.866
X-Spam-Level: 
X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69SbkyshUU9e; Tue, 30 Jun 2009 20:59:41 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 0852F3A69FE; Tue, 30 Jun 2009 20:59:11 -0700 (PDT)
Received: from [115.130.26.31] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MLqya-000791-Hd; Wed, 01 Jul 2009 13:59:20 +1000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 01 Jul 2009 13:59:00 +1000
From: Hesham Soliman <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description
Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQAA9SYq
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: [e-mail], [e-mail]
Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 03:59:42 -0000

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm



From [e-mail]  Tue Jun 30 22:21:40 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA063A6A21 for <[e-mail]>; Tue, 30 Jun 2009 22:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.133
X-Spam-Level: 
X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=2.465,  BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjgI0EJd0lWw for <[e-mail]>; Tue, 30 Jun 2009 22:21:39 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0661E3A6901 for <[e-mail]>; Tue, 30 Jun 2009 22:21:39 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 13:21:56 +0800 (CST)
Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 13:21:56 +0800 (CST)
Date: Wed, 01 Jul 2009 13:21:56 +0800
From: Xiangsong Cui <[e-mail]>
To: [e-mail], Jari Arkko <[e-mail]>, Hui Deng <[e-mail]>
Message-id: <030001c9fa0b$da208b80$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Subject: [netext] A consideration for NETEXT2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 05:21:40 -0000

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 [e-mail]  Tue Jun 30 22:24:52 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B143A6B68 for <[e-mail]>; Tue, 30 Jun 2009 22:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.645
X-Spam-Level: 
X-Spam-Status: No, score=0.645 tagged_above=-999 required=5 tests=[AWL=1.140,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cjzs7bPtG3p for <[e-mail]>; Tue, 30 Jun 2009 22:24:52 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id CF3F83A6A21 for <[e-mail]>; Tue, 30 Jun 2009 22:24:51 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 13:25:02 +0800 (CST)
Received: from c00111037 ([10.111.16.64]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 13:25:02 +0800 (CST)
Date: Wed, 01 Jul 2009 13:25:01 +0800
From: Xiangsong Cui <[e-mail]>
To: Xiangsong Cui <[e-mail]>, [e-mail], Jari Arkko <[e-mail]>, Hui Deng <[e-mail]>
Message-id: <030b01c9fa0c$48c28930$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <030001c9fa0b$da208b80$[e-mail]>
Subject: Re: [netext] A consideration for NETEXT2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 05:24:53 -0000

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

Regards/Xiangsong


----- Original Message ----- 
From: "Xiangsong Cui" <[e-mail]>
To: <[e-mail]>; "Jari Arkko" <[e-mail]>; "Hui Deng" 
<[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext 


From [e-mail]  Tue Jun 30 22:54:53 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28DA3A6823 for <[e-mail]>; Tue, 30 Jun 2009 22:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.531
X-Spam-Level: 
X-Spam-Status: No, score=0.531 tagged_above=-999 required=5 tests=[AWL=1.025,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVwle0xT-NbV for <[e-mail]>; Tue, 30 Jun 2009 22:54:52 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C1A0D3A6768 for <[e-mail]>; Tue, 30 Jun 2009 22:54:52 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 13:55:04 +0800 (CST)
Received: from c00111037 ([10.111.16.64]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 01 Jul 2009 13:55:03 +0800 (CST)
Date: Wed, 01 Jul 2009 13:55:03 +0800
From: Xiangsong Cui <[e-mail]>
To: [e-mail], Jari Arkko <[e-mail]>, Hui Deng <[e-mail]>
Message-id: <038e01c9fa10$7a737ee0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Subject: [netext]  A consideration for NETEXT2/update
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 05:54:53 -0000

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 [e-mail]  Tue Jun 30 23:08:03 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABDE3A6CBC for <[e-mail]>; Tue, 30 Jun 2009 23:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.149
X-Spam-Level: 
X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljil0ed8vpI5 for <[e-mail]>; Tue, 30 Jun 2009 23:08:02 -0700 (PDT)
Received: from mail-px0-f178.google.com (mail-px0-f178.google.com [209.85.216.178]) by core3.amsl.com (Postfix) with ESMTP id 6C8923A6977 for <[e-mail]>; Tue, 30 Jun 2009 23:08:02 -0700 (PDT)
Received: by pxi8 with SMTP id 8so789061pxi.29 for <[e-mail]>; Tue, 30 Jun 2009 23:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1XwnD3Kbyn96XHKVcB6eYufQMMJA6v6KwPDbaOXcz3s=; b=Ei1OdZ0/8HrcsNcM0lJ6Ws1ev/kQbTh45OqwSsDi6Rbdwn7us8aJURM81YFptDo77c WE2BSHJ++ZeH+Ox23Yg9YKp0Q8PkVQcZ6BjwTBkgqrjeUh8+Reqm4bhnbkcae8idcns/ v5OWiB2a6vuotP6kIR4moCaN9BY2m6T08M+Go=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y8r11qMskEw18z/rTLSxByO26Jn56poY9Khk2H7awQR66GqxnByvkUgHh1w10fbdet BGxh8dPROq7Lru687iq4Oza8cmw6tlHoEQ560uNB//d49UHSHiu4Zvgng+WCAB5s4t71 6DxLlNdHiDZgORGM6033hCviMelAHW8/+Tb/g=
MIME-Version: 1.0
Received: by 10.115.106.14 with SMTP id i14mr15017863wam.77.1246428501683;  Tue, 30 Jun 2009 23:08:21 -0700 (PDT)
In-Reply-To: <009301c9f9a5$c03b6d90$[e-mail]>
References: <[e-mail]> <[e-mail]> <009301c9f9a5$c03b6d90$[e-mail]>
Date: Wed, 1 Jul 2009 14:08:21 +0800
Message-ID: <[e-mail]>
From: Min Hui <[e-mail]>
To: Frank Xia <[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [netext] Fwd: New Version Notification fordraft-hui-netext-service-flow-identifier-00
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 06:08:03 -0000

Hi, Frank Xia

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

- Hui Min

2009/7/1 Frank Xia <[e-mail]>:
> 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" <[e-mail]>
> To: <[e-mail]>
> 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 <[e-mail]>
>> Date: 2009/6/30
>> Subject: New Version Notification for
>> draft-hui-netext-service-flow-identifier-00
>> To: [e-mail]
>> =B3=AD=CB=CD=A3=BA [e-mail], [e-mail]
>>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>
>