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