-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-dmm-pmipv6-dlif-00.txt
1792 lines (1248 loc) · 75.4 KB
/
draft-ietf-dmm-pmipv6-dlif-00.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
DMM Working Group CJ. Bernardos
Internet-Draft A. de la Oliva
Intended status: Standards Track UC3M
Expires: October 20, 2018 F. Giust
NEC
JC. Zuniga
SIGFOX
A. Mourad
InterDigital
April 18, 2018
Proxy Mobile IPv6 extensions for Distributed Mobility Management
draft-ietf-dmm-pmipv6-dlif-00
Abstract
Distributed Mobility Management solutions allow for setting up
networks so that traffic is distributed in an optimal way and does
not rely on centralized deployed anchors to provide IP mobility
support.
There are many different approaches to address Distributed Mobility
Management, as for example extending network-based mobility protocols
(like Proxy Mobile IPv6), or client-based mobility protocols (as
Mobile IPv6), among others. This document follows the former
approach, and proposes a solution based on Proxy Mobile IPv6 in which
mobility sessions are anchored at the last IP hop router (called
mobility anchor and access router). The mobility anchor and access
router is an enhanced access router which is also able to operate as
local mobility anchor or mobility access gateway, on a per prefix
basis. The document focuses on the required extensions to
effectively support simultaneously anchoring several flows at
different distributed gateways.
This document introduces the concept of distributed logical
interface, which is a software construct that allows to easily hide
the change of anchor from the mobile node.
Requirements Language
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].
Bernardos, et al. Expires October 20, 2018 [Page 1]
Internet-Draft PMIPv6 DMM and DLIF April 2018
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 https://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 October 20, 2018.
Copyright Notice
Copyright (c) 2018 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
(https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PMIPv6 DMM extenstions . . . . . . . . . . . . . . . . . . . 5
3.1. Initial registration . . . . . . . . . . . . . . . . . . 7
3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8
3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10
3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11
3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12
3.6. The Distributed Logical Interface (DLIF) concept . . . . 12
3.7. Message Format . . . . . . . . . . . . . . . . . . . . . 16
3.7.1. Proxy Binding Update . . . . . . . . . . . . . . . . 16
3.7.2. Proxy Binding Acknowledgment . . . . . . . . . . . . 17
3.7.3. Anchored Prefix Option . . . . . . . . . . . . . . . 17
3.7.4. Local Prefix Option . . . . . . . . . . . . . . . . . 18
Bernardos, et al. Expires October 20, 2018 [Page 2]
Internet-Draft PMIPv6 DMM and DLIF April 2018
3.7.5. Previous MAAR Option . . . . . . . . . . . . . . . . 19
3.7.6. Serving MAAR Option . . . . . . . . . . . . . . . . . 21
3.7.7. DLIF Link-local Address Option . . . . . . . . . . . 21
3.7.8. DLIF Link-layer Address Option . . . . . . . . . . . 22
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Comparison with Requirement document . . . . . . . . 25
A.1. Distributed mobility management . . . . . . . . . . . . . 25
A.2. Bypassable network-layer mobility support for each
application session . . . . . . . . . . . . . . . . . . . 26
A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26
A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26
A.5. Coexistence with deployed networks/hosts and operability
across different networks . . . . . . . . . . . . . . . . 27
A.6. Operation and management considerations . . . . . . . . . 27
A.7. Security considerations . . . . . . . . . . . . . . . . . 27
A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Implementation experience . . . . . . . . . . . . . 28
Appendix C. Applicability to the fog environment . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The Distributed Mobility Management (DMM) paradigm aims at minimizing
the impact of currently standardized mobility management solutions,
which are centralized (at least to a considerable extent).
Current IP mobility solutions, standardized with the names of Mobile
IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two
most relevant examples, offer mobility support at the cost of
handling operations at a cardinal point, the mobility anchor, and
burdening it with data forwarding and control mechanisms for a great
amount of users. As stated in [RFC7333], centralized mobility
solutions are prone to several problems and limitations: longer (sub-
optimal) routing paths, scalability problems, signaling overhead (and
most likely a longer associated handover latency), more complex
network deployment, higher vulnerability due to the existence of a
potential single point of failure, and lack of granularity on the
mobility management service (i.e., mobility is offered on a per-node
basis, not being possible to define finer granularity policies, as
for example per-application).
The purpose of Distributed Mobility Management is to overcome the
limitations of the traditional centralized mobility management
Bernardos, et al. Expires October 20, 2018 [Page 3]
Internet-Draft PMIPv6 DMM and DLIF April 2018
[RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed
bringing the mobility anchor closer to the MN. Following this idea,
in our proposal, the central anchor is moved to the edge of the
network, being deployed in the default gateway of the mobile node.
That is, the first elements that provide IP connectivity to a set of
MNs are also the mobility managers for those MNs. In the following,
we will call these entities Mobility Anchor and Access Routers
(MAARs).
This document focuses on network-based DMM, hence the starting point
is making PMIPv6 working in a distributed manner [RFC7429]. Mobility
is handled by the network without the MNs involvement, but,
differently from PMIPv6, when the MN moves from one access network to
another, it also changes anchor router, hence requiring signaling
between the anchors to retrieve the MN's previous location(s). Also,
a key-aspect of network-based DMM, is that a prefix pool belongs
exclusively to each MAAR, in the sense that those prefixes are
assigned by the MAAR to the MNs attached to it, and they are routable
at that MAAR.
We consider partially distributed schemes, where the data plane only
is distributed among access routers similar to MAGs, whereas the
control plane is kept centralized towards a cardinal node used as
information store, but relieved from any route management and MN's
data forwarding task.
2. Terminology
The following terms used in this document are defined in the Proxy
Mobile IPv6 specification [RFC5213]:
Local Mobility Anchor (LMA)
Mobile Access Gateway (MAG)
Mobile Node (MN)
Binding Cache Entry (BCE)
Proxy Care-of Address (P-CoA)
Proxy Binding Update (PBU)
Proxy Binding Acknowledgement (PBA)
The following terms used in this document are defined in the DMM
Deployment Models and Architectural Considerations document
[I-D.ietf-dmm-deployment-models]:
Bernardos, et al. Expires October 20, 2018 [Page 4]
Internet-Draft PMIPv6 DMM and DLIF April 2018
Home Control-Plane Anchor (H-CPA)
Home Data Plane Anchor (Home-DPA)
Access Control Plane Node (Access-CPN)
Access Data Plane Node (Access-DPN)
The following terms are defined and used in this document:
MAAR (Mobility Anchor and Access Router). First hop router where the
mobile nodes attach to. It also plays the role of mobility
manager for the IPv6 prefixes it anchors, running the
functionalities of PMIP's MAG and LMA. Depending on the prefix,
it plays the role of Access-DPN, Home-DPA and Access-CPN.
CMD (Central Mobility Database). Node that stores the BCEs allocated
for the MNs in the mobility domain. It plays the role of Home-
CPA.
P-MAAR (Previous MAAR). MAAR which was previously visited by the MN
and is still involved in an active flow using an IPv6 prefix it
has advertised to the MN (i.e., MAAR where that IPv6 prefix is
anchored). There might be multiple P-MAARs for an MN's mobility
session. It plays the role of Home-DPA.
S-MAAR (Serving MAAR). MAAR which the MN is currently attached to.
Depending on the prefix, it plays the role of Access-DPN, Home-DPA
and Access-CPN.
DLIF (Distributed Logical Interface). It is a logical interface at
the IP stack of the MAAR. For each active prefix used by the
mobile node, the serving MAAR has a DLIF configured (associated to
the anchoring MAAR). In this way, a serving MAAR exposes itself
towards each MN as multiple routers, one per active anchoring
MAAR.
3. PMIPv6 DMM extenstions
The solution consists in de-coupling the entities that participates
in the data and the control planes: the data plane becomes
distributed and managed by the MAARs near the edge of the network,
while the control plane, besides on the MAARs, relies on a central
entity called Central Mobility Database (CMD). In the proposed
architecture, the hierarchy present in PMIPv6 between LMA and MAG is
preserved, but with the following substantial variations:
Bernardos, et al. Expires October 20, 2018 [Page 5]
Internet-Draft PMIPv6 DMM and DLIF April 2018
o The LMA is relieved from the data forwarding role, only the
Binding Cache and its management operations are maintained. Hence
the LMA is renamed into Central Mobility Database (CMD), which is
therefore a Home-CPA. Also, the CMD is able to send and parse
both PBU and PBA messages.
o The MAG is enriched with the LMA functionalities, hence the name
Mobility Anchor and Access Router (MAAR). It maintains a local
Binding Cache for the MNs that are attached to it and it is able
to send and parse PBU and PBA messages.
o The binding cache will have to be extended to include information
regarding previous MAARs where the mobile node was anchored and
still retains active data sessions, see Appendix B for further
details.
o Each MAAR has a unique set of global prefixes (which are
configurable), that can be allocated by the MAAR to the MNs, but
must be exclusive to that MAAR, i.e. no other MAAR can allocate
the same prefixes.
The MAARs leverage on the Central Mobility Database (CMD) to access
and update information related to the MNs, stored as mobility
sessions; hence, a centralized node maintains a global view on the
status of the network. The CMD is queried whenever a MN is detected
to join/leave the mobility domain. It might be a fresh attachment, a
detachment or a handover, but as MAARs are not aware of past
information related to a mobility session, they contact the CMD to
retrieve the data of interest and eventually take the appropriate
action. The procedure adopted for the query and the messages
exchange sequence might vary to optimize the update latency and/or
the signaling overhead. Here is presented one method for the initial
registration, and three different approaches to update the mobility
sessions using PBUs and PBAs. Each approach assigns a different role
to the CMD:
o The CMD is a PBU/PBA relay;
o The CMD is only a MAAR locator;
o The CMD is a PBU/PBA proxy.
This solution can be categorized under Model-1: Split Home Anchor
Mode in [I-D.ietf-dmm-deployment-models]. As another note, the
solution described in this document allows performing per-prefix
anchoring decisions, to support e.g., some flows to be anchored at a
central Home-DPA (like a traditional LMA) or to enable an application
Bernardos, et al. Expires October 20, 2018 [Page 6]
Internet-Draft PMIPv6 DMM and DLIF April 2018
to switch to the locally anchored prefix to gain route optimization,
as indicated in [I-D.ietf-dmm-ondemand-mobility].
3.1. Initial registration
Upon the MN's attachment to a MAAR, say MAAR1, if the MN is
authorized for the service, an IPv6 global prefix belonging to the
MAAR's prefix pool is reserved for it (Pref1) into a temporal Binding
Cache Entry (BCE) allocated locally. The prefix is sent in a
[RFC5213] PBU with the MN's Identifier (MN-ID) to the CMD, which,
since the session is new, stores a permanent BCE containing as main
fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA.
The CMD replies to MAAR1 with a PBA including the usual options
defined in PMIP/RFC5213, meaning that the MN's registration is fresh
and no past status is available. MAAR1 definitely stores the
temporal BCE previously allocated and unicasts a Router Advertisement
(RA) to the MN including the prefix reserved before, that can be used
by the MN to configure an IPv6 address (e.g., with stateless auto-
configuration). The address is routable at the MAAR, in the sense
that it is on the path of packets addressed to the MN. Moreover, the
MAAR acts as plain router for those packets, as no encapsulation nor
special handling takes place. Figure 1 illustrates this scenario.
+-----+ +---+ +--+
|MAAR1| |CMD| |CN|
+-----+ +---+ +*-+
| | *
MN | * +---+
attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \
| | * / | \
local BCE | * / | \
allocation | * / | \
|--- PBU -->| +---*-+-' +--+--+ `+-----+
| BCE | * | | | | |
| creation |MAAR1+------+MAAR2+-----+MAAR3|
|<-- PBA ---| | * | | | | |
local BCE | +---*-+ +-----+ +-----+
finalized | *
| | Pref1 *
| | +*-+
| | |MN|
| | +--+
Operations sequence Packets flow
Figure 1: First attachment to the network
Bernardos, et al. Expires October 20, 2018 [Page 7]
Internet-Draft PMIPv6 DMM and DLIF April 2018
3.2. The CMD as PBU/PBA relay
When the MN moves from its current access and associates to MAAR2
(now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it
stores a temporal BCE, and it sends a plain PBU to the CMD for
registration. Upon PBU reception and BC lookup, the CMD retrieves an
already existing entry for the MN, binding the MN-ID to its former
location; thus, the CMD forwards the PBU to the MAAR indicated as
Proxy CoA (MAAR1), including a new mobility option to communicate the
S-MAAR's global address to MAAR1, defined as Serving MAAR Option in
Section 3.7.6. The CMD updates the P-CoA field in the BCE related to
the MN with the S-MAAR's address.
Upon PBU reception, MAAR1 can install a tunnel on its side towards
MAAR2 and the related routes for Pref1. Then MAAR1 replies to the
CMD with a PBA (including the option mentioned before) to ensure that
the new location has successfully changed, containing the prefix
anchored at MAAR1 in the Home Network Prefix option. The CMD, after
receiving the PBA, updates the BCE populating an instance of the
P-MAAR list. The P-MAAR list is an additional field on the BCE that
contains an element for each P-MAAR involved in the MN's mobility
session. The list element contains the P-MAAR's global address and
the prefix it has delegated (see Appendix B for further details).
Also, the CMD send a PBA to the new S-MAAR, containing the previous
Proxy-CoA and the prefix anchored to it embedded into a new mobility
option called Previous MAAR Option (defined in Section 3.7.5), so
that, upon PBA arrival, a bi-directional tunnel can be established
between the two MAARs and new routes are set appropriately to recover
the IP flow(s) carrying Pref1.
Now packets destined to Pref1 are first received by MAAR1,
encapsulated into the tunnel and forwarded to MAAR2, which finally
delivers them to their destination. In uplink, when the MN transmits
packets using Pref1 as source address, they are sent to MAAR2, as it
is MN's new default gateway, then tunneled to MAAR1 which routes them
towards the next hop to destination. Conversely, packets carrying
Pref2 are routed by MAAR2 without any special packet handling both
for uplink and downlink. The procedure is depicted in Figure 2.
Bernardos, et al. Expires October 20, 2018 [Page 8]
Internet-Draft PMIPv6 DMM and DLIF April 2018
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| |--- PBA*-->| +*--*+
| | route ---move-->|*MN*|
| | update +----+
Operations sequence Data Packets flow
PBU/PBA Messages with * contain
a new mobility option
Figure 2: Scenario after a handover, CMD as relay
For next MN's movements the process is repeated except for the number
of P-MAARs involved, that rises accordingly to the number of prefixes
that the MN wishes to maintain. Indeed, once the CMD receives the
first PBU from the new S-MAAR, it forwards copies of the PBU to all
the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR
prior to handover) and in the P-MAARs list. They reply with a PBA to
the CMD, which aggregates them into a single one to notify the
S-MAAR, that finally can establish the tunnels with the P-MAARs.
It should be noted that this design separates the mobility management
at the prefix granularity, and it can be tuned in order to erase old
mobility sessions when not required, while the MN is reachable
through the latest prefix acquired. Moreover, the latency associated
to the mobility update is bound to the PBA sent by the furthest
P-MAAR, in terms of RTT, that takes the longest time to reach the
CMD. The drawback can be mitigated introducing a timeout at the CMD,
by which, after its expiration, all the PBAs so far collected are
transmitted, and the remaining are sent later upon their arrival.
Bernardos, et al. Expires October 20, 2018 [Page 9]
Internet-Draft PMIPv6 DMM and DLIF April 2018
3.3. The CMD as MAAR locator
The handover latency experienced in the approach shown before can be
reduced if the P-MAARs are allowed to signal directly their
information to the new S-MAAR. This procedure reflect what was
described in Section 3.2 up to the moment the P-MAAR receives the PBU
with the P-MAAR option. At that point a P-MAAR is aware of the new
MN's location (because of the S-MAAR's address in the S-MAAR option),
and, besides sending a PBA to the CMD, it also sends a PBA to the
S-MAAR including the prefix it is anchoring. This latter PBA does
not need to include new options, as the prefix is embedded in the HNP
option and the P-MAAR's address OS taken from the message's source
address. The CMD is relieved from forwarding the PBA to the S-MAAR,
as the latter receives a copy directly from the P-MAAR with the
necessary information to build the tunnels and set the appropriate
routes. In Figure 3 is illustrated the new messages sequence, while
the data forwarding is unaltered.
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+
|<-- PBU*---| | | * | | *| | |
route | | |MAAR1|______|MAAR2+-----+MAAR3|
update | | | **(______)** *| | |
|--------- PBA -------->| +-----+ +-*--*+ +-----+
|--- PBA*-->| route * *
| BCE update Pref1 * *Pref2
| update | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packets flow
PBU/PBA Messages with * contain
a new mobility option
Figure 3: Scenario after a handover, CMD as locator
Bernardos, et al. Expires October 20, 2018 [Page 10]
Internet-Draft PMIPv6 DMM and DLIF April 2018
3.4. The CMD as MAAR proxy
A further enhancement of previous solutions can be achieved when the
CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of
the location change. Indeed, when the CMD receives the PBU for the
new registration, it is already in possess of all the information
that the new S-MAAR requires to set up the tunnels and the routes.
Thus the PBA is sent to the S-MAAR immediately after a PBU is
received, including also in this case the P-MAAR option. In
parallel, a PBU is sent by the CMD to the P-MAARs containing the
S-MAAR option, to notify them about the new MN's location, so they
receive the information to establish the tunnels and routes on their
side. When P-MAARs complete the update, they send a PBA to the CMD
to indicate that the operation is concluded and the information are
updated in all network nodes. This procedure is obtained from the
first one re-arranging the order of the messages, but the parameters
communicated are the same. This scheme is depicted in Figure 4,
where, again, the data forwarding is kept untouched.
+-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+
| | | * *
| | MN * +---+ *
| | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ *
| BCE | * / | *******
| check+ | * / | * \
| update | +---*-+-? +--+-*+ `+-----+
|<-- PBU*---x--- PBA*-->| | * | | *| | |
route | route |MAAR1|______|MAAR2+-----+MAAR3|
update | update | **(______)** *| | |
|--- PBA*-->| | +-----+ +-*--*+ +-----+
| BCE | * *
| update | Pref1 * *Pref2
| | | +*--*+
| | | ---move-->|*MN*|
| | | +----+
Operations sequence Data Packets flow
PBU/PBA Messages with * contain
a new mobility option
Figure 4: Scenario after a handover, CMD as proxy
Bernardos, et al. Expires October 20, 2018 [Page 11]
Internet-Draft PMIPv6 DMM and DLIF April 2018
3.5. De-registration
The de-registration mechanism devised for PMIPv6 is no longer valid
in the Partial DMM architecture. This is motivated by the fact that
each MAAR handles an independent mobility session (i.e., a single or
a set of prefixes) for a given MN, whereas the aggregated session is
stored at the CMD. Indeed, when a previous MAAR initiates a de-
registration procedure, because the MN is no longer present on the
MAAR's access link, it removes the routing state for that (those)
prefix(es), that would be deleted by the CMD as well, hence defeating
any prefix continuity attempt. The simplest approach to overcome
this limitation is to deny an old MAAR to de-register a prefix, that
is, allowing only a serving MAAR to de-register the whole MN session.
This can be achieved by first removing any layer-2 detachment event,
so that de-registration is triggered only when the session lifetime
expires, hence providing a guard interval for the MN to connect to a
new MAAR. Then, a change in the MAAR operations is required, and at
this stage two possible solutions can be deployed:
o A previous MAAR stops the BCE timer upon receiving a PBU from the
CMD containing a "Serving MAAR" option. In this way only the
Serving MAAR is allowed to de-register the mobility session,
arguing that the MN left definitely the domain.
o Previous MAARs can, upon BCE expiry, send de-registration messages
to the CMD, which, instead of acknowledging the message with a 0
lifetime, send back a PBA with a non-zero lifetime, hence re-
newing the session, if the MN is still connected to the domain.
The evaluation of these methods is left for future work.
3.6. The Distributed Logical Interface (DLIF) concept
One of the main challenges of a network-based DMM solution is how to
allow a mobile node to simultaneously send/receive traffic which is
anchored at different MAARs, and how to influence on the preference
of the mobile selecting the source IPv6 address for a new
communication, without requiring special support on the mobile node
stack. This document defines the Distributed Logical Interface
(DLIF), which is a software construct that allows to easily hide the
change of anchor from the mobile node.
Bernardos, et al. Expires October 20, 2018 [Page 12]
Internet-Draft PMIPv6 DMM and DLIF April 2018
+---------------------------------------------------+
( Operator's )
( core )
+---------------------------------------------------+
| |
+---------------+ tunnel +---------------+
| IP stack |===============| IP stack |
+---------------+ +-------+-------+
| mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+
+---------------+ | | +-------+-------+ |
| phy interface | | | | phy interface | |
+---------------+ | | +---------------+ |
MAAR1 (o) (o) MAAR2 (o)
x x
x x
prefA::/64 x x prefB::/64
(AdvPrefLft=0) x x
(o)
|
+-----+
prefA::MN1 | MN1 | prefB::MN1
(deprecated) +-----+
Figure 5: DLIF: exposing multiple routers (one per active anchoring
MAAR)
The basic idea of the DLIF concept is the following. Each serving
MAAR exposes itself towards a given MN as multiple routers, one per
active anchoring MAAR associated to the MN. Let's consider the
example shown in Figure 5, MN1 initially attaches to MAAR1,
configuring an IPv6 address (prefA::MN1) from a prefix locally
anchored at MAAR1 (prefA::/64). At this stage, MAAR1 plays both the
role of anchoring and serving MAAR, and also it behaves as a plain
IPv6 access router. MAAR1 creates a distributed logical interface to
communicate (point-to-point link) with MN1, exposing itself as a
(logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and
IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64)
using the DLIF mn1mar1. As explained below, these addresses
represent the "logical" identity of MAAR1 towards MN1, and will
"follow" the mobile node while roaming within the domain (note that
the place where all this information is maintained and updated is
out-of-scope of this draft; potential examples are to keep it on the
HSS or the user's profile).
If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in
the example of Figure 5), this MAAR will create a new logical
interface (mn1mar2) to expose itself towards MN1, providing it with a
locally anchored prefix (prefB::/64). In this case, since the MN1
Bernardos, et al. Expires October 20, 2018 [Page 13]
Internet-Draft PMIPv6 DMM and DLIF April 2018
has another active IPv6 address anchored at a MAAR1, MAAR2 also needs
to create an additional logical interface configured to exactly
resemble the one used by MAAR1 to communicate with MN1. In this
example, there is only one active anchoring MAAR (in addition to
MAAR2, which is the serving one): MAAR1, so only the logical
interface mn1mar1 is created, but the same process would be repeated
in case there were more active anchoring MAARs involved. In order to
maintain the prefix anchored at MAAR1 reachable, a tunnel between
MAAR1 and MAAR2 is established and the routing is modified
accordingly. The PBU/PBA signaling is used to set-up the bi-
directional tunnel between MAAR1 and MAAR2, and it might also be used
to convey to MAAR2 the information about the prefix(es) anchored at
MAAR1 and about the addresses of the associated DLIF (i.e., mn1mar1).
+------------------------------------------+ +----------------------+
| MAAR1 | | MAAR2 |
|+----------------------------------------+| |+--------------------+|
||+------------------++------------------+|| ||+------------------+||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2||||
|||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 ||||
|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 |||
||+------------------++------------------+|| ||+------------------+||
|| HMAC1 (phy if MAAR1) || ||HMAC2 (phy if MAAR2)||
|+----------------------------------------+| |+--------------------+|
+------------------------------------------+ +----------------------+
x x x
x x x
(o) (o) (o)
| | |
+--+--+ +--+--+ +--+--+
| MN3 | | MN2 | | MN1 |
+-----+ +-----+ +-----+
Figure 6: Distributed Logical Interface concept
Figure 6 shows the logical interface concept in more detail. The
figure shows two MAARs and three MNs. MAAR1 is currently serving MN2
and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two
active anchoring MAARs: MAAR1 and MAAR2. Note that a serving MAAR
always plays the role of anchoring MAAR for the attached (served)
MNs. Each MAAR has one single physical wireless interface.
As introduced before, each MN always "sees" multiple logical routers
-- one per active anchoring MAAR -- independently of to which serving
MAAR the MN is currently attached. From the point of view of the MN,
these MAARs are portrayed as different routers, although the MN is
Bernardos, et al. Expires October 20, 2018 [Page 14]
Internet-Draft PMIPv6 DMM and DLIF April 2018
physically attached to one single interface . The way this is
achieved is by the serving MAAR configuring different logical
interfaces. If we focus on MN1, it is currently attached to MAAR2
(i.e., MAAR2 is its serving MAAR) and, therefore, it has configured
an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 has set-
up a logical interface (mn1dgw2) on top of its wireless physical
interface (phy if MAAR2) which is used to serve MN1. This interface
has a logical MAC address (LMAC6), different from the hardware MAC
address (HMAC2) of the physical interface of MAAR2. Over the mn1dgw2
interface, MAAR2 advertises its locally anchored prefix prefB::/64.
Before attaching to MAAR2, MN1 visited MAAR1, configuring also an
address locally anchored at this MAAR, which is still being used by
the MN1 in active communications. MN1 keeps "seeing" an interface
connecting to MAAR1, as if it were directly connected to the two
MAARs. This is achieved by the serving MAAR (MAAR1) configuring an
additional distributed logical interface: mn1dgw1, which behaves
exactly as the logical interface configured by the actual MAAR1 when
MN1 was attached to it. This means that both the MAC and IPv6
addresses configured on this logical interface remain the same
regardless of the physical MAAR which is serving the MN. The
information required by a serving MAAR to properly configure this
logical interfaces can be obtained in different ways: as part of the
information conveyed in the PBA, from an external database (e.g., the
HSS) or by other means. As shown in the figure, each MAAR may have
several logical interfaces associated to each attached MN, having
always at least one (since a serving MAAR is also an anchoring MAAR
for the attached MN).
In order to enforce the use of the prefix locally anchored at the
serving MAAR, the router advertisements sent over those logical
interfaces playing the role of anchoring MAARs (different from the
serving one) include a zero prefix lifetime. The goal is to
deprecate the prefixes delegated by these MAARs (which will be no
longer serving the MN). Note that on-going communications keep on
using those addresses, even if they are deprecated, so this only
affects to new sessions.
The distributed logical interface concept also enables the following
use case. Suppose that access to a local IP network is provided by a
given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that
the resources available at that network cannot be reached from
outside the local network (e.g., cannot be accessed by an MN attached
to MAAR2). This is similar to the LIPA scenario currently being
consider by 3GPP. The goal is to allow an MN to be able to roam
while still being able to have connectivity to this local IP network.
The solution adopted to support this case makes use of RFC 4191
[RFC4191] more specific routes when the MN moves to a MAAR different
from the one providing access to the local IP network (MAAR1 in the
Bernardos, et al. Expires October 20, 2018 [Page 15]
Internet-Draft PMIPv6 DMM and DLIF April 2018
example). These routes are advertised through the distributed
logical interface representing the MAAR providing access to the local
network (MAAR1 in this example). In this way, if MN1 moves from
MAAR1 to MAAR2, any active session that MN1 may have with a node of
the local network connected to MAAR1 will survive, being the traffic
forwarded via the tunnel between MAAR1 and MAAR2. Also, any
potential future connection attempt towards the local network will be
supported, even though MN1 is no longer attached to MAAR1.
3.7. Message Format
This section defines extensions to the Proxy Mobile IPv6 [RFC5213]
protocol messages.
3.7.1. Proxy Binding Update
A new flag (D) is included in the Proxy Binding Update to indicate
that the Proxy Binding Update is coming from a Mobility Anchor and
Access Router and not from a mobile access gateway. The rest of the
Proxy Binding Update format remains the same as defined in [RFC5213].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAAR Flag (D)
The D Flag is set to indicate to the receiver of the message that
the Proxy Binding Update is from a MAAR.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of
Bernardos, et al. Expires October 20, 2018 [Page 16]
Internet-Draft PMIPv6 DMM and DLIF April 2018
[RFC6275]. The MAAR MUST ignore and skip any options that it does
not understand.
3.7.2. Proxy Binding Acknowledgment
A new flag (D) is included in the Proxy Binding Acknowledgment to
indicate that the sender supports operating as a distributed gateway.
The rest of the Proxy Binding Acknowledgment format remains the same
as defined in [RFC5213].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|D| Reser |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAAR (D)
The D is set to indicate that the sender of the message supports
operating as a distributed gateway.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of
[RFC6275]. The MAAR MUST ignore and skip any options that it does
not understand.
3.7.3. Anchored Prefix Option
A new Anchored Prefix option is defined for use with the Proxy
Binding Update and Proxy Binding Acknowledgment messages exchanged
between distributed gateways. This option is used for exchanging the
mobile node's prefix anchored at the anchoring MAAR. There can be
multiple Anchored Prefix options present in the message.
The Anchored Prefix Option has an alignment requirement of 8n+4. Its
format is as follows:
Bernardos, et al. Expires October 20, 2018 [Page 17]
Internet-Draft PMIPv6 DMM and DLIF April 2018
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Anchored Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA.
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST be
set to 18.
Reserved
This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver.
Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Anchored Prefix
A sixteen-byte field containing the mobile node's IPv6 Anchored
Prefix.
3.7.4. Local Prefix Option
A new Local Prefix option is defined for use with the Proxy Binding
Update and Proxy Binding Acknowledgment messages exchanged between
MAARs. This option is used for exchanging a prefix of a local