Subject: [netext] FW: New Version Notification for draft-gundavelli-netext-pmipv6-sipto-option-01.txt

From: Sri Gundavelli <[email-masked]>
Date: Tue, 05 Jul 2011 12:00:35 -0700

Attached is the pointer to the draft on, IP Traffic Offload Selector Option
for Proxy Mobile IPv6

http://www.ietf.org/id/draft-gundavelli-netext-pmipv6-sipto-option-01.txt

This is essentially for defining offload mechanisms at the access network
edge. Comments welcome.

Regards
Sri

------ Forwarded Message
From: <[email-masked]>
Date: Tue, 05 Jul 2011 11:16:21 -0700
To: Sri Gundavelli <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>,
<[email-masked]>, Sri Gundavelli <[email-masked]>
Subject: New Version Notification for
draft-gundavelli-netext-pmipv6-sipto-option-01.txt

A new version of I-D, draft-gundavelli-netext-pmipv6-sipto-option-01.txt has
been successfully submitted by Sri Gundavelli and posted to the IETF
repository.

Filename:  draft-gundavelli-netext-pmipv6-sipto-option
Revision:  01
Title:   IP Traffic Offload Selector Option for Proxy Mobile IPv6
Creation date:  2011-07-05
WG ID:   Individual Submission
Number of pages: 10

Abstract:
   This specification defines a mechanism and a related mobility option
   for carrying IP Offload traffic selectors between a mobile access
   gateway and a local mobility anchor in a Proxy Mobile IPv6 domain.
   Based on the received offload flow selectors from the local mobility
   anchor, a mobile access gateway can enable offload traffic rule on
   the selected IP flows.

The IETF Secretariat

------ End of Forwarded Message

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Jul 2011 14:33:36 -0700

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.txt
   Presenter: Jouni Korhonen

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 13 Jul 2011 16:23:59 -0700

Sri

I reviewed this document. 

Why do you exchange this static information dynamically? 
If MAG and LMA are located in the Proxy Mobile IPv6 Domain,
can't LMA know the access network information from the MAG's IP address?!

The spec. is very simple and straightforward.
There are minor comments.

- better to define the access network information in 2.2?
- In section3, 
"in  DHCP option (82), which is the DHCP Relay Agent Information option  [RFC3046]."
"in  DHCP option (code: 82), which is the DHCP Relay Agent Information option  [RFC3046]."
- In section4,
"Realm names are required to be unique, and are piggybacked on the administration of the DNS  namespace."
What does the latter sentence mean, "piggybacked on the administration of the DNS  namespace"? 
- In section 5, 
"creates a two new name spaces" -> "creates two new name spaces"

regards,
ryuji

On 2011/07/13, at 14:33, Sri Gundavelli wrote:

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Jul 2011 23:37:01 -0700

Hi Ryuji,

Thanks for the quick review. Appreciate it.

Yes, static keying of the information is always an option. But, that will be
a provisioning nightmare and secondly the information may be multi-valued
for a given MAG ID and may not be 1:1. We fundamentally need a container for
carrying access network information, that may be specific to the SSID,
Operator Id ... of the AP ..., having this generic container will greatly
help deployments. In one of our deployments, we have a requirement to carry
the Geo-location of one of the AP's out of the several attached to the MAG.
Hence, we need this simple option.

I will make the below suggested changes.

Regards
Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 14 Jul 2011 12:08:56 -0700

Hi Sri,

> carrying access network information, that may be specific to the SSID,

ok

> Hence, we need this simple option.

For geo-location, do you assume lat-long? Don't you need to specify the format of  information?

ryuji

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Jul 2011 13:10:38 -0700

Hi Ryuji:

> For geo-location, do you assume lat-long? Don't you need to specify the format

Yes, we need to carry that information element. We need to define a sub-type
for this.

Regards
Sri

---

From: <[email-masked]>
Date: Thu, 14 Jul 2011 20:34:02 +0000

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.

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.

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.

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.

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.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Jul 2011 22:42:51 +0200

Le 14/07/2011 22:10, Sri Gundavelli a écrit :
> Hi Ryuji:
>
>
>
> On 7/14/11 12:08 PM, "Ryuji Wakikawa"<[email-masked]>
> wrote:
>
>> Hi Sri,
>>
>>
>>> Yes, static keying of the information is always an option. But,
>>> that will be a provisioning nightmare and secondly the
>>> information may be multi-valued for a given MAG ID and may not be
>>> 1:1. We fundamentally need a container for carrying access
>>> network information, that may be specific to the SSID,
>>
>> ok
>>
>>> Operator Id ... of the AP ..., having this generic container will
>>> greatly help deployments. In one of our deployments, we have a
>>> requirement to carry the Geo-location of one of the AP's out of
>>> the several attached to the MAG. Hence, we need this simple
>>> option.
>>
> Yes, we need to carry that information element. We need to define a
> sub-type for this.

Defining geo-localization in a more universal manner (IETF) may or may
not be straightforward.  It is true that "GPS" is in widespread use in
certain regions, and simple lat-long sound acceptable by most.  But.

Do other IETF documents define such a representation for lat-long?
Maybe that could be re-used here.

Does one consider altitude as well?  This may prove useful when two APs
of same MAG serve clients at different height.

Does one consider encoding the precision of measurement (GPS talks HDOP, 
PDOP, etc.)  This is important when making decisions about where objects 
really are.

Does one assume WGS-84?  Others exist.

Would this work with devices not equipped with GPS, but with inertial
platforms (i.e. wrist watches).

Etc.

Alex

>
> Regards Sri
>
>
>
> _______________________________________________ netext mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/netext
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Jul 2011 09:06:15 -0700 (PDT)

> is a need to specify this in the DHC  WG.

BTW Option 82 is DHCPv4 option, RFC 3046 defines DHCPv4 Relay Agent Options.

> Is IMO not very realistic.

Way back 2008, we had a draft which is relevant on this:
http://tools.ietf.org/id/draft-xia-netlmm-mpls-tunnel-00.txt

and in 2009 this one:

http://tools.ietf.org/id/draft-xia-netext-qos-00.txt

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 17 Jul 2011 11:13:11 -0700

Hi Alex,

Thanks for the review. Please see inline.

> Maybe that could be re-used here.

This is a good question. I assumed the SIP guys must have defined the
semantics for the Geo-location info, as they carry in the SIP headers. I
will check with the SIP guys.

> of same MAG serve clients at different height.

I do not know the semantics of a GPS information element. I assume that is
very standard and I'm not sure what all is included in that. Even in the
digital pictures, the camera embeds the Geo info in the meta-deta, we need
to see that meta data. But, there must surely be very standard option
format.

> platforms (i.e. wrist watches).

Ok. For defining the sub-type, we need to use the data format that has
already been defined. Will check with some experts.

Thanks for the review.

Regards
Sri

---

From: jouni korhonen <[email-masked]>
Date: Mon, 18 Jul 2011 15:50:45 +0300

Raj,

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

> information carried in the ANI option? I don¹t see how it would be used

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

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

> Is IMO not very realistic.

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

> 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

---

From: jouni korhonen <[email-masked]>
Date: Wed, 27 Jul 2011 15:09:49 +0300

Ryuji,

> What does the latter sentence mean, "piggybacked on the administration of the DNS  namespace"? 

That basically means realms are actually domain names that also exist in DNS system. The wording is rather direct quote from Diameter base spec, which has the same requirement for realms. 

- Jouni