Re: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt
tu.yangwei@zte.com.cn Wed, 25 July 2012 07:11 UTC
Return-Path: <tu.yangwei@zte.com.cn>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC62711E807F; Wed, 25 Jul 2012 00:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.436
X-Spam-Level:
X-Spam-Status: No, score=-99.436 tagged_above=-999 required=5 tests=[AWL=-1.802, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgibAWaOaMK2; Wed, 25 Jul 2012 00:11:47 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 57D7E21F8493; Wed, 25 Jul 2012 00:11:45 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107233502467742; Wed, 25 Jul 2012 15:01:19 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 46806.5406157678; Wed, 25 Jul 2012 15:11:33 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6P7BV5R099177; Wed, 25 Jul 2012 15:11:31 +0800 (GMT-8) (envelope-from tu.yangwei@zte.com.cn)
In-Reply-To: <CC32F2DC.21AAE%basavaraj.patil@nokia.com>
To: Basavaraj.Patil@nokia.com
MIME-Version: 1.0
X-KeepSent: 769F0E31:5762C27E-48257A46:00221758; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF769F0E31.5762C27E-ON48257A46.00221758-48257A46.00280544@zte.com.cn>
From: tu.yangwei@zte.com.cn
Date: Wed, 25 Jul 2012 15:11:28 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-25 15:11:28, Serialize complete at 2012-07-25 15:11:28
Content-Type: multipart/alternative; boundary="=_alternative 0028054448257A46_="
X-MAIL: mse02.zte.com.cn q6P7BV5R099177
Cc: netext@ietf.org, netext-bounces@ietf.org
Subject: Re: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
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/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jul 2012 07:11:47 -0000
Hi Basavaraj, In my understanding the Idle/Power saving mode information can be retrieved by the MAG from some network elements, such as Paging controller in WiMAX, MME in 3GPP and AP in WLAN. In some of the access networks, the MAG is even combined with these network elements(e.g. PC in WiMAX)。For the radio quality information, there are some mechanismes have already be provided for some access networks, take 3GPP access network for example, the eNB obtains the radio quality of the Mobile node periodically(e.g. to offer some location base services ), and these information can be retrieved by the MAG to make the decision to update low radio quality event to the LMA. For mobile node capability information(LIF, dual IPv4/IPv6 stack and MIP stack), these information can be forwarded from the MN to the MAG before the PMIP signalling (one possibility is using the EAP process). And then the MAG can forward these information to the LMA using the PBU/PBA messages. Thanks for your good comments, and hope this clarifies, BR, Yangwei Tu <Basavaraj.Patil@nokia.com> 发件人: netext-bounces@ietf.org 2012-07-24 01:23 收件人 <netext@ietf.org> 抄送 主题 [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt Hello, The proposal of sending additional information related to the MNs connectivity state is no doubt useful and can help the LMA make a more informed decision about switching flows. However I am trying to understand how the MAG gets such access/interface specific information. Do you expect the access network to provide such information on a per MN basis? There is an implicit assumption that the MAG has access to resource information that is maintained by nodes in the access network. Is that the case? -Raj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext
- [netext] Comments on I-D: draft-tu-netext-mn-stat… Basavaraj.Patil
- Re: [netext] Comments on I-D: draft-tu-netext-mn-… tu.yangwei
- Re: [netext] Comments on I-D: draft-tu-netext-mn-… Basavaraj.Patil