Internet DRAFT - draft-ietf-dime-pmip6-lr

draft-ietf-dime-pmip6-lr






Network Working Group                                            G. Zorn
Internet-Draft                                               Network Zen
Intended status: Standards Track                                   Q. Wu
Expires: February 3, 2013                                         Huawei
                                                             J. Korhonen
                                                                     NSN
                                                          August 2, 2012


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

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 a Proxy Mobile IPv6 deployment,
   it may be desirable to control the establishment of localized routing
   sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring
   that the session be authorized.  This document specifies how to
   accomplish this 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."

   This Internet-Draft will expire on February 3, 2013.

Copyright Notice

   Copyright (c) 2012 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



Zorn, et al.            Expires February 3, 2013                [Page 1]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Attribute Value Pair Used in this Document . . . . . . . . . .  4
     4.1.  User-Name AVP  . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  PMIP6-IPv4-Home-Address AVP  . . . . . . . . . . . . . . .  5
     4.3.  MIP6-Home-Link-Prefix AVP  . . . . . . . . . . . . . . . .  5
     4.4.  MIP6-Feature-Vector AVP  . . . . . . . . . . . . . . . . .  5
   5.  Example Signaling Flows for Localized Routing Service
       Authorization  . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11





















Zorn, et al.            Expires February 3, 2013                [Page 2]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


1.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobility Access
   Gateway (MAG) to optimize media delivery by locally routing packets
   from a Mobile Node to a Correspondent Node that is locally attached
   to an access link connected to the same Mobile Access Gateway,
   avoiding tunneling them to the Mobile Node's Local Mobility Anchor
   (LMA).  This is referred to as "local routing" in RFC 5213.  However,
   this mechanism is not applicable to the typical scenarios in which
   the MN and CN are connected to different MAGs and are registered to
   the same LMA or different LMAs.  [RFC6279] takes those typical
   scenarios into account and defines the problem statement for PMIPv6
   localized routing.  [I-D.ietf-netext-pmip-lr] specifies the PMIPv6
   localized routing protocol based on the scenarios A11, A12, and A21
   [RFC6279], which is used to establish a localized routing path
   between two Mobile Access Gateways in a PMIPv6 domain.

   However, there is no relevant work discussing how AAA-based
   mechanisms can be used to provide authorization to the Mobile Node's
   MAG or LMA for enabling localized routing between MAGs.

   This document describes Diameter [I-D.ietf-dime-rfc3588bis] support
   for the authorization of PMIPv6 mobility entities in case of
   A11,A12,A21 during localized routing.


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


3.  Solution Overview

   This document addresses how to provide authorization to the Mobile
   Node's MAG or LMA for enabling localized routing and 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
   Routing Service Authorization.  This reference architecture assumes
   that

   o  If MN and CN belong to different LMAs, MN and CN should share the
      same MAG (i.e.,A12 described in [RFC6279]), e.g., MN1 and CN2 in
      Figure 1 are attached to the same MAG1 and belong to LMA1 and LMA2
      respectively.  Note that LMA1 and LMA2 in Figure 1 are in the same
      provider domain (as described in [RFC6279]).




Zorn, et al.            Expires February 3, 2013                [Page 3]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


   o  If MN and CN are attached to the different MAGs, MN and CN should
      belong to the same LMA (i.e.,A21 described in [RFC6279]), e.g.,
      MN1 and CN3 in theFigure 1 are attached to the MAG1 and MAG3
      respectively but belong to LMA1.

   o  MN and CN may belong to the same LMA and are attached to the same
      MAG(i.e.,A11 described in [RFC6279]), e.g.,MN1 and CN1 in the
      Figure 1 are both attached to the MAG1 and belong to LMA1.

   o  The MAG and LMA support Diameter client functionality.


                                             +---------+
                     +---------------------->|  AAA &  |
                     |               +------>| Policy  |
                     |               |       | Profile |
                     |           Diameter    +---------+
                     |               |
                     |            +--V-+    +----+
                     |   +------->|LMA1|    |LMA2|
                     |   |        +---++    +----+
                     |   |          | |       |
                Diameter |          | +-------+---------
                     |   |          |         |        |
                     |  PMIP        |         |        \\
                     |   |         //        //         \\
                     |   |        //        //           \\
                     |   |       //        //             \\
                     |   |       |         |               |
                     |   +---->+---------------+         +----+
                     |         |     MAG1      |         |MAG3|
                     +-------->+---------------+         +----+
                                 :    :      :              :
                              +---+  +---+  +---+         +---+
                              |MN1|  |CN1|  |CN2|         |CN3|
                              +---+  +---+  +---+         +---+

        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 is used to authorize the
   localized routing service.


4.  Attribute Value Pair Used in this Document

   This section describes Attribute Value Pairs (AVPs) defined by this



Zorn, et al.            Expires February 3, 2013                [Page 4]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


   specification or re-used from existing specifications in a PMIPv6-
   specific way.

4.1.  User-Name AVP

   The User-Name AVP (AVP Code 1) is defined in
   [I-D.ietf-dime-rfc3588bis].  This AVP is used to carry the MN-
   Identifier (Mobile Node identifier) [RFC5213] in the AA-Request (AAR)
   message [I-D.ietf-dime-rfc4005bis].

4.2.  PMIP6-IPv4-Home-Address AVP

   The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in
   [RFC5779].  This AVP is used to carry the IPv4-MN-HoA (Mobile Node's
   IPv4 home address)[RFC5844] in the AA-Request (AAR) message
   [I-D.ietf-dime-rfc4005bis].

4.3.  MIP6-Home-Link-Prefix AVP

   The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779].
   This AVP is used to carry the MN-HNP (Mobile Node's home network
   prefix) in the AAR.

4.4.  MIP6-Feature-Vector AVP

   The MIP6-Feature-Vector AVP is defined in [RFC5447].  This document
   allocates a new capability flag bit according to the IANA rules in
   RFC 5447.

   INTER_MAG_ROUTING_SUPPORTED (TBD)

      Direct routing of IP packets between MNs anchored to different
      MAGs without involving any LMA is supported.  This bit is used
      with MN-Identifier.  When a MAG or LMA sets this bit in the MIP6-
      Feature-Vector and MN-Identifier corresponding to the Mobile Node
      is carried with this bit, it indicates to the home AAA server
      (HAAA) that the Mobile Node associated with this LMA is allowed to
      use localized routing.If this bit is cleared and MN-Identifier
      corresponding to the Mobile Node is carried with this bit, it
      indicates to the home AAA server (HAAA) that the Mobile Node
      associated with this LMA is not allowed to use localized routing.
      When a MAG or LMA sets this bit in the MIP6-Feature-Vector and MN-
      Identifiers corresponding to the Mobile Node and Correspondent
      Node are both carried with this bit, it indicates to the HAAA that
      localized routing of IP packets between Mobile Node and
      Correspondent Node anchored to different MAGs is supported.  If
      this bit is cleared and MN- Identifiers corresponding to the
      Mobile Node and Correspondent Node are both carried with this bit



Zorn, et al.            Expires February 3, 2013                [Page 5]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


      to HAAA, it indicates to the HAAA that localized routing of IP
      packets between Mobile Node and Correspondent Node anchored to
      different MAGs is not supported.  If this bit is cleared in the
      returned MIP6-Feature-Vector AVP, the HAAA does not authorize
      direct routing of packets between MNs anchored to the different
      MAG.  The MAG and LMA MUST support this policy feature on a per-MN
      and per-subscription basis.


5.  Example Signaling Flows for Localized Routing Service Authorization

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

   Figure 2 shows an example scenario in which MAG1 acts as a Diameter
   client, processing the data packet from MN1 to MN2 and requesting
   authorization of localized routing (i.e.,MAG-Initiated LR
   authorization).  In this example scenario, MN1 and MN2 are attached
   to the same MAG and anchored to the different LMAs (i.e.,A12
   described in [RFC6279]).  In this case, MAG1 knows that MN2 belongs
   to a different LMA (which can be determined by looking up the binding
   cache entries corresponding to MN1 and MN2 and comparing the
   addresses of LMA1 and LMA2).  In order to setup a localized routing
   path with MAG2, MAG1 acts as Diameter client and sends an 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
   LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5 ) set,two
   instances of the User-Name AVP ([I-D.ietf-dime-rfc3588bis], Section
   8.14)containing MN1-Identifier and MN2-Identifier.  In addition, the
   message may contain either an instance of the MIP6-Home-Link-Prefix
   AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-IPv4- Home-
   Address AVP ([RFC5779], Section 5.2) containing the IP address/ HNP
   of MN1.

   The Diameter server authorizes localized routing service by checking
   if MN1 and MN2 are allowed to use localized routing.  If so, the
   Diameter server responds with an AAA message encapsulating an
   instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section
   4.2.5) with the the LOCAL_MAG_ROUTING_SUPPORTED bit
   ([RFC5779],Section 5.5) set indicating direct routing of IP packets
   between MNs anchored to the same MAG is supported.  MAG1 then knows
   the localized routing between MN1 and MN2 is allowed.  Then MAG1
   sends the Request messages respectively to LMA1 and LMA2.  The



Zorn, et al.            Expires February 3, 2013                [Page 6]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


   request message is the Localized Routing Initialization (LRI) message
   in Figure 2 and belongs to the Initial phase of the localized
   routing.  LMA1 and LMA2 responds to MAG1 using the Localized Routing
   Acknowledge message (LRA inFigure 2 ) in accordance with
   [I-D.ietf-netext-pmip-lr].

   In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr],MAG1
   should ask for authorization of localized routing again according to
   the procedure described above before LRI is retransmitted up to a
   maximum of LRI_RETRIES.


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

      Figure 2: MAG-initiated Localized Routing Authorization in A12

   Figure 3 shows the second example scenario, in which LMA1 acts as a
   Diameter client, processing the data packet from MN2 to MN1 and
   requesting the authorization of localized routing.  In this scenario,
   MN1 and MN2 are attached to the different MAG and anchored to the
   same LMA (i.e., A21 described in [RFC6279] ), LMA knows that MN1 and
   MN2 belong to the same LMA (which can be determined by looking up the
   binding cache entries corresponding to MN1 and MN2 and comparing the
   addresses of LMA corresponding to MN1 and LMA corresponding to MN2).
   In contrast with the signaling flow shown in Figure 2, it is LMA1
   instead of MAG1 which initiates the setup of the localized routing
   path.




Zorn, et al.            Expires February 3, 2013                [Page 7]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


   The Diameter client in LMA1 sends an AA-Request 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 4.5) set indicating direct
   routing of IP packets between MNs anchored to different MAGs is
   supported and two instances of the User-Name AVP
   ([I-D.ietf-dime-rfc3588bis], Section 8.14)containing MN1-Identifier
   and MN2-Identifier.  The Diameter server authorizes the localized
   routing service by checking if MN1 and MN2 are allowed to use
   localized routing.  If so, the Diameter server responds with an AA-
   Answer message encapsulating an instance of the MIP6-Feature-Vector
   (MFV) AVP ([RFC5447], Section 4.2.5) with the
   INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating direct
   routing of IP packets between MNs anchored to different MAGs is
   supported.  LMA1 then knows the localized routing is allowed.  In
   success case, LMA1 responds to MAG1 in accordance with
   [I-D.ietf-netext-pmip-lr].

   In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr],LMA1
   should ask for authorization of localized routing again according to
   the procedure described above before LRI is retransmitted up to a
   maximum of LRI_RETRIES.


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

      Figure 3: LMA-initiated Localized Routing Authorization in A21

   Figure 4 shows another example scenario, in which LMA1 acts as a
   Diameter client, processing the data packet from MN2 to MN1 and
   requesting the authorization of localized routing.  In this scenario,
   MN1 and MN2 are attached to the same MAG and anchored to the same LMA
   (i.e., A11 described in [RFC6279]), LMA knows that MN1 and MN2 belong
   to the same LMA (which can be determined by looking up the binding



Zorn, et al.            Expires February 3, 2013                [Page 8]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


   cache entries corresponding to MN1 and MN2 and comparing the
   addresses of LMA corresponding to MN1 and LMA corresponding to MN2).

   The Diameter client in LMA1 sends an AA-Request message to the
   Diameter server.  The message contains an instance of the MIP6-
   Feature-Vector AVP ([RFC5447], Section 4.2.5) with the
   LOCAL_MAG_ROUTING_SUPPORTED bit set and two instances of the User-
   Name AVP ([I-D.ietf-dime-rfc3588bis], Section 8.14)containing MN1-
   Identifier and MN2-Identifier.  The Diameter server authorizes the
   localized routing service by checking if MN1 and MN2 are allowed to
   use localized routing.  If so, the Diameter server responds with an
   AA- Answer message encapsulating an instance of the MIP6-Feature-
   Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the
   LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5) set
   indicating direct routing of IP packets between MNs anchored to the
   same MAG is supported.  LMA1 then knows the localized routing is
   allowed and responds to MAG1 for localized routing in accordance with
   [I-D.ietf-netext-pmip-lr].

   In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr], LMA1
   should ask for authorization of localized routing again according to
   the procedure described above before LRI is retransmitted up to a
   maximum of LRI_RETRIES.

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

      Figure 4: LMA-initiated Localized Routing Authorization in A11


6.  Security Considerations

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



Zorn, et al.            Expires February 3, 2013                [Page 9]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


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

   An authorised MAG could in principle track the movement of any
   participating CNs at the level of the MAG to which they are anchored.
   If such a MAG were compromised, or under the control of a bad-actor,
   then such tracking could represent a privacy breach for the set of
   tracked CNs.  In such a case, the traffic pattern from the
   compromised MAG might be notable so monitoring for e.g. excessive
   queries from MAGs might be worthwhile.


7.  IANA Considerations

   This specification defines a new value in the Mobility Capability
   registry [RFC5447] for use with the MIP6-Feature-Vector AVP:
   INTER_MAG_ROUTING_SUPPORTED (see Section 4.4).


8.  Contributors

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


9.  Acknowledgements

   The authors would like to thank Marco Liebsch, Carlos Jesus Bernardos
   Cano, Dan Romascanu, Elwyn Davies, Basavaraj Patil, Ralph Droms,
   Stephen Farrel,Robert Sparks, Benoit Claise and Abhay Roy for their
   valuable comments and suggestions on this document.


10.  References

10.1.  Normative References

   [I-D.ietf-dime-rfc3588bis]
              Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34
              (work in progress), June 2012.

   [I-D.ietf-dime-rfc4005bis]
              Zorn, G., "Diameter Network Access Server Application",
              draft-ietf-dime-rfc4005bis-11 (work in progress),
              July 2012.




Zorn, et al.            Expires February 3, 2013               [Page 10]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


   [I-D.ietf-netext-pmip-lr]
              Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6",
              draft-ietf-netext-pmip-lr-10 (work in progress), May 2012.

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

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

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

10.2.  Informative References

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


Authors' Addresses

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

   Phone: +66 (0) 87-040-4617
   Email: glenzorn@gmail.com










Zorn, et al.            Expires February 3, 2013               [Page 11]

Internet-Draft       PMIP6 Localized Routing Support         August 2012


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

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


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

   Email: jouni.nospam@gmail.com


































Zorn, et al.            Expires February 3, 2013               [Page 12]