Network Working Group                                              Q. Wu
Internet-Draft                                                    J. Xia
Intended status: Standards Track                                 Y. Wang
Expires: April 29, 2010                                           Huawei
                                                            G. Zorn, Ed.
                                                             Network Zen
                                                        October 26, 2009


 AAA Support for PMIP6 mobility entities Locating and Discovery during
                           localized routing
                       draft-wu-dime-pmip6-lr-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Wu, et al.               Expires April 29, 2010                 [Page 1]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


Abstract

   In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the
   the Mobile Access Gateway (MAG) to which it is attached are typically
   tunneled to a Local Mobility Anchor (LMA) for routing.  The term
   "localized routing" refers to a method by which packets are routed
   directly by the MAG without involving the LMA.  In order to establish
   a localized routing session between two Mobile Access Gateways in a
   Proxy Mobile IPv6 domain, two tasks must be accomplished:

   1.  The usage of local routing must be authorized for both MAGs and

   2.  The address of the MAG to which the Correspondent Node (CN) is
       attached must be discovered

   This document specifies how to accomplish these tasks using the
   Diameter protocol


































Wu, et al.               Expires April 29, 2010                 [Page 2]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Locating the Recipient of Localized Routing  . . . . . . . . .  6
   5.  Diameter Server Authorizes a MAG Location Query  . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






































Wu, et al.               Expires April 29, 2010                 [Page 3]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


1.  Introduction

   Proxy Mobile IPv6 (PMIPv6 [RFC5213] allows the Mobility Access
   Gateway to optimize media delivery by locally routing packets within
   itself, avoiding tunneling them to the Mobile Node's Local Mobility
   Anchor.  This is referred to as "local routing" in RFC 5213.
   However, this mechanism is not applicable to the typical scenario
   where the MN and CN are under different MAGs and belong to different
   LMAs.  In this scenario (described in [I-D.ietf-netext-pmip6-lr-ps]),
   the relevant information needed to set up a localized routing path
   (e.g., the Mobile Access Gateways to which the MN and CN are
   respectively attached) is distributed between their respective Local
   Mobility Anchors.  This may complicate the setup and maintenance of
   localized routing.

   Therefore, in order to establish a localized routing path between the
   two Mobile Access Gateways, the Mobile Node's MAG must discover which
   LMA is managing the Correspondent Node's traffic and then fetch the
   address of the Correspondent Node's MAG from that LMA.  In Proxy
   Mobile IPv6, the LMA to be assigned to CN may be maintained as a
   configured entry in the Correspondent Node's policy profile located
   on a Authentication, Authorization and Accounting (AAA) server.
   However, there is no relevant work discussing how the Correspondent
   Node's LMA is discovered by Mobile Node's MAG in terms of the
   Correspondent Node's Home Network Prefix (HNP) using AAA-based
   mechanisms during the setup of localized routing.  The method by
   which the Mobile Node's MAG interacts with the Correspondent Node's
   LMA to identify the Correspondent Node's MAG is also unspecified.

   This document describes AAA support for the authorization and
   discovery of PMIPv6 mobility entities during localized routing.  In
   LMA discovery, Diameter [RFC3588] is used to authorize the localized
   routing service and provide the Mobile Node's MAG/LMA with
   information regarding the Correspondent Node's LMA.  In MAG
   discovery, AAA is used to determine whether Mobile Node's MAG is
   allowed to fetch the address of the Correspondent Node's MAG from the
   Correspondent Node's LMA.  If MAG discovery is successful, the the
   Correspondent Node's LMA will respond to the Mobile Node's MAG with
   the address of the Correspondent Node's MAG.


2.  Terminology

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





Wu, et al.               Expires April 29, 2010                 [Page 4]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


3.  Solution Overview

   MAG/LMA resolution is a prerequisite to the establishment of a direct
   routing path between MAG1 and MAG2 (associated with MN1 and MN2
   respectively), this document addresses how to resolve the destination
   MN's MAG by means of interaction between the MAG and the AAA server,
   and between the LMA and the AAA server.  Figure 1 shows the reference
   architecture for the MAG resolution.  This reference architecture
   assumes

   o  MN1 and MN2 belong to different LMA

   o  the MAG and LMA support Diameter client functionality


                         LMA2?  +---------+
                +-------------->| AAA &   |
                |        LMA2?  | Policy  |<--------------+
                |           +-->| Profile |               |
                |       Diameter+---------+            Diameter
             Diameter    AAA(a)                          AAA(b)
              AAA(a)     +--+-+             +----+        |
                |        |LMA1|      +----->|LMA2|<-------+
                |        +----+      |      +----+
                |          |         |        |
                |         //         |        \\
                |        //         PMIP       \\
                |       //           |          \\
                |       |            |           |
                |     +----+  MAG2?  |         +----+
                +---->|MAG1|<--------+         |MAG2|
                      +----+                   +----+
                        :                         :
                      +---+                     +---+
                      |MN1|                     |MN2|
                      +---+                     +---+

   Figure 1: Local Routing Service Authorization Reference Architecture

   The interaction of the MAG and LMA with the AAA server is a two step
   procedure involving

   1.  Interaction between MAG1 or LMA1 and the AAA server authorizing
       the use of localized routing between MAG1 and MAG2 and (if
       successful) fetching the IP address of LMA2 (step 'a' in
       (Figure 1))





Wu, et al.               Expires April 29, 2010                 [Page 5]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


   2.  Interaction between LMA2 and the AAA server authorizing the use
       of localized routing between MAG1 and MAG2 and (if successful)
       fetching the IP address of MAG2 (step 'b' in (Figure 1))


4.  Locating the Recipient of Localized Routing

   Figure 2 shows a scenario where MAG1 acts as a Diameter client,
   processing the data packet from MN1 to MN2 and requesting the
   recipient of localized routing.  In this scenario, MN1 and MN2 are
   anchored to LMA1 and LMA2 respectively.  In order to initiate a
   localized routing path with NMAG2, MAG1 must first locate the entity
   that maintains the data required to setup the path (i.e., LMA2).  The
   Diameter client in MAG1 sends an AA-Request (AAR) message to the
   Diameter server.  The message contains an instance of the Service-
   Type AVP ([RFC4005], section 6.1). with the value "PMIPv6 Localized
   Routing Authorization" Section 7 and an instance of the MIP6-Home-
   Link-Prefix AVP ([RFC5447], section 4.2.4) containing the IP address
   of MN2.  The Diameter server checks if localized routing is allowed
   between MAG1 and MAG2 and if so, responds with an AA-Answer (AAA)
   message encapsulating an instance of the MIP6-Agent-Info AVP
   [I-D.ietf-dime-pmip6] containing the IP address and/or Fully
   Qualified Domain Name (FQDN) of LMA2.  MAG1 then determines the IP
   address of LMA2 using the data returned in the MIP6-Agent-Info,
   requests the address of MAG2 from LMA2 and uses that address to setup
   the localized routing path between itself and MAG2 via the Proxy
   Binding Update (PBU)/Proxy Binding Acknowledgement (PBA) message
   exchange [RFC5213].























Wu, et al.               Expires April 29, 2010                 [Page 6]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


      +---+    +----+  +----+     +---+      +----+  +----+   +---+
      |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
      +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
        |        |       |          |          |       |        |
        |     Anchored   |          |          |    Anchored    |
        o----------------o          |          o-------+--------o
      Data[MN1->MN2]     |          |          |       |        |
        |------->|AAR(service type,MN2)        |       |        |
        |        |----------------->|          |       |        |
        |        |AAA(LMA2)         |          |       |        |
        |        |<-----------------|          |       |        |
        |        |       |PBU(LR[MN1,MN2])     |       |        |
        |        |-------+----------+--------->|       |        |
        |        |       | PBA(LR[MAG2])       |       |        |
        |        |<--------------------------- |       |        |
        |        |       MAGs PBU/PBA exchange |       |        |
        |        |<----------------------------------->|        |
        |        |       |          |          |       |        |
        |        |====================================>|------->|
        |        |       |          |          |       |Data[MN2->MN1]
        |<------ |<====================================|<-------|
        |        |       |          |          |       |        |

           Figure 2: Locating the Recipient of Localized Routing

   Figure 3 shows another scenario, in which LMA1 acts as a Diameter
   client, processing the data packet from MN1 to MN2 and requesting the
   recipient of localized routing.  In this scenario, MN1 and MN2 are
   anchored to LMA1 and LMA2 respectively.  In contrast with the
   signaling flow of Figure 2 the difference is that it is LMA1 instead
   of MAG1 who solicits the IP address of LMA2 from the Diameter server.

   The Diameter client in LMA1 sends an AA-Request (AAR) message to the
   Diameter server.  The message contains an instance of the Service-
   Type AVP ([RFC4005], section 6.1). with the value "PMIPv6 Localized
   Routing Authorization" Section 7 and an instance of the MIP6-Home-
   Link-Prefix AVP ([RFC5447], section 4.2.4) containing the IP address
   of MN2.  The Diameter server checks if localized routing is allowed
   between MAG1 and MAG2 and if so, responds with an AA-Answer (AAA)
   message encapsulating an instance of the MIP6-Agent-Info AVP
   [I-D.ietf-dime-pmip6] containing the IP address and/or Fully
   Qualified Domain Name (FQDN) of LMA2.  LMA1 then determines the IP
   address of LMA2 using the data returned in the MIP6-Agent-Info and
   forwards it to MAG1 in the Notification Request message.







Wu, et al.               Expires April 29, 2010                 [Page 7]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


      +---+    +----+  +----+     +---+      +----+  +----+   +---+
      |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
      +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
        |        |       |          |          |       |        |
        |     Anchored   |          |          |    Anchored    |
        o----------------o          |          o-------+--------o
      Data[MN1->MN2]     |          |          |       |        |
        |------->|=====-> AAR(Service Type,MN2)|       |        |
        |        |       |--------->|          |       |        |
        |    Notification|AAA(LMA2)            |       |        |
        |    Req[LMA2]   <----------|          |       |        |
        |        |<------|  PBU(LR[MN1,MN2])   |       |        |
        |        |-------+----------+--------->|       |        |
        |        |       |  PBA(LR[MAG2])      |       |        |
        |        |<--------------------------- |       |        |
        |        |       MAGs PBU/PBA exchange |       |        |
        |        |<----------------------------------->|        |
        |        |                                     |        |
        |        |===================================->|        |
        |        |       |          |          |       |------->|
        |        |       |          |          |       |Data[MN2->MN1]
        |<------ |<-===================================|<-------|
        |        |       |          |          |       |        |

           Figure 3: Locating the Recipient of Localized Routing


5.  Diameter Server Authorizes a MAG Location Query

   Figure 4 shows a scenario in which LMA2 acts as a Diameter client,
   receiving location request and requesting authorization for MAG
   location lookup.  In this scenario, MN1 and MN2 are anchored to LMA1
   and LMA2 respectively.  Upon receiving an upstream data packet, MAG1
   needs to determine the recipient of localized routing, i.e., LMA2.
   And then MAG1 solicit the LMA2 to lookup IP address of MAG2 to which
   MN2 is currently attached by sending localized routing request
   message containing IP address/HNP of MN1 and MN2.  In this step, the
   LMA2 needs to validate the request from MAG1 by sending an AAR to the
   AAA server.  In the AAR message, IP address/HNP of MN1 and the new
   service type for localized routing are included.  The Diameter Server
   makes authorization based on the IP address/HNP of MN1 and checks the
   new service type for localized routing encapsulated in the LMA-AAA
   AVPs.  In successful case, the Diameter Server responds to the LMA
   with success status.  And then LMA2 lookup IP address of MAG2 based
   on the IP address/HNP of MN2 and respond to the MAG1 with the IP
   address of MAG2.





Wu, et al.               Expires April 29, 2010                 [Page 8]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


       +---+    +----+  +----+     +---+      +----+  +----+   +---+
       |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
       +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
         |        |       |          |          |       |        |
         |     Anchored   |          |          |    Anchored    |
         o----------------o          |          o-------+--------o
       Data[MN1->MN2]     |          |          |       |        |
         |------->|       |          |          |       |        |
         |+--------------+|          |          |       |        |
         ||Recipient=LMA2||          |          |       |        |
         |+--------------+|          |          |       |        |
         |        |       PBU(LR[MN1,MN2])      |       |        |
         |        |-------+----------+--------->|       |        |
         |        |       |          |AAR(Service Type,MN1)      |
         |        |       |          |<-------- |       |        |
         |        |       |          |   AAA    |       |        |
         |        |       |          |--------->|       |        |
         |        |       |PBA(LR[MAG2])        |       |        |
         |        |<--------------------------- |       |        |
         |        |      MAGs PBU/PBA exchange  |       |        |
         |        |<----------------------------------->|        |
         |        |                                     |        |
         |        |===================================->|        |
         |        |       |          |          |       |------->|
         |        |       |          |          |       |Data[MN2->MN1]
         |<------ |<-===================================|<-------|
         |        |       |          |          |       |        |

          Figure 4: Diameter Server Authorizes MAG Location Query


6.  Security Considerations

   The security considerations for the Diameter NASREQ [RFC4005] and
   Diameter Proxy Mobile IPv6 applications [I-D.ietf-dime-pmip6] are
   applicable to this document.

   The service authorization solicited by the MAG or the LMA relies upon
   the existing trust relationship between the MAG or LMA and the AAA
   server.


7.  IANA considerations

   The IANA is requested to allocate a new value for the Service-Type
   AVP as follows: PMIPv6 Localized Routing Authorization <TBD>
   according to the "IETF Review" policy [RFC5225].




Wu, et al.               Expires April 29, 2010                 [Page 9]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


8.  References

8.1.  Normative References

   [I-D.ietf-dime-pmip6]
              Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
              and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
              Gateway and Local Mobility Anchor  Interaction with
              Diameter Server", draft-ietf-dime-pmip6-04 (work in
              progress), September 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5225]  Pelletier, G. and K. Sandlund, "RObust Header Compression
              Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
              UDP-Lite", RFC 5225, April 2008.

   [RFC5447]  Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
              and K. Chowdhury, "Diameter Mobile IPv6: Support for
              Network Access Server to Diameter Server Interaction",
              RFC 5447, February 2009.

8.2.  Informative References

   [I-D.ietf-netext-pmip6-lr-ps]
              Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized
              Routing Problem Statement",
              draft-ietf-netext-pmip6-lr-ps-00 (work in progress),
              September 2009.











Wu, et al.               Expires April 29, 2010                [Page 10]


Internet-Draft      AAA Support for MAG/LMA Locating        October 2009


Authors' Addresses

   Qin Wu
   Huawei Technologies Co., Ltd.
   Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
   Nanjing, JiangSu  210001
   China

   Phone: +86-25-84565892
   Email: Sunseawq@huawei.com


   Jinwei Xia
   Huawei Technologies Co., Ltd.
   Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Phone: +86-025-8456-5890


   Yungui Wang
   Huawei Technologies Co., Ltd.
   Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Phone: +86-025-8456-5893


   Glen Zorn (editor)
   Network Zen
   1310 East Thomas Street
   Seattle, Washington  98102
   +1 (206) 377-9035

   Email: gwz@net-zen.net














Wu, et al.               Expires April 29, 2010                [Page 11]