Truong-Xuan Do Internet Draft Younghan Kim Intended status: Informational Soongsil University, Korea Expires: April 2014 Oct 22, 2014 Network Mobility Support in the Distributed Mobility Management draft-xuan-dmm-nemo-dmm-03.txt 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), 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 22,2015. Copyright Notice Copyright (c) 2014 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. Expires April 22,2015 [Page 1]  Internet-Draft Oct 22, 2014 Abstract Network mobility (NEMO) provides session continuity for mobile nodes (MN) while moving in vehicles without their involvement in signaling process. NEMO Basic support protocol is standardized to provide network mobility support. Current mobility management protocols rely on a central mobility anchor in order to provide mobility support for the mobile nodes. These centralized approaches show some big issues, such as a single point of failure, non-optimal routing, and scalability. Ever-increasing demand for the mobile traffic changes the network architecture from hierarchical to flat architecture, and distributed mobility management (DMM) approaches are being researched to adapt the new flat architecture and overcome big above issues. This document presents about detailed protocol operation to support network mobility in the DMM domain. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Protocol Operation.............................................4 3.1. The attachment procedure of PR............................4 3.2. The attachment procedure of MN............................5 3.3. The handover procedure of PR from p-MAR to n-MAR..........6 3.4. The handover procedure of MN from PR to outside network...7 3.5. Lifetime management for binding entries...................8 4. Considerations for fully distributed DMM.......................8 5. Considerations for IP Multicast................................9 6. Binding Entry Information.....................................10 6.1. Binding cache entry in MAR...............................10 6.2. Cache entry in the CDB...................................10 7. Security Considerations.......................................11 8. IANA Considerations...........................................11 9. References....................................................11 9.1. Normative References.....................................11 9.2. Informative References...................................11 Expires April 22,2015 [Page 2]  Internet-Draft Oct 22, 2014 1. Introduction Network mobility (NEMO)[RFC3963] is used to provide mobility support for a group of mobile nodes. This solution allows the mobile nodes to access Internet from a device called mobile router. This router is used to handle mobility signaling on behalf of mobile node attached to it. However, this approach is host-based and causes high signaling and packet delivery overhead. Some other network mobility management approaches, such as PRNEMO [Jeon2011] which are PMIPv6-based [RFC5213] (network-based) have been defined in the research groups. These approaches have some advantages over host-based network mobility management ones, such as not require host stack involvement, handover delay improvement. However, all of these approaches are centralized that means all mobility management functions are centralized at a mobility anchor. These centralized approaches suffer from major issues, such as a single point of failure, wasting network resources and scalability, as defined in [RFC7333]. New trend in the evolution of mobile network is going toward flat architecture. In the flat architecture, the distributed mobility management (DMM) which distributes mobility management functions into access networks has been proposed to overcome the big issues of the centralized approaches. This document presents about detailed protocol operation to support network mobility in the DMM domain. In our scheme, the proxy router which is responsible for handling mobility related signaling will cache the IDs and prefixes of the attached mobile nodes. When the proxy router moves from one cell to another, it will get the new network prefixes for all attached mobile nodes and distribute to each mobile node via the router advertisement messages. This allows our network mobility management scheme to take the advantages of DMM. In this document, we use partially PMIPv6-based DMM approach in [Seite2014] to enable network mobility support. 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 RFC-2119 [RFC2119]. o Proxy router (PR) - It will detect the MN's movement and perform mobility signaling on behalf of mobile nodes when moving from one cell to another. PR also manages the IDs and prefixes of attached mobile nodes. Expires April 22,2015 [Page 3]  Internet-Draft Oct 22, 2014 o Mobility Access Router (MAR) - It is an enhanced mobility anchor which supports common mobility management functions, such as prefix allocation, location management, and location update. In addition, to support network mobility, this enhanced anchor needs to have different responses to different kinds of router solicitation messages which are received from proxy router or mobile nodes. This enhanced anchor supports prefix assignment for a list of IDs and maintains binding cache entries for both proxy router and attached mobile nodes. o Central database (CDB) - It is a central database which is used to store mobility session information of the MN and the PR. 3. Protocol Operation 3.1. The attachment procedure of PR PR p-MAR CDB |--L2 Attach----->| | | | | |-------RS------->| | | ('G', PR-ID) | | | Update | | Binding cache | | | | | |<--Session update-->| |<------RA--------| | | (pref1) | | Configure an IP address (pref1::PR-ID) Figure 1 The attachment procedure of the PR When a proxy router (PR) approaches the DMM domain, the event is detected by the p-MAR using the Layer 2 signals. Then, the PR sends the router solicitation message (RS) containing the ID of the PR, 'G' flag set to 1 toward the p-MAR. In our scheme, in order to distinguish between the RS messages of the PR and the mobile node (MN), we use the 'G' flag. The PR sends the RS message with 'G' flag set to 1, but the MN sends the RS message without 'G' flag. On receiving the RS message, the p-MAR will make an binding cache entry, including the ID of PR, the assigned network prefix, the anchor point, the 'D' flag, and the group ID. In this binding cache, 'D' flag is used to know whether the PR or MN attach directly to the mobility access router (MAR) or not. All mobile nodes and its proxy router have the same group ID value. Then, the p-MAR performs the mobility session update to the central database, as defined in [Seite2014]. The p-MAR will assign a network prefix pref1 for the Expires April 22,2015 [Page 4]  Internet-Draft Oct 22, 2014 PR and sends it back via the RA message. After receiving the pref1, the PR can configure an IPv6 address. 3.2. The attachment procedure of MN MN PR p-MAR CN1 CDB | | | | | |--L2 Attach----->| | | | | | | | | |-------RS------->| | | | | (MN-ID) |------RS-------->| | | | | ('P','G', MN-ID)| | | | | Update | | | | Binding cache | | | | | | | | |<------RA--------| | | | | ('P', pref2) | | | | Cache ID |<------Session update---->| | and prefix | | | | of MN | | | | | | | | |<------RA--------| | | | | (pref2) | | | | Configure | | | | an IP address | | | | (pref2::MN-ID) | | | | | | | | | |<----------------Data flow to pref2 ----------->| | Figure 2 MN attachment to the DMM domain When an MN attaches to the PR, it sends its ID to the PR via RS message. The PR will forward this RS message with 'P' and 'G' flags set to 1 to the p-MAR. 'P' flag means this RS is the proxy RS sent by the PR on behalf of the MN. 'G' flag is used to request the p-MAG to assign a group ID for the MN. After receiving this RS message, the p-MAG will assign a network prefix pref2 for the MN and assign the same group ID as the PR. 'D' flag is set to 0 means the MN attaches to the PR not the p-MAR. Then, the p-MAG sends the network prefix pref2 to the PR and at the same time performs session update to the CDB. On receiving the RA message, the PR will cache the ID and the prefix of the MN for later handover operation. After Expires April 22,2015 [Page 5]  Internet-Draft Oct 22, 2014 receiving the pref2, the MN can configure an IPv6 address and initiate and maintain the data session using this address. In this case, the data packets which go to the IP address pref2::MN-ID will be routed to the p-MAR. Then, the p-MAR will perform recursive lookup in its binding cache, if the anchor point for this address is the p-MAR, the data packets will be routed to the PR, finally to the MN without adding any tunnel headers. 3.3. The handover procedure of PR from p-MAR to n-MAR MN PR p-MAR n-MAR CN1 CN2 CDB | | | | | | | | Handover | | | | | | |------------RS----------->| | | | | | ('G', PR-ID, MN-ID) Update | | | | | | Binding cache | | | | | | | | | | | |<-----------RA------------|<--Get previous MAR-->| | | (pref3, pref4) | of PR | | Cache new | | | | | | prefix of MN | | | | | |<----RA------| | | | | | | (pref4) | |<----PBU----| | | | Configure | |('G',PR-ID, | | | | an IP address | | n-MAG) | | | | (pref4::MN-ID) | |----PBA---->| | | | | | Update | | | | | | Binding cache | | | | | | | | | | | | | |<-Data flow to pref2(#1)->| | | | | |<===(#1)===>| | | | |<---(#1)---->|<=========(#1)===========>| | | | | | | | | | |<------------Data flow to pref4(#2)---->|<------(#2)----->| | Figure 3 Handover operation When the PR handovers from the p-MAR to the n-MAR, the PR will send a RS message, including its ID and the IDs of all attached MN to the n-MAR in order to request new network prefixes for the attached MNs. On receiving this RS message, the n-MAG will make new binding cache entries. When receiving a RS message with more than one ID, the n- MAR will consider the first ID as the ID of the PR and also assign the same group ID, new network prefixes: pref3, pref4. The 'D' flag in the entry of the first ID is set to 1 and of other IDs are set to Expires April 22,2015 [Page 6]  Internet-Draft Oct 22, 2014 0. Then, the n-MAR will query to the CDB to get the previous anchor points of the PR. The n-MAR will send a PBU message, containing the new location of the PR to the p-MAR to establish a tunnel. On receiving new network prefixes from the RA message, the MN also configure a new IP address pref4::MN-ID. For the data delivery operation, the data flow to the old IP address of the MN will be routed to the p-MAR. At the p-MAR, the data packets will be added two tunnel headers, the outer header is the IP address of the n-MAR and the inner header is the IP address of the PR. The data packets will be de-capsulated at the n-MAR and the PR, finally sent to the MN. The data flow to the new IP address of the MN will be routed to the currently attached anchor point, i.e. n-MAR, then to the PR, finally to the MN without adding any tunnel headers. 3.4. The handover procedure of MN from PR to outside network MN p-MAR n-MAR CN1 CN2 CDB | | | | | | Detachment | | | | | from PR | | | | | |----------L2 attachment-------------->| | | | |---------------RS-------------------->| | | | | (MN-ID) Update | | | | Binding cache | | | |<--------------RA---------------------|<---Session update--->| | (pref4) | |<--Get previous MAR-->| | | | of MN | | |<-----PBU-------| | | | | | (MN-ID, n-MAR) | | | | | |-------PBA----->| | | | | Update | | | | | Binding cache | | | | | |<----Data flow to pref2(#1)-->| | | | |<====(#1)======>| | | | |<----------------(#1)---------------->| | | | |<-----------Data flow to pref4(#2)--->|<------(#2)----->| | Figure 4 The MN handovers to outside network After detaching from the PR, the MN attaches to the n-MAR. The MN sends a RS message with 'G' flag set to 0 to the n-MAR. The n-MAR will update the binding cache entry for the MN. The 'D' flag for the binding entry of the MN set to 1 means the MN attaches directly to the n-MAR and the group ID will be deleted. Next steps are Expires April 22,2015 [Page 7]  Internet-Draft Oct 22, 2014 similar to the handover procedure of the PR. The n-MAR also queries to the central database to get previous anchor points of the MN, and then sends a PBU message to update the new location of the MN. For the packet delivery operation, the data packets to the old IP address of the MN will be routed to the p_MAR. At the p-MAR, data packets will be added one tunnel header which is the IP address of the n-MAR. These data packets will be de-capsulated at the n-MAR, and sent to the MN. For the data packets to the new IP address of the MN, the data packets will be routed to the n-MAR and to the MN without adding any tunnel headers. 3.5. Lifetime management for binding entries The number of binding entries in the binding caches in the MAR and the CDB increases with the attachment of new mobile nodes. A mechanism is needed to clean unused entries in these binding caches. There are two solutions to do this task: o A lifetime value is set for each binding entry. When this lifetime value expires, the binding entry will be removed from the cache of MAR or CDB. o After receiving the PBU message of the MN, the previous MAR waits until the data session toward the prefix assigned to the MN finishes. Then, the previous MAR will remove the binding entry related to the MN and the prefix of finished session. Then, the previous MAR sends a de-registration message to the CDB to remove the mobility session information of the MN from the binding cache of the CDB. 4. Considerations for fully distributed DMM In the fully distributed DMM, both data plane and control plane are processed in the MARs. The central database becomes useless in the full architecture. The information about mobility sessions is no longer stored in the central database, but is exchanged between the previous MAR and next MAR using control messages. Concretely, when the previous MAR finishes assigning prefixes for the PR or the MN, instead of updating these mobility sessions to the CDB, it can broadcast the information to its neighboring MARs. The next MAR then can receive this mobility session information of the PR or the MN without going to the CDB. The mobility session information includes the IP addresses of the previous MARs and the prefixes advertised to the PR and the MN. Expires April 22,2015 [Page 8]  Internet-Draft Oct 22, 2014 5. Considerations for IP Multicast IP Multicast can be supported in the DMM-based network mobility management by placing the MLD-Proxy (Multicast Listener Discovery Proxy) function into the PRs and MARs. The CDB is extended to contain both mobility session information and multicast context. After the attachment procedure of the MNs, the MNs will subscribe multicast channels by sending the MLD Report messages to the PR. The PR will send an aggregated MLD Report message to the current serving MAR of the PR (p-MAR). After the attachment and multicast subscription procedures, the p-MAR will update this information to the CDB, including multicast context from the aggregated MLD Report and mobility session information from the attachment procedure. When handover occurs, after the attachment procedure of the PR to the new MAR (n-MAR), the n-MAR will query to the CDB to get the multicast context and mobility session information of all MNs, then the n-MAR can send an aggregated MLD-Report to the multicast tree and perform location update procedure to the p-MAR as discussed earlier. From now, the multicast data can flow from multicast tree to the n-MAR, to the PR, and to MNs. Expires April 22,2015 [Page 9]  Internet-Draft Oct 22, 2014 6. Binding Entry Information 6.1. Binding cache entry in MAR In the p-MAR after handover procedure of the PR +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Prefix | Anchor point | GID | D flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PR-ID | Pref1::/64 | n-MAR | GID1 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-ID | Pref2::/64 | PR | GID1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the n-MAR after handover procedure of the PR +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Prefix | Anchor point | GID | D flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PR-ID | Pref3::/64 | n-MAR | GID2 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-ID | Pref4::/64 | PR | GID2 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2. Cache entry in the CDB +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Prefix | Anchor point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PR-ID | Pref1::/64 | p-MAR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-ID | Pref2::/64 | p-MAR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PR-ID | Pref3::/64 | n-MAR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-ID | Pref4::/64 | n-MAR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires April 22,2015 [Page 10]  Internet-Draft Oct 22, 2014 7. Security Considerations TBD. 8. IANA Considerations TBD. 9. References 9.1. Normative References [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol," IETFRFC 3963, January, 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Aug. 2008. [RFC7333] Chan, H., "Requirements for distributed mobility management", IETF RFC 7333, Apr. 2014 9.2. Informative References [Jeon2011] Jeon, S. and Kim,Y., "Cost-efficient network mobility scheme over proxy mobile IPv6 network", IET Commun., 2011, 5, (18), pp. 2656-2661 [Seite2014] Seite, P., Bertin, P.:'Distributed mobility anchoring', draft-seite-dmm-dma-07, Feb. 2014. Expires April 22,2015 [Page 11]  Internet-Draft Oct 22, 2014 Authors' Addresses Truong-Xuan Do Soongsil University 4F Hyungnam Engineering Bldg. 424, (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea Phone: +82 10 4473 6869 Email: xuan@dcn.ssu.ac.kr Younghan Kim Soongsil University 4F Hyungnam Engineering Bldg. 424, (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea Phone: +82-2-820-0904 Email: younghak@ssu.ac.kr Expires April 22,2015 [Page 12]