Re: [Int-area] AD review of draft-zhu-mobility-survey

Alberto García <alberto@it.uc3m.es> Thu, 10 February 2011 12:08 UTC

Return-Path: <alberto@it.uc3m.es>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9603A6973 for <int-area@core3.amsl.com>; Thu, 10 Feb 2011 04:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 lgbjQW+NrAxK for <int-area@core3.amsl.com>; Thu, 10 Feb 2011 04:08:39 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0705C3A6921 for <int-area@ietf.org>; Thu, 10 Feb 2011 04:08:37 -0800 (PST)
X-uc3m-safe: yes
Received: from BOMBO (unknown [163.117.139.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id A7ED96C308F; Thu, 10 Feb 2011 13:08:47 +0100 (CET)
From: Alberto García <alberto@it.uc3m.es>
To: 'Ryuji Wakikawa' <ryuji.wakikawa@gmail.com>, 'Jari Arkko' <jari.arkko@piuha.net>
References: <4D528D3C.3000606@piuha.net> <6B8BD18E-BCE7-4DFE-901C-FD09F77E0B64@gmail.com>
In-Reply-To: <6B8BD18E-BCE7-4DFE-901C-FD09F77E0B64@gmail.com>
Date: Thu, 10 Feb 2011 13:08:50 +0100
Message-ID: <003e01cbc91b$46eda330$d4c8e990$@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF8Dx4XWSZd3FGGXaAWJgagn0hCJQIniOxQlIjKD2A=
Content-Language: es
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17946.003
Cc: draft-zhu-mobility-survey@tools.ietf.org, 'Internet Area' <int-area@ietf.org>, 'Lixia Zhang' <lixia@CS.UCLA.EDU>
Subject: Re: [Int-area] AD review of draft-zhu-mobility-survey
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Feb 2011 12:08:40 -0000

Hi Ryuji,

|  > It might be valuable to describe the limited mobility support in
transport
|  layer solutions (SCTP and MP-TCP) as well. That is, they allow a single
|  connection to stay up even as you move around, but do not by themselves
|  allow simultaneous mobility of both parties. What about SHIM6?
|  >
|  > I would talk about GTP (a network-based mobility protocol) as well.
|  >
|  > What about mentioning application layer mobility designs (e.g., start
from
|  the paper by Henning on SIP mobility)?
|  >
|  > It might be useful to have at least some pointers to various
optimization
|  efforts that the community has spent quite a lot of time on. It felt that
FMIP
|  was the only one that was mentioned in addition to the general idea of
|  route optimization in Mobile IP.  Look for pointers from the MIPSHOP WG's
|  page, RFC 4651, etc.
|  
|  OK, I mostly agree with you.
|  
|  Do we need SHIM6 here? Although SHIM6 solve ID and locator things for
|  multihoming purpose, it has potential to solve mobility issue, too.
|  I remembered there were some mobility discussion, but I'm not sure there
|  is mobility related extension to SHIM6.
|  

Regarding to Shim6, it allows a node which has changed its location to
inform the corresponding node about its new address(es). For this, the
moving node must have a CGA configured, and the identifier used for
initiating the Shim6 context (the ULID of the node) must be this CGA. Since
there is no Rendezvous server defined for the Shim6 suite, 'simultaneous'
movement of the communicating parties is not supported. As RFC 5533 states,
Shim6 does not attempt to solve the problems of host mobility, although it
may be useful in some specific scenarios.

Besides, there are some guidelines (draft-ietf-shim6-applicability-08) on
how to combine Shim6 and MIPv6 to allow mobile nodes benefiting from
multihoming when the Multihomed Home Network is multihomed and the MN has
multiple HoAs, so that Shim6 can be used between MN and CN; and when Shim6
can be used between MN and HA. A previous draft (draft-bagnulo-shim6-mip-00)
went in more detail on this topic.
Apart from this, there are no mobility extensions to Shim6.

Regards,
Alberto