NETEXT WG R. Pazhyannur
Internet-Draft S. Speicher
Intended status: Standards Track S. Gundavelli
Expires: April 25, 2014 Cisco
J. Korhonen
Broadcom
October 22, 2013
Civic Location ANI Suboption for PMIPv6
draft-pazhyannur-netext-civic-location-ani-subopt-00.txt
Abstract
This specification extensions to Access Network Identifier mobility
option for carrying the Civic Location information of the mobile node
from the mobile access gateway to the local mobility anchor. This
specificaton also 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 the freshness of the ANI.
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 April 25, 2014.
Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect
Pazhyannur, et al. Expires April 25, 2014 [Page 1]
Internet-Draft Civic Location ANI Suboption October 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Civic Location Sub-Option . . . . . . . . . . . . . . . . . . 4
4. ANI Update-Frequency Sub-Option . . . . . . . . . . . . . . . 5
5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In many deployments, the LMA needs to be aware of various identidiers
of client's access network to ensure appropriate policies are
implemented or in some cases provide access network identifiers to
other systems like location based applications. RFC 6757 defined new
mobility options to enable a MAG to provide such information. When
this used in Wi-Fi systems the Access Network Identifer could carry
the identifier of the Access Point (for instance the BSSID or the
geo-spatial coordinates of the Acess Point). For example, when a
client associates with an Access Point in a Wi-Fi hotspot, the MAG
would send the ANI information (like SSID, BSSID, geo-location) to
the LMA. In many indoor AP deployments, it may be difficult to
provide Geo-spatial coordinates of APs but for many location based
applications, the civic location may be sufficient. [RFC4776]
provides further motivations on usage of civic information in
providing human-usable information, particularly within buildings.
To provide civic location information, this document defines a new
ANI sub-option.
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:
Pazhyannur, et al. Expires April 25, 2014 [Page 2]
Internet-Draft Civic Location ANI Suboption October 2013
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. This PBU would contain ANI information
correspondng to the target Access Point. As a result, the LMA has
the current ANI. For example, if the MAG sent BSSID or geo-location,
then the LMA would have the latest information about the client's
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 Access Point to another. 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.
This is because, the LMA will only have the ANI information at the
time of the PBU, but the ANI may have changed due to handovers within
the access network (which are not visible to LMA).
If the network deployment and applications that use ANI require the
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 would be 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. In these deployments the mobility within the
venue is not handled by PMIPv6 but handled by some layer 2 mechanism,
while the mobility across venues is provided by PMIPv6. If MAG sends
PBU with every intra-venue handover, this may result in a large
number of PMIPv6 transactions on the transactions in the MAG and LMA.
Moreover, since mobility inside the LMA may not be handled by PMIPv6,
these transactions are being sent only to update the ANI. This
document describes a method to solve this problem.
This specification extensions to Access Network Identifier mobility
option for carrying the Civic 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.
Pazhyannur, et al. Expires April 25, 2014 [Page 3]
Internet-Draft Civic Location ANI Suboption October 2013
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 [RFC6463]. This sub-option
carries the Civic Location information of the mobile node as known to
the mobile access gateway. There MUST be no more than a single
instance of this specific sub-option in any Access Network Identifier
option. The format of this option is defined below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Civic Location (PIDF Format) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Network-Identifier Sub-option
ANI Type: It MUST be set to value of (1), indicating that its a
Network-Identifier sub-option
ANI Length: Total length of this sub option in octets, excluding the
ANI Type and ANI length fields. The value can be in the range of
5 to 32 octets.
Reserved: MUST be set to zero when sending and ignored when
received.
Civic Location: This format is as specified in the Presence
Information Data Format Location Object [RFC5139].
Pazhyannur, et al. Expires April 25, 2014 [Page 4]
Internet-Draft Civic Location ANI Suboption October 2013
4. ANI Update-Frequency Sub-Option
The ANI Update Frequency is a mobility sub-option carried in the
Access Network Identifier option defined in [RFC6463]. This option
gives a hint regarding for how long the ANI information should be
considered current. This applies to all the ANI sub-options present
in the ANI option. (If there is a need to specify different Time-To-
Live values for different ANI sub options, then the MAG may provide
multiple ANI options each with its corresponding Time-To-Live value.
This may be motivated by the fact that certain ANI sub-options such
as Network Identifier sub-option may have longer Time-To-Live values
compared to Geo-Location sub-otion. The data type of this field is a
string and the content is expressed in the 64-bit Network Time
Protocol (NTP) timestamp format [RFC1305].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Network-Identifier Sub-option
ANI Type: It MUST be set to value of (1), indicating that its a
Network-Identifier sub-option
ANI Length: Total length of this sub option in octets, excluding the
ANI Type and ANI length fields. The value can be in the range of
5 to 32 octets.
Reserved: MUST be set to zero when sending and ignored when
received.
TTL: TTL Format - TBD
5. 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 a Time-to-Live ANI sub
option
Pazhyannur, et al. Expires April 25, 2014 [Page 5]
Internet-Draft Civic Location ANI Suboption October 2013
o Application request LMA for ANI Information
o if ANI information is current 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
+--+ +--------+ +------+ +------+
|MN| |AP/WLC | | LMA | |App |
+--+ | MAG | | | |Server|
| +--------+ +------+ +------+
| | | |
| | | |
(1)|-ATTACH--->| | |
(2)| |PBU[Civic Loc, Update-Freq]---->| |
| | | |
(3)| |<-----PBA-----------------------| |
| | | |
(4)| | |<-Get Location-|
| | | |
| | check ANI |
| | TTL |
(5)| |<-Update Notification-----------| |
| | (ANI-PARAMS-Requested) | |
| | | |
(6)| |---Update Notification Ack----->| |
(7)| |PBU[Civic Loc, Update-Freq]---->| |
(8)| |<-----PBA-----------------------| |
(9)| | |---Location--->|
Figure 3: Usage Example
Note the the protocol for retrieving location from the LMA is outside
the scope of this document.
6. IANA Considerations
This document requires the following IANA action.
Pazhyannur, et al. Expires April 25, 2014 [Page 6]
Internet-Draft Civic Location ANI Suboption October 2013
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 ANI-Update-Frequency 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-
Option Type Values". RFC Editor: Please replace <IANA-2> in
Section 4 with the assigned value, and update this section
accordingly.
7. 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 [RFC6463]. 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 [RFC6463]. Therefore, it inherits from
[RFC5213] and [RFC6463], its security guidelines and does not require
any additional security considerations.
8. Acknowledgements
TBD
9. References
9.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.
Pazhyannur, et al. Expires April 25, 2014 [Page 7]
Internet-Draft Civic Location ANI Suboption October 2013
[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.
9.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.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012.
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
Pazhyannur, et al. Expires April 25, 2014 [Page 8]
Internet-Draft Civic Location ANI Suboption October 2013
Jouni Korhonen
Broadcom
Porkkalankatu 24
Helsinki FIN-00180
Finland
Email: jouni.nospam@gmail.com
Pazhyannur, et al. Expires April 25, 2014 [Page 9]