Re: [Hipsec] HIP Registration problem
" Zhangfeng HU " <zfhu2001@163.com> Mon, 08 November 2010 03:04 UTC
Return-Path: <zfhu2001@163.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852CC3A6951 for <hipsec@core3.amsl.com>; Sun, 7 Nov 2010 19:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.61
X-Spam-Level: *
X-Spam-Status: No, score=1.61 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152]
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 SrptgZMbNGjR for <hipsec@core3.amsl.com>; Sun, 7 Nov 2010 19:04:21 -0800 (PST)
Received: from m50-133.163.com (m50-133.163.com [123.125.50.133]) by core3.amsl.com (Postfix) with ESMTP id 92F5D3A672F for <hipsec@ietf.org>; Sun, 7 Nov 2010 19:04:14 -0800 (PST)
Received: from ZFHU-BUTP (unknown [123.116.137.174]) by smtp3 (Coremail) with SMTP id DdGowKBbDIWjaNdMFBv_AA--.288S2; Mon, 08 Nov 2010 11:04:05 +0800 (CST)
Date: Mon, 08 Nov 2010 11:03:58 +0800
From: Zhangfeng HU <zfhu2001@163.com>
To: Miika Komu <mkomu@cs.hut.fi>, hipsec <hipsec@ietf.org>
References: <201011041748233287181@163.com>
Message-ID: <201011081103570007893@163.com>
X-mailer: Foxmail 6, 15, 201, 23 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon350103238280_====="
X-CM-TRANSID: DdGowKBbDIWjaNdMFBv_AA--.288S2
X-Coremail-Antispam: 1Uf129KBjvJXoW7Cr15Zr48tw1UWF48CF47CFg_yoW8KFWkpF W5Kay5KrWkGryrXw18ArWIqr4jvFWxXr4UWas5Grn7CFZ0qw1jvr1kGr1Y9a4UurWfGF1F vF1jg3yrZ3WDJw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jcgAwUUUUU=
X-CM-SenderInfo: p2ik3jqqqrqiywtou0bp/1tbiOQKDiUjh4yUE+AAAsi
Cc: 杜文静 <lxadj@126.com>
Subject: Re: [Hipsec] HIP Registration problem
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 03:04:33 -0000
Hi, yes, that's the truth. Since HIP does provide a mechanism as DAAP of MIP, we are just considering a method of providing fault torlerance for RVS in HIP. For some mobile nodes, the high availability is very important, however the availability of these mobile nodes is mostly decided by the availability of the corresponding RVS who serves them. This RVS fault torlerance can not be easily implemented through updating the entries in DNS, because of the high latency and the cache mechanism used in DNS. 2010-11-08 Zhangfeng HU, PhD candidate of Broadband Network Research Center, State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing, China Email:zfhu2001@gmail.com Tel:86+13811892137 发件人: Miika Komu 发送时间: 2010-11-04 18:47:45 收件人: hipsec 抄送: 主题: Re: [Hipsec] HIP Registration problem On 11/04/2010 11:48 AM, zfhu2001 wrote: > Hi all, > As we know, a mobile node registers its HIP and IP address binding to a > correponding RVS server, but now I'm wondering whether the MN will > register to a new RVS if a mobile node moves to another network and > simultaneously its previous RVS server does not work any more. Or does > HIP provide a mechanisim as DAAP of MIP to detect the serving RVS server > of its home area? > Thanks. > 2010-11-04 Hi, there's no such thing as "home agent" or "home area" in HIP. This is one of the differences to MIP. The same rendezvous server can be reused independently of the current network using the UPDATE procedure. Remember also that the rendezvous server forwards only the first I1 or the first UPDATE packet, so it's still a light-weight operation even though the latency be longer. The rendezvous server does not forward any application payload. Fault-tolerance for RVS may fall into the category of local policies (?). Changing the "current" RVS requires also an update to the DNS records. Another strategy could be just to publish multiple RVS servers in the DNS and send packets to all of them (which ever happens to be alive). _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec ÔÚ´«ÈëµÄÓʼþÖÐδ·¢ÏÖ²¡¶¾¡£ ¼ì²é¹¤¾ß£ºAVG - www.avg.com °æ±¾£º9.0.865 / ²¡¶¾Êý¾Ý¿â£º271.1.1/3235 - ·¢²¼ÈÕÆÚ£º11/03/10 16:36:00
- Re: [Hipsec] HIP Registration problem Andrew McGregor
- Re: [Hipsec] HIP Registration problem Miika Komu
- [Hipsec] HIP Registration problem zfhu2001
- Re: [Hipsec] HIP Registration problem Miika Komu
- Re: [Hipsec] HIP Registration problem Zhangfeng HU