Re: [netext] Access Network Information option for Proxy Mobile IPv6

jouni korhonen <jouni.nospam@gmail.com> Mon, 18 July 2011 12:50 UTC

Return-Path: <jouni.nospam@gmail.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 905F421F8BFD for <netext@ietfa.amsl.com>; Mon, 18 Jul 2011 05:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoS9jIisfxqD for <netext@ietfa.amsl.com>; Mon, 18 Jul 2011 05:50:50 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 713AF21F8BF1 for <netext@ietf.org>; Mon, 18 Jul 2011 05:50:50 -0700 (PDT)
Received: by ewy19 with SMTP id 19so1649427ewy.31 for <netext@ietf.org>; Mon, 18 Jul 2011 05:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rXjws9JWv7dSLWziloMQtrirTi4+OvYoRKw9cxuJMTo=; b=wPcvRPEN2ENAPFuu4Nh6pyCc8ewkSFh1exv8NMGBSpW2hn09uupi0kCTjrNOXMvnVC kQzXgWqWX9ZttfGKKoo4X3I6koxfmZdomtkIlsdsieXlnT9GmG8L73hCZG4X0nNGs/Aq Av0sXwVkMzGDDQ3ZSJqybxDP4nJvIaJcviLFE=
Received: by 10.213.17.2 with SMTP id q2mr132715eba.79.1310993449535; Mon, 18 Jul 2011 05:50:49 -0700 (PDT)
Received: from a88-114-169-32.elisa-laajakaista.fi (a88-114-169-32.elisa-laajakaista.fi [88.114.169.32]) by mx.google.com with ESMTPS id w8sm2119540eef.48.2011.07.18.05.50.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 05:50:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <CA44B65A.1BBB4%basavaraj.patil@nokia.com>
Date: Mon, 18 Jul 2011 15:50:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7391522-4E9E-4587-8F5E-AC6697185032@gmail.com>
References: <CA44B65A.1BBB4%basavaraj.patil@nokia.com>
To: Basavaraj.Patil@nokia.com
X-Mailer: Apple Mail (2.1084)
Cc: netext@ietf.org
Subject: Re: [netext] Access Network Information option for Proxy Mobile IPv6
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: Mon, 18 Jul 2011 12:50:51 -0000

Raj,

On Jul 14, 2011, at 11:34 PM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com> wrote:

> 
> I reviewed this I-D and have a few questions:
> 
> 1. Why does the LMA need to obtain the access network information from the
> MAG? Can it not obtain the same from the AAA server with which it has an
> interface?
> The MN has to authenticate via the AN to the AAA server prior to PMIP6
> being triggered. So I would expect that AAA has the information about the
> access network which could then be obtained by the LMA.

AAA interface is obviously used for access authentication in any larger PMIPv6 deployment. Piggybacking access network information via AAA to LMA is of course possible. However, that would imply LMA has to query AAA or the AAA has to push new policy to the LMA on each handover, which might not be desirable. 

Another point is that a functionality like this should also be made possible without relying on additional support infrastructure, especially when it would require specifying new functionality to AAA protocols, and also specifying how AAA-PMIPv6 interaction is supposed to work. 

> 
> 2. Why does the binding cache at the LMA and/or MAG need to store the
> information carried in the ANI option? I don¹t see how it would be used
> from the document.

One use is management. For example allowing for searches in BC using ANI as an additional search key..  e.g. terminate session for all subscribers @example.com who are attached to SSID "foobar". One could issue such command in LMA management interface, for instance..

> 
> 3. The statement : "In access systems where the mobile access gateway is
>      attached to a micro-mobility domain such as IEEE 802.11 WLAN
>      domain, the DHCP relay agent function in that micro-mobility
>      domain may be configured to add the access network information in
>      DHCP option (82), which is the DHCP Relay Agent Information option
>      [RFC3046].  The mobile access gateway may learn the access network
>      information from this option."
> Seems like a lot of handwaving. Is there a DHCP option for carrying access
> network information?
> If you want this info to be carried in option 82, I would think that there
> is a need to specify this in the DHC WG.

DHCP option 82 is rather loose what you can put into it. Even a VLAN tag could server as ANI in certain cases. It is then deployment specific what goes into these container options.

The other issue then is that option 82 is for DHCPv4. In case of IPv6 we should use something like RFC4946.. or so.

> 
> 4. Can you give me an example of how the LMA would classify traffic or
> treat Mns differently based on the information carried in the ANI option?
> The statement:
> "Policy systems in mobility architectures such as PCC [TS23203] and ANDSF
>   [TS23402] in 3GPP system allow configuration of policy rules with
>   conditions based on the access network information.  For example, the
>   service treatment for the mobile node's traffic may be different when
>   they are attached to a access network owned by the home operator than
>   when owned by a roaming partner.  The service treatment can also be
>   different based on the configured SSID in case of IEEE 802.11 based
>   access networks.
> "
> Is IMO not very realistic.

Shared networks, where the access providers are different from MAG operators, for example.


> 
> 5. And lastly consider the following scenario:
> The LMA knows the identity of the MAG from which it receives BUs. If a MAG
> is associated with a wifi AP then the LMA already knows (or can be
> configured) about the MAGs AN details. And hence there is really no reason
> to send that information in every BU. The LMA is already aware whether a
> MAG is viewed as one that belongs to the home network or a visited
> network. Hence I don¹t see the need for explicit signaling.

See above. Shared networks are one example where a MAG does not equal directly to access provider. LMA is not only interested in the MAG or the subscriber, but also whose access network gets used. The policy might change for the subscriber under the same MAG if the access provide changes.

- Jouni


> 
> -Raj
> 
> 
> On 7/13/11 4:33 PM, "ext Sri Gundavelli" <sgundave@cisco.com> wrote:
> 
>> Please comment on the draft related to carrying Access Network Information
>> to the LMA.
>> 
>> 
>> 7. Access Network Information Option for Proxy Mobile IPv6   10 Mins
>>  I-D: 
>> http://www.ietf.org/id/draft-gundavelli-netext-access-network-option-01.tx
>> t
>>  Presenter: Jouni Korhonen
>> 
>> 
>> 
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
> 
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext