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]