NetExt Working Group                                       M. Jeyatharan
Internet-Draft                                                     C. Ng
Intended status: Informational                                 Panasonic
Expires: September 10, 2010                                March 9, 2010


                Multihoming Problem Statement in NetLMM
               draft-jeyatharan-netext-multihoming-ps-02

Abstract

   The Proxy Mobile Internet Protocol version 6 (PMIPv6) supports
   multihoming whereby a mobile node (1) gets assigned prefixes by the
   local mobility anchor which are associated with an interface of a
   mobile node and are managed by the PMIPv6 elements as a single IP
   mobility session, and (2) can connect to a Proxy Mobile IPv6 domain
   through multiple interfaces for simultaneous access and get assigned
   a different set of prefix(es) per interface, since being each
   interface managed via an independent mobility session.  However,
   PMIPv6 needs multihoming enhancements such that it needs the ability
   to instantiate additional IP mobility sessions associated with an
   already active interface or a secondary interface of the mobile node
   which has an established IP mobility session at a local mobility
   anchor (LMA), the ability to selectively share home network
   prefix(es) across access technology types, the ability to perform
   flow mobility tied to a subset of prefixes associated with an access
   technology to another access technology and extended support for
   multiple IP mobility sessions in a scenario where multiple interfaces
   of the mobile node are connected to a single mobile access gateway
   (MAG).  This memo highlights such required enhancements to PMIPv6
   multihoming with respect to improved operations and extended
   applicability to different deployment scenarios.

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




Jeyatharan & Ng        Expires September 10, 2010               [Page 1]


Internet-Draft          Multihoming PS in NetLMM              March 2010


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





























Jeyatharan & Ng        Expires September 10, 2010               [Page 2]


Internet-Draft          Multihoming PS in NetLMM              March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Needed Enhancement to Create Dynamic Mobility Sessions . . . .  4
     2.1.  Needed Enhancement to Create Dynamic Mobility Sessions
           via an Interface . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Needed Enhancement to Create Dynamic Mobility Sessions
           Between Interfaces . . . . . . . . . . . . . . . . . . . .  5
   3.  Using the Same HNPs across Multiple Interfaces . . . . . . . .  6
   4.  Adding Prefixes to stable interface due to disconnection
       via unstable interface . . . . . . . . . . . . . . . . . . . .  7
   5.  Enhanced Support to Attach Interfaces to a Single MAG  . . . .  8
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative Reference  . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative Reference  . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 12
   Appendix B.  Use Case analysis if simultaneous usage and
                PMIPv6 Flow filering  . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15




























Jeyatharan & Ng        Expires September 10, 2010               [Page 3]


Internet-Draft          Multihoming PS in NetLMM              March 2010


1.  Introduction

   The Proxy Mobile Internet Protocol version 6 (PMIPv6) [1] supports
   three different multihoming operations.  Firstly, a mobile node (MN)
   can receive home network prefix(es) via a certain interface and all
   assigned prefixes are managed under a single mobility session.
   Secondly, the mobile node is able to attach multiple interfaces to
   the PMIPv6 domain and receive different home network prefixes via
   each interface.  Hence, the mobile node is able to communicate using
   all interfaces.  Thirdly, the mobile node is able to perform flow
   mobility tied to all prefixes of an existing interface to a newly
   attached interface.  However, these multihoming operations need
   further enhancements -- either to increase their efficiency in
   operations or to be applicable to different deployment scenarios.
   This memo highlights such multihoming enhancements required, the need
   for such enhancements, and where applicable, the possible solution
   approaches.

   The required enhancements to PMIPv6 protocol with respect to
   multihoming support are described in three main sections.  Section 2
   describes the enhancement required with respect to the ability to
   dynamically create mobility sessions associated with an interface.
   Section 2 describes dynamically modifying the set of prefixes
   allocated to an interface, either by adding new prefixes or by
   transferring some or subset of prefixes from one interface to
   another.  The draft [2] highlights a solution to achieve such flow
   movement tied to subset of prefixes.  Section 3 describes multihoming
   enhancement needed to use the same home network prefix(es) across
   multiple interfaces to achieve benefits such as load sharing, load
   balancing, aggregated bandwidth and flow based routing.  The drafts
   [3] and [4] highlights a solution for the usage of same home network
   prefix(es) across multiple interfaces.  Section 4 highlights the
   needed work in fast handoff when one of the interface suddenly looses
   connection and flows need to be transferred via a stable or connected
   interface.  Section 5 highlights enhancement needed to PMIPv6
   protocol operations and some optimizations that can be done to the
   PMIPv6 protocol, when applied to a scenario where multiple interfaces
   of a mobile node are attached to the PMIPv6 domain via a single MAG.
   All the enhancements highlighted in this memo are targeted towards a
   MN that cannot manage its mobility on its own.


2.  Needed Enhancement to Create Dynamic Mobility Sessions

2.1.  Needed Enhancement to Create Dynamic Mobility Sessions via an
      Interface





Jeyatharan & Ng        Expires September 10, 2010               [Page 4]


Internet-Draft          Multihoming PS in NetLMM              March 2010


   o  Problem

      In PMIPv6 protocol, all the home network prefixes assigned to an
      interface are established when the mobility session is first
      created for a given interface.  There is no support for adding
      home network prefix(es) to the same interface in a dynamic manner.
      Thus, creating multiple mobility sessions or binding cache entries
      for a given interface is not possible according to the PMIPv6
      protocol.

   o  Motivation

      Such support is required especially in the cases where a mobile
      node wants to get appropriate home network prefixes to access
      services from the packet data networks (PDNs) in a 3GPP evolved
      packet core at different points in time rather than getting all
      the home network prefixes to access services at the same time.
      For example, a mobile node may want prefixes P1 and P2 to access
      services from packet data networks PDN1 and PDN2 respectively at
      time instance T1.  Later at time instance T2, it needs to access
      services from PDN3 (thus requiring a prefix P3 to be assigned).

   o  Possible Approaches

      To support this use case, PMIPv6 mechanism should be extended to
      support multiple mobility sessions associated with a given
      interface, each having a different group of prefixes assigned and
      may have different binding lifetime attached.

2.2.  Needed Enhancement to Create Dynamic Mobility Sessions Between
      Interfaces

   o  Problem

      In PMIPv6 protocol, when a mobile node powers on a new interface,
      the new mobile access gateway sets the handoff indication option
      value to '2'.  All the prefixes that are assigned to the
      previously attached interface are then transferred to the new
      interface.  When such transfer takes place, the binding cache
      entry of current interface is updated with the new binding cache
      entry created for the new interface.  This is inflexible, as it
      cannot support the case where only some (but not all) prefixes
      that are assigned to one interface are transferred to a newly
      powered on interface, or transferred to an already connected
      interface.

   o  Motivation




Jeyatharan & Ng        Expires September 10, 2010               [Page 5]


Internet-Draft          Multihoming PS in NetLMM              March 2010


      Such dynamic management of mobility sessions whereby a subset of
      prefixes are removed from one interface and transferred to another
      interface is useful to support load balancing of flows across
      different interfaces of the mobile node.  It also enable the flows
      tied to the transferred prefixes to traverse via a preferred or
      suitable access technology type for want of a better quality of
      service (QoS) or cheaper service.

   o  Possible Approaches

      To support this type of prefix transfer, new signalling mechanisms
      may be required in PMIPv6 to allow (a) the removal of one or more
      (but not all) home network prefixes from an interface of the
      mobile node, (b) the addition of one or more home network prefixes
      to a connected interface of the mobile node, and (c) the handoff
      of one or more (but not all) home network prefixes from an
      existing interface to a newly connected interface.  The draft [2]
      highlights the motivation and signaling interactions between MAG
      and LMA to achieve such flow mobility of subset of prefixes.


3.  Using the Same HNPs across Multiple Interfaces

   o  Problem

      PMIPv6 protocol operation is such that different home network
      prefixes are assigned to different interfaces of the mobile node.
      PMIPv6 does not support selectively using the same home network
      prefix across multiple interfaces of the mobile node.  Benefits of
      doing this is thus not enjoyed with RFC5213.

   o  Motivation

      If the flows associated with home network prefix(es) are allowed
      to traverse via multiple interfaces of the mobile node by allowing
      the same home network prefix to be assigned to multiple interfaces
      of the mobile node, then the mobile node can achieve higher
      aggregated bandwidth for flows tied to the home network prefix as
      well as achieve load balancing of traffic across its interfaces.
      Additionally, it is not only the mobile node that will enjoy
      benefits from sharing the same prefix among multiple interfaces,
      the network side can also benefit from it as well.  For instance,
      when the local mobility anchor receives a packet destined for a
      home network prefix, it can choose among multiple routes to
      different interfaces of the mobile node to forward the packet.
      Such choice allows better utilization of the network resources and
      the network can avoid congested region of the local network
      domain.  Furthermore, with the same home network prefix assigned



Jeyatharan & Ng        Expires September 10, 2010               [Page 6]


Internet-Draft          Multihoming PS in NetLMM              March 2010


      to multiple interfaces, flow based routing can be achieved.  For
      instance, the mobile node can choose to install filters on the
      network to route packets of realtime interactive application
      through its cellular interface which offers QoS assurance, and
      packets of other non-realtime application through other
      interfaces.  A 3GPP operator can also have routing policy which
      route VoIP packets over the cellular radio network, while file
      transfer packets are routed over the WLAN network.

   o  Possible Approaches

      There are two requisites associated with selective usage of same
      home network prefix across multiple interfaces of the mobile node.
      The first requisite is being able to selectively use the same home
      network prefix across multiple interfaces and being able to
      receive flows tied to the home network prefix via any interface of
      the mobile node.  This allows improved load balancing and
      aggregated bandwidth.  The second requisite is is to be able to
      specify which flows are expected to traverse via which selected or
      preferred interface(es).  This allows flow filtering in PMIPv6
      based on user's preference or operator policy.

      To achieve the first requisite, it might be necessary for the
      mobile access gateway to be informed of which home network
      prefixes are shared between multiple interfaces.  This can be
      informed by the mobile node or the local mobility anchor.  It is
      also necessary for multiple routing paths to be enabled for a
      shared home network prefix among the affected mobile access
      gateways and the local mobility anchor.  The mobile node should
      also accepts data packet sent to a shared home network prefix via
      any of its connected interfaces.

      To achieve the second requisite, it should be possible for the
      local mobility anchor to route packets based on explicitly
      specified flow filters.  Such filters may be dynamically installed
      (and modified) by the network operator or the mobile node.  To
      further understand the different simultaneous usage scenario and
      flow filtering scenarios more elaborate explanation is given in
      Appendix B.


4.  Adding Prefixes to stable interface due to disconnection via
    unstable interface

   In Figure 2, it is considered that the mobile node MN is attached to
   the PMIPv6 domain via both its interfaces.





Jeyatharan & Ng        Expires September 10, 2010               [Page 7]


Internet-Draft          Multihoming PS in NetLMM              March 2010


   o  Problem

      In PMIPv6 protocol, when one of the interface undergo handoff, the
      other interface might still be attached to the same access router.
      For example, due to the coverage area differences, the mobile node
      may change its access router for the WLAN interface while the
      access router of its 3G interface remains unchanged.  If the
      mobile node suddenly loses connection to the network via the WLAN
      interface, according to standard PMIPv6 operation, the mobile node
      needs to trigger vertical handoff at the 3G MAG so as to maintain
      session continuity via its cellular interface.  However, in some
      cases of disconnection, the mobile node may not have enough time
      to trigger vertical handoff at 3G MAG without suffering packet
      loss.  Furthermore, according to PMIPv6 protocol, prefixes cannot
      be dynamically assigned to a connected interface and the mobile
      node may not be able to transfer the prefix tied to the interface
      that suddenly looses connection to a connected interface by simply
      using the HI value of "2" in the handoff PBU.

   o  Motivation

      For real time transmission, it is essential that packet loss
      should be reduced or avoided for the user to enjoy high user
      perceived QoS.  Thus, there should be a fast handover binding
      mechanism to re-route flows to another interface when one
      interface has lost its connection with the shortest possible
      delay.

   o  Possible Approaches

      A possible approach to solve this issue will be such that a
      binding to flows tied to an interface via which disconnection will
      happen to a stable interface needs to be present and stored in the
      system whereby, when disconnection happens packet loss can be
      prevented.  Such mechanism is highlighted in [5].


5.  Enhanced Support to Attach Interfaces to a Single MAG

   o  Problem

      The PMIPv6 protocol supports simultaneous attachment to PMIPv6
      network via multiple interfaces of a mobile node but with the
      assumption that each of the interfaces is attached to different
      mobile access gateways.  However, in some deployment scenarios, a
      mobile access gateway may be handling different access technology
      types and may results in the mobile node attaching to the same
      mobile access gateway via multiple interfaces, such as illustrated



Jeyatharan & Ng        Expires September 10, 2010               [Page 8]


Internet-Draft          Multihoming PS in NetLMM              March 2010


      in Figure 1.  In section 5.3.1 of RFC5213, it is mentioned that if
      the Proxy-CoA in the binding cache entry matches the source
      address of the binding cache entry update request, considerations
      associated with binding lifetime extension (No handoff) MUST be
      applied.  Thus it is clear that the PMIPv6 protocol does not
      handle inter technology handoff where the mobile node is connected
      simultaneously to the same mobile access gateway.  In addition,
      since the same mobile access gateway will be sending multiple PBU
      messages for the same mobile node, it will be desirable if these
      can be combined into one PBU message.

                                +---------------+-----------+--------+
                                | Home Prefix   | CoA       | IF-ID  |
                   +--------+   +---------------+-----------+--------+
                   |  LMA   |   | MN.Prefix1(P1)| MAG1.Addr | IF-ID1 |
                   +--------+   | MN.Prefix2(P2)| MAG1.Addr | IF-ID2 |
                        |       +---------------+-----------+--------+
                        |
                  +--------------------------+
                  |                          |
                  | Proxy Mobile IPv6 Domain |
                  |                          |
                  +--------------------------+
                                |
            MAG1 Address        |
      (MN.IF2/MN.IF1 proxy CoA) |
                         +-------------+
                         |    MAG1     |
                         +-------------+
                            \        /
                     IF2(3G) \      / IF1(WLAN)
                             +------+
                             |  MN  |
                             +------+

             Figure 1: Multiple Interfaces attaching to same MAG

   o  Motivation

      There are valid scenarios in some standard organizations where a
      single mobile access gateway may handle multiple attachments of a
      mobile node.  For instance in 3GPP, it is possible for a Serving
      Gateway (S-GW) to be serving as the mobile access gateway for both
      the cellular and wireless-LAN access of a mobile node (e.g. the
      LTE access and the I-WLAN access are both connected to the same
      S-GW).  In such scenarios, the PMIPv6 operation needs to be
      extended such that inter access technology handoff can be
      correctly and efficiently performed.



Jeyatharan & Ng        Expires September 10, 2010               [Page 9]


Internet-Draft          Multihoming PS in NetLMM              March 2010


   o  Possible Approaches

      In order to be able to support a scenario where the same mobile
      access gateway is proxying for multiple attachments of a single
      mobile node, operation of the local mobility anchor should be
      modified.  For instance, the local mobility anchor should rely
      only on the proxy care-of address when updating the binding cache
      entries.  Other factors, such as the hand off indication option,
      should also be taken into account.

      To improve signalling efficiency, one possible approach is to
      allow the mobile access gateway to send a single PBU message when
      creating (or refreshing) multiple mobility sessions for the mobile
      node. well.


6.  Conclusion

   In this memo, we highlighted additional work that has to be done with
   respect to multihoming for the PMIPv6 protocol.  The main categories
   of additional work are summarized as follows:

   o  Being able to use same HNP across multiple interfaces of the MN so
      that flows tied to a given HNP can reach the MN via a plurality of
      interfaces.

   o  Achieving flow mobility when a subset of prefixes needs to be
      transferred to the newly powered on interface or connected
      interface.

   o  Achieving flow based routing to interface(s) for particluar flows
      associated with a prefix given to a multiple interfaced MN.

   o  Achieving fast vertical handoff and session continuity during
      disconnection of one of the interfaces.

   o  Achieving dynamic prefix addition to an interface.

   o  Extending PMIPv6 operation in scenarios where multiple interfaces
      are attached to the same MAG.


7.  IANA Considerations

   This is an informational document and does not require any IANA
   action.





Jeyatharan & Ng        Expires September 10, 2010              [Page 10]


Internet-Draft          Multihoming PS in NetLMM              March 2010


8.  Security Considerations

   This document explores the problem of providing advanced multihoming
   for mobile nodes with multiple interfaces connecting to a single
   PMIPv6 domain.  No additional security threat is identified as of the
   writing of this memo that is specific to multiple interfaces support.


9.  Acknowledgements

   The authors would like to express their gratitude to (in alphabetical
   order) Carlos Jesus Bernados Cano, Basavaraj Patil, David Cypher,
   Yungui Wang and Hidetoshi Yokota for their gracious comments which
   have helped improve the draft.


10.  References

10.1.  Normative Reference

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

10.2.  Informative Reference

   [2]  Jeyatharan, M., Ng, C., Gundavelli, S., Leung, K., and V.
        Devarapalli, "Partial Handoff Support in PMIPv6",
        draft-jeyatharan-netext-pmip-partial-handoff-02 (work in
        progress), February 2010.

   [3]  Koodli, R. and K. Chowdhury, "Flow Handover for Proxy Mobile
        IPv6", draft-koodli-netext-flow-handover-01 (work in progress),
        October 2009.

   [4]  Hui, M. and H. Deng, "PMIPv6 Multihoming Extension and
        Synchronization in LMA and MAG", draft-hui-netext-multihoming-00
        (work in progress), October 2009.

   [5]  Jeyatharan, M. and C. Ng, "Fast Handoff using Dormant Bindings
        in PMIPv6", draft-jeyatharan-netext-pmip-dormant-binding-00
        (work in progress), October 2009.

   [6]  Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K.
        Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic
        Support", draft-ietf-mext-flow-binding-05 (work in progress),
        February 2010.

   [7]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K.



Jeyatharan & Ng        Expires September 10, 2010              [Page 11]


Internet-Draft          Multihoming PS in NetLMM              March 2010


        Nagami, "Multiple Care-of Addresses Registration",
        draft-ietf-monami6-multiplecoa-14 (work in progress), May 2009.

   [8]  "Technical Specification Group Services and System aspects",
        3GPP TR 23.402, December 2007.


Appendix A.  Change Log

   o  draft-jeyatharan-netext-multihoming-ps-02:

      *  Added one new section 4: Fast handoff support when sudden
         disconnection happens and flows needs to be transferred via
         existing interface.

      *  Modified the conclusion and have added new summary bullets.

      *  Removed the PMIP/CMIP interaction section from draft.

      *  Added more solution drafts and highlighted the problems they
         are trying to solve.

   o  draft-jeyatharan-netext-multihoming-ps-01:

      *  Added two new sections: One about dynamic creation of mobility
         sessions and another about supporting multiple interfaces via a
         single MAG.

      *  Improved the same HNP usage across multiple interfaces by
         highlighting mor on solution space.

      *  Moved the PMIP/CMIP interaction section and some scenarios that
         are more tied to handoff to appendix.

   o  draft-jeyatharan-netext-multihoming-ps-00:

      *  Initial version.


Appendix B.  Use Case analysis if simultaneous usage and PMIPv6 Flow
             filering

   To further understand the need for having the same home network
   prefix across multiple interfaces of the mobile node, consider the
   scenario depicted in Figure 2.






Jeyatharan & Ng        Expires September 10, 2010              [Page 12]


Internet-Draft          Multihoming PS in NetLMM              March 2010


                    +-----+    +-----+
                    | CN2 |....| CN3 |
                    +-----+    +-----+
                       |
                       |        +---------------+-----------+--------+
                       |        | Home Prefix   | CoA       | IF-ID  |
       +-----+     +--------+   +---------------+-----------+--------+
       | CN1 |-----|  LMA   |   | MN.Prefix1(P1)| MAG1.Addr | IF-ID1 |
       +-----+     +--------+   | MN.Prefix2(P2)| MAG2.Addr | IF-ID2 |
                        |       +---------------+-----------+--------+
                        |
                  +--------------------------+
                  |                          |
                  | Proxy Mobile IPv6 Domain |
                  |                          |
                  +--------------------------+
                         |             |
          MAG2 Address   |             |    MAG1 Address
      (MN.IF2 proxy CoA) |             | (MN.IF1 proxy CoA)
                      +------+     +------+
                      | MAG2 |     | MAG1 |
                      +------+     +------+
                            \        /
                     IF2(3G) \      / IF1(WLAN)
                             +------+
                             |  MN  |
                             +------+

               Figure 2: Simultaneous Usage in PMIPv6 Domain

   In Figure 2, it is assumed that the mobile node MN has two interfaces
   IF1 (3G cellular) and IF2 (WLAN) which are attached to mobile access
   gateway MAG1 and MAG2 respectively.  According to PMIPv6 operation,
   it is considered that the IF1 will be assigned prefix P1 and IF2 will
   be assigned prefix P2.  Thus, all flows addressed to prefix P1 will
   traverse via IF1 only and all flows addressed to prefix P2 will
   traverse only via IF2.  Suppose MN is having video conference with
   correspondent node CN1, then MN may want the audio flows to traverse
   via 3G interface for better quality of service and the video flows to
   traverse via WLAN interface to get a higher bandwidth.  The media
   flows associated with an application can be uniquely identified by a
   combination of parameters such as flow label, transport protocol
   numbers and port numbers as outlined in [6].

   Normally, the audio and video flows of the same application will have
   the same pair of endpoint addresses.  Thus, with current PMIPv6 as
   specified in RFC5213, the mobile node MN cannot split the video
   conference flows to traverse via different interfaces.  This is



Jeyatharan & Ng        Expires September 10, 2010              [Page 13]


Internet-Draft          Multihoming PS in NetLMM              March 2010


   because the prefix P1 is tied to IF1 only and there is no mechanism
   available to set PMIPv6 filter or flow based routing.  To fully enjoy
   the benefit of simultaneous usage of interfaces for such video
   conference application, it must be possible for prefix P1 to be used
   by multiple interfaces.  LMA should have support such that same home
   network prefix or P1 should be tied to multiple interfaces, MAG2
   should be aware of other interface prefix P1 and some filter rules
   needs to be set at LMA such that it is given instructions to route
   above mentioned voice flows associated with prefix P1 via interface 2
   only and above mentioned video flows associated with prefix P1 via
   IF1 only.  The requirement for same home network prefix usage across
   MN interfaces and filter rule setting may need MN involvement.  It is
   clear that new functionality is essential in LMA, MAG and even in the
   MN to achieve simultaneous usage of MN interfaces for traversal of
   such multimedia application flows.  This use case specifically
   highlights a need for a HNP being used via multiple interfaces and
   the need to set filter rules in the PMIPv6 network.

   In an alternate scenario associated with Figure 2 it is considered
   that MN is downloading some data files and also performing some web
   browsing and the CNs from which the MN is getting such data are CN1
   and CN2 respectively.  It is further considered that the prefix
   associated with MN to communicate with CN1 and CN2 is P1 and all the
   data packets associated with file transfer and web browsing will
   traverse via IF1.  However, when the 3G interface is not used much by
   the MN for other flows, the MN may want all the data flows sent to
   prefix P1 from CN1 and CN2 to be sent to both interfaces of MN to
   achieve higher bandwidth for web browsing and file transfer
   applications.  The MN can inform the LMA via the MAG that it needs P1
   flows associated with above mentioned applications via both its
   interfaces.  In this use case for same HNP(es) across MN interfaces,
   MN does not specify flow based routing preference.  Instead MN needs
   to indicate to LMA that any interface can be used for the flows
   associated with the above mentioned web browsing and file transfer
   applications.  As explained previously, PMIPv6 protocol does not
   support same home network prefix(es) usage across its interfaces.
   For such same home network prefix usage to happen, in case of
   downlink packets for example, MAG2 needs to be able to route packets
   sent to prefix P1, LMA needs to be able to route packets sent to
   prefix P1 via MAG2 as well as MAG1 and MN needs to know that this is
   PMIPv6 network and be able to configure prefix P1 for IF2 or be able
   to accept packet addressed to IF1 via IF2.  All these changes needs
   to be done to get the benefits attached to this use case.

   In another scenario associated with Figure 2, MN may have started
   communication with CN1 using prefix P1 and communication with say CN3
   using P2.  However, due to load balancing feature or function being
   implemented in the PMIPv6 network, the LMA may send certain P2 flows



Jeyatharan & Ng        Expires September 10, 2010              [Page 14]


Internet-Draft          Multihoming PS in NetLMM              March 2010


   via IF1 and certain P1 flows via IF2.  Such network initiated load
   balancing is essential in order to take some measures to prevent the
   network segments from being overloaded.  In some cases, the MN may
   give its preference such as inform the network which P1 flows it does
   not mind being sent via interface 2 and which P2 flows it does not
   mind being sent via interface 1.  Thus in such a scenario, both MAG1
   and MAG2 need to know MN other interface prefixes and flow parameters
   and also the LMA need to send some P1 flows via MAG2 and some P2
   flows via MAG1.  Again, this use case highlights the need to support
   same multiple home network prefixes P1 and P2 across MN interfaces
   and be able to set flow based routing rules associated with multiple
   prefixes at LMA.


Authors' Addresses

   Mohana Dahamayanthi Jeyatharan
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG

   Phone: +65 65505494
   Email: mohana.jeyatharan@sg.panasonic.com


   Chan-Wah Ng
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG

   Phone: +65 65505420
   Email: chanwah.ng@sg.panasonic.com















Jeyatharan & Ng        Expires September 10, 2010              [Page 15]