[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-wu-dime-pmip6-lr) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 7156

Network Working Group                                       G. Zorn, Ed.
Internet-Draft                                               Network Zen
Intended status: Standards Track                              Q. Wu, Ed.
Expires: August 8, 2010                                           Huawei
                                                             M. Liebsch
                                                                     NEC
                                                            J. Korhonen
                                                                     NSN
                                                        February 4, 2010


        Diameter Support for Proxy Mobile IPv6 Localized Routing
                      draft-ietf-dime-pmip6-lr-00

Abstract

   In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by 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 ascertained

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

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



Zorn, et al.             Expires August 8, 2010                 [Page 1]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


   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 August 8, 2010.

Copyright Notice

   Copyright (c) 2010 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
   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 BSD License.






























Zorn, et al.             Expires August 8, 2010                 [Page 2]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Localized Routing Service Authorization  . . . . . . . . . . .  6
   5.  Diameter Server Authorizes MAG Location Query  . . . . . . . .  8
   6.  Local Routing Service Authorization in Networks with
       Multiple AAA Servers . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 11
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12



































Zorn, et al.             Expires August 8, 2010                 [Page 3]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


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 in
   which the MN and CN are connected to different MAGs and are
   registered to different LMAs.  In this scenario (as described in
   [I-D.ietf-netext-pmip6-lr-ps]), the relevant information needed to
   set up a localized routing path (e.g., the addresses of 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 identify the
   LMA that is managing the Correspondent Node's traffic and then obtain
   the address of the Correspondent Node's MAG from that LMA.  In Proxy
   Mobile IPv6, the LMA to be assigned to the CN may be maintained as a
   configured entry in the Correspondent Node's policy profile located
   on an Authentication, Authorization and Accounting (AAA) server.
   However, there is no relevant work discussing how AAA-based
   mechanisms can be used by the Mobile Node's MAG to discover the
   address of the Correspondent Node's LMA 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
   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].





Zorn, et al.             Expires August 8, 2010                 [Page 4]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


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 LMA and the
   AAA server.  Figure 1 shows the reference architecture for Local
   Routing Service Authorization.  This reference architecture assumes

   o  MN1 and MN2 belong to different LMAs

   o  the MAG and LMA support Diameter client functionality


                                   +---------+
                        LMA2?      |  AAA &  |
                           +------>| Policy  |<----------+
                           |       | Profile |           |
                       Diameter    +---------+        Diameter
                        AAA(a)                         AAA(b)
                  LMA2? +--+-+             +----+        |
               +------->|LMA1|      +----->|LMA2|<-------+
               |        +----+      |      +----+
               |          |         |        |
               |         //         |        \\
              PMIP      //         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

   a.  The LMA1 interaction with the AAA server is used to authorize the
       localized routing service and fetch the IP address of LMA2 from
       the AAA server (step 'a' in (Figure 1))

   b.  LMA2 interaction with the AAA server is used to determine whether
       MAG1 is allowed to obtain the IP address of MAG2 (step 'b' in
       (Figure 1))



Zorn, et al.             Expires August 8, 2010                 [Page 5]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


4.  Localized Routing Service Authorization

   Figure 2 shows a scenario where MAG1 acts as a Diameter client,
   processing the data packet from MN1 to MN2 and requesting
   authorization of localized routing.  In this scenario, MN1 and MN2
   are anchored to LMA1 and LMA2 respectively.  In order to setup a
   localized routing path with MAG2, MAG1 must first locate the entity
   that maintains the data required to setup the path (i.e., LMA2) by
   sending a Local Routing Optimization Request message
   ([I-D.wu-netext-local-ro]) to LMA1.  Note that the discovery of LMA2
   is only done once; upon LMA1 know LMA2 address from AAA serer, LMA1
   may associate LMA2 address with MN's data for future use (e.g.,
   handover case).  The Diameter client in LMA1 sends an AA-Request
   (AAR) message to the Diameter server.  The message contains an
   instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section
   4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit Section 8 set 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
   responds to MAG1 with the address of LMA2.  MAG1 then requests the
   address of MAG2 from LMA2 and uses that address to setup the
   localized routing path between itself and MAG2 via a Proxy Binding
   Update (PBU)/Proxy Binding Acknowledgement (PBA) message exchange
   [RFC5213].





















Zorn, et al.             Expires August 8, 2010                 [Page 6]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


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

          Figure 2: MAG-initiated Localized Routing Authorization

   Figure 3 shows another scenario, in which the LMA1 acts as a Diameter
   client, processing the data packet from MN1 to MN2 and requesting the
   authorization 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 which initiates the setup of the localized routing path.

   The Diameter client in LMA1 sends an AA-Request (AAR) message to the
   Diameter server.  The message contains an instance of the MIP6-
   Feature-Vector AVP ([RFC5447], Section 4.2.5) with the
   INTER_MAG_ROUTING_SUPPORTED bit set 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 AVP



Zorn, et al.             Expires August 8, 2010                 [Page 7]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


   and forwards it to MAG1 in the Local Routing Optimization message
   ([I-D.wu-netext-local-ro]).

       +---+    +----+  +----+     +---+      +----+  +----+   +---+
       |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
       +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
         |        |       |          |          |       |        |
         |     Anchored   |          |          |    Anchored    |
         o--------+-------o          |          o-------+--------o
         | Data[MN2->MN1] |          |          |       |        |
         |--------+------>|          |          |       |        |
         |        |       |AAR(MN2,MFV)         |       |        |
         |        |       |--------->|          |       |        |
         |        |       |AAA(LMA2) |          |       |        |
         |        |       |<---------|          |       |        |
         |     LROREQ(MN2,LMA2)      |          |       |        |
         |        |<------|          |          |       |        |
         |      LRORSP(Succ)         |          |       |        |
         |        |------>|          |          |       |        |
         |        |       |  PBU(LR[MN1,MN2])   |       |        |
         |        |---------------------------->|       |        |
         |        |       |  PBA(LR[MAG2])      |       |        |
         |        |<----------------------------|       |        |
         |        |       |  MAGs PBU/PBA exch  |       |        |
         |        |<----------------------------------->|        |
         |Data[MN1->MN2]                                |        |
         |------->|====================================>|------->|
         |        |       |          |          |       |        |
         |        |       |          |          |  Data[MN2->MN1]|
         |<-------|<====================================|<-------|
         |        |       |          |          |       |        |

          Figure 3: LMA-initiated Localized Routing Authorization


5.  Diameter Server Authorizes 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 solicits LMA2 to look up the IP address of the MAG to
   which MN2 is currently attached (in this case, MAG2) by sending a
   Local Routing Optimization Request message containing the IP
   addresses/HNPs of MN1 and MN2.  LMA2 validates the request from MAG1
   by sending an AAR to the AAA server containing the IP address/HNP of
   MN1 (encapsulated in an instance of the MIP6-Home-Link-Prefix AVP)



Zorn, et al.             Expires August 8, 2010                 [Page 8]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


   and an instance of the MIP6-Feature-Vector AVP ([RFC5447], Section
   4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit set.  If the
   authorization is successful, LMA2 then looks up the IP address of
   MAG2 based on the IP address/HNP of MN2 and responds to MAG1 with the
   IP address of MAG2.

      +---+    +----+  +----+     +---+      +----+  +----+   +---+
      |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
















Zorn, et al.             Expires August 8, 2010                 [Page 9]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


6.  Local Routing Service Authorization in Networks with Multiple AAA
    Servers

                      +------------------------------------+
                      (                      AAA           )
                      (     +--------+     Backend         )
                      (     |Redirect|                     )
                      (     | Agent  |                     )
                      (     +--------+                     )
                      (         ^                          )
                      (         |                          )
                      (         |                          )
                      (         v                          )
                      (  +---------+          +---------+  )
                   +---->| AAA1 &  |          | AAA2 &  |<---+
                   |  (  | Policy  |<-------->| Policy  |  ) |
                   |  (  | Profile |          | Profile |  ) |
                   |  (  +---------+          +---------+  ) |
                   |  (      ^                     ^       ) |
                   |  +----- | ------------------- |-------+ |
                   |         A1                    A2        |
                   |         |                     |         |
                   |         |                     |         |
                Diameter     v                     v      Diameter
                   B1       +----+  LMA2 ?     +----+        B2
                   |        |LMA1| ------>     |LMA2|        |
                   |        +----+             +----+        |
                   |          |                  |           |
                   |         //                  \\          |
                   |        //                    \\         |
                   |       //                      \\        |
                   |       |                        |        |
                   |     +----+                   +----+     |
                   +---->|MAG1|                   |MAG2|<----+
                         +----+                   +----+
                            :                        :
                         +---+                     +---+
                         |MN1|                     |MN2|
                         +---+                     +---+

    Figure 5: Use of a Diameter Redirect Agent to Support Local Routing
        Service Authorization in Networks with Multiple AAA servers

   Referring to an architecture with multiple AAA servers (as
   illustrated in Figure 5), AAA1 may not maintain the LMA to be
   assigned to MN2 as a configured entry in the Correspondent Node's
   Policy profile, as AAA2 holds this information in its policy store.
   In such a case, AAA1 contacts a Diameter redirect agent [RFC3588] to



Zorn, et al.             Expires August 8, 2010                [Page 10]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


   request the AAA server being responsible for maintaining MN2's policy
   profile.  AAA2 checks if localized routing is allowed between MAG1
   and MAG2 and if so, responds with the IP address of LMA2
   corresponding to MN2 and sends the results back to LMA1 via AAA1.
   Details about the use of redirect agents in this context are beyond
   scope of this document.


7.  Security Considerations

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

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


8.  IANA Considerations

   This specification specifies a new value in the Mobility Capability
   registry [RFC5447] for use with the MIP6-Feature-Vector AVP:
   INTER_MAG_ROUTING_SUPPORTED (0x0000080000000000).


9.  Contributors

   Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early
   versions of this document.


10.  References

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



Zorn, et al.             Expires August 8, 2010                [Page 11]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


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

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

10.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-02 (work in progress),
              January 2010.

   [I-D.wu-netext-local-ro]
              Wu, W. and B. Sarikaya, "Proxy MIP extension for local
              routing optimization", draft-wu-netext-local-ro-04 (work
              in progress), October 2009.


Authors' Addresses

   Glen Zorn (editor)
   Network Zen
   1463 East Republican Street
   #358
   Seattle, Washington  98112
   USA

   Email: gwz@net-zen.net


   Qin Wu (editor)
   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





Zorn, et al.             Expires August 8, 2010                [Page 12]

Internet-Draft       PMIP6 Localized Routing Support       February 2010


   Marco Liebsch
   NEC Europe Ltd.
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg,   69115
   Germany

   Email: liebsch@nw.neclab.eu


   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo FI-02600,
   Finland

   Email: jouni.nospam@gmail.com


































Zorn, et al.             Expires August 8, 2010                [Page 13]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/