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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
|
<pre>Internet Engineering Task Force (IETF) H. Yokota
Request for Comments: 5949 KDDI Lab
Category: Standards Track K. Chowdhury
ISSN: 2070-1721 R. Koodli
Cisco Systems
B. Patil
Nokia
F. Xia
Huawei USA
September 2010
<span class="h1">Fast Handovers for Proxy Mobile IPv6</span>
Abstract
Mobile IPv6 (MIPv6; <a href="./rfc3775">RFC 3775</a>) provides a mobile node with IP mobility
when it performs a handover from one access router to another, and
fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the
handover performance in terms of latency and packet loss. While
MIPv6 (and FMIPv6 as well) requires the participation of the mobile
node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6;
<a href="./rfc5213">RFC 5213</a>) provides IP mobility to nodes that either have or do not
have MIPv6 functionality without such involvement. Nevertheless, the
basic performance of PMIPv6 in terms of handover latency and packet
loss is considered no different from that of MIPv6.
When the fast handover is considered in such an environment, several
modifications are needed to FMIPv6 to adapt to the network-based
mobility management. This document specifies the usage of fast
handovers for Mobile IPv6 (FMIPv6; <a href="./rfc5568">RFC 5568</a>) when Proxy Mobile IPv6
is used as the mobility management protocol. Necessary extensions
are specified for FMIPv6 to support the scenario when the mobile node
does not have IP mobility functionality and hence is not involved
with either MIPv6 or FMIPv6 operations.
<span class="grey">Yokota, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5949">http://www.rfc-editor.org/info/rfc5949</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. This document is subject to
<a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal Provisions Relating to IETF
Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Yokota, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Requirements Notation ...........................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Proxy-Based FMIPv6 Protocol Overview ............................<a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Protocol Operation .........................................<a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Inter-AR Tunneling Operation ..............................<a href="#page-14">14</a>
<a href="#section-4.3">4.3</a>. IPv4 Support Considerations ...............................<a href="#page-16">16</a>
<a href="#section-5">5</a>. PMIPv6-Related Fast Handover Issues ............................<a href="#page-16">16</a>
<a href="#section-5.1">5.1</a>. Manageability Considerations ..............................<a href="#page-16">16</a>
<a href="#section-5.2">5.2</a>. Expedited Packet Transmission .............................<a href="#page-17">17</a>
<a href="#section-6">6</a>. Message Formats ................................................<a href="#page-18">18</a>
<a href="#section-6.1">6.1</a>. Mobility Header ...........................................<a href="#page-18">18</a>
<a href="#section-6.1.1">6.1.1</a>. Handover Initiate (HI) .............................<a href="#page-18">18</a>
<a href="#section-6.1.2">6.1.2</a>. Handover Acknowledge (HAck) ........................<a href="#page-20">20</a>
<a href="#section-6.2">6.2</a>. Mobility Options ..........................................<a href="#page-22">22</a>
<a href="#section-6.2.1">6.2.1</a>. Context Request Option .............................<a href="#page-22">22</a>
<a href="#section-6.2.2">6.2.2</a>. Local Mobility Anchor Address (LMAA) Option ........<a href="#page-23">23</a>
6.2.3. Mobile Node Link-Local Address Interface
Identifier (MN LLA-IID) Option .....................<a href="#page-24">24</a>
<a href="#section-6.2.4">6.2.4</a>. Home Network Prefix Option .........................<a href="#page-25">25</a>
<a href="#section-6.2.5">6.2.5</a>. Link-Local Address Option ..........................<a href="#page-25">25</a>
<a href="#section-6.2.6">6.2.6</a>. GRE Key Option .....................................<a href="#page-25">25</a>
<a href="#section-6.2.7">6.2.7</a>. IPv4 Address Option ................................<a href="#page-25">25</a>
<a href="#section-6.2.8">6.2.8</a>. Vendor-Specific Mobility Option ....................<a href="#page-25">25</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-26">26</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-26">26</a>
<a href="#section-9">9</a>. Acknowledgments ................................................<a href="#page-28">28</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-28">28</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-28">28</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-29">29</a>
<a href="#appendix-A">Appendix A</a>. Applicable Use Cases ..................................<a href="#page-30">30</a>
<a href="#appendix-A.1">A.1</a>. PMIPv6 Handoff Indication .................................<a href="#page-30">30</a>
<a href="#appendix-A.2">A.2</a>. Local Routing .............................................<a href="#page-31">31</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Proxy Mobile IPv6 (PMIPv6) [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] provides IP mobility to a mobile
node that does not support Mobile IPv6 (MIPv6) [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] mobile node
functionality. A proxy agent in the network performs the mobility
management signaling on behalf of the mobile node. This model
transparently provides mobility for nodes within a PMIPv6 domain.
Nevertheless, the basic performance of PMIPv6 in terms of handover
latency and packet loss is considered no different from that of
Mobile IPv6.
<span class="grey">Yokota, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Fast handovers for Mobile IPv6 (FMIPv6) [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] describes the
protocol to reduce the handover latency for Mobile IPv6 by allowing a
mobile node to send packets as soon as it detects a new subnet link
and by delivering packets to the mobile node as soon as its
attachment is detected by the new access router. This document
extends FMIPv6 for Proxy MIPv6 operation to minimize handover delay
and packet loss as well as to transfer network-resident context for a
PMIPv6 handover. [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] is normative for this document, except
where this document specifies new or revised functions and messages.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Notation</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
This document reuses terminology from [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>], and
[<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>]. The following terms and abbreviations are additionally
used in this document.
Access Network (AN):
A network composed of link-layer access devices such as access
points or base stations providing access to a Mobile Access
Gateway (MAG) connected to it.
Previous Access Network (P-AN):
The access network to which the Mobile Node (MN) is attached
before handover.
New Access Network (N-AN):
The access network to which the Mobile Node (MN) is attached after
handover.
Previous Mobile Access Gateway (PMAG):
The MAG that manages mobility-related signaling for the mobile
node before handover. In this document, the MAG and the Access
Router are co-located.
New Mobile Access Gateway (NMAG):
The MAG that manages mobility-related signaling for the mobile
node after handover. In this document, the MAG and the Access
Router (AR) are co-located.
<span class="grey">Yokota, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Local Mobility Anchor (LMA):
The topological anchor point for the mobile node's home network
prefix(es) and the entity that manages the mobile node's binding
state. This specification does not alter any capability or
functionality defined in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>].
Handover indication:
A generic signaling message, sent from the P-AN to the PMAG, that
indicates a mobile node's handover. While this signaling is
dependent on the access technology, it is assumed that Handover
indication can carry the information to identify the mobile node
and to assist the PMAG in resolving the NMAG (and the new access
point or base station) to which the mobile node is moving. The
details of this message are outside the scope of this document.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Proxy-Based FMIPv6 Protocol Overview</span>
This specification describes fast handover protocols for the network-
based mobility management protocol called Proxy Mobile IPv6 (PMIPv6)
[<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>]. The core functional entities defined in PMIPv6 are the
Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The
LMA is the topological anchor point for the mobile node's home
network prefix(es). The MAG acts as an access router (AR) for the
mobile node and performs the mobility management procedures on its
behalf. The MAG is responsible for detecting the mobile node's
movements to and from the access link and for initiating binding
registrations to the mobile node's local mobility anchor. If the
MAGs can be informed of the detachment and/or attachment of the
mobile node in a timely manner via, e.g., lower-layer signaling, it
will become possible to optimize the handover procedure, which
involves establishing a connection on the new link and signaling
between mobility agents, compared to the baseline specification of
PMIPv6.
In order to further improve the performance during the handover, this
document specifies a bidirectional tunnel between the Previous MAG
(PMAG) and the New MAG (NMAG) to tunnel packets meant for the mobile
node. In order to enable the NMAG to send the Proxy Binding Update
(PBU), the Handover Initiate (HI) and Handover Acknowledge (HAck)
messages in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] are extended for context transfer, in which
parameters such as the mobile node's Network Access Identifier (NAI),
Home Network Prefix (HNP), and IPv4 Home Address are transferred from
the PMAG. New flags, 'P' and 'F', are defined for the HI and HAck
messages to distinguish from those in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] and to request packet
forwarding, respectively.
<span class="grey">Yokota, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
In this document, the Previous Access Router (PAR) and New Access
Router (NAR) are interchangeable with the PMAG and NMAG,
respectively. The reference network is illustrated in Figure 1. The
access networks in the figure (i.e., P-AN and N-AN) are composed of
Access Points (APs) defined in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>], which are often referred to
as base stations in cellular networks.
Since a mobile node is not directly involved with IP mobility
protocol operations, it follows that the mobile node is not directly
involved with fast handover procedures either. Hence, the messages
involving the mobile node in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] are not used when PMIPv6 is in
use. More specifically, the Router Solicitation for Proxy
Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv),
Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack), and
the Unsolicited Neighbor Advertisement (UNA) messages are not
applicable in the PMIPv6 context. A MAG that receives a RtSolPr or
FBU message from a mobile node SHOULD behave as if they do not
implement FMIPv6 as defined in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] at all -- continuing to
operate according to this specification within the network -- or
alternatively, start serving that particular mobile node as specified
in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>].
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PMAG |()_______)| NMAG | .
. | (PAR) | . . | (NAR) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover
<span class="grey">Yokota, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Protocol Operation</span>
There are two modes of operation in FMIPv6 [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]. In the
predictive mode of fast handover, a bidirectional tunnel between the
PMAG (PAR) and NMAG (NAR) is established prior to the mobile node's
attachment to the NMAG. In the reactive mode, this tunnel
establishment takes place after the mobile node attaches to the NMAG.
In order to alleviate the packet loss during a mobile node's handover
(especially when the mobile node is detached from both links), the
downlink packets for the mobile node need to be buffered either at
the PMAG or NMAG, depending on when the packet forwarding is
performed. It is hence REQUIRED that all MAGs have the capability
and enough resources to buffer packets for the mobile nodes
accommodated by them. The buffer size to be prepared and the rate at
which buffered packets are drained are addressed in <a href="./rfc5568#section-5.4">Section 5.4 of
[RFC5568]</a>. Note that the protocol operation specified in the
document is transparent to the local mobility anchor (LMA); hence
there is no new functional requirement or change on the LMA.
Unlike MIPv6, the mobile node in the PMIPv6 domain is not involved
with IP mobility signaling; therefore, in order for the predictive
fast handover to work effectively, it is REQUIRED that the mobile
node is capable of reporting lower-layer information to the AN at a
short enough interval, and that the AN is capable of sending the
Handover indication to the PMAG at an appropriate timing. The
sequence of events for the predictive fast handover is illustrated in
Figure 2.
<span class="grey">Yokota, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) |--Report-->| | | | |
| | | | | |
| | Handover | | |
(b) | |------indication------>| | |
| | | | | |
| | | | | |
(c) | | | |----HI---->| |
| | | | | |
| | | | | |
(d) | | | |<---HAck---| |
| | | | | |
| | | | | |
| | | |HI/HAck(optional) |
(e) | | | |<- - - - ->| |
| | | #=|<===================|
(f) | | | #====DL data=>| |
| Handover | Handover | | |
(g) |<-command--|<------command---------| | |
~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(h) |<---establishment---->|<----establishment----->| |
| | | (substitute for UNA) | |
| | | | | |
(i) |<==================DL data=====================| |
| | | | | |
(j) |===================UL data====================>|=# |
| | | #=|<============# |
| | | #=====================>|
/ | | | | | | \
|(k) | | | | |--PBU-->| |
| | | | | | | |
|(l) | | | | |<--PBA--| |
| |<==================DL data=====================|<=======| |
| | | | | | | |
\ |===================UL data====================>|=======>| /
UL Uplink
DL Downlink
PBA Proxy Binding Acknowledgment
Figure 2: Predictive Fast Handover for PMIPv6 (Initiated by PMAG)
<span class="grey">Yokota, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
The detailed descriptions are as follows:
(a) The mobile node detects that a handover is imminent and reports
its identifier (MN ID) and the New Access Point Identifier (New
AP ID) [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] to which the mobile node is most likely to
move. The MN ID could be the NAI, link-layer address, or any
other suitable identifier, but the MAG SHOULD be able to map any
access-specific identifier to the NAI as the MN ID. In some
cases, the previous access network (P-AN) will determine the New
AP ID for the mobile node. This step is access technology
specific, and details are outside the scope of this document.
(b) The previous access network, to which the mobile node is
currently attached, indicates the handover of the mobile node to
the previous mobile access gateway (PMAG), with the MN ID and
New AP ID. Detailed definition and specification of this
message are outside the scope of this document.
(c) The previous MAG derives the new mobile access gateway (NMAG)
from the New AP ID, which is a similar process to that of
constructing an [AP ID, AR-Info] tuple in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]. The
previous MAG then sends the Handover Initiate (HI) message to
the new MAG. The HI message MUST have the 'P' flag set and
include the MN ID, the HNP(s), and the address of the local
mobility anchor that is currently serving the mobile node. If
there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID),
that information MUST also be included. With some link layers,
the MN Link-local Address Interface Identifier (MN LLA-IID) can
also be included (see <a href="#section-6.2.3">Section 6.2.3</a>).
(d) The new MAG sends the Handover Acknowledge (HAck) message back
to the previous MAG with the 'P' flag set.
(e) If it is preferred that the timing of buffering or forwarding
should be later than step (c), the new MAG MAY optionally
request that the previous MAG buffer or forward packets at a
later and appropriate time, by setting the 'U' flag [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] or
the 'F' flag in the HI message, respectively.
(f) If the 'F' flag is set in the previous step, a bidirectional
tunnel is established between the previous MAG and new MAG, and
packets destined for the mobile node are forwarded from the
previous MAG to the new MAG over this tunnel. After
decapsulation, those packets MAY be buffered at the new MAG. If
the connection between the new access network and new MAG has
already been established, those packets MAY be forwarded towards
<span class="grey">Yokota, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
the new access network, which then becomes responsible for them
(e.g., buffering or delivering, depending on the condition of
the mobile node's attachment); this is access technology
specific.
(g) When handover is ready on the network side, the mobile node is
triggered to perform handover to the new access network. This
step is access technology specific, and details are outside the
scope of this document.
(h) The mobile node establishes a physical-layer connection with the
new access network (e.g., radio channel assignment), which in
turn triggers the establishment of a link-layer connection
between the new access network and new MAG if not yet
established. An IP-layer connection setup may be performed at
this time (e.g., PPP IPv6 Control Protocol) or at a later time
(e.g., stateful or stateless address autoconfiguration). This
step can be a substitute for the Unsolicited Neighbor
Advertisement (UNA) in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]. If the new MAG acquires a
valid new MN LL-ID via the new access network and a valid old MN
LL-ID from the previous MAG at step (c), these IDs SHOULD be
compared to determine whether the same interface is used before
and after handover. When the connection between the mobile node
and new MAG is PPP and the same interface is used for the
handover, the new MAG SHOULD confirm that the same interface
identifier is used for the mobile node's link-local address
(this is transferred from the previous MAG using the MN LLA-IID
option at step (c), and sent to the mobile node during the
Configure-Request/Ack exchange).
(i) The new MAG starts to forward packets destined for the mobile
node via the new access network.
(j) The uplink packets from the mobile node are sent to the new MAG
via the new access network, and the new MAG forwards them to the
previous MAG. The previous MAG then sends the packets to the
local mobility anchor that is currently serving the mobile node.
(k) The new MAG sends the Proxy Binding Update (PBU) to the local
mobility anchor, whose address is provided in step (c). Steps
(k) and (l) are not part of the fast handover procedure but are
shown for reference.
(l) The local mobility anchor sends back the Proxy Binding
Acknowledgment (PBA) to the new MAG. From this time on, the
packets to/from the mobile node go through the new MAG instead
of the previous MAG.
<span class="grey">Yokota, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
According to <a href="./rfc5568#section-4">Section 4 of [RFC5568]</a>, the previous MAG establishes a
binding between the Previous Care-of Address (PCoA) and New Care-of
Address (NCoA) to forward packets for the mobile node to the new MAG,
and the new MAG creates a proxy neighbor cache entry to receive those
packets for the NCoA before the mobile node arrives. In the case of
PMIPv6, however, the only address that is used by the mobile node is
the Mobile Node's Home Address (MN-HoA), so the PMAG forwards the
mobile node's packets to the NMAG instead of the NCoA. The NMAG then
simply decapsulates those packets and delivers them to the mobile
node. FMIPv4 [<a href="./rfc4988" title=""Mobile IPv4 Fast Handovers"">RFC4988</a>] specifies forwarding when the mobile node
uses the home address as its on-link address rather than the care-of
address. The usage in PMIPv6 is similar to that in FMIPv4, where the
address(es) used by the mobile node is/are based on its HNP(s).
Since the NMAG can obtain the link-layer address (MN LL-ID) and
HNP(s) via the HI message (also the interface identifier of the
mobile node's link-local address (MN LLA-ID), if available), it can
create a neighbor cache entry for the link-local address and the
routes for the whole HNP(s), even before the mobile node performs
Neighbor Discovery. For the uplink packets from the mobile node
after handover in step (j), the NMAG forwards the packets to the PMAG
through the tunnel established in step (f). The PMAG then
decapsulates and sends them to the local mobility anchor.
The timing of the context transfer and that of packet forwarding may
be different. Thus, a new flag 'F' and Option Code values for it in
the HI and HAck messages are defined to request forwarding. To
request buffering, the 'U' flag has already been defined in
[<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]. If the PMAG receives the HI message with the 'F' flag
set, it starts forwarding packets for the mobile node. The HI
message with the 'U' flag set MAY be sent earlier if the timing of
buffering is different from that of forwarding. If packet forwarding
is completed, the PMAG MAY send the HI message with the 'F' flag set
and the Option Code value set to 2. Via this message, the ARs on
both ends can tear down the forwarding tunnel synchronously.
The IP addresses in the headers of those user packets are summarized
below:
In step (f),
Inner source address: IP address of the correspondent node
Inner destination address: HNP or Mobile Node's IPv4 Home Address
(IPv4-MN-HoA)
Outer source address: IP address of the PMAG
Outer destination address: IP address of the NMAG
<span class="grey">Yokota, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
In step (i),
Source address: IP address of the correspondent node
Destination address: HNP or IPv4-MN-HoA
In step (j),
- from the mobile node to the NMAG,
Source address: HNP or IPv4-MN-HoA
Destination address: IP address of the correspondent node
- from the NMAG to the PMAG,
Inner source address: HNP or IPv4-MN-HoA
Inner destination address: IP address of the correspondent node
Outer source address: IP address of the NMAG
Outer destination address: IP address of the PMAG
- from the PMAG to the LMA,
Inner source address: HNP or IPv4-MN-HoA
Inner destination address: IP address of the correspondent node
Outer source address: IP address of the PMAG
Outer destination address: IP address of the LMA
In the case of the reactive handover for PMIPv6, since the mobile
node does not send either the FBU or UNA, it would be more natural
that the NMAG send the HI message to the PMAG after the mobile node
has moved to the new link. The NMAG then needs to obtain the
information of the PMAG beforehand. Such information could be
provided, for example, by the mobile node sending the AP-ID on the
old link and/or by the lower-layer procedures between the P-AN and
N-AN. The exact method is not specified in this document. Figure 3
illustrates the reactive fast handover procedures for PMIPv6, where
the bidirectional tunnel establishment is initiated by the NMAG.
<span class="grey">Yokota, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
| | |(substitute for UNA and FBU)| |
| | | | | |
| | | | | |
(c) | | | |<-----HI-------| |
| | | | | |
| | | | | |
(d) | | | |-----HAck----->| |
| | | | | |
| | | | | |
(e) | | | #=|<=======================|
| | | #================>|=# |
|<====================DL data======================# |
| | | | | |
(f) |=====================UL data===================>|=# |
| | | #=|<================# |
| | | #=========================>|
| | | | | |
/ | | | | | | \
|(g) | | | | |--PBU-->| |
| | | | | | | |
|(h) | | | | |<--PBA--| |
| |<====================DL data====================|<=======| |
| | | | | | | |
\ |=====================UL data===================>|=======>| /
Figure 3: Reactive Fast Handover for PMIPv6 (Initiated by NMAG)
The detailed descriptions are as follows:
(a) The mobile node undergoes handover from the previous access
network to the new access network.
(b) The mobile node establishes a connection (e.g., radio channel)
with the new access network, which triggers the establishment of
the connection between the new access network and new MAG. The
MN ID is transferred to the new MAG at this step for the
subsequent procedures. The AP-ID on the old link (Old AP ID),
which will be provided by either the mobile node or the new
access network, is also transferred to the new MAG to help
identify the previous MAG on the new link. This can be regarded
as a substitute for the UNA and FBU.
<span class="grey">Yokota, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
(c) The new MAG sends the HI message to the previous MAG. The HI
message MUST have the 'P' flag set and include the MN ID. The
Context Request option MAY be included to request additional
context information on the mobile node to the previous MAG.
(d) The previous MAG sends the HAck message back to the new MAG with
the 'P' flag set. The HAck message MUST include the HNP(s)
and/or IPv4-MN-HoA that corresponds to the MN ID in the HI
message and SHOULD include the MN LL-ID, only if it is valid
(non-zero), and the local mobility anchor address that is
currently serving the mobile node. The context information
requested by the new MAG MUST be included. If the requested
context is not available for some reason, the previous MAG MUST
return the HAck message with the Code value 131. If the 'F'
flag is set in the HI message at step (c) and forwarding is
nevertheless not executable for some reason, the previous MAG
MUST return the HAck message with the Code value 132.
(e) If the 'F' flag in the HI message is set at step (c), a
bidirectional tunnel is established between the previous MAG and
new MAG, and packets destined for the mobile node are forwarded
from the previous MAG to the new MAG over this tunnel. After
decapsulation, those packets are delivered to the mobile node
via the new access network.
(f) The uplink packets from the mobile node are sent to the new MAG
via the new access network, and the new MAG forwards them to the
previous MAG. The previous MAG then sends the packets to the
local mobility anchor that is currently serving the mobile node.
Steps (g)-(h) are the same as steps (k)-(l) in the predictive fast
handover procedures.
In step (c), the IP address of the PMAG needs to be resolved by the
NMAG to send the HI message to the PMAG. This information may come
from the N-AN or some database that the NMAG can access.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Inter-AR Tunneling Operation</span>
When the PMAG (PAR) or NMAG (NAR), depending on the fast handover
mode, receives the HI message with the 'F' flag set, it prepares to
send/receive the mobile node's packets to/from the other MAG and
returns the HAck message with the same sequence number. Both MAGs
SHOULD support the following encapsulation modes for the user
packets, which are also defined for the tunnel between the local
mobility anchor and MAG:
<span class="grey">Yokota, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
o IPv4-or-IPv6-over-IPv6 [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]
o IPv4-or-IPv6-over-IPv4 [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]
o IPv4-or-IPv6-over-IPv4-UDP [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]
o TLV-header UDP tunneling [<a href="./rfc5845" title=""Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6"">RFC5845</a>]
o Generic Routing Encapsulation (GRE) tunneling with or without GRE
key(s) [<a href="./rfc5845" title=""Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6"">RFC5845</a>]
The PMAG and the NMAG MUST use the same tunneling mechanism for the
data traffic tunneled between them. The encapsulation mode to be
employed SHOULD be configurable. It is RECOMMENDED that:
1. As the default behavior, the inter-MAG tunnel uses the same
encapsulation mechanism as that for the PMIPv6 tunnel between the
local mobility anchor and the MAGs. The PMAG and NMAG
automatically start using the same encapsulation mechanism
without a need for a special configuration on the MAGs or a
dynamic tunneling mechanism negotiation between them.
2. Configuration on the MAGs can override the default mechanism
specified in scenario #1 above. The PMAG and NMAG MUST be
configured with the same mechanism, and this configuration is
most likely to be uniform throughout the PMIPv6 domain. If the
packets on the PMIPv6 tunnel cannot be uniquely mapped on to the
configured inter-MAG tunnel, this scenario is not applicable, and
scenario #3 below SHOULD directly be applied.
3. An implicit or explicit tunnel negotiation mechanism between the
MAGs can override the default mechanism specified in scenario #1
above. The employed tunnel negotiation mechanism is outside the
scope of this document.
The necessary information MUST be transferred in the HI/HAck messages
to determine whether a mobile node's packets should be forwarded
immediately or at a later time. Such information includes the HNP(s)
(or IPv4-MN-HoA) and/or GRE key(s). In the case of GRE tunneling
with GRE keys being used, for each mobility session, the NMAG selects
the GRE key for the downlink packets, and the PMAG selects the GRE
key for the uplink packets. These GRE keys are exchanged between the
PMAG and the NMAG using the GRE Key option as described in [<a href="./rfc5845" title=""Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6"">RFC5845</a>];
e.g., in the case of the reactive mode as shown in Figure 3, the DL
GRE key is communicated in the HI message while the UL GRE key is
sent in the HAck message. In the case of downlink packets, the PMAG
redirects the mobile node's packets from the local mobility anchor
towards the NMAG, and if the mobile node is ready to receive those
<span class="grey">Yokota, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
packets or the N-AN can handle them regardless of the state of the
mobile node, the NMAG SHOULD immediately send them towards the N-AN;
otherwise, it SHOULD buffer them until the mobile node is ready. In
the case of uplink packets, the NMAG SHOULD reverse-tunnel them from
the mobile node towards the PMAG, and the PMAG will then send them to
the local mobility anchor.
When the PMAG or NMAG receives the HI message with the 'U' flag set,
it prepares to buffer the mobile node's packets and returns the HAck
message with the same sequence number. It MUST be followed by
another HI message with the 'F' flag set at an appropriate time to
forward the buffered packets.
If the MAG that received the HI message encounters an erroneous
situation (e.g., insufficient buffer space), it SHOULD immediately
send the HAck message with the cause of the error and cancel all
tunneling operations.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. IPv4 Support Considerations</span>
The motivation and usage scenarios of IPv4 protocol support by PMIPv6
are described in [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]. The scope of IPv4 support covers the
following two features:
o IPv4 Home Address Mobility Support, and
o IPv4 Transport Support.
As for IPv4 Home Address Mobility Support, the mobile node acquires
the IPv4 Home Address (IPv4-MN-HoA), and in the case of handover, the
PMAG needs to transfer IPv4-MN-HoA to the NMAG, which is the inner
destination address of the packets forwarded on the downlink. For
this purpose, the IPv4 Address option described in <a href="#section-6.2.7">Section 6.2.7</a> is
used. In order to provide IPv4 Transport Support, the NMAG needs to
know the IPv4 address of the local mobility anchor (IPv4-LMAA) to
send PMIPv6 signaling messages to the local mobility anchor in the
IPv4 transport network. For this purpose, a new option called the
LMA Address (LMAA) option is defined in <a href="#section-6.2.2">Section 6.2.2</a> so as to convey
IPv4-LMAA from the PMAG to the NMAG.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. PMIPv6-Related Fast Handover Issues</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Manageability Considerations</span>
This specification does not require any additional IP-level
functionality on the local mobility anchor and the mobile node
running in the PMIPv6 domain. A typical network interface that the
mobile node could be assumed to have is one with the cellular
<span class="grey">Yokota, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
network, where the network controls the movement of the mobile node.
Different types of interfaces could be involved, such as different
generations (3G and 3.9G) or different radio access systems. This
specification supports a mobile node with the single radio mode,
where only one interface is active at any given time. The assigned
IP address is preserved whether the physical interface changes or
not, and the mobile node can identify which interface should be used
if there are multiple ones.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Expedited Packet Transmission</span>
The protocol specified in this document enables the NMAG to obtain
parameters that would otherwise be available only by communicating
with the local mobility anchor. For instance, the HNP(s) and/or
IPv4-MN-HoA of a mobile node are made available to the NMAG through
context transfer. This allows the NMAG to perform some procedures
that may be beneficial. The NMAG, for example, SHOULD send a Router
Advertisement (RA) with prefix information to the mobile node as soon
as its link attachment is detected (e.g., via receipt of a Router
Solicitation message). Such an RA is recommended, for example, in
scenarios where the mobile node uses a new radio interface while
attaching to the NMAG; since the mobile node does not have
information regarding the new interface, it will not be able to
immediately send packets without first receiving an RA with HNP(s).
Especially in the reactive fast handover, the NMAG gets to know the
HNP(s) assigned to the mobile node on the previous link at step (d)
in Figure 3. In order to reduce the communication disruption time,
the NMAG SHOULD expect the mobile node to keep using the same HNP and
to send uplink packets before that step upon the mobile node's
request. However, if the HAck message from the PMAG returns a
different HNP or the subsequent PMIPv6 binding registration for the
HNP fails for some reason, then the NMAG MUST withdraw the advertised
HNP by sending another RA with zero prefix lifetime for the HNP in
question. This operation is the same as that described in
<a href="./rfc5213#section-6.12">Section 6.12 of [RFC5213]</a>.
The protocol specified in this document is applicable regardless of
whether link-layer addresses are used between a mobile node and its
MAG. A mobile node should be able to continue sending packets on the
uplink even when it changes link. When link-layer addresses are
used, the mobile node performs Neighbor Unreachability Detection
(NUD) [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>], after attaching to a new link, probing the
reachability of its default router. The new router should respond to
the NUD probe, providing its link-layer address in the solicited
Neighbor Advertisement, which is common in the PMIPv6 domain.
Implementations should allow the mobile node to continue to send
uplink packets while it is performing NUD.
<span class="grey">Yokota, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Message Formats</span>
This document defines new Mobility Header messages for the extended
HI and HAck, and new mobility options for conveying context
information.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Mobility Header</span>
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Handover Initiate (HI)</span>
This section defines extensions to the HI message in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]. The
format of the Message Data field in the Mobility Header is as
follows:
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 # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|Resv'd | Code | |
+-+-+-+-+-------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
IP Fields:
Source Address
The IP address of the PMAG or NMAG
Destination Address
The IP address of the peer MAG
Message Data:
Sequence # Same as [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>].
'S' flag Defined in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>], and MUST be set to zero in this
specification.
'U' flag Buffer flag. Same as [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>].
<span class="grey">Yokota, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
'P' flag Proxy flag. Used to distinguish the message from that
defined in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>], and MUST be set in all new message
formats defined in this document when using this protocol
extension.
'F' flag Forwarding flag. Used to request to forward the packets
for the mobile node.
Reserved Same as [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>].
Code [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>] defines this field and its values, 0 and 1. In
this specification, with the 'P' flag set, this field can
be set to zero by default, or to the following values:
2: Indicate the completion of forwarding
3: All available context transferred
Code value 3 is set when the transfer of all necessary
context information is completed with this message. This
Code value is used both in cases where the context
information is fragmented into several pieces and the
last fragment is contained in this message, and where the
whole information is transferred in one piece.
Mobility options:
This field contains one or more mobility options, whose encoding and
formats are defined in [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>].
Required option
In order to uniquely identify the target mobile node, the mobile
node identifier MUST be contained in the Mobile Node Identifier
option.
The transferred context MUST be for one mobile node per message. In
addition, the NMAG can request necessary mobility options via the
Context Request option defined in this document.
Context Request Option
This option MAY be present to request context information,
typically by the NMAG to the PMAG in the NMAG-initiated fast
handover.
<span class="grey">Yokota, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Handover Acknowledge (HAck)</span>
This section defines extensions to the HAck message in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>].
The format of the Message Data field in the Mobility Header is as
follows:
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 # |
+-+-+-+---------+---------------+-------------------------------+
|U|P|F|Reserved | Code | |
+-+-+-+---------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
IP Fields:
Source Address
Copied from the destination address of the Handover Initiate
message to which this message is a response.
Destination Address
Copied from the source address of the Handover Initiate message to
which this message is a response.
Message Data:
The usages of Sequence # and Reserved fields are exactly the same as
those in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>].
'U' flag Same as defined in <a href="#section-6.1.1">Section 6.1.1</a>.
'P' flag Same as defined in <a href="#section-6.1.1">Section 6.1.1</a>. Used to distinguish
the message from that defined in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>], and MUST be
set in all new message formats defined in this document
when using this protocol extension.
'F' flag Same as defined in <a href="#section-6.1.1">Section 6.1.1</a>.
<span class="grey">Yokota, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Code Code values 0 through 4 and 128 through 130 are defined
in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]. When the 'P' flag is set, the meaning of
Code value 0 is as defined in this specification; 128
through 130 are reused; and 5, 6, 131, and 132 are newly
defined.
0: Handover Accepted or Successful
5: Context Transfer Accepted or Successful
6: All available Context Transferred
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
131: Requested Context Not Available
132: Forwarding Not Available
Mobility options:
This field contains one or more mobility options, whose encoding and
formats are defined in [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>]. The mobility option that uniquely
identifies the target mobile node MUST be copied from the
corresponding HI message, and the transferred context MUST be for one
mobile node per message.
Required option(s)
All the context information requested by the Context Request
option in the HI message SHOULD be present in the HAck message.
The other cases are described below.
In the case of the PMAG-initiated fast handover, when the PMAG sends
the HI message to the NMAG with the context information and the NMAG
successfully receives it, the NMAG returns the HAck message with Code
value 5. In the case of the NMAG-initiated fast handover, when the
NMAG sends the HI message to the PMAG with or without the Context
Request option, the PMAG returns the HAck message with the requested
or default context information (if any). If all available context
information is transferred, the PMAG sets the Code value in the HAck
message to 6. If more context information is available, the PMAG
<span class="grey">Yokota, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
sets the Code value in the HAck message to 5, and the NMAG MAY send
new HI message(s) to retrieve the rest of the available context
information. If none of the requested context information is
available, the PMAG returns the HAck message with Code value 131
without any context information.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Mobility Options</span>
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Context Request Option</span>
This option is sent in the HI message to request context information
on the mobile node. If a default set of context information is
defined and always sufficient, this option is not used. This option
is more useful to retrieve additional or dynamically selected context
information.
The Context Request option is typically used for the reactive (NMAG-
initiated) fast handover mode to retrieve the context information
from the PMAG. When this option is included in the HI message, all
the requested context information SHOULD be included in the HAck
message in the corresponding mobility option(s) (e.g., HNP, LMAA, or
MN LL-ID mobility options).
The default context information to request is the Home Network Prefix
option. If the Mobile Node link layer is available and used, the
Mobile Node Link-layer Identifier option MUST also be requested.
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
+---------------+---------------+---------------+---------------+
| Option-Type | Option-Length | Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 |
+---------------------------------------------------------------+
| Req-type-3 | Req-length-3 | Req-option-3 |
+---------------------------------------------------------------+
| ... |
Option-Type 40
Option-Length The length in octets of this option, not including the
Option Type and Option Length fields.
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Req-type-n The type value for the nth requested option.
<span class="grey">Yokota, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Req-length-n The length of the nth requested option, excluding the
Req-type-n and Req-length-n fields.
Req-option-n The optional data to uniquely identify the requested
context for the nth requested option.
In the case where there are only Req-type-n and Req-length-n fields,
the value of Req-length-n is set to zero. If additional information
besides Req-type-n is necessary to uniquely specify the requested
context, such information follows after Req-length-n. For example,
when the requested contexts start with the HNP option (type=22), the
MN Link-layer ID option (type=25), and the Vendor-Specific option
(type=19), the required option format looks as follows:
| ... |
+---------------+---------------+---------------+---------------+
|Option-Type=CRO| Option-Length | Reserved |
+---------------+---------------+---------------+---------------+
| Req-type-n=22 | Req-length-n=0| Req-type-n=25 | Req-length-n=0|
+---------------+---------------+-------------------------------+
| Req-type-n=19 | Req-length-n=5| Vendor-ID |
+-------------------------------+---------------+---------------+
| Vendor-ID | Sub-Type | |
+-----------------------------------------------+ |
| ... |
Note: CRO = Context Request Option
The first two options can uniquely identify the requested contexts
(i.e., the HNP and MN Link-layer ID) by the Req-type, so the
Req-length is set to zero; however, the subsequent Vendor-Specific
option further needs the Vendor-ID and Sub-Type to identify the
requested context, so these parameters follow, and the Req-length is
set to 5. Note that the exact values in the Vendor-ID and Sub-Type
follow [<a href="./rfc5094" title=""Mobile IPv6 Vendor Specific Option"">RFC5094</a>].
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Local Mobility Anchor Address (LMAA) Option</span>
This option is used to transfer the Local Mobility Anchor IPv6
Address (LMAA) or its IPv4 Address (IPv4-LMAA) with which the mobile
node is currently registered. The detailed definition of the LMAA is
described in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>].
<span class="grey">Yokota, et al. Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Mobility Anchor Address ... |
Option-Type 41
Option-Length 18 or 6
Option-Code 0 Reserved
1 IPv6 address of the local mobility anchor (LMAA)
2 IPv4 address of the local mobility anchor
(IPv4-LMAA)
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Local Mobility Anchor Address
If the Option-Code is 1, the LMA IPv6 address (LMAA)
is inserted. If the Option-Code is 2, the LMA IPv4
address (IPv4-LMA) is inserted.
<span class="h4"><a class="selflink" id="section-6.2.3" href="#section-6.2.3">6.2.3</a>. Mobile Node Link-Local Address Interface Identifier (MN LLA-IID)</span>
<span class="h4"> Option</span>
This option is used to transfer the interface identifier of the
mobile node's IPv6 Link-local Address that is used in the P-AN. In
deployments where the interface identifier is assigned by the network
or is known to the network, this option is used to transfer this
identifier from the PMAG to the NMAG.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Yokota, et al. Standards Track [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Option-Type 42
Option-Length 10
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Interface Identifier
The Interface Identifier value used for the mobile
node's IPv6 Link-local address in the P-AN.
<span class="h4"><a class="selflink" id="section-6.2.4" href="#section-6.2.4">6.2.4</a>. Home Network Prefix Option</span>
This option, as defined in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], is used to transfer the home
network prefix that is assigned to the mobile node in the P-AN.
<span class="h4"><a class="selflink" id="section-6.2.5" href="#section-6.2.5">6.2.5</a>. Link-Local Address Option</span>
This option, as defined in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], is used to transfer the link-
local address of the PMAG.
<span class="h4"><a class="selflink" id="section-6.2.6" href="#section-6.2.6">6.2.6</a>. GRE Key Option</span>
This option is used to transfer the GRE Key for the mobile node's
data flow over the bidirectional tunnel between the PMAG and NMAG.
The message format of this option follows that of the GRE Key option
defined in [<a href="./rfc5845" title=""Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6"">RFC5845</a>]. The GRE Key value uniquely identifies each
flow, and the sender of this option expects to receive packets of the
flow from the peer AR with this value.
<span class="h4"><a class="selflink" id="section-6.2.7" href="#section-6.2.7">6.2.7</a>. IPv4 Address Option</span>
As described in <a href="#section-4.3">Section 4.3</a>, if the mobile node runs in IPv4-only
mode or dual-stack mode, it requires the IPv4 home address
(IPv4-MN-HoA). This option is used to transfer the IPv4 home address
if assigned on the previous link. The format of this option follows
that of the IPv4 Home Address Request option defined in [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>].
<span class="h4"><a class="selflink" id="section-6.2.8" href="#section-6.2.8">6.2.8</a>. Vendor-Specific Mobility Option</span>
This option is used to transfer any other information defined in this
document. The format and used values of this option follow those of
the Vendor-Specific Mobility option defined in [<a href="./rfc5094" title=""Mobile IPv6 Vendor Specific Option"">RFC5094</a>].
<span class="grey">Yokota, et al. Standards Track [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Security issues for this document follow those for PMIPv6 [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>]
and FMIPv6 [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]. In PMIPv6, the MAG and local mobility anchor
are assumed to share security associations. In FMIPv6, the access
routers (i.e., the PMAG and NMAG in this document) are assumed to
share security associations.
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
exchanged between the PMAG and NMAG MUST be protected using end-to-
end security association(s) offering integrity and data origin
authentication. The PMAG and the NMAG MUST implement IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>]
for protecting the HI and HAck messages. IPsec Encapsulating
Security Payload (ESP) [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] in transport mode with mandatory
integrity protection SHOULD be used for protecting the signaling
messages. Confidentiality protection SHOULD be used if sensitive
context related to the mobile node is transferred.
IPsec ESP [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] in tunnel mode SHOULD be used to protect the
mobile node's packets at the time of forwarding if the link between
the PMAG and NMAG exposes the mobile node's packets to more threats
than if they had followed their normal routed path.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This document defines new flags and status codes in the HI and HAck
messages, as well as three new mobility options. The Type values for
these mobility options are assigned from the same numbering space as
that allocated for the other mobility options defined in [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>].
Those for the flags and status codes are assigned from the
corresponding numbering space defined in [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>], and have been
created as new tables in the IANA registry (marked with asterisks).
New values for these registries can be allocated by Standards Action
or IESG approval [<a href="./rfc5226" title="">RFC5226</a>].
Mobility Options
Value Description Reference
----- ------------------------------------- -------------
40 Context Request Option <a href="#section-6.2.1">Section 6.2.1</a>
41 Local Mobility Anchor Address Option <a href="#section-6.2.2">Section 6.2.2</a>
42 Mobile Node Link-local Address
Interface Identifier Option <a href="#section-6.2.3">Section 6.2.3</a>
<span class="grey">Yokota, et al. Standards Track [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Handover Initiate Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ----------------------------------- -------------
S 0x80 Assigned Address Configuration flag [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
U 0x40 Buffer flag [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
P 0x20 Proxy flag <a href="#section-6.1.1">Section 6.1.1</a>
F 0x10 Forwarding flag <a href="#section-6.1.1">Section 6.1.1</a>
Handover Acknowledge Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ------------------------------- -------------
U 0x80 Buffer flag <a href="#section-6.1.2">Section 6.1.2</a>
P 0x40 Proxy flag <a href="#section-6.1.2">Section 6.1.2</a>
F 0x20 Forwarding flag <a href="#section-6.1.2">Section 6.1.2</a>
Handover Initiate Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- -------------------------------------- -------------
0 FBU with the PCoA as source IP address [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
1 FBU whose source IP address is not PCoA [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
2 Indicate the completion of forwarding <a href="#section-6.1.1">Section 6.1.1</a>
3 All available context transferred <a href="#section-6.1.1">Section 6.1.1</a>
4-255 Unassigned
Handover Acknowledge Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- --------------------------------------- -------------
0 Handover Accepted or Successful
(when 'P' flag is set) <a href="#section-6.1.2">Section 6.1.2</a>
Handover Accepted with NCoA valid [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
1 Handover Accepted, NCoA not valid [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
2 Handover Accepted, NCoA assigned [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
3 Handover Accepted, use PCoA [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
4 Message sent unsolicited [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
5 Context Transfer Accepted or Successful <a href="#section-6.1.2">Section 6.1.2</a>
6 All available Context Transferred <a href="#section-6.1.2">Section 6.1.2</a>
7-127 Unassigned
128 Handover Not Accepted, reason unspecified [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
129 Administratively prohibited [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
130 Insufficient resources [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>]
131 Requested Context Not Available <a href="#section-6.1.2">Section 6.1.2</a>
132 Forwarding Not Available <a href="#section-6.1.2">Section 6.1.2</a>
133-255 Unassigned
<span class="grey">Yokota, et al. Standards Track [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
The authors would like to specially thank Vijay Devarapalli and Sri
Gundavelli for their thorough reviews of this document.
The authors would also like to thank Charlie Perkins, Desire Oulai,
Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan
Zhao, Julien Laganier, and Pierrick Seite for their passionate
discussions in the MIPSHOP working group mailing list.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3775">RFC3775</a>] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)",
<a href="./rfc4303">RFC 4303</a>, December 2005.
[<a id="ref-RFC5094">RFC5094</a>] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
Vendor Specific Option", <a href="./rfc5094">RFC 5094</a>, December 2007.
[<a id="ref-RFC5213">RFC5213</a>] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", <a href="./rfc5213">RFC 5213</a>,
August 2008.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-RFC5568">RFC5568</a>] Koodli, R., "Mobile IPv6 Fast Handovers", <a href="./rfc5568">RFC 5568</a>,
July 2009.
[<a id="ref-RFC5844">RFC5844</a>] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", <a href="./rfc5844">RFC 5844</a>, May 2010.
[<a id="ref-RFC5845">RFC5845</a>] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", <a href="./rfc5845">RFC 5845</a>, June 2010.
<span class="grey">Yokota, et al. Standards Track [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
September 2007.
[<a id="ref-RFC4988">RFC4988</a>] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
<a href="./rfc4988">RFC 4988</a>, October 2007.
<span class="grey">Yokota, et al. Standards Track [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Applicable Use Cases</span>
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. PMIPv6 Handoff Indication</span>
PMIPv6 [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] defines the Handoff Indicator option and also
describes the type of handoff and values that can be set for this
option. This document proposes one approach to determining the
handoff type by the NMAG when the handoff of the mobile node is
executed.
According to [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], the following handoff types are defined:
0) Reserved
1) Attachment over a new interface
2) Handoff between two different interfaces of the mobile node
3) Handoff between mobile access gateways for the same interface
4) Handoff state unknown
5) Handoff state not changed (Re-registration)
Assuming that there is a valid MN Link-layer Identifier (MN LL-ID),
the following solution can be considered. When the NMAG receives the
MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck
message, the NMAG compares it with the new MN LL-ID that is obtained
from the mobile node in the N-AN. If these two MN LL-IDs are the
same, the handoff type falls into type 3 (defined above) and the
Handoff Indicator value is set to 3. If these two MN LL-IDs are
different, the handoff is likely to be type 2 (defined above) since
the HI/HAck message exchange implies that this is a handoff rather
than a multihoming, and therefore the Handoff Indicator value can be
set to 2. If there is no HI/HAck exchange performed prior to the
network attachment of the mobile node in the N-AN, the NMAG may infer
that this is a multi-homing case and set the Handoff Indicator value
to 1. In the case of re-registration, the MAG, to which the mobile
node is attached, can determine if the handoff state is not changed,
so the MAG can set the HI value to 5 without any additional
information. If no handoff type can be assumed or if there is no
valid MN LL-ID available, the NMAG may set the value to 4.
<span class="grey">Yokota, et al. Standards Track [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Local Routing</span>
As described in <a href="./rfc5213#section-6.10.3">Section 6.10.3 of [RFC5213]</a>, if the
EnableMAGLocalRouting flag is set, when two mobile nodes are attached
to one MAG, the traffic between them may be locally routed. If one
mobile node moves from this MAG (PMAG) to another MAG (NMAG) and if
the PMAG does not detect the mobile node's detachment, it will
continue to forward packets locally forever. This situation is more
likely to happen in the reactive fast handover with Wireless Local
Area Network (WLAN) access, which does not have the capability to
detect the detachment of the mobile node in a timely manner. This
specification can be applied to handle this case. When the mobile
node attaches to the NMAG, the NMAG sends the HI message to the PMAG
with the 'F' flag set, which makes the PMAG realize the detachment of
the mobile node and establish the inter-MAG tunnel. The PMAG
immediately stops the local routing and sends the packets for the
mobile node to the NMAG via that tunnel; the packets are then
delivered to the mobile node on the new link.
<span class="grey">Yokota, et al. Standards Track [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc5949">RFC 5949</a> Proxy-Based Fast Handover September 2010</span>
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama 356-8502
Japan
EMail: yokota@kddilabs.jp
Kuntal Chowdhury
Cisco Systems
30 International Place
Tewksbury, MA 01876
USA
EMail: kchowdhu@cisco.com
Rajeev Koodli
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
EMail: rkoodli@cisco.com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
EMail: basavaraj.patil@nokia.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
EMail: xiayangsong@huawei.com
Yokota, et al. Standards Track [Page 32]
</pre>
|
