Re: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt

<Basavaraj.Patil@nokia.com> Wed, 25 July 2012 19:53 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
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 D1C8521F8753 for <netext@ietfa.amsl.com>; Wed, 25 Jul 2012 12:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.577
X-Spam-Level:
X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 3BU0f2K3UPkW for <netext@ietfa.amsl.com>; Wed, 25 Jul 2012 12:53:02 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3A21F8750 for <netext@ietf.org>; Wed, 25 Jul 2012 12:53:01 -0700 (PDT)
Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6PJquXb032566; Wed, 25 Jul 2012 22:52:56 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jul 2012 22:53:36 +0300
Received: from 008-AM1MPN1-072.mgdnok.nokia.com ([169.254.2.83]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Wed, 25 Jul 2012 21:52:54 +0200
From: Basavaraj.Patil@nokia.com
To: tu.yangwei@zte.com.cn
Thread-Topic: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt
Thread-Index: AQHNaPfsr+OVqfbzHEuWSUjuqpiZjpc5dfQAgACA5oA=
Date: Wed, 25 Jul 2012 19:52:53 +0000
Message-ID: <CC35B7ED.21BEC%basavaraj.patil@nokia.com>
In-Reply-To: <OF769F0E31.5762C27E-ON48257A46.00221758-48257A46.00280544@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [172.19.40.98]
Content-Type: multipart/alternative; boundary="_000_CC35B7ED21BECbasavarajpatilnokiacom_"
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Jul 2012 19:53:36.0115 (UTC) FILETIME=[2D9BEC30:01CD6A9F]
X-Nokia-AV: Clean
Cc: netext@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 19:53:04 -0000

I agree that network elements such as the eNB have fairly relevant information related to the state of the connection associated with an MN. Getting this information over to a MAG is not easily done. So there is a leap of faith here. How do you propose to obtain this information is shared with the MAG?

MN capability could be indicated during the EAP exchange as you suggested. I think Rajeev's I-D discusses such capability.

-Raj

From: "ext tu.yangwei@zte.com.cn<mailto:tu.yangwei@zte.com.cn>" <tu.yangwei@zte.com.cn<mailto:tu.yangwei@zte.com.cn>>
Date: Wednesday, July 25, 2012 2:11 AM
To: Basavaraj Patil <basavaraj.patil@nokia.com<mailto:basavaraj.patil@nokia.com>>
Cc: Netext <netext@ietf.org<mailto:netext@ietf.org>>, "netext-bounces@ietf.org<mailto:netext-bounces@ietf.org>" <netext-bounces@ietf.org<mailto:netext-bounces@ietf.org>>
Subject: re: [netext] Comments on I-D: draft-tu-netext-mn-status-option-02.txt


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<mailto:Basavaraj.Patil@nokia.com>>
发件人:  netext-bounces@ietf.org<mailto:netext-bounces@ietf.org>

2012-07-24 01:23


收件人
        <netext@ietf.org<mailto: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<mailto:netext@ietf.org>
https://www.ietf.org/mailman/listinfo/netext