NETEXT WG R. Pazhyannur
Internet-Draft S. Speicher
Intended status: Standards Track S. Gundavelli
Expires: August 18, 2014 Cisco
J. Korhonen
Broadcom
February 14, 2014
Civic Location ANI Suboption for PMIPv6
draft-pazhyannur-netext-civic-location-ani-subopt-01.txt
Abstract
This specification defines extensions to Access Network Identifier
mobility option for carrying the Civic Location information and MAG
Group Identifer from the mobile access gateway to the local mobility
anchor. This specificaton also defines a new ANI update timer sub-
option that enables a MAG to communicate when the MAG will update the
ANI information. This helps the LMA determine the freshness of the
ANI options.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Pazhyannur, et al. Expires August 18, 2014 [Page 1]
Internet-Draft Extensions to ANI February 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Civic-Location Sub-Option . . . . . . . . . . . . . . . . . . 4
4. MAG Group-Id Sub-Option . . . . . . . . . . . . . . . . . . . 5
5. ANI Update-Timer Sub-Option . . . . . . . . . . . . . . . . . 6
6. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Pazhyannur, et al. Expires August 18, 2014 [Page 2]
Internet-Draft Extensions to ANI February 2014
1. Introduction
In many deployments, the LMA needs to be aware of various identifiers
of client's access network to ensure appropriate policies are
implemented. For example, the LMA may provide access network
identifiers to location based applications. [RFC6757] defined new
mobility options to enable a MAG to provide Access Network
Information (ANI). In Wi-Fi systems the ANI mobility option may
carry the identifier of the Access Point (for instance the BSSID, AP-
Name, or the geo-spatial coordinates of the Acess Point). When a
client associates with an Access Point, the MAG (corresponding to the
AP) may send the ANI (like SSID, BSSID, Geo-location) to the LMA.
In many deployments (especially indoor AP deployments), it is
difficult to provide Geo-spatial coordinates of APs. However, for
many location based applications the civic location is sufficient.
To provide civic location information, this document defines a new
ANI sub-option within the ANI mobilty option defined in [RFC6757].
[RFC4776] provides further motivations on usage of civic information
in providing human-usable information, particularly within buildings.
We also address an aspect related to ANI, frequency of ANI Update.
In other words, how often does the MAG update the ANI. To understand
this better, it is instructive to look at this closely in two Wi-Fi
deployment scenarios:
MAG is co-located with the Access Point: In this scenario, whenever
the Wi-Fi client hands over from a source Access Point to a target
Access Point there is new Proxy Binding Update (PBU) sent by the MAG
on the target AP. If the PBU contains ANI information related to
BSSID, or Geo-Lcation then those will correspondng to that of the
target Access Point. As a result, the LMA has the latest ANI.
MAG is not co-located with Access Point: An example of such a
deployment is when the MAG may be co-located with a Wireless LAN
Controller (WLC) also known as an Access Controller (as defined in
[RFC5415] and [RFC5416]) or it may be co-located with an Access
Router. Additionally in these deployments, the Mobile Node mobility
between Access Points may be handled by acesss network (layer 2)
specific methods and may not require any PMIPv6 signaling.
Specifically, there may be no need for MAG to trigger a PBU when a
client hands over from one AP another AP. As a result, in these
cases it is possible (depending on which ANI sub options were sent by
the MAG), the LMA may have "stale" acess network identifers. For
example, the LMA may contain the BSSID or Geo-Location of a
previously associated AP and not the currently associated AP.
If the network deployment and applications that use ANI require the
Pazhyannur, et al. Expires August 18, 2014 [Page 3]
Internet-Draft Extensions to ANI February 2014
LMA to have the current ANI, then one way of solving this problem is
to require the MAG to send a fresh PBU (with updated ANI) whenever it
is aware of an ANI change. This is an acceptable solution when the
MAG is aggregating a small number (say between 1 and 4) APs.
Consider a Wi-Fi deployment in stadium or in large exposition center
or a large enterprise. The number of APs in such venues could be
multiple hundred APs. This combined with a large number of mobility
events may create a large number of ANI updates (sent in PBUs). In
this specification, we propose a way to mechanism to specify the ANI
update interval based on the deployment needs as well as the
capability of the MAG and LMA.
This specification enables extensions to Access Network Identifier
mobility option for carrying Location information of the mobile node
from the mobile access gateway to the local mobility anchor. This
documents defines a new ANI sub-option that enables a MAG to
communicate how often the MAG will update the ANI information. This
helps the LMA determine whether the ANI informaiton is fresh or
stale.
2. Conventions and Terminology
2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in [RFC5213] and [RFC5844].
3. Civic-Location Sub-Option
The Civic-Location is a mobility sub-option carried in the Access
Network Identifier option defined in [RFC6757]. This sub-option
carries the Civic Location information of the mobile node as known to
the MAG. The format of this option is defined below.
Pazhyannur, et al. Expires August 18, 2014 [Page 4]
Internet-Draft Extensions to ANI February 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANI Type=IANA | ANI Length | Civic Location (PIDF Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Civic Location (PIDF Format) continued ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Network-Identifier Sub-option
ANI Type: <IANA-1>
ANI Length: Total length of this sub option in octets, excluding the
ANI Type and ANI length fields.
Civic Location: This format is as specified in the Presence
Information Data Format Location Object [RFC5139] with the
additional constraint that the length shall not exceed 255 bytes.
System architectures may choose to identify the exact PIDF XML
elements to be carried in the PIDF object.
4. MAG Group-Id Sub-Option
In many deployments, MAGs may be co-located with APs. In such cases,
APs may be clustered in a "group". There is a common policy (for
QoS, charging, etc) for all MNs connected to the same group.
Further, in some cases there is a common policy (for QoS, DPI, etc)
between MAGs and LMA in the same group. The group identifier may
also serve a proxy for coarse location identification for MNs
connected to the group of MAGs. These considerations motivate
introduction of a group identifier to a MAG.
The MAG Group Identifier is a mobility sub-option carried in the
Access Network Identifier option defined in [RFC6757]. The MAG Group
Identifier identifies the group affiliation of the mobile access
gateway within that Proxy Mobile IPv6 domain.
When the MAG is configured with a group identifier, the MAG may send
its group-id in the PBU. The usage of the group identifier by the
LMA is left to implementation. The format of this option is defined
below.
Pazhyannur, et al. Expires August 18, 2014 [Page 5]
Internet-Draft Extensions to ANI February 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANI Type=IANA | ANI Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MAG Group-Identifier Sub-option
ANI Type: <IANA-2>
ANI Length: Total length of this sub option in octets, excluding the
ANI Type and ANI length fields. The value is always 6.
Reserved: MUST be set to zero when sending and ignored when
received.
Group Identifier:
5. ANI Update-Timer Sub-Option
The ANI Update Timer is a mobility sub-option carried in the ANI
option defined in [RFC6757]. The MAG sends a PBU with an updated
value of ANI mobility options when the update-timer expires.
Specifically, if the update-timer expires and the ANI values are
identical to the last transmitted ANI values, then a PBU shall not be
transmitted.
When the Update-Timer Sub option is carried in a PBU, it is
considered as a proposed value for the update-timer. When the
Update-Timer sub option is carried in a PBA, then it is considered as
an accepted value for the update-timer. If the MAG does not receive
a update-timer sub option in PBA (in response to sending the sub-
option in the PBU), then it the MAG behavior with respect to updating
the ANI values is left to implementation choices.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANI Type=IANA | ANI Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update-Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pazhyannur, et al. Expires August 18, 2014 [Page 6]
Internet-Draft Extensions to ANI February 2014
Figure 3: Network-Identifier Sub-option
ANI Type: <IANA-3>
ANI Length: Total length of this sub option in octets, excluding the
ANI Type and ANI length fields is always 6.
Reserved: MUST be set to zero when sending and ignored when
received.
Update-Timer: Update-Timer is a 16 bit unsigned integer. It
indicates the time in seconds before the MAG sends an update value
of ANI mobility options. A value of 0 indicates that the MAG will
send an updated ANI mobility option as soon as it discovers a
change in ANI values.
6. Usage Example
Consider a case where the MAG is not co-located with an AP.
o MN Attaches to Wi-Fi Network
o MAG registers with the LMA and provides an Update-Timer ANI sub
option. The LMA responds with a value of Update-Timer in the PBA.
o Application request LMA for ANI Information
o if ANI information is current (for example, the MAG had sent the
Update-Timer value of 0) then LMA provides ANI information
o if ANI is not current, LMA sends Update Notification with ANI-
Update-Requied Notiiication reason
o MAG sends a re-registration with updated ANI sub options
Pazhyannur, et al. Expires August 18, 2014 [Page 7]
Internet-Draft Extensions to ANI February 2014
+--+ +--------+ +------+ +------+
|MN| |AP/WLC | | LMA | |App |
+--+ | MAG | | | |Server|
| +--------+ +------+ +------+
| | | |
| | | |
(1)|-ATTACH--->| | |
(2)| |PBU[Civic Loc, Update-Timer]--->| |
| | | |
(3)| |<-----PBA[Update-Timer]---------| |
| | | |
(4)| | |<-Get Loc----|
| | | |
| | check ANI |
| | Timer |
(5)| |<-Update Notification-----------| |
| | (ANI-PARAMS-Requested) | |
| | | |
(6)| |---Update Notification Ack----->| |
(7)| |PBU[Civic Loc, Update-Timer]--->| |
(8)| |<-----PBA[Update-Timer]---------| |
(9)| | |---Location->|
Figure 4: Usage Example
Note the the protocol for retrieving location from the LMA is outside
the scope of this document.
7. IANA Considerations
This document requires the following IANA action.
o Action-1: This specification defines a new Access Network
Identifier sub-option called Civic Location Sub-option. This
mobility sub-option is described in Section 3 and this sub-option
can be carried in Access Network Identifier mobility option. The
type value <IANA-1> for this sub-option needs to be allocated from
the registry "Access Network Information (ANI) Sub-Option Type
Values". RFC Editor: Please replace <IANA-1> in Section 3 with
the assigned value, and update this section accordingly.
o Action-2: This specification defines a new Access Network
Identifier sub-option called MAG Group Identifier Sub-option.
This mobility sub-option is described in Section 4 and this sub-
option can be carried in Access Network Identifier mobility
option. The type value <IANA-2> for this sub-option needs to be
allocated from the registry "Access Network Information (ANI) Sub-
Pazhyannur, et al. Expires August 18, 2014 [Page 8]
Internet-Draft Extensions to ANI February 2014
Option Type Values". RFC Editor: Please replace <IANA-2> in
Section 4 with the assigned value, and update this section
accordingly.
o Action-3: This specification defines a new Access Network
Identifier sub-option called ANI-Update-Frequency Sub-option.
This mobility sub-option is described in Section 5 and this sub-
option can be carried in Access Network Identifier mobility
option. The type value <IANA-3> for this sub-option needs to be
allocated from the registry "Access Network Information (ANI) Sub-
Option Type Values". RFC Editor: Please replace <IANA-3> in
Section 5 with the assigned value, and update this section
accordingly.
8. Security Considerations
The Civic Location and the ANI-Update-Frequency sub-Options defined
in this specification are to be carried in the Access Network
Identifier option defined in [RFC6757]. This sub-option is carried
in Proxy Binding Update and Proxy Binding Acknowledgement messages.
This sub-option is carried like any other Access Network Identifier
sub-option as defined in [RFC6757]. Therefore, it inherits from
[RFC5213] and [RFC6757], its security guidelines and does not require
any additional security considerations.
The Civic Location sub-option carried in the Access Network
Information option exposes the geo-location of the network to which
the mobile node is attached. This information is considered to be
very sensitive, so care must be taken to secure the Proxy Mobile IPv6
signaling messages when carrying this sub-option. The base Proxy
Mobile IPv6 specification [RFC5213] specifies the use of IPsec for
securing the signaling messages, and those mechanisms can be enabled
for protecting this information. Operators can potentially apply
IPsec Encapsulating Security Payload (ESP) with confidentiality and
integrity protection for protecting the location information.
Access-network-specific information elements that the mobile access
gateway sends may have been dynamically learned over DHCP or using
other protocols. If proper security mechanisms are not in place, the
exchanged information may be potentially compromised with the mobile
access gateway sending incorrect access network parameters to the
local mobility anchor. This situation may potentially result in
incorrect service policy enforcement at the local mobility anchor and
impact to other services that depend on this access network
information. This threat can be mitigated by ensuring the
communication path between the mobile access gateway and the access
points is properly secured by the use of IPsec, Transport Layer
Pazhyannur, et al. Expires August 18, 2014 [Page 9]
Internet-Draft Extensions to ANI February 2014
Security (TLS), or other security protocols.
9. Acknowledgements
TBD
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC6757] Gundavelli, S., Korhonen, J., Grayson, M., Leung, K., and
R. Pazhyannur, "Access Network Identifier (ANI) Option for
Proxy Mobile IPv6", RFC 6757, October 2012.
10.2. Informative References
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and
Provisioning of Wireless Access Points (CAPWAP) Protocol
Binding for IEEE 802.11", RFC 5416, March 2009.
Pazhyannur, et al. Expires August 18, 2014 [Page 10]
Internet-Draft Extensions to ANI February 2014
Authors' Addresses
Rajesh S. Pazhyannur
Cisco
170 West Tasman Drive
San Jose, CA 95134,
USA
Email: rpazhyan@cisco.com
Sebastian Speicher
Cisco
Richtistrasse 7
Wallisellen, Zurich, 8304
Switzerland
Email: sespeich@cisco.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Jouni Korhonen
Broadcom
Porkkalankatu 24
Helsinki FIN-00180
Finland
Email: jouni.nospam@gmail.com
Pazhyannur, et al. Expires August 18, 2014 [Page 11]