Network Working Group D. Liu Internet-Draft Z. Cao Intended status: Informational China Mobile Expires: January 11, 2011 P. Seite France Telecom - Orange H. Chan Huawei Technologies July 10, 2010 Distributed mobility management draft-liu-distributed-mobility-02 Abstract Current mobility solutions generally introduce an anchor point in the network, e.g., HA in MIPv6, LMA in PMIPv6, GGSN in 3GPP. The anchor point is used to maintain the mapping between the stable IP address (e.g., Home address in MIPv6) and the current routable IP address (e.g., CoA in MIPv6). However, one of the trend in mobile network evolution is to "flatten" mobility architecture by confining mobility support in the access network, e.g. at the access routers level, keeping the rest of the network unaware of the mobility events and their support. This document discusses the deployment of current IP mobility mechanisms in such a flat architecture. 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 January 11, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires January 11, 2011 [Page 1] Internet-Draft DMM July 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Motivation for flattening mobile network architecture . . . . 4 3.1. General considerations . . . . . . . . . . . . . . . . . . 4 3.2. IP Flow Mobility support in flat architectures . . . . . . 5 3.3. Dynamic mobility anchoring . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Considerations of distributed mobility solutions . . . . . . . 9 6.1. Client-based solutions . . . . . . . . . . . . . . . . . . 9 6.2. Network based solutions . . . . . . . . . . . . . . . . . 11 6.3. Splitting the routing and the location management function . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Liu, et al. Expires January 11, 2011 [Page 2] Internet-Draft DMM July 2010 1. Introduction Most existing IP mobility solutions are derived from Mobile IP [RFC3775] principles where a given mobility anchor (e.g. the Home Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy Mobile IPv6 [RFC5213] maintains Mobile Nodes (MNs) bindings. Data traffic is then encapsulated between the MN or its Access Router (e.g. the Mobile Access Gateway (MAG) in PMIPv6) and its mobility agent. These approaches lead to the implementation of centralised architectures where both MN context and traffic encapsulation need to be maintained at a central network entity, the mobility anchor. Such centralised approach provides the ability to route MN traffic whatever MN's localisation while maintaining IP session continuity during handovers. However, when hundreds of thousands of MNs are communicating in a given cellular network, a centralized mobility anchoring point causes well-known bottlenecks and single point of failure issues, which requires costly network dimensioning and engineering to be fixed. In addition, tunnelling encapsulations impact the overall network efficiency since they require the maintenance of MN's specific contexts in each tunnel end nodes and they incur delays in packet processing and transport functions. It is however well established that a huge amount of mobile communications are set up while the user is not physically moving, i.e. its MN stays in the same radio cell. For example, the user is being communicating at home, in his office, at a cafe... Applying the aforementioned centralised principles leads then to aggregate user's contexts and traffic at a central node in the network for the sake of mobility support whereas the MN remains motionless. As this leads to the introduced scalability and performances issues, alternative approaches may consider a way to better adapt mobility support in the network to cope with MN's movements and its ongoing traffic flows' requirements. Typically, one of the trend in the evolution of mobile networks is to go to a flat architecture with the distribution of network functions, including mobility functions, close to the access gateways. This document discusses the deployment of current IP mobility mechanisms (Mobile IPv6 and proxy Mobile IPv6) in such a flat architecture by dynamically distributing the mobility handling functions among terminals and access routers. The goal is twofold: o confining the mobility support at the access routers level, keeping the rest of the network unaware of mobility events and their support. o dynamically adapting mobility support to each of the MN's needs by applying traffic redirection only to MNs' flows that are already established when an IP handover occurs; Liu, et al. Expires January 11, 2011 [Page 3] Internet-Draft DMM July 2010 2. Conventions used in this document 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 [RFC2119]. 3. Motivation for flattening mobile network architecture 3.1. General considerations Development of new mobile services and usages (e.g., video streaming, mobile Internet) has led to huge increase of data traffic on the mobile network, thus giving much pressure to the mobile operator's core network. In order to address scalability and performance issues with current centralized architecture, one of the trends in network evolution is to leverage on local content delivery network (CDN) where IP communications with local services are routed directly to the CDN without going through the IP core network. For the same reason, it is now preferable to offload the traffic that are not generated by mobile services from the IP core of the mobile network (e.g. Internet traffic should be offloaded). On the other hand, IP communications with mobile services are routed via a centralized anchor point (e.g., the PGW in 3GPP/EPS mobile network). In current proposals for network evolution, a local traffic anchor (i.e. a local gateway, L-GW), usually located near the access router, is in charge of offloading the traffic (e.g. Internet and local traffic). The generic mobile architecture with offload capabilities is depicted in Figure 1; it illustrates the following use-cases: o Mobile node MN1 is attached to access router AR1 and consumes service delivered by the local CDN. So, the corresponding IP flows are routed directly from AR1 to the CDN. o MN2 is attached to AR1 and has an IP communication with CN. So, the corresponding IP flows are routed to the packet data network PDN, via a centralized traffic anchor. o MN3 is attached to AR2. MN3 has an IP communication with CN and get access to the Internet. The IP flow corresponding to Internet traffic is offloaded to the local Internet access via the L-PGW, whereas the IP communication with CN is routed via the centralized traffic anchor. Liu, et al. Expires January 11, 2011 [Page 4] Internet-Draft DMM July 2010 +----+ ,-'' |CN |. +----------+ ,' +----+ \---------| central | / Packet \ | anchor | | Data | +----------+ \ Network ,' | `. _, | `-..____,,' ***************** * IP network * __...._ * * ,' `-. +---------+ +----+ +----+ / Internet \ | Local |__ |L-GW| |L-GW|--- | Access | | Content | +----+ +----+ \ ,' | Delivery| * * `-._ _,' | Network | ****************** `''' +---------+ || || +----+ +----+ |AR1 | |AR2 | +----+ +----+ | | | | | | MN1 MN2 MN3 Figure 1: Deployment of Local content delivery and IP traffic offload in a centralized mobility architecture 3.2. IP Flow Mobility support in flat architectures When the host can simultaneously connect to different access systems, IP flow mobility is considered by operator as a flexible way to route traffic according network access and applications specific contraints. For example, a given IP flow (e.g. video streaming), initially routed through one access, could be selectively offloaded to another access while maintaining other traffic (e.g. traffic with specific QoS requirements) on the primary access. This kind of traffic management is specified in [TR23.261] when considering centralized architecture. This section discusses deployment of IP mobility mechanisms in flat mobile architectures as specified in Figure 1. Existing mobility solutions generally introduce a mobility anchor in the network; examples are HA in MIPv6, LMA in PMIPv6, and GGSN/PGW in 3GPP. The mobility anchor is used to maintain the mapping between the stable IP address (e.g., Home address in MIPv6) and the current routable IP address (e.g., CoA in MIPv6). In the centralized architecture, the mobility anchor point is usually located at the top Liu, et al. Expires January 11, 2011 [Page 5] Internet-Draft DMM July 2010 of the architecture. Yet in a flat architecture, such as the one depicted in Figure 1, the traffic anchor point can be much lower (e.g. located in the access system) compared with centralized architecture. So, for the sake of routing optimization the mobility anchor should also be located closer to the traffic anchoring point, otherwise the traffic could not break out locally. Actually, routing optimization issue will become more severe in the flat architecture if traditional mobility protocol is used. The mobility tunnel needs to be connected back to the mobility anchor where the mobile node attaches (and gets the IP address allocation). Then all IP traffic of that mobile node will be routed through the mobility anchor. Despite the well-known scalability issues brought by centralized approaches, a central mobility anchor in a flat architecture leads to non-optimal routing for local and offloaded traffic: the data path goes through the central mobility anchor point before being routing back to the local traffic anchoring point (e.g. L-GW). Such non- optimal routing may degrade the user experience due to the latency caused by the long route to the destination. So, in a mobile architecture distributing the traffic anchoring, as depicted on Figure 1, the mobility anchoring function shall also be distributed to provide efficient IP session continuity for both local and centralized traffic. Figure 2 shows an example of distributed IP mobility architecture. In this example mobility anchors are deployed both in the centralized traffic anchoring point and in the access routers to manage respectively mobility of centralized and local traffic. Liu, et al. Expires January 11, 2011 [Page 6] Internet-Draft DMM July 2010 +----+ ,-'' |CN |. +-----------+ ,' +----+ \---------| Mobility | Mobility / Packet \ |anchor (MA)| Anchor | Data | +-----------+ for centralized \ Network ,' | traffic `. _, | `-..____,,' ***************** * IP network * __...._ * * ,' `-. +---------+ +----+ +----+ / Local \ | Local |__ |L-GW| |L-GW|--- | content | | Content | | | | | | | | Delivery| +----+ +----+ \ ,' | Network | ****************** `''''''`''' +---------+ || || +----+ +----+ mobility |AR1 | |AR2 | anchors |+MA |+MA | for local +----+ +----+ traffic | | 3GPP | |WiFi +-----MN1----+ Figure 2: Distributed Mobility Anchoring 3.3. Dynamic mobility anchoring Applying the centralized mobility management principles leads to aggregate user's contexts and traffic at a central node in the network whereas the MN remains stationary. However, once attached to the new access router, the mobile node can again acquire a routable global IPv6 address to be used for any new communication flow it sets up. Hence, a flow based mobility support may be restricted to provide traffic indirection to host's flows that are already ongoing during host's handovers between access routers. Any new flow being set up uses the new host's global address acquired on the new link available after the handover. When a multiple-interfaces node moves an IP flow between access routers of different access technologies, such a simple approach can also apply. Flow mobility management should then be required only to support the necessary traffic indirection from the mobility anchor on Liu, et al. Expires January 11, 2011 [Page 7] Internet-Draft DMM July 2010 which the flow has been initially set up to the access router to which the host is currently attached. Hence, any given IP flow can be considered as implicitly anchored on the current MN's access router when being set up. So, it leads to deploy mobility anchors in access routers. While the MN is attached to its initial access router, the IP flow is delivered as for any standard IPv6 node. The mobility anchoring at the access router then allow to manage traffic indirection if the MN moves to a new access router (and for subsequent movements while the IP flow remains active), maintaining the flow communication until it ends up. 4. Requirements This section gives the requirements for mobility management support in flat architectures. o To ensure the IP traffic offload in the flat architecture and still maintain the service continuity, the mobility anchoring should close to the local gateway(access router),i.e. confining mobility support to the access routers level, keeping the rest of the network unaware of mobility events. For example, the access router mayshould be the anchoring point of local IP traffic. o IP flow mobility: it shall be possible to offload selected traffic (e.g. Internet) by moving IP flows from one access to another. o It is preferred for the distributed mobility solution requiring less changes to the network and current mobility protocols. The distributed mobility solution should compatible with legacy mobility mechanisms. This requirement may help the distributed mobility solution easier for deployment o Mobility mechanism should come into play only for node on the move (optional feature) . It leads to dynamically adapting mobility support to each MN's needs by applying traffic redirection only to MN's flows those are ongoing when handover occurs. 5. Gap analysis Current mobility protocols (DSMIPv6/PMIPv6) may be used in the flat architecture. For example, for the architecture depicted in figure 1, DSMIPv6 or PMIPv6 may be used. The L-GW (Local Gateway in Figure 2) could be the mobility anchor point (HA/LMA) for DSMIPv6/PMIPv6 and also act as MAG for PMIPv6. But it is not optimized in many ways. Liu, et al. Expires January 11, 2011 [Page 8] Internet-Draft DMM July 2010 1. Non-optimized routing: When the UE attaches to the network through one L-GW, that L-GW will be the anchor point of that UE. When the UE moves out of this L-GW's service area, the UE/MAG has to establish a mobility tunnel back the original L-GW. Obviously, the routing is not optimized since the UE/MAG always needs to establish the mobility tunnel back to the original L-GW no matter where it has moved to. This will increase unnecessary traffic to the operator's network compared with locally breaking out the traffic. In LTE/SAE network, when the UE attaches to the network it will always keep that IP address, this feature is called "always on". The "always on" feature will worsen the problem. The reason is that in 2G/3G mobile network, when the UE terminates a session, it will detach from the network, when it attach to the network again, it will get a new IP address and the anchor point could be changed to the L-GW accordingly. But in LTE/SAE, the UE does not detach from the network as long as it is power on. 2. Increased delay: The non-optimized routing causes the routing path to be much longer compared with local breakout, this will increase the transmission delay. 3. Single point of failure: The UE will always depend on its original anchor point to maintain service continuity to wherever it has moved. This will cause the single point of failure problem compared with distributing the mobility anchor function. 6. Considerations of distributed mobility solutions This section discusses the applicability of MIPv6/PMIPv6 in flat architectures. Based on the above analysis, there may be an interest to consider specific deployment of mobility mechanisms in flat architecture. This kind of solution may be called distributed mobility solutions since the mobility anchor function is distributed compared with the centralized mobility anchor point in traditional mobility protocol. The distributed mobility solutions should make minimal changes to the existing network entity. It is preferable to require no change to the UE and be transparent to the application layer. The following sub-sections only give basics for distributed mobility, the detailed solutions will be identified in future. 6.1. Client-based solutions One solution to deploy Mobile IP in a flat architecture is to implement the HA functionalities in the access routers, as shown on Figure 3. Any given IP flow can be considered as implicitly anchored Liu, et al. Expires January 11, 2011 [Page 9] Internet-Draft DMM July 2010 on the current host's access router when set up. In addition, dynamic mobility anchoring [I-D.kassi-mobileip-dmi] could avoid data encapsulation for motionless nodes: until the host does not move, the IP flow is delivered as for any standard IPv6 node. The anchoring function at the access router is acting only to manage traffic indirection while the host moves to a new access router. So, when the MN handoff, its current traffic is still attached to the anchor access router which is responsible for forwarding the IP flows to the MN.For example, let's consider an IP flow, flow#1, initiated by the mobile node, MN, when attached to AR2. Flow#1 will is routed in a standard way as long as the MN remain attached to AR2. If the MN moves to AR3, flow#1 remains anchored to AR2, which plays the role of HA. If MN starts a new IP communication, flow#2, while attached to AR3; flow#2 will be routed in a standard way as long as the MN remains attached to AR3. Then, if the MN moves to AR1, flow#1 and flow#2 will be respectively anchored to AR2/HA and AR3/HA. +---+ +---+ +---+ |CN1| |CN2| |CN3| +---+ +---+ +--,+ _.---------+----------. \ ,----'' | `---'-. ,-' |flow#1 \ `-. ,' | ' `. ( IP Network| \ `. | ' ,' `-. ; ,\' ;-----. ; _.----' ' ,' `---------+----------'' | / | ' +---'---+ +---:---+ +-------+ | AR1 | | AR2`--|------------| AR3 | | HA | | HA |------------|HA | +-------+ +-------+ +-------+ flow#1 \\ \ flow#2 tunnelled \\ ' +-----+ +--\--+ | MN | ----move-------> | MN | +-----+ +-----+ Figure 3: Distributed Client Based Mobility Liu, et al. Expires January 11, 2011 [Page 10] Internet-Draft DMM July 2010 6.2. Network based solutions Figure 4 shows de deployment of PMIP [RFC5213] in a flat mobile architecture. The basic is to distribute mobility traffic management with dynamic user's traffic anchoring in the access network nodes. Each AR supports both the MAG and LMA functionalities. Any given IP flow can be considered as implicitly anchored on the current host's access router when set up. Until the host does not move, the IP flow is delivered as for any standard IPv6 node. The anchoring function at the access router is thus acting only to manage traffic indirection while the host moves to a new access router. So, when the MN handoff, its current traffic is still attached to the anchor access router which is responsible for forwarding its anchored MN's IP flows to the new MN's location (i.e. to the AR the MN is attached to). For example, let's consider an IP flow, flow#1, initiated by the mobile node, MN, when attached to AR2. Flow#1 will is routed in a standard way as long as the MN remain attached to AR2. If the MN moves to AR3, flow#1 remains anchored to AR2, which plays the role of LMA. AR3 plays the role of MAG for MN/flow#1. If MN starts a new IP communication, flow#2, while attached to AR3; flow#2 will be routed in a standard way as long as the MN remains attached to AR3. Then, if the MN moves to AR1, flow#1 and flow#2 will be respectively anchored to AR2/LMA and AR3/LMA and AR1 will provide MAG functionalities for MN. +---+ +---+ +---+ |CN1| |CN2| |CN3| +---+ +---+ +--,+ _.---------+----------. \ ,----'' | `---+-. ,-' |flow#1 \ `-. ,' | \ `. ( IP Network| \ `. | \ ,' `-. ; ,+' ;-----. ; _.----' `. ,' `---------+----------'' | / | flow#1 \ +---'---+ +---:---+ tunnelled +-------+ | AR1 | | AR2`--|------------| AR3 | |MAG/LMA| |MAG/LMA|------------|MAG/LMA| +-------+ +-------+ +-------+ flow#1 `. \ flow#2 +--`--+ +-----+ | MN | ----move-------> | MN | +-----+ +-----+ Liu, et al. Expires January 11, 2011 [Page 11] Internet-Draft DMM July 2010 Figure 4: Distributed Network Based Mobility 6.3. Splitting the routing and the location management function The logical functions of the mobility anchor defined in conventional mobility protocols may be split for both a better scalability and signaling efficiency. For instance [I-D.chan-netext-distributed-lma] proposes to split the mobility anchor entity into the following functions: 1. location management anchoring function 2. mobility routing anchoring function. The location management anchoring function includes keeping track of the internetwork location of the mobile node, which is identified with a permanent home address HoA. The mobility routing anchoring function includes routing the packets with HoA as destination address to the destination or to some other network element that knows how to forward to the destination. In the conventional mobility protocols, these two anchoring functions have been colocated into one mobility anchor. The collocated mobility anchor contains the full location information to enable its role to redirect packets to the new location of the mobile node. The result is the dilemma in where to position this collocated mobility anchor in a hierarchical network. On the one hand, it is simpler to have only one or possibly a very small number of mobility anchors to centrally manage the location of a larger number of mobile nodes. However, routing the packets through such centralized nodes often results in non-optimal routing. On the other hand, having many mobility anchors whose locations are low in the hierarchy will shorten the route. Yet it will then be costly and difficult to synchronize the location information when many such collocated mobility anchors are performing location management and each needs to have full location information of all the mobile nodes. Splitting the logical functions of location management and routing enables each function to be optimized in the design. The mobility routing function can be implemented in many physical places instead of in one or very few centralized places only. There are then many such places to provide the mobility routing function, and the packets can always be served by one that is nearby. Many of these packets would have to traverse a long route to reach a mobility routing function if there were only one centralized mobility routing function. The location management function, being implemented separately from the mobility routing function, do not need to be implemented in as many places as the mobility routing function. The implementation of Liu, et al. Expires January 11, 2011 [Page 12] Internet-Draft DMM July 2010 the location information system can be optimized according to the optimization of a database design. There may be only one, except for backup, database system. The database may still be distributed but are only distributed to much fewer number of places than the routing functions. After splitting the above functions, the mobility routing anchor points serving a source node sending packet to a destination mobile node may lack the location information of the destination mobile node. The mobility routing anchor may query the location management system to obtain the location information of the mobile node to which it needs to route the first packet. Alternatively, the location management anchor point may also possess routing function so that the first packet may be forwarded to the location management anchor point to route to the destination mobile node. Meanwhile the location information of this mobile node is being sent to the mobility routing anchor. After the mobility routing anchor has received the location information, it caches this information for its use to route the subsequent packets to the same mobile node. One access gateway plays the role of LM. Location update may be implemented in a separate entity (see figure) +---+ +---+ |CN1| |CN2| +---+ +---+ _.---------+----------. ,----'' | `----. ,-' |flow#1 `-. ,' | `. ( IP Network| ) `. | ,' `-. ; +-----+ , ;-----. ; +------ | LM |---+ ,' `---------+--|-------+-----+ | / | | flow#1 | +---'---+ +---:---+ tunnelled +-------+ | AR1 | | AR2`--|------------| AR3 | |MAG | |MAG |------------|MAG | +-------+ +-------+ +-------+ flow#1 `. +--`--+ +-----+ | MN | ----move-------> | MN | +-----+ +-----+ Liu, et al. Expires January 11, 2011 [Page 13] Internet-Draft DMM July 2010 Figure 5: Distributed Network Based Mobility 7. Security Considerations TBD 8. IANA Considerations None 9. Contributors The following people contributed to this document (in no specific order): Bo Zhou China Mobile zhouboyj@chinamobile.com Philippe Bertin France Telecom - Orange philippe.bertin@orange-ftgroup.com 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.chan-netext-distributed-lma] Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed Local Mobility Anchors", draft-chan-netext-distributed-lma-03 (work in progress), March 2010. [I-D.ietf-mext-flow-binding] 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-06 (work in progress), March 2010. Liu, et al. Expires January 11, 2011 [Page 14] Internet-Draft DMM July 2010 [I-D.kassi-mobileip-dmi] Kassi-Lahlou, M., "Dynamic Mobile IP (DMI)", draft-kassi-mobileip-dmi-01 (work in progress), January 2003. [I-D.seite-netext-dma] Seite, P. and P. Bertin, "Dynamic Mobility Anchoring", draft-seite-netext-dma-00 (work in progress), May 2010. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. [TR23.261] 3GPP, "IP Flow Mobility and seamless WLAN offload", 2010. Authors' Addresses Dapeng Liu China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: liudapeng@chinamobile.com Zhen Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: caozhen@chinamobile.com Liu, et al. Expires January 11, 2011 [Page 15] Internet-Draft DMM July 2010 Pierrick Seite France Telecom - Orange 4, rue du clos courtel, BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange-ftgroup.com H Anthony Chan Huawei Technologies 1700 Alma Ave Plano, TX 75075 USA Email: anthonychan@huawei.com Liu, et al. Expires January 11, 2011 [Page 16]