Re: [netext] Question about extending the ANI option

"Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com> Wed, 07 May 2014 16:03 UTC

Return-Path: <rpazhyan@cisco.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24841A0791 for <netext@ietfa.amsl.com>; Wed, 7 May 2014 09:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level:
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7gJw6IDtR-n for <netext@ietfa.amsl.com>; Wed, 7 May 2014 09:03:01 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 864D71A07B2 for <netext@ietf.org>; Wed, 7 May 2014 09:03:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30922; q=dns/txt; s=iport; t=1399478576; x=1400688176; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OGg7Mt7dv2nbvShm0ufbynm8PXaGJt5+KCyoIC3sh5c=; b=avuauVa5jT0pKcex9V6o+cQ79HRJMWEM2CTWmhQLaDA7dO5qY1zFqznf URURgEQorQ+le73O44kmDmHt9i3TovH++sKAIZD9EFWXDhPqslNVhLEU7 CgLzlDhbq9ym6Wyjhq8y7IiqmcSQyWqKXJegLvWCjP8Cq3JbxeiHFAn6V I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwIAOtXalOtJA2M/2dsb2JhbABQCoJCRE9YgmeoHAEBAQUBmg4BGYEAFnSCJQEBAQQjCkELEAIBCA4DBAEBCxYHAwICAh8RFAkIAgQOBQgMiBkDEAGqOZ5uDYZIF4VWhmWBNQYLAR8xBgGCdDaBFQSXRY8MhWGDNIF2OQ
X-IronPort-AV: E=Sophos;i="4.97,1004,1389744000"; d="scan'208,217";a="323035625"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 07 May 2014 16:02:56 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s47G2t5v012353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 16:02:55 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 7 May 2014 11:02:55 -0500
From: "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>
To: Basavaraj Patil <bpatil1@gmail.com>
Thread-Topic: Question about extending the ANI option
Thread-Index: AQHPaf3VpTqmG1NALUKU4SE67RUyxJs1LQpQgABp/ID//68WgA==
Date: Wed, 07 May 2014 16:02:54 +0000
Message-ID: <4ED2E36A22261145861BAB2C24088B4320F7BBB0@xmb-aln-x09.cisco.com>
References: <CAA5F1T2o6=+ZOh20WVOFGwKo8=Pc41SbOkQV3KJph41Dtbe93g@mail.gmail.com> <4ED2E36A22261145861BAB2C24088B4320F7BA96@xmb-aln-x09.cisco.com> <CAA5F1T1OKtyYgLovUipK=4TPp9F+QWamyELPd33yerjPZDbz4A@mail.gmail.com>
In-Reply-To: <CAA5F1T1OKtyYgLovUipK=4TPp9F+QWamyELPd33yerjPZDbz4A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [171.70.242.20]
Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F7BBB0xmbalnx09ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/H6OxLhHumDqIiR6cQvl71hbL30A
Cc: "netext@ietf.org" <netext@ietf.org>, "draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org" <draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org>
Subject: Re: [netext] Question about extending the ANI option
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
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, 07 May 2014 16:03:03 -0000

Question is whether the only source of information for the PGW/LMA about the AP that the MN is attached to via the PMIP6 PBU?


Ø  The technically right answer is that PMIPv6  is *not* the only source of information. As I indicated in earlier email, today’s implementation use Radius 5580 and/or DHCP Option 82 to send location information.

Ø  However, RFC 6757 provided a way to signal geo-location “in-band”. This approach is preferable to some operators. We feel that such deployments will benefit from further enhancement in the form of Civic-location and Group-Id.
From: Basavaraj Patil [mailto:bpatil1@gmail.com]
Sent: Wednesday, May 07, 2014 8:47 AM
To: Rajesh Pazhyannur (rpazhyan)
Cc: draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org; netext@ietf.org
Subject: Re: Question about extending the ANI option

Hi Rajesh,

Thanks for the response.

So the objective is for the LMA to get location information about the MN w.r.t the WiFi AP that it is attached to.
In a 3GPP context, the LMA is part of the PGW. Does the PGW not have access to this information?

The PGW has location information w.r.t the cellular location. And I agree that indoor location w.r.t GPS is an issue.
Question is whether the only source of information for the PGW/LMA about the AP that the MN is attached to via the PMIP6 PBU?

Rgds,
-Raj

On Wed, May 7, 2014 at 9:42 AM, Rajesh Pazhyannur (rpazhyan) <rpazhyan@cisco.com<mailto:rpazhyan@cisco.com>> wrote:
Hi Raj

1. Why is the existing ANI option not sufficient for encoding WLAN specific information?
2. Is the primary goal to provide information regarding location? And as a means for indoor location tracking?




1)      RFC 6757 defines three ANI Types: Network Identifier, Geo-Location, Operator Identifier.  For WLAN deployments, there is a need in many cases (e.g., regulatory,  location based services, location based policy, etc) to identify the AP the user is attached to.  RFC 6757 provides one way to do it via Geo-Location. However, many indoor APs are unlikely to have GPS to provide Geo-location. However, these indoor APs are often provisioned with a Civic location today. RFC 6757 does not provide a way to encapsulate Civic Location. So we are proposing adding a new ANI Type: Civic Location.  We are also defining another ANI Type: Group Identifier. In many existing deployments APs are grouped together with a group-id. The group identifier refers to a coarse location such as a specific coffee-store, book-store, etc.  This form of ANI information is also useful in facilitating many location based applications.

2)      The primary goal is indeed for the MAG to provide location information about the Access Point that the user is attached to. RFC 6757 provided a way to provide GPS. But GPS does not work well in indoor deployments and sometimes is considered expensive for indoor APs. As a result, we are looking for alternatives. The two alternatives proposed: Civic Location, and Group-Identifier.

The I-D does not really explain the key problem to be solved other than saying that 3GPP has a requirement in WLAN deployments. It would be good if you can explain the motivation to the WG so that the WG can decide on adopting and progressing this I-D.


Hopefully the above answers provide some further explanation.  I agree saying that 3GPP has a requirement in not adequate by itself. We cited that as a reference or evidence that there is a real problem in the larger community that needs addressing.

When, I presented this draft in Vancouver last year, there was a fair bit of interest on the floor. If I recall correctly, Rajeev asked for a show of hands and a number of hands went up in support. I am hoping to get the same folks voice their support on the mailing list ☺

Regards

Rajesh

From: Basavaraj Patil [mailto:bpatil1@gmail.com<mailto:bpatil1@gmail.com>]
Sent: Wednesday, May 07, 2014 7:08 AM
To: draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org<mailto:draft-pazhyannur-netext-civic-location-ani-subopt@tools.ietf.org>
Cc: netext@ietf.org<mailto:netext@ietf.org>
Subject: Question about extending the ANI option


Hello authors,

Couple of questions regarding the problem being that this I-D aims to solve:

1. Why is the existing ANI option not sufficient for encoding WLAN specific information?
2. Is the primary goal to provide information regarding location? And as a means for indoor location tracking?

The I-D does not really explain the key problem to be solved other than saying that 3GPP has a requirement in WLAN deployments. It would be good if you can explain the motivation to the WG so that the WG can decide on adopting and progressing this I-D.

-Raj

--
Basavaraj Patil



--
Basavaraj Patil