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

[Sri Gundavelli <[e-mail]>]

Hi Raj:

Thanks for the review, please see inline.




On 7/14/11 1:34 PM, "[e-mail]" <[e-mail]>
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.
> 

Not really. Sure, the AAA interface would be used for the access
authentication. However, the access network details are typically not
present in the AAA. If we look at a very simple access network architecture
below, the MAG is hosted on an aggregation device, which is talking to
various access network links.









> 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.

I agree, we need to add more details. The access network parameters such as
SSID, Geo-Location ..etc, if present in the session state, the LMA can apply
the needed policies. One example I can think is how some folks wanted to
enable session security to a MIPv6 session based on the access network to
which the MN is attached, same way here, the MAG can present all the access
network parameters as part of the signaling. Another example is the ANDSF
policies have already evolved to use access network parameters in applying
policies, except the anchor in the home network has no clue on the access
network details, Finally, if we look at PWLAN deployments today, based on
L2TP or other approaches, these access network parameters are used for
handling many deployment specific requirements, enterprise support or other
use-cases. The mechanism here is just about carrying the parameters and
making them available to the anchor.

Mark Grayson had bunch of other use-cases, he added few cases ..., he can
comment...


> 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.

Hmm... No handwaiving

DHCP option 82 is used for carrying VLAN and other information tags. Many
wireless/wireline architectures use this in different ways.
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gdhcpopt.html
#wp1027173

The ³handwaiving² if any, was specifically not to dictate any specific
approach. Typically, between the AP/radio and the access gateway/MAG there
is either a tunnel, or the packets are carried over a specific 802.1q tag
and the MAG can use that detect the access network and other parameters
associated to that link.



> 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.
> "

A simple forwarding decision can be based on the ANI/SSID. It could be
routed toward a enterprise gateway, based on the access network.
Use of Geo-Location for supporting some regulatory requirements
Applying access controls based on the location


> 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.

There is no 1:1 mapping between the parameter value set in the ANI option to
a MAG identity. If we look at the PWLAN deployments, the aggregation device
is practically terminating 1000¹s AP¹s, in this case its a MAG talking to
PGW over 3GPP S2a PMIPv6 interface and on the ingress side peering with
1000¹s AP¹s over a IP tunnel or by the use of .1q tags. The MAG inserting
specific ANI data set is based on the input interface on which it received a
MN trigger, this deployment model is reflective of today¹s dominant WLAN
architectures. These access architectures could be based on
CAPWAP/LWAP/L2TP/PMIPv6/L2-Aggregation ..., so the MAG can provide the ANI
option set based on the input interface.







The option in the draft is for enabling the linking of existing deployed
access network architectures, with EPC integration, using PMIPv6.


Again, thanks for the review. Will revise the draft.



Regards
Sri

 





























d