Skip to main content

Civic Location ANI Suboption for PMIPv6
draft-pazhyannur-netext-civic-location-ani-subopt-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Rajesh Pazhyannur , Sebastian Speicher , Sri Gundavelli , Jouni Korhonen
Last updated 2013-10-21
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-pazhyannur-netext-civic-location-ani-subopt-00
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]