[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 RFC 7156

Network Working Group                                            G. Zorn
Internet-Draft                                               Network Zen
Intended status: Standards Track                                   Q. Wu
Expires: December 31, 2011                                        Huawei
                                                              M. Liebsch
                                                                     NEC
                                                             J. Korhonen
                                                                     NSN
                                                           June 29, 2011


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

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 between an MN's MAG and the MAG of its Correspondent Node
   (CN) without involving any 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 localized 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 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."



Zorn, et al.            Expires December 31, 2011               [Page 1]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   This Internet-Draft will expire on December 31, 2011.

Copyright Notice

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



































Zorn, et al.            Expires December 31, 2011               [Page 2]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Localized Routing Service Authorization  . . . . . . . . . . .  6
   4.  Diameter Server Authorizes MAG Location Query  . . . . . . . .  9
   5.  Localized Routing Service Authorization in Networks with
       Multiple AAA Servers . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1.  draft-ietf-dime-pmip6-lr-03 . . . . . . . . . . . . . . . 12
     10.2.  draft-ietf-dime-pmip6-lr-04 . . . . . . . . . . . . . . . 13
     10.3.  draft-ietf-dime-pmip6-lr-05 . . . . . . . . . . . . . . . 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14































Zorn, et al.            Expires December 31, 2011               [Page 3]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


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
   [RFC6279]), 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 or LMA 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 or LMA
   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.  Solution Overview

   MAG/LMA discovery 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 Localized



Zorn, et al.            Expires December 31, 2011               [Page 4]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   Routing Service Authorization.  This reference architecture assumes

   o  MN1 and MN2 belong to different LMAs or the same LMA.  If MN1 and
      MN2 belong to the same LMA, the LMA1 and LMA2 to which MN1 and MN2
      are anchored in the figure1 should be the same LMA.

   o  The MAG and LMA support Diameter client functionality.


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

        Figure 1: Localized Routing Service Authorization Reference
                               Architecture

   The interaction of the MAG and LMA with the AAA server according to
   the extension specified in this document considers the follows
   features:

   a.  The interaction of LMA1 with the AAA server is used to authorize
       the localized routing service and, if necessary, fetch the IP
       address of LMA2 (Step a in Figure 1)

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



Zorn, et al.            Expires December 31, 2011               [Page 5]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   Note that if MN1 and MN2 are connected to different MAGs but share
   the same LMA, the interaction between LMA1 and the AAA server should
   be exactly the same as the case where MNs belong to MAGs under
   different LMAs.


3.  Localized Routing Service Authorization

   Localized Routing Service Authorization also can happen during the
   network access authentication procedure [RFC5779],i.e., before
   Localized routing is initialized.  In this case, the preauthorized
   pairs of LMA/prefix sets can be downloaded to Proxy Mobile IPv6
   entities during RFC5779 procedure.  Localized routing can be
   initiated once a destination of received packet matches to some of
   the prefixes received during RFC5779 procedure.

   Figure 2 shows an example scenario where MAG1 acts as a Diameter
   client, processing the data packet from MN1 to MN2 and requesting
   authorization of localized routing.  In this example scenario, MN1
   and MN2 are anchored to LMA1 and LMA2 respectively if MN1 and MN2
   belong to the different LMA, otherwise, the LMA to which MN1 and MN2
   are anchored should be the same LMA,i.e., LMA1 or LMA2.  In the case
   where MNs belong to the different LMAs, 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 Request message to LMA1.  Note that the discovery of LMA2 is only
   done once and the request message is Localized routing initialization
   (LRI) message in the Figure 2 and belong to the Initial phase of the
   localized routing; once LMA1 has obtained the address of LMA2 from
   the AAA serer, LMA1 may associate address of LMA2 with the Mobile
   Node's cached data for future use (e.g., in the case of a handover).
   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 7) 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 MN2 is allowed to use localized routing
   and if so, responds with an AA-Answer (AAA) message encapsulating an
   instance of the MIP6-Agent-Info AVP [RFC5779] 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 in the
   localized routing acknowledge message (LRA in the Figure 2).  MAG1
   can verify whether both MAGs are under the same LMA by comparing LMA1
   address with LMA2 address.  MAG1 then requests the address of MAG2
   from LMA2 and uses that address to setup the localized routing path



Zorn, et al.            Expires December 31, 2011               [Page 6]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   between itself and MAG2 via a Proxy Binding Update (PBU)/Proxy
   Binding Acknowledgement (PBA) message exchange [RFC5213].

   In the case where MNs share the same LMA, the MAG1 should send a
   request message (LRI in the Figure 2) to LMA for localized routing
   which includes IP address of MN2.  The subsequent interaction between
   LMA1 and the AAA should be exact the same as the case where MNs
   belong to different LMAs.  If authorization is successful, the LMA
   may look up MAG2 address directly based on IP address of MN2 and
   respond a message to the MAG1 with IP address of MAG2 included.


   +---+    +----+    +----+     +---+    +----+  +----+   +---+
   |MN1|    |MAG1|    |LMA1|     |AAA|    |LMA2|  |MAG2|   |MN2|
   +-+-+    +-+--+    +-+--+     +-+-+    +-+--+  +-+--+   +-+-+
     |        |         |          |        |       |        |
     |     Anchored     |          |        |    Anchored    |
     o------------------o          |        o-------+--------o
   Data[MN1->MN2]       |          |        |       |        |
     |------->| LRI(MN2)|          |        |       |        |
     |        |-------->|          |        |       |        |
     |        |         | AAR(MN2,MFV)      |       |        |
     |        |         |--------->|        |       |        |
     |        |         |  AAA(LMA2)        |       |        |
     |      LRA([LMA2]) |<---------|        |       |        |
     |        |<--------|          |        |       |        |
     |                  |          |        |       |        |

          Figure 2: MAG-initiated Localized Routing Authorization

   Figure 3 shows another example scenario, in which the LMA1 acts as a
   Diameter client, processing the data packet from MN2 to MN1 and
   requesting the authorization of localized routing.  In this example
   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 MN2 is allowed to use
   localized routing and if so, responds with an AA-Answer (AAA) message
   encapsulating an instance of the MIP6-Agent-Info AVP [RFC5779]
   containing the IP address and/or Fully Qualified Domain Name (FQDN)
   of LMA2.  LMA1 then determines the IP address of LMA2 using the data



Zorn, et al.            Expires December 31, 2011               [Page 7]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   returned in the MIP6-Agent-Info AVP and responds to MAG1 with the
   address of LMA2.

   In the case where MNs share the same LMA, the Diameter client in LMA1
   sends an AA-Request (AAR) message to the Diameter server.  The
   interaction between LMA1 and the AAA should be exact the same as the
   case where MNs belong to different LMAs.  If authorization is
   successful, the LMA may look up MAG2 address directly based on IP
   address of MN2 and send a request message (LRI in the Figure 3) to
   the MAG1 for localized routing with IP address of MAG2 included.  The
   MAG1 confirms the success of localized routing if localized routing
   path can be setup.


          +---+    +----+  +----+     +---+      +----+  +----+   +---+
          |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
          +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
            |        |       |          |          |       |        |
            |     Anchored   |          |          |    Anchored    |
            o--------+-------o Data[MN2->MN1]      o-------+--------o
            |        |       |<-----    |          |       |        |
            |        |       |AAR(MFV,MN2)         |       |        |
            |        |       |--------->|          |       |        |
            |          LRI   |AAA(LMA2) |          |       |        |
            |    (MN2,[LMA2])|<---------|          |       |        |
            |        |<------|          |          |       |        |
            |     LRA(Succ)  |          |          |       |        |
            |        |------>|          |          |       |        |

          Figure 3: LMA-initiated Localized Routing Authorization

   Figure 4 shows another example scenario, similar to the example
   scenario illustrated in Figure 3, LMA1 does not respond to MAG1 with
   the address of LMA2, instead setting up a localized routing path
   directly between itself and LMA2 via localized routing signaling.
















Zorn, et al.            Expires December 31, 2011               [Page 8]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


          +---+    +----+  +----+     +---+      +----+  +----+   +---+
          |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
          +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
            |        |       |          |          |       |        |
            |     Anchored   |          |          |    Anchored    |
            o--------+-------o Data[MN2->MN1]      o-------+--------o
            |        |       |<-----    |          |       |        |
            |        |       |AAR(MFV,MN2)         |       |        |
            |        |       |--------->|          |       |        |
            |        |       |AAA(LMA2) |          |       |        |
            |        |       |<---------|          |       |        |
            |        |       Localized routing setup       |        |
            |        |       |<------------------->|       |        |

          Figure 4: LMA-initiated Localized Routing Authorization


4.  Diameter Server Authorizes MAG Location Query

   Figure 5 shows an example scenario in which LMA2 acts as a Diameter
   client, receiving MAG location request and requesting authorization
   for MAG location Query to the AAA server.  In this example scenario,
   MN1 and MN2 may be anchored to LMA1 and LMA2 respectively or belong
   to the same LMA.  In the case where MNs belong to the different LMAs,
   MAG1 or LMA1 should has already known the recipient of localized
   routing is LMA2.  If MAG1 initiates LR, MAG1 may take option 1 in the
   Figure 5 and solicit LMA2 to look up the IP address of the MAG to
   which MN2 is currently attached (in this case, MAG2) according to the
   IP addresses/HNPs of MN2.  If LMA1 initiate LR, LMA1 may take option
   2 in the Figure 5 and solicit LMA2 to look up IP address of the MAG
   to which MN2 is currently attached.  LMA2 validates the request (LRI
   in the Figure 5) 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) 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 or LMA1 with the IP address
   of MAG2.












Zorn, et al.            Expires December 31, 2011               [Page 9]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


        +---+    +----+  +----+     +---+      +----+  +----+   +---+
        |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
        +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
          |        |       |          |          |       |        |
          |     Anchored   |          |          |    Anchored    |
          o----------------o          |          o-------+--------o
        Data[MN1->MN2]     |          |          |       |        |
          |------->|       |          |          |       |        |
          |        |       LRI(MN1,MN2 )         |       |        |
          |        |-------+----------+--------->|\      |        |
          |        |       |          |          | |     |        |
          |        |       |         AAR(MFV,MN1)|Option 1        |
          |        |       |          |<-------- | |     |        |
          |        |       |          | AAA(LMA1)| |     |        |
          |        |       |          |--------->| |     |        |
          |        |       LRA(MAG2 )            | |     |        |
          |        |<--------------------------- |/      |        |
          |        |                             |       |        |
          |        |       |LRI(MN1,MN2)         |\      |        |
          |        |       +----------+--------->| |     |        |
          |        |       |         AAR(MFV,MN1)|Option 2        |
          |        |       |          |<-------- | |     |        |
          |        |       |          | AAA(LMA1)| |     |        |
          |        |       |          |--------->| |     |        |
          |        |       |    LRA(MAG2)        | |     |        |
          |        |       |<------------------- |/      |        |
          |        |       |                             |        |
          |        |       |Localized routing setup      |        |
          |        |<------+---------------------------->|        |
          |        |===================================->|        |
          |        |       |          |          |       |------->|
          |        |       |          |          |    Data[MN2->MN1]
          |<------ |<-===================================|<-------|
          |        |       |          |          |       |        |

          Figure 5: Diameter Server Authorizes MAG Location Query

   In the case where MNs share the same LMA, LR should be initiated by
   LMA1(i.e.,LMA2) since only LMA1 knows both MN1 and MN2 belong to
   itself by lookup its binding cache corresponding to MN1 and MN2.
   Unlike the case where MNs belong to different LMAs, the interaction
   between LMAs in option 2 is omitted since LMA1 is LMA2.  The
   interaction between LMA1 and the AAA should be exact the same as the
   case where MNs belong to different LMAs.







Zorn, et al.            Expires December 31, 2011              [Page 10]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


5.  Localized 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 6: Use of a Diameter Redirect Agent to Support Localized
    Routing Service Authorization in Networks with Multiple AAA servers

   Referring to an architecture with multiple AAA servers (as
   illustrated in Figure 6), 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 December 31, 2011              [Page 11]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   request the AAA server being responsible for maintaining MN2's policy
   profile.  AAA2 checks if MN2 is allowed to use localized routing 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.


6.  Security Considerations

   The security considerations for the Diameter NASREQ [RFC4005] and
   Diameter Proxy Mobile IPv6 [RFC5779] 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.


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


8.  Contributors

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


9.  Acknowledgement

   The authors would like to thank Carlos Jesus Bernardos Cano for his
   valuable comments and suggestions on this document.


10.  Change Log

10.1.  draft-ietf-dime-pmip6-lr-03

   The following are the major changes compared to previous version 02:

   o  Allow return the LMA address in all cases.

   o  Using localized routing for terminology consistency.





Zorn, et al.            Expires December 31, 2011              [Page 12]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   o  Allow localized routing service authorization before localized
      routing is initialized.

   o  Treat MAGs under the different LMA in the same way as the MAGs
      under the same LMA.

   o  Get rid of references to individual drafts and only get alignment
      with Localized routing PS document.

10.2.  draft-ietf-dime-pmip6-lr-04

   The following are the major changes compared to previous version 03:

   o  Move the last paragraph in section 3 to the first paragraph.

   o  Using "request" rather than "localized routing optimization
      request".

   o  Using "respond" rather than "localized routing optimization
      response".

   o  Remove the informative reference to [I-D.wu-netext-local-ro].

   o  Using "discovery" rather than "resolution".

   o  Section 5 Fix Typo: "LMA"->"LMA2".

10.3.  draft-ietf-dime-pmip6-lr-05

   The following are the major changes compared to previous version 04:

   o  Redraw the figure 1 to get alignment with the described text.

   o  Section 2 Fix Typo: "the interaction between LMA1 interaction and
      the AAA server-> the interaction between LMA1 and the AAA server"

   o  Section 3 Fix Typo "the data packet from MN1 to MN2 and requesting
      -> the data packet from MN2 to MN1 and requesting"

   o  Section 4 Fix Typo: "MAG1 or LMA may solicit-> MAG1 or LMA1 may
      solicit""

   o  Differentiate MAG initiated case from LMA initiated case in
      Figure5

   o  Add text in section 3 and 4 to explicitly explain how LR
      authorization works in A21.




Zorn, et al.            Expires December 31, 2011              [Page 13]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


   o  Change "localized routing is allowed between MAG1 and MAG2" in
      section 3,4,5 to "MN2 is allowed to use localized routing".

   o  Update the abstract to make the description consistent

   o  Highlight the figure 2,3,4,5 and related texts are examples of how
      LR authorization works using Diameter AAA protocol.

   o  Reference Update.


11.  References

11.1.  Normative References

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

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

   [RFC5779]  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", RFC 5779, February 2010.

11.2.  Informative References

   [RFC6279]  Liebsch, M., Jeong, S., and Q. Wu, "PMIPv6 Localized
              Routing Problem Statement", RFC 6279, June 2011.












Zorn, et al.            Expires December 31, 2011              [Page 14]

Internet-Draft       PMIP6 Localized Routing Support           June 2011


Authors' Addresses

   Glen Zorn
   Network Zen
   227/358 Thanon Sanphawut
   Bang Na, Bangkok  10260
   Thailand

   Phone: +66 (0) 87-040-4617
   Email: gwz@net-zen.net


   Qin Wu
   Huawei Technologies Co., Ltd.
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  21001
   China

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


   Marco Liebsch
   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 December 31, 2011              [Page 15]


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