-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-dmm-pmipv6-dlif-02.xml
1877 lines (1560 loc) · 76.2 KB
/
draft-ietf-dmm-pmipv6-dlif-02.xml
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
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5213 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY rfc6275 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY rfc4877 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml">
<!ENTITY rfc3972 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY rfc7333 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7333.xml">
<!ENTITY rfc7429 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7429.xml">
<!ENTITY rfc4191 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY rfc4861 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY I-D.bernardos-dmm-distributed-anchoring SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernardos-dmm-distributed-anchoring.xml">
<!ENTITY I-D.bernardos-dmm-pmip SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernardos-dmm-pmip.xml">
<!ENTITY I-D.ietf-dmm-ondemand-mobility SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dmm-ondemand-mobility.xml">
<!ENTITY I-D.ietf-dmm-deployment-models SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dmm-deployment-models.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-dmm-pmipv6-dlif-02">
<front>
<title abbrev="PMIPv6 DMM and DLIF">Proxy Mobile IPv6 extensions for Distributed Mobility Management</title>
<!-- AUTHORS -->
<author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
<organization abbrev="UC3M">Universidad Carlos III de
Madrid</organization>
<address>
<postal>
<street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34 91624 6236</phone>
<email>[email protected]</email>
<uri>http://www.it.uc3m.es/cjbc/</uri>
</address>
</author>
<author fullname="Antonio de la Oliva" initials="A." surname="de la Oliva">
<organization abbrev="UC3M">Universidad Carlos III de
Madrid</organization>
<address>
<postal>
<street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34 91624 8803</phone>
<email>[email protected]</email>
<uri>http://www.it.uc3m.es/aoliva/</uri>
</address>
</author>
<author fullname="Fabio Giust" initials="F." surname="Giust">
<organization abbrev="Athonet">Athonet S.r.l.</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Juan Carlos Zuniga"
initials="JC."
surname="Zuniga">
<organization abbrev="SIGFOX">
SIGFOX
</organization>
<address>
<postal>
<street>425 rue Jean Rostand</street>
<city>Labege</city>
<code> 31670</code>
<country>France</country>
</postal>
<email>[email protected]</email>
<uri>http://www.sigfox.com/</uri>
</address>
</author>
<author fullname="Alain Mourad"
initials="A."
surname="Mourad">
<organization abbrev="InterDigital">
InterDigital Europe
</organization>
<address>
<email>[email protected]</email>
<uri>http://www.InterDigital.com/</uri>
</address>
</author>
<date month="August" year="2018" />
<area>Internet</area>
<workgroup>DMM Working Group</workgroup>
<abstract>
<t>
Distributed Mobility Management solutions allow for setting up networks so that
traffic is distributed in an optimal way and does not rely on centrally
deployed anchors to provide IP mobility support.
</t>
<t>
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 (like 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 a 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.
</t>
<!--
<t>
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.
</t>
-->
</abstract>
<note title="Requirements Language">
<t>
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 <xref
target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section anchor="sec:introduction" title="Introduction">
<t>
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).
</t>
<t>
Current IP mobility solutions, standardized with the names of Mobile IPv6 <xref
target="RFC6275"></xref>, or Proxy Mobile IPv6 (PMIPv6) <xref
target="RFC5213"></xref>, just to cite the two most relevant examples, offer
mobility support at the cost of handling operations at a cardinal point, the
mobility anchor (i.e., the home agent for Mobile IPv6, and the local mobility
anchor for Proxy Mobile IPv6), and burdening it with data forwarding and control
mechanisms for a great amount of users. As stated in <xref
target="RFC7333"></xref>, 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 of 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).
</t>
<t>
The purpose of Distributed Mobility Management is to overcome the limitations of
the traditional centralized mobility management <xref target="RFC7333" /> <xref
target="RFC7429" />; the main concept behind DMM solutions is indeed bringing
the mobility anchor closer to the Mobile Node (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).
</t>
<t>
This document focuses on network-based DMM, hence the starting point is making
PMIPv6 working in a distributed manner <xref target="RFC7429"></xref>. 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.
</t>
<t>
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.
</t>
</section>
<section anchor="sec:terminology" title="Terminology">
<!-- [2018-06-27] cjbc: comment from Alex:
> Overall, you have:
> - Serving MAAR
> - Previous MAAR
> - [non-active] anchoring MAAR
> - active anchoring MAAR
>
> Not sure which is which since the latter two are not defined in
> Terminology.
[Carlos] This is a good point. We will clarify this in the terminology
section of the next revision.
[2018-08-22] Carlos: a P-MAAR is by definition an active anchoring MAAR, so no
need to ad further. What was needed was to replace the use of "active anchoring
MAAR(s)" by "P-MAAR(s)", done as per Lyle's review.
-->
<t>
The following terms used in this document are defined in the Proxy Mobile IPv6
specification <xref target="RFC5213" />:
<list style="empty">
<t>Local Mobility Anchor (LMA)</t>
<t>Mobile Access Gateway (MAG)</t>
<t>Mobile Node (MN)</t>
<t>Binding Cache Entry (BCE)</t>
<t>Proxy Care-of Address (P-CoA)</t>
<t>Proxy Binding Update (PBU)</t>
<t>Proxy Binding Acknowledgement (PBA)</t>
</list>
</t>
<t>
The following terms used in this document are defined in the DMM Deployment
Models and Architectural Considerations document <xref
target="I-D.ietf-dmm-deployment-models" />:
<list style="empty">
<t>Home Control-Plane Anchor (Home-CPA)</t>
<t>Home Data Plane Anchor (Home-DPA)</t>
<t>Access Control Plane Node (Access-CPN)</t>
<t>Access Data Plane Node (Access-DPN)</t>
</list>
</t>
<t>
The following terms are defined and used in this document:
<list style="hanging">
<t hangText="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.
</t>
<t hangText="CMD (Central Mobility Database).">
Node that stores the BCEs allocated for the MNs in the mobility domain. It plays
the role of Home-CPA.
</t>
<t hangText="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). It plays the role of Home-DPA for the flows it is
still serving for the MN's mobility session. There might be multiple P-MAARs for
an MN's mobility session.
</t>
<t hangText="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.
</t>
<t hangText="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 S-MAAR has a DLIF configured (associated to each
MAAR still anchoring flows). In this way, a S-MAAR exposes itself towards each
MN as multiple routers, one as itself and one per P-MAAR.
</t>
</list>
</t>
</section>
<section anchor="sec:pmipv6_based" title="PMIPv6 DMM extensions">
<t>
The solution consists of de-coupling the entities that participate 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 those 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:
<list style="symbols">
<t>
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 an Home-CPA. Also, the CMD is able
to send and parse both PBU and PBA messages.
</t>
<t>
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.
</t>
<t>
The binding cache will be extended to include information regarding P-MAARs
where the mobile node was anchored and still retains active data sessions, see
<xref target="sec:appx2"></xref> for further details.
</t>
<t>
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.
</t>
</list>
</t>
<t>
The MAARs leverage 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 of the network status. 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:
<list style="symbols">
<t>The CMD is a PBU/PBA relay;</t>
<t>The CMD is only a MAAR locator;</t>
<t>The CMD is a PBU/PBA proxy.</t>
</list>
</t>
<t>
This solution can be categorized under Model-1: Split Home Anchor Mode in <xref
target="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 to switch to the locally anchored
prefix to gain route optimization, as indicated in <xref
target="I-D.ietf-dmm-ondemand-mobility" />.
</t>
<t>
Note that a MN MAY move across different MAARs, which might result in several
P-MAARs existing at a given moment of time, each of them anchoring a prefix used
by the MN.
</t>
<section anchor="subsec:init" title="Initial registration">
<t>
Upon the MN's attachment to a MAAR, say MAAR1 as shown in <xref
target="fig:DMM_1" />, if the MN is authorized for the service, an IPv6 global
prefix belonging to the MAAR1's prefix pool is reserved for it (Pref1) into a
temporary Binding Cache Entry (BCE) allocated locally. The prefix is sent in a
<xref target="RFC5213" /> PBU with the MN's Identifier (MN-ID) to the CMD,
which, since the session is new, stores a permanent BCE containing as primary
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 PMIPv6 <xref
target="RFC5213" />, meaning that the MN's registration is fresh and no past
status is available. MAAR1 stores the temporary 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, SLAAC). Alternative IPv6 auto-configuration
mechanisms can also be used, though this document describes the SLAAC-based one.
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.
</t>
<figure anchor="fig:DMM_1" title="First attachment to the network">
<artwork><![CDATA[
+-----+ +---+ +--+
|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
]]></artwork>
</figure>
<t>
Note that the registration process does not change regardless of the CMD's modes
(relay, locator or proxy) described next.
</t>
</section>
<section anchor="subsec:relay" title="The CMD as PBU/PBA relay">
<t>
When the MN moves from its current access and attaches to MAAR2 (now the
S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it stores a temporary 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 <xref
target="subsec:smaaropt" />. The CMD updates the P-CoA field in the BCE related
to the MN with the S-MAAR's address.
</t>
<t>
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 <xref target="sec:appx2"></xref> for further details). Also, the
CMD sends 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 <xref target="subsec:pmaaropt"></xref>), 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.
</t>
<t>
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 <xref target="fig:DMM2" />.
</t>
<figure anchor="fig:DMM2"
title="Scenario after a handover, CMD as relay">
<artwork><![CDATA[
+-----+ +---+ +-----+ +--+ +--+
|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
]]></artwork>
</figure>
<t>
For MN's next movements the process is repeated except the number of P-MAARs
involved increases, 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.
</t>
<t>
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.
</t>
</section>
<section anchor="subsec:locator" title="The CMD as MAAR locator">
<t>
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 reflects what was described in <xref target="subsec:relay" /> 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 is 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. <xref target="fig:DMM3" /> illustrates the new message
sequence, while the data forwarding is unaltered.
</t>
<figure anchor="fig:DMM3"
title="Scenario after a handover, CMD as locator">
<artwork><![CDATA[
+-----+ +---+ +-----+ +--+ +--+
|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
]]></artwork>
</figure>
</section>
<section anchor="subsec:proxy" title="The CMD as MAAR proxy">
<t>
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
possession 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 <xref
target="fig:DMM4"></xref>, where, again, the data forwarding is kept untouched.
</t>
<figure anchor="fig:DMM4"
title="Scenario after a handover, CMD as proxy">
<artwork><![CDATA[
+-----+ +---+ +-----+ +--+ +--+
|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
]]></artwork>
</figure>
</section>
<section anchor="subsec:dereg" title="De-registration">
<t>
The de-registration mechanism devised for PMIPv6 cannot be used as is in this
solution. 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:
<!-- [2018-08-22] cjbc: comments from Lyle still to be addressed:
- Okay, this is an important concept - the aggregated session. In fact the CMD only holds an aggregated session. It MAY be good to note that in previous sections and it MAY be ideal to add it to the Terminology. This is just a suggestion.
- In this scenario if you have N P-MAARs and one fails then you have to tear down the whole session. Your available went from a probability of X to a lower value.
(check word file) -->
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section anchor="sec:dlif_concept" title="The Distributed Logical
Interface (DLIF) concept">
<t>
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 node
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.
</t>
<figure anchor="fig:exposing_multiple_routers"
title="DLIF: exposing multiple routers (one per P-MAAR)">
<artwork><![CDATA[
+---------------------------------------------------+
( 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) +-----+
]]></artwork>
</figure>
<t>
The basic idea of the DLIF concept is the following. Each serving MAAR exposes
itself towards a given MN as multiple routers, one per P-MAAR
associated to the MN. Let's consider the example shown in <xref
target="fig:exposing_multiple_routers" />, 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 home
subscriber server -- HSS -- or the user's profile).
</t>
<t>
If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in the
example of <xref target="fig:exposing_multiple_routers" />), 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 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 P-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 P-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).
</t>
<!-- [2018-08-22] cjbc: comment from Lyle:
Is it an assumption of this document that all MAARs are part of the same domain? If so, how does roaming transitioning to/from non-roaming work? Also keeping the sessions active (per the deregistration section) would be agitating if the aggregated session spanned two domains.
-->
<figure anchor="fig:dlif_concept"
title="Distributed Logical Interface concept">
<artwork><![CDATA[
+------------------------------------------+ +----------------------+
| 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 |
+-----+ +-----+ +-----+
]]></artwork>
</figure>
<t>
<xref target="fig:dlif_concept" /> 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 P-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.
</t>
<t>
As introduced before, each MN always "sees" multiple logical routers -- one per
P-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 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 (mn1mar2) 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 mn1mar2 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 (MAAR2) configuring an additional distributed logical interface: mn1mar1,
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).
</t>
<t>
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 preferred prefix
lifetime (and a non-zero valid prefix lifetime, so the prefix remains valid,
while being deprecated). 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.
</t>
<!-- [2018-08-222] cjbc: Comment from Lyle:
A lot of this should probably have been mentioned in the previous sections.
Would it be wiser to place this section before the CMD PBU/PBA discussion.
Carlos: I think it is better not to move it, as our solution would work also
without the DLIF.
-->
<t>
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 <xref target="fig:exposing_multiple_routers" />)
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 local IP access scenario considered by 3GPP, where a local
gateway node is selected for sessions requiring access to services provided
locally (instead of going through a central gateway). 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 <xref
target="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 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.
</t>
</section>
</section>
<!-- end of section "PMIPv6-based" -->
<section anchor="subsec:messages" title="Message Format">
<t>
This section defines extensions to the Proxy Mobile IPv6 <xref target="RFC5213"
/> protocol messages.
</t>
<section anchor="sec:pbu_format" title="Proxy Binding Update">
<t>
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 <xref target="RFC5213" />.
</t>
<figure>
<artwork><![CDATA[
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
MAAR Flag (D)
<list>
<t>
The D Flag is set to indicate to the receiver of the message that the Proxy
Binding Update is from a MAAR. When an LMA that does not support the extensions
described in this document receives a message with the D-Flag set, the PBU in
that case MUST NOT be processed by the LMA and an error MUST be returned.
</t>
</list>
</t>
<t>
Mobility Options
<list>
<t>
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 <xref target="RFC6275" />. The MAAR MUST ignore and skip any
options that it does not understand.
</t>
</list>
</t>
</section>
<section anchor="sec:pba_format" title="Proxy Binding Acknowledgment">
<t>
A new flag (D) is included in the Proxy Binding Acknowledgment to indicate that
the sender supports operating as a Mobility Anchor and Access Router. The rest
of the Proxy Binding Acknowledgment format remains the same as defined in <xref
target="RFC5213" />.
</t>
<figure>
<artwork><![CDATA[
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
MAAR (D)
<list>
<t>
The D is set to indicate that the sender of the message supports operating as a
Mobility Anchor and Access Router. When a MAG that does not support the
extensions described in this document receives a message with the D-Flag set,
the PBA in that case MUST NOT be processed by the MAG and an error MUST be
returned.
</t>
</list>
</t>