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 for this sub-option needs to be allocated from the registry "Access Network Information (ANI) Sub-Option Type Values". RFC Editor: Please replace 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 for this sub-option needs to be allocated from the registry "Access Network Information (ANI) Sub- Option Type Values". RFC Editor: Please replace 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]