idnits 2.17.1 

draft-xuan-dmm-nemo-dmm-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.

  -- The document date (Oct 22, 2014) is 3471 days in the past.  Is this
     intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'RFC2119' is mentioned on line 125, but not defined


     Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

1	<Distributed Mobility Management>                        Truong-Xuan Do
2	Internet Draft                                             Younghan Kim
3	Intended status: Informational               Soongsil University, Korea
4	Expires: April 2014                                        Oct 22, 2014

6	      Network Mobility Support in the Distributed Mobility Management
7	                      draft-xuan-dmm-nemo-dmm-03.txt

9	Status of this Memo

11	   This Internet-Draft is submitted in full conformance with the
12	   provisions of BCP 78 and BCP 79.

14	   Internet-Drafts are working documents of the Internet Engineering
15	   Task Force (IETF), its areas, and its working groups.  Note that
16	   other groups may also distribute working documents as Internet-
17	   Drafts.

19	   Internet-Drafts are draft documents valid for a maximum of six
20	   months and may be updated, replaced, or obsoleted by other documents
21	   at any time.  It is inappropriate to use Internet-Drafts as
22	   reference material or to cite them other than as "work in progress."

24	   The list of current Internet-Drafts can be accessed at
25	   http://www.ietf.org/1id-abstracts.html

27	   The list of Internet-Draft Shadow Directories can be accessed at
28	   http://www.ietf.org/shadow.html

30	   This Internet-Draft will expire on April 22,2015.

32	Copyright Notice

34	   Copyright (c) 2014 IETF Trust and the persons identified as the
35	   document authors. All rights reserved.

37	   This document is subject to BCP 78 and the IETF Trust's Legal
38	   Provisions
39	   Relating to IETF Documents (http://trustee.ietf.org/license-info)
40	   in effect on the date of publication of this document.  Please
41	   review these documents carefully, as they describe your rights
42	   and restrictions with respect to this document.

44	Abstract

46	   Network mobility (NEMO) provides session continuity for mobile nodes
47	   (MN) while moving in vehicles without their involvement in signaling
48	   process. NEMO Basic support protocol is standardized to provide
49	   network mobility support.

51	   Current mobility management protocols rely on a central mobility
52	   anchor in order to provide mobility support for the mobile nodes.
53	   These centralized approaches show some big issues, such as a single
54	   point of failure, non-optimal routing, and scalability.
55	   Ever-increasing demand for the mobile traffic changes the network
56	   architecture from hierarchical to flat architecture, and distributed
57	   mobility management (DMM) approaches are being researched to adapt
58	   the new flat architecture and overcome big above issues.

60	   This document presents about detailed protocol operation to support
61	   network mobility in the DMM domain.

63	Table of Contents

65	   1. Introduction...................................................3
66	   2. Conventions used in this document..............................3
67	   3. Protocol Operation.............................................4
68	      3.1. The attachment procedure of PR............................4
69	      3.2. The attachment procedure of MN............................5
70	      3.3. The handover procedure of PR from p-MAR to n-MAR..........6
71	      3.4. The handover procedure of MN from PR to outside network...7
72	      3.5. Lifetime management for binding entries...................8
73	   4. Considerations for fully distributed DMM.......................8
74	   5. Considerations for IP Multicast................................9
75	   6. Binding Entry Information.....................................10
76	      6.1. Binding cache entry in MAR...............................10
77	      6.2. Cache entry in the CDB...................................10
78	   7. Security Considerations.......................................11
79	   8. IANA Considerations...........................................11
80	   9. References....................................................11
81	      9.1. Normative References.....................................11
82	      9.2. Informative References...................................11

84	1. Introduction

86	   Network mobility (NEMO)[RFC3963] is used to provide mobility support
87	   for a group of mobile nodes. This solution allows the mobile nodes
88	   to access Internet from a device called mobile router. This router
89	   is used to handle mobility signaling on behalf of mobile node
90	   attached to it. However, this approach is host-based and causes high
91	   signaling and packet delivery overhead.

93	   Some other network mobility management approaches, such as PRNEMO
94	   [Jeon2011] which are PMIPv6-based [RFC5213] (network-based) have
95	   been defined in the research groups. These approaches have some
96	   advantages over host-based network mobility management ones, such
97	   as not require host stack involvement, handover delay improvement.

99	   However, all of these approaches are centralized that means all
100	   mobility management functions are centralized at a mobility anchor.
101	   These centralized approaches suffer from major issues, such as a
102	   single point of failure, wasting network resources and scalability,
103	   as defined in [RFC7333]. New trend in the evolution of mobile
104	   network is going toward flat architecture. In the flat architecture,
105	   the distributed mobility management (DMM) which distributes mobility
106	   management functions into access networks has been proposed to
107	   overcome the big issues of the centralized approaches.

109	   This document presents about detailed protocol operation to support
110	   network mobility in the DMM domain. In our scheme, the proxy router
111	   which is responsible for handling mobility related signaling will
112	   cache the IDs and prefixes of the attached mobile nodes. When the
113	   proxy router moves from one cell to another, it will get the new
114	   network prefixes for all attached mobile nodes and distribute to
115	   each mobile node via the router advertisement messages. This allows
116	   our network mobility management scheme to take the advantages of
117	   DMM. In this document, we use partially PMIPv6-based DMM approach
118	   in [Seite2014] to enable network mobility support.

120	2. Conventions used in this document

122	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
123	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
124	   document are to be interpreted as described in RFC-2119 [RFC2119].

126	   o  Proxy router (PR) - It will detect the MN's movement and perform
127	   mobility signaling on behalf of mobile nodes when moving from
128	   one cell to another. PR also manages the IDs and prefixes of
129	   attached mobile nodes.

131	   o  Mobility Access Router (MAR) - It is an enhanced mobility anchor
132	   which supports common mobility management functions, such as prefix
133	   allocation, location management, and location update. In addition,
134	   to support network mobility, this enhanced anchor needs to have
135	   different responses to different kinds of router solicitation
136	   messages which are received from proxy router or mobile nodes. This
137	   enhanced anchor supports prefix assignment for a list of IDs and
138	   maintains binding cache entries for both proxy router and attached
139	   mobile nodes.

141	   o  Central database (CDB) - It is a central database which is used
142	   to store mobility session information of the MN and the PR.

144	3. Protocol Operation
145	3.1. The attachment procedure of PR

147	        PR              p-MAR                 CDB
148	        |--L2 Attach----->|                    |
149	        |                 |                    |
150	        |-------RS------->|                    |
151	        | ('G', PR-ID)    |                    |
152	        |              Update                  |
153	        |           Binding cache              |
154	        |                 |                    |
155	        |                 |<--Session update-->|
156	        |<------RA--------|                    |
157	        |      (pref1)    |                    |
158	      Configure
159	   an IP address
160	      (pref1::PR-ID)

162	                   Figure 1 The attachment procedure of the PR

164	      When a proxy router (PR) approaches the DMM domain, the event is
165	   detected by the p-MAR using the Layer 2 signals. Then, the PR sends
166	   the router solicitation message (RS) containing the ID of the PR,
167	   'G' flag set to 1 toward the p-MAR. In our scheme, in order to
168	   distinguish between the RS messages of the PR and the mobile node
169	   (MN), we use the 'G' flag. The PR sends the RS message with 'G' flag
170	   set to 1, but the MN sends the RS message without 'G' flag. On
171	   receiving the RS message, the p-MAR will make an binding cache
172	   entry, including the ID of PR, the assigned network prefix, the
173	   anchor point, the 'D' flag, and the group ID. In this binding cache,
174	   'D' flag is used to know whether the PR or MN attach directly to the
175	   mobility access router (MAR) or not. All mobile nodes and its proxy
176	   router have the same group ID value. Then, the p-MAR performs the
177	   mobility session update to the central database, as defined in
178	   [Seite2014]. The p-MAR will assign a network prefix pref1 for the
179	   PR and sends it back via the RA message. After receiving the pref1,
180	   the PR can configure an IPv6 address.

182	3.2. The attachment procedure of MN

184	    MN                PR              p-MAR          CN1           CDB
185	     |                 |                 |            |             |
186	     |--L2 Attach----->|                 |            |             |
187	     |                 |                 |            |             |
188	     |-------RS------->|                 |            |             |
189	     |     (MN-ID)     |------RS-------->|            |             |
190	     |                 | ('P','G', MN-ID)|            |             |
191	     |                 |               Update         |             |
192	     |                 |          Binding cache       |             |
193	     |                 |                 |            |             |
194	     |                 |<------RA--------|            |             |
195	     |                 | ('P', pref2)    |            |             |
196	     |             Cache ID              |<------Session update---->|
197	     |             and prefix            |            |             |
198	     |               of MN               |            |             |
199	     |                 |                 |            |             |
200	     |<------RA--------|                 |            |             |
201	     |     (pref2)     |                 |            |             |
202	    Configure          |                 |            |             |
203	   an IP address       |                 |            |             |
204	   (pref2::MN-ID)      |                 |            |             |
205	     |                 |                 |            |             |
206	     |<----------------Data flow to pref2 ----------->|             |

208	                 Figure 2 MN attachment to the DMM domain

210	      When an MN attaches to the PR, it sends its ID to the PR via RS
211	   message. The PR will forward this RS message with 'P' and 'G' flags
212	   set to 1 to the p-MAR. 'P' flag means this RS is the proxy RS sent
213	   by the PR on behalf of the MN. 'G' flag is used to request the p-MAG
214	   to assign a group ID for the MN. After receiving this RS message,
215	   the p-MAG will assign a network prefix pref2 for the MN and assign
216	   the same group ID as the PR. 'D' flag is set to 0 means the MN
217	   attaches to the PR not the p-MAR. Then, the p-MAG sends the network
218	   prefix pref2 to the PR and at the same time performs session update
219	   to the CDB. On receiving the RA message, the PR will cache the ID
220	   and the prefix of the MN for later handover operation. After
221	   receiving the pref2, the MN can configure an IPv6 address and
222	   initiate and maintain the data session using this address. In this
223	   case, the data packets which go to the IP address pref2::MN-ID will
224	   be routed to the p-MAR. Then, the p-MAR will perform recursive
225	   lookup in its binding cache, if the anchor point for this address is
226	   the p-MAR, the data packets will be routed to the PR, finally to the
227	   MN without adding any tunnel headers.

229	3.3. The handover procedure of PR from p-MAR to n-MAR

231	     MN            PR          p-MAR        n-MAR           CN1 CN2  CDB
232	     |             |             |            |             |   |    |
233	     |          Handover         |            |             |   |    |
234	     |             |------------RS----------->|             |   |    |
235	     |             | ('G', PR-ID, MN-ID)   Update           |   |    |
236	     |             |             |      Binding cache       |   |    |
237	     |             |             |            |             |   |    |
238	     |             |<-----------RA------------|<--Get previous MAR-->|
239	     |             |      (pref3, pref4)      |           of PR      |
240	     |          Cache new        |            |             |   |    |
241	     |         prefix of MN      |            |             |   |    |
242	     |<----RA------|             |            |             |   |    |
243	     |     (pref4) |             |<----PBU----|             |   |    |
244	   Configure       |             |('G',PR-ID, |             |   |    |
245	   an IP address   |             |   n-MAG)   |             |   |    |
246	   (pref4::MN-ID)  |             |----PBA---->|             |   |    |
247	     |             |          Update          |             |   |    |
248	     |             |        Binding cache     |             |   |    |
249	     |             |             |            |             |   |    |
250	     |             |             |<-Data flow to pref2(#1)->|   |    |
251	     |             |             |<===(#1)===>|             |   |    |
252	     |<---(#1)---->|<=========(#1)===========>|             |   |    |
253	     |             |                          |             |   |    |
254	     |<------------Data flow to pref4(#2)---->|<------(#2)----->|    |

256	                        Figure 3 Handover operation

258	   When the PR handovers from the p-MAR to the n-MAR, the PR will send
259	   a RS message, including its ID and the IDs of all attached MN to the
260	   n-MAR in order to request new network prefixes for the attached MNs.
261	   On receiving this RS message, the n-MAG will make new binding cache
262	   entries. When receiving a RS message with more than one ID, the n-
263	   MAR will consider the first ID as the ID of the PR and also assign
264	   the same group ID, new network prefixes: pref3, pref4. The 'D' flag
265	   in the entry of the first ID is set to 1 and of other IDs are set to
266	   0. Then, the n-MAR will query to the CDB to get the previous anchor
267	   points of the PR. The n-MAR will send a PBU message, containing the
268	   new location of the PR to the p-MAR to establish a tunnel. On
269	   receiving new network prefixes from the RA message, the MN also
270	  configure a new IP address pref4::MN-ID.

272	   For the data delivery operation, the data flow to the old IP address
273	   of the MN will be routed to the p-MAR. At the p-MAR, the data
274	   packets will be added two tunnel headers, the outer header is the IP
275	   address of the n-MAR and the inner header is the IP address of the
276	   PR. The data packets will be de-capsulated at the n-MAR and the PR,
277	   finally sent to the MN. The data flow to the new IP address of the
278	   MN will be routed to the currently attached anchor point, i.e.
279	   n-MAR, then to the PR, finally to the MN without adding any tunnel
280	   headers.

282	3.4. The handover procedure of MN from PR to outside network

284	    MN                  p-MAR            n-MAR           CN1 CN2  CDB
285	     |                     |                |             |   |    |
286	   Detachment              |                |             |   |    |
287	   from PR                 |                |             |   |    |
288	     |----------L2 attachment-------------->|             |   |    |
289	     |---------------RS-------------------->|             |   |    |
290	     |            (MN-ID)                 Update          |   |    |
291	     |                                 Binding cache      |   |    |
292	     |<--------------RA---------------------|<---Session update--->|
293	     |             (pref4) |                |<--Get previous MAR-->|
294	     |                     |                |        of MN         |
295	     |                     |<-----PBU-------|             |   |    |
296	     |                     | (MN-ID, n-MAR) |             |   |    |
297	     |                     |-------PBA----->|             |   |    |
298	     |                 Update               |             |   |    |
299	     |              Binding cache           |             |   |    |
300	     |                     |<----Data flow to pref2(#1)-->|   |    |
301	     |                     |<====(#1)======>|             |   |    |
302	     |<----------------(#1)---------------->|             |   |    |
303	     |<-----------Data flow to pref4(#2)--->|<------(#2)----->|    |

305	               Figure 4 The MN handovers to outside network

307	      After detaching from the PR, the MN attaches to the n-MAR. The MN
308	   sends a RS message with 'G' flag set to 0 to the n-MAR. The n-MAR
309	   will update the binding cache entry for the MN. The 'D' flag for
310	   the binding entry of the MN set to 1 means the MN attaches directly
311	   to the n-MAR and the group ID will be deleted. Next steps are
312	   similar to the handover procedure of the PR. The n-MAR also queries
313	   to the central database to get previous anchor points of the MN,
314	   and then sends a PBU message to update the new location of the MN.
315	      For the packet delivery operation, the data packets to the old IP
316	   address of the MN will be routed to the p_MAR. At the p-MAR, data
317	   packets will be added one tunnel header which is the IP address
318	   of the n-MAR. These data packets will be de-capsulated at the n-MAR,
319	   and sent to the MN. For the data packets to the new IP address of
320	   the MN, the data packets will be routed to the n-MAR and to the MN
321	   without adding any tunnel headers.

323	3.5. Lifetime management for binding entries

325	      The number of binding entries in the binding caches in the MAR
326	   and the CDB increases with the attachment of new mobile nodes. A
327	   mechanism is needed to clean unused entries in these binding caches.
328	   There are two solutions to do this task:

330	   o  A lifetime value is set for each binding entry. When this
331	      lifetime value expires, the binding entry will be removed from
332	      the cache of MAR or CDB.

334	   o  After receiving the PBU message of the MN, the previous MAR waits
335	      until the data session toward the prefix assigned to the MN
336	      finishes. Then, the previous MAR will remove the binding entry
337	      related to the MN and the prefix of finished session. Then, the
338	      previous MAR sends a de-registration message to the CDB to remove
339	      the mobility session information of the MN from the binding cache
340	      of the CDB.

342	4. Considerations for fully distributed DMM

344	      In the fully distributed DMM, both data plane and control plane
345	   are processed in the MARs. The central database becomes useless in
346	   the full architecture. The information about mobility sessions is no
347	   longer stored in the central database, but is exchanged between the
348	   previous MAR and next MAR using control messages. Concretely, when
349	   the previous MAR finishes assigning prefixes for the PR or the MN,
350	   instead of updating these mobility sessions to the CDB, it can
351	   broadcast the information to its neighboring MARs. The next MAR then
352	   can receive this mobility session information of the PR or the MN
353	   without going to the CDB. The mobility session information includes
354	   the IP addresses of the previous MARs and the prefixes advertised to
355	   the PR and the MN.

357	5. Considerations for IP Multicast
358	   IP Multicast can be supported in the DMM-based network mobility
359	   management by placing the MLD-Proxy (Multicast Listener Discovery
360	   Proxy) function into the PRs and MARs. The CDB is extended to contain
361	   both mobility session information and multicast context. After the
362	   attachment procedure of the MNs, the MNs will subscribe multicast
363	   channels by sending the MLD Report messages to the PR. The PR will
364	   send an aggregated MLD Report message to the current serving MAR of
365	   the PR (p-MAR). After the attachment and multicast subscription
366	   procedures, the p-MAR will update this information to the CDB,
367	   including multicast context from the aggregated MLD Report and
368	   mobility session information from the attachment procedure. When
369	   handover occurs, after the attachment procedure of the PR to the
370	   new MAR (n-MAR), the n-MAR will query to the CDB to get the multicast
371	   context and mobility session information of all MNs, then the n-MAR
372	   can send an aggregated MLD-Report to the multicast tree and perform
373	   location update procedure to the p-MAR as discussed earlier. From
374	   now, the multicast data can flow from multicast tree to the n-MAR,
375	   to the PR, and to MNs.

377	6. Binding Entry Information

379	6.1. Binding cache entry in MAR

381	   In the p-MAR after handover procedure of the PR

383	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
384	   |   ID   | Prefix     | Anchor point  |    GID    |  D flag |
385	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
386	   | PR-ID  | Pref1::/64 |  n-MAR        |    GID1   |    1    |
387	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
388	   | MN-ID  | Pref2::/64 |  PR           |    GID1   |    0    |
389	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

391	   In the n-MAR after handover procedure of the PR

393	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
394	   |   ID   | Prefix     | Anchor point  |    GID    |  D flag |
395	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
396	   | PR-ID  | Pref3::/64 |  n-MAR        |    GID2   |    1    |
397	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
398	   | MN-ID  | Pref4::/64 |  PR           |    GID2   |    0    |
399	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

401	6.2. Cache entry in the CDB

403	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
404	   |   ID   | Prefix     | Anchor point  |
405	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406	   | PR-ID  | Pref1::/64 |  p-MAR        |
407	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
408	   | MN-ID  | Pref2::/64 |  p-MAR        |
409	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410	   | PR-ID  | Pref3::/64 |  n-MAR        |
411	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
412	   | MN-ID  | Pref4::/64 |  n-MAR        |
413	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

415	7. Security Considerations

417	TBD.

419	8. IANA Considerations

421	TBD.

423	9. References

425	9.1. Normative References

427	   [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.
428	             Thubert, "Network Mobility (NEMO) Basic Support Protocol,"
429	             IETFRFC 3963, January, 2005.

431	   [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.
432	             and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213,
433	             Aug. 2008.

435	   [RFC7333] Chan, H., "Requirements for distributed mobility
436	              management", IETF RFC 7333, Apr. 2014

438	9.2. Informative References

440	   [Jeon2011] Jeon, S. and Kim,Y., "Cost-efficient network mobility
441	              scheme over proxy mobile IPv6 network", IET Commun.,
442	              2011, 5, (18), pp. 2656-2661

444	   [Seite2014] Seite, P., Bertin, P.:'Distributed mobility anchoring',
445	               draft-seite-dmm-dma-07, Feb. 2014.

447	Authors' Addresses

449	   Truong-Xuan Do
450	   Soongsil University
451	   4F Hyungnam Engineering Bldg. 424,
452	   (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea

454	   Phone: +82 10 4473 6869
455	   Email: xuan@dcn.ssu.ac.kr

457	   Younghan Kim
458	   Soongsil University
459	   4F Hyungnam Engineering Bldg. 424,
460	   (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea

462	   Phone: +82-2-820-0904
463	   Email: younghak@ssu.ac.kr