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
|
<pre>Independent Submission H. Yokota
Request for Comments: 7109 KDDI Lab
Category: Experimental D. Kim
ISSN: 2070-1721 JEJU Technopark
B. Sarikaya
F. Xia
Huawei
February 2014
<span class="h1">Flow Bindings Initiated by Home Agents for Mobile IPv6</span>
Abstract
There are scenarios in which the home agent needs to trigger flow
binding operations towards the mobile node, such as moving a flow
from one access network to another based on network resource
availability. In order for the home agent to be able to initiate
interactions for flow bindings with the mobile node, this document
defines new signaling messages and sub-options for Mobile IPv6. Flow
bindings initiated by a home agent are supported for mobile nodes
enabled by both IPv4 and IPv6.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see <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/rfc7109">http://www.rfc-editor.org/info/rfc7109</a>.
<span class="grey">Yokota, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
Copyright Notice
Copyright (c) 2014 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Use Cases .......................................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. QoS Provisioning ...........................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Traffic Offload from Congested Network .....................<a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Flow Movement or Deletion in an Emergency Situation ........<a href="#page-4">4</a>
<a href="#section-3.4">3.4</a>. Service-Specific Data Cap ..................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Protocol Operation ..............................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Adding Flow Bindings .......................................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Deleting Flow Bindings .....................................<a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. Modifying Flow Bindings ....................................<a href="#page-6">6</a>
<a href="#section-4.4">4.4</a>. Refreshing Flow Bindings ...................................<a href="#page-6">6</a>
<a href="#section-4.5">4.5</a>. Moving Flow Bindings .......................................<a href="#page-7">7</a>
<a href="#section-4.6">4.6</a>. Revoking Flow Bindings .....................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Handling of the Flow Bindings List ..............................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Flow Binding Messages and Options ...............................<a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Mobility Header ............................................<a href="#page-9">9</a>
<a href="#section-6.1.1">6.1.1</a>. Flow Binding Indication .............................<a href="#page-9">9</a>
<a href="#section-6.1.2">6.1.2</a>. Flow Binding Acknowledgement .......................<a href="#page-10">10</a>
<a href="#section-6.1.3">6.1.3</a>. Flow Binding Revocation Extensions .................<a href="#page-11">11</a>
<a href="#section-6.2">6.2</a>. New Options ...............................................<a href="#page-12">12</a>
<a href="#section-6.2.1">6.2.1</a>. Flow Binding Action Sub-Option .....................<a href="#page-12">12</a>
<a href="#section-6.2.2">6.2.2</a>. Target Care-of Address Sub-Option ..................<a href="#page-13">13</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-13">13</a>
<a href="#section-8">8</a>. Protocol Constants .............................................<a href="#page-14">14</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-14">14</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-16">16</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-16">16</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-17">17</a>
<span class="grey">Yokota, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-RFC6089">RFC6089</a>] allows a mobile node (MN) to bind a particular flow to a
care-of address (CoA) without affecting other flows using the same
home address. BU/BA (Binding Update / Binding Acknowledgement)
messages are extended for the mobile node to add, delete, modify,
move, refresh, and revoke flow bindings in a home agent (HA). The
operations are always initiated by the mobile node.
While the mobile node manipulates flow bindings by, e.g., the user
interaction or the change of the attached link condition, these
operations are also required for network-related reasons such as
dynamic QoS control in the network, load balancing, or maintenance in
mobility agent nodes. For the latter case, the mobile node is not
very aware of the transport network condition away from it or of the
policy and charging status controlled by the operator; thus, the
network needs to request that the mobile node handle proper flow
bindings.
This document defines a new Mobility Header and messages in order for
the home agent to request that the mobile node initiate flow bindings
in a timely manner. Flow mobility is also supported for mobile nodes
with an IPv4 home address and an IPv4 address of the home agent, as
described in [<a href="./rfc5555" title=""Mobile IPv6 Support for Dual Stack Hosts and Routers"">RFC5555</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</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>].
The terminology in this document is based on the definitions in
[<a href="./rfc6275" title=""Mobility Support in IPv6"">RFC6275</a>] and [<a href="./rfc6089" title=""Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support"">RFC6089</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Use Cases</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. QoS Provisioning</span>
When the user launches a video chat application and starts sending
voice and video to the other end, the network may need to provide
different QoS treatments to these media based on the operator's
policy. In such a case, the network needs to request the user or
mobile node to establish separate flows for voice and video.
<span class="grey">Yokota, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Traffic Offload from Congested Network</span>
The 3G operator may want to move traffic flows from the 3G access
network to another network (e.g., Wi-Fi network) due to instantaneous
traffic increases in the 3G access network. Fine-grained traffic
offload is desirable. For example, Voice over IP (VoIP) flows based
on IP Multimedia Subsystems (IMS) must stay in the mobile core
network while video-streaming flows provided by servers on the
Internet could bypass the mobile core network via Wi-Fi access.
Since the network knows more about its conditions and has access to
the policy server, more timely and well-controlled traffic offloading
is possible. The home agent sends an updated flow descriptor to be
offloaded to the mobile node.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Flow Movement or Deletion in an Emergency Situation</span>
In an emergency situation caused by a natural disaster, it is
necessary to accept as many voice calls as possible for inquiries to
confirm the safety status of family and friends, while non-critical
services such as gaming would be considered lower priority. In order
to save the 3G / Long Term Evolution (LTE) radio resources for
emergency services, non-critical services may need to be moved to
another access network or closed down. The home agent requests that
the mobile node use Wi-Fi access for non-critical application flows
or terminate them gracefully, e.g., by letting it notify the user of
possible QoS degradation or ask him/her to finish the corresponding
applications before taking any action.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Service-Specific Data Cap</span>
The mobile operator offers a mobile broadband service with a flat
rate subscription limited to 5 GB per month. Once the allotment is
used up, the service is downgraded to 64 kbits/s. This limitation,
however, is not applied to IMS-based services (e.g., Voice over LTE
(VoLTE)), while video conversations over the Internet will be
affected. The operator can indicate this to the user by sending
modified flow descriptors as a proposal to adjust the communication
data rate or change access for an ongoing session.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Operation</span>
[<a id="ref-RFC6089">RFC6089</a>] makes use of BU/BA signaling to forward, i.e., register or
discard, a flow binding in a home agent. Flow binding operations are
always initiated from the mobile node. The basic principle of this
specification is that the home agent prompts the mobile node to
perform flow binding operations. For this purpose, a new Mobility
Header and two new messages, that is, Flow Binding Indication (FBI)
and Flow Binding Acknowledgement (FBA), are defined. An FBI is used
<span class="grey">Yokota, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
by the home agent to request flow binding operations to the mobile
node, and an FBA is used for acknowledging an FBI. In order for the
flow binding operation to be complete, a BU/BA exchange MUST be
initiated by the mobile node after an FBI/FBA exchange.
It is assumed that the home agent has already created binding cache
entries for the mobile node before launching flow binding operations.
Due to access-network change on the mobile-node side, some interfaces
that used to be active may not be valid at the time of the flow
binding operation by the home agent, in which case, even if the HA
sends the FBI to the MN, the FBA will not return. After
retransmitting the FBIs for MAX_FBI_RETRIES times and not receiving
the FBA, the HA determines that the target interface is not
available.
If the mobile node does not support the FBI message, it responds with
a Binding Error message with status set to 2 (unrecognized Mobility
Header (MH) type value) as described in [<a href="./rfc6275" title=""Mobility Support in IPv6"">RFC6275</a>]. When the Binding
Error message with status set to 2 is received in response to an FBI
message, the home agent MUST NOT use an FBI message with that mobile
node again.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Adding Flow Bindings</span>
Adding the flow binding implies associating a particular flow with
one of the care-of addresses on the mobile node. The care-of address
concerned with the flow binding is present in the destination address
of the packet or the alternate care-of address option.
Alternatively, the care-of address may be indicated by the Target
Care-of Address sub-option defined in <a href="#section-6.2.2">Section 6.2.2</a>.
When adding a new flow binding, the home agent sends an FBI with a
Flow Identification Mobility option to the mobile node. In Figure 1,
which is shown as an example for this operation, the mobile node
exchanges both voice and video over FID#1 (Flow Identifier #1).
Based on the operator's policy, the network determines if it needs to
provide separate QoS for the video flow, and the home agent sends the
FBI to the mobile node. The Flow Identification Mobility option
defined in [<a href="./rfc6089" title=""Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support"">RFC6089</a>] includes the current FID and the Traffic
Selector (TS) to specify the video flow. The Flow Binding Action
sub-option MUST indicate the Add operation defined in <a href="#section-6.2.1">Section 6.2.1</a>.
The mobile node returns the FBA to the home agent with the same
options. The BU/BA exchange follows afterwards to perform the actual
flow binding as defined in [<a href="./rfc6088" title=""Traffic Selectors for Flow Bindings"">RFC6088</a>], and the video traffic is
exchanged over FID#2.
<span class="grey">Yokota, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
+----+ +----+
| MN | | HA |
+----+ +----+
| FID#1(voice+video) |
|/==============================\|
|\==============================/|
| |
| FBI(add,FID#1,TS[video]) |
|<-------------------------------|
| FBA(FID#1,TS[video]) |
|------------------------------->|
| BU(FID#2,TS[video]) |
|------------------------------->|
| BA(FID#2,TS[video]) |
|<-------------------------------|
| |
| FID#1(voice) |
|<==============================>|
| FID#2(video) |
|<==============================>|
Figure 1: Example Call Flow for Adding a Flow Binding
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Deleting Flow Bindings</span>
When removing a flow binding, the home agent sends an FBI with a Flow
Identification Mobility option in which the Flow Binding Action sub-
option indicates the Delete operation. The Flow Identification
Mobility option includes a unique FID for the mobile node to locate
the flow binding and remove it.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Modifying Flow Bindings</span>
When modifying a flow binding (e.g., changing QoS attributes of the
flow as defined in [<a href="#ref-PMIP6-QOS" title=""Quality of Service Option for Proxy Mobile IPv6"">PMIP6-QOS</a>]) is needed, the home agent sends the
mobile node an FBI message with the Flow Identification Mobility
option. The option includes the FID to be modified. A Traffic
Selector sub-option MAY come with the Flow Identification Mobility
option and contain new attributes, e.g., the in Quality of Service
option.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Refreshing Flow Bindings</span>
A flow binding is refreshed by simply including the Flow
Identification Mobility option with the Refresh Action field in the
FBI message. The message should be sent before the expiration of the
flow binding. The message updates existing bindings with new
<span class="grey">Yokota, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
information. Hence, all information previously sent in the last
refreshing message need to be resent; otherwise, such information
will be lost.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Moving Flow Bindings</span>
The home agent can request to move a flow associated with one
interface of the multi-interfaced mobile node to another by sending
an FBI message to the mobile node. The Action field of the Flow
Binding Action sub-option is set to Move, and the address of the
target interface is also included in the Target Care-of Address sub-
option. After the FBA is returned to the home agent, the flow
mobility is performed by the mobile node. Figure 2 shows the
movement of a flow label as FID from the interface with sCoA to that
with tCoA, which is stored in the Binding Identity Mobility option.
+----+ +----+
| MN | | HA |
+----+ +----+
|<=sCoA |
| |<=tCoA |
| | FBI(FID,tCoA) |
|<--------------------------------|
| | FBA(FID,tCoA) |
|-------------------------------->|
| | |
| | BU(BID[tCoA],FID) |
| |------------------------------>|
| | BA(BID[tCoA],FID) |
| |<------------------------------|
| | |
Figure 2: Example Call Flow for Moving a Flow Binding
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Revoking Flow Bindings</span>
When the home agent or the network attached to it is overloaded, the
home agent can revoke a flow binding registered by the mobile node.
The home agent sends the mobile node an FBI message with a Flow
Identification Mobility option in which the Flow Binding Action sub-
option indicates the Revoke operation. When the MN receives the FBI
message with the Revoke operation, it decides whether the flow should
be removed (de-registration) or moved to another interface and
returns the FBA with an appropriate status code. The mobile node
SHOULD take an action by sending a new BU, for example, to deregister
the flow.
<span class="grey">Yokota, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
The difference between revoking and deleting flow bindings
(<a href="#section-4.2">Section 4.2</a>) is that the target flow may be revoked by the network
with the procedures defined in [<a href="./rfc5846" title=""Binding Revocation for IPv6 Mobility"">RFC5846</a>] even if the mobile node does
not take any action.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Handling of the Flow Bindings List</span>
The flow bindings list defined in [<a href="./rfc6089" title=""Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support"">RFC6089</a>] needs to be updated as
follows after each protocol operation defined above is performed:
If an FBI contains a flow binding Add operation and if the
corresponding FBA has a status code equal to zero, the home agent
MUST add a new entry to the flow bindings list. The FID, Flow
Descriptor, FID-PRI, and Action fields are taken from the Flow
Identification Mobility option. The binding identifier (BID) is
copied from the Binding Reference sub-option. The Active/Inactive
Flag is set to Active. Note that if BID is not available, it may be
replaced by Target Care-of Address.
If an FBI contains a flow binding Delete operation and if the
corresponding FBA has a status code equal to zero, the home agent
MUST locate the list entry corresponding to this flow and then delete
the entry.
If the home agent sends a Binding Revocation Indication message with
the Flow Identification Mobility option with the action field set to
Revoke and if the corresponding Binding Revocation Acknowledgement
message indicates acceptance, the home agent MUST locate the list
entry corresponding to this flow and then delete the entry.
If an FBI contains a flow binding Modify operation and if the
corresponding FBA has a status code equal to zero, the home agent
MUST delete the list entry corresponding to this flow and then add a
new entry, setting the values as defined in the Flow Identification
Mobility option.
If an FBI contains a flow binding Refresh operation and if the
corresponding FBA has a status code equal to zero, the home agent
MUST locate the list entry corresponding to this flow and then set
the Active/Inactive Flag to Active.
If an FBI contains a flow binding Move operation and if the
corresponding FBA has a status code equal to zero, the home agent
MUST locate the list entry corresponding to this flow and then change
the BID value to the care-of address in the Flow Identification
Mobility option.
<span class="grey">Yokota, et al. Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
If an FBI contains a flow binding Revoke operation and if the
corresponding FBA has a status code equal to zero, the home agent
MUST locate the list entry corresponding to this flow and then delete
the entry.
Flow binding operations apply equally to IPv4 packets and IPv6
packets as per Dual-Stack Mobile IPv6 [<a href="./rfc5555" title=""Mobile IPv6 Support for Dual Stack Hosts and Routers"">RFC5555</a>]. In order to support
the situation where there is a NAT/firewall between the mobile node
and home agent, NAT detection and NAT keepalive mechanisms defined in
[<a href="./rfc5555" title=""Mobile IPv6 Support for Dual Stack Hosts and Routers"">RFC5555</a>] MUST be used. When the mobile node and home agent are in
IPv6-only and IPv4-only networks respectively and NAT64 [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>]
resides in between, each node would behave as if the other node was
in the same network domain. Even though this scenario is not fully
described in [<a href="./rfc5555" title=""Mobile IPv6 Support for Dual Stack Hosts and Routers"">RFC5555</a>], the initial mobility binding is always
performed by the mobile node, and the binding cache is created in the
home agent. The destination address of the FBI SHALL be the mobile
node's IPv4 care-of address in the binding cache entry.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Flow Binding Messages and Options</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Mobility Header</span>
The messages described below follow the Mobility Header format
specified in <a href="./rfc6275#section-6.1">Section 6.1 of [RFC6275]</a>.
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Flow Binding Indication</span>
Flow Binding Indication messages are used by the home agent to
initiate flow binding operations to the mobile node. Flow Binding
Indication messages use the MH Type value (21) for Flow Binding
messages and a Flow Binding Type value of 1, and 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Binding Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Trigger |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Binding Indication Mobility Header Format
<span class="grey">Yokota, et al. Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
Sequence #
A 16-bit unsigned integer used by the home agent to match a
returned Flow Binding Acknowledgement with the Flow Binding
Indication. It could be a random number.
Trigger
8-bit unsigned integer indicating the event that triggered the
home agent to send the Flow Binding Indication message. The
following Trigger values are currently defined:
0 Reserved
1 Unspecified
2 Administrative Reason
3 Possible Out-of-Sync BCE State
250-255 Reserved for Testing Purposes Only
All other values are unassigned.
Acknowledge (A)
The Acknowledge (A) bit is set by the home agent to request that a
Flow Binding Acknowledgement be returned upon receipt of the Flow
Binding Indication.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Flow
Identification Mobility options are included in this field.
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Flow Binding Acknowledgement</span>
The Flow Binding Acknowledgement is used to acknowledge receipt of a
Flow Binding Indication. The mobile node sends an FBA message to
acknowledge the reception of an FBI to add, delete, modify, refresh,
move, or revoke a flow binding. On receiving messages with Flow
Identification Mobility option(s), the mobile node should copy each
Flow Identification Mobility option to the Acknowledgement message.
The Flow Binding Acknowledgement has the MH Type value (21) for Flow
Binding messages and a Flow Binding Type value of 2. When this value
is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
<span class="grey">Yokota, et al. Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Binding Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Flow Binding Acknowledgement Mobility Header Format
Sequence #
The sequence number in the Flow Binding Acknowledgement is copied
from the Sequence Number field in the Flow Binding Indication.
Status
8-bit unsigned integer indicating the result of processing the
Flow Binding Indication message by the receiving mobile node.
Values less than 128 in the Status field indicate that the Flow
Binding Indication was processed successfully by the receiving
node. Values greater than or equal to 128 indicate that the Flow
Binding Indication was rejected by the receiving node. The
following status values are currently defined:
0 Success
128 Binding (target CoA) Does NOT Exist
129 Action NOT Authorized
All other values are unassigned.
Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. Flow
Identification Mobility options are included in this field.
<span class="h4"><a class="selflink" id="section-6.1.3" href="#section-6.1.3">6.1.3</a>. Flow Binding Revocation Extensions</span>
This specification enables Binding Revocation Indication and Binding
Revocation Acknowledgement messages to carry Flow Identification
Mobility options as defined in [<a href="./rfc6089" title=""Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support"">RFC6089</a>] with the extensions defined
in this document.
<span class="grey">Yokota, et al. Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. New Options</span>
This document defines new Flow Identification sub-options that are
included in the Flow Identification Mobility option specified in
[<a href="./rfc6089" title=""Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support"">RFC6089</a>].
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Flow Binding Action Sub-Option</span>
This section defines a new sub-option for flow binding actions, which
MUST be included in the Flow Identification Mobility option when it
is sent from the home agent to the mobile node via the FBI message.
The format of this sub-option is shown in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-opt Type |Sub-opt Length | Reserved | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Flow Binding Action Sub-Option
Sub-opt Type
4
Sub-opt Length
Length of the sub-option in octets, excluding the Sub-opt Type and
Sub-opt Length fields.
Action
This is a 8-bit field that describes the required processing for
the option. It can be assigned one of the following new values:
11 Add a flow binding
12 Delete a flow binding
13 Modify a flow binding
14 Refresh a flow binding
15 Move a flow binding
16 Revoke a flow binding
All other values are unassigned.
<span class="grey">Yokota, et al. Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Target Care-of Address Sub-Option</span>
This section introduces the Target Care-of Address sub-option, which
may be included in the Flow Identification Mobility option. This
sub-option is used to indicate to the mobile node that a flow binding
is to be moved from one interface to another.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-opt Type |Sub-opt Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Care-of Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Target Care-of Address Sub-Option
Sub-opt Type
5
Sub-opt Length
Length of the sub-option in octets, excluding the Sub-opt Type and
Sub-opt Length fields.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Target Care-of Address
The address of an interface that the flow is moved to. This
address could be an IPv4 or IPv6 address. This sub-option MUST be
included when the action taken is "15 Move a flow binding".
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Security issues for this document follow those of [<a href="./rfc6088" title=""Traffic Selectors for Flow Bindings"">RFC6088</a>],
[<a href="./rfc6089" title=""Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support"">RFC6089</a>], and [<a href="./rfc5846" title=""Binding Revocation for IPv6 Mobility"">RFC5846</a>]. This specification allows the home agent
to manipulate only the binding of a flow(s) that is currently
registered with it, which is the same principle described in
[<a href="./rfc5846" title=""Binding Revocation for IPv6 Mobility"">RFC5846</a>]. No additional security issue specific to this document is
identified.
<span class="grey">Yokota, et al. Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Protocol Constants</span>
Maximum FBI retries (MAX_FBI_RETRIES)
This variable specifies the maximum number of times the HA MAY
retransmit a Flow Binding Indication message when the FBA is not
returned within the time period specified by MAX_FBA_TIMEOUT. The
default value for this parameter is 3.
Maximum FBA timeout (MAX_FBA_TIMEOUT)
This variable specifies the maximum time in seconds the HA MUST
wait before retransmitting another FBI message. The default for
this parameter is 3 seconds.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
IANA has taken the actions described below.
Action-1
This specification defines a new Mobility Header Type, "Flow
Binding Message". This Mobility Header message is described in
<a href="#section-6.1">Section 6.1</a>, and the type value for this messages is 21, which has
been assigned in the "Mobility Header Types - for the MH Type
field in the Mobility Header" registry.
Action-2
This specification defines "Flow Binding Type". IANA has created
a new sub-registry within the "Mobile IPv6 parameters" registry.
Flow Binding Type is described in Sections <a href="#section-6.1.1">6.1.1</a> and <a href="#section-6.1.2">6.1.2</a>, which
reserve the following values:
+-------+------------------------------+--------------+
| Value | Description | Reference |
+-------+------------------------------+--------------+
| 0 | Unassigned | |
+-------+------------------------------+--------------+
| 1 | Flow Binding Indication | [<a href="./rfc7109">RFC7109</a>] |
+-------+------------------------------+--------------+
| 2 | Flow Binding Acknowledgement | [<a href="./rfc7109">RFC7109</a>] |
+-------+------------------------------+--------------+
| 3-255 | Unassigned | |
+--------------------------------------+--------------+
Future assignments in the "Flow Binding Type" registry are to be
made through RFC Required [<a href="./rfc5226" title="">RFC5226</a>].
<span class="grey">Yokota, et al. Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
Action-3
This specification defines "Flow Binding Indication Triggers".
IANA has created a new sub-registry within the "Mobile IPv6
parameters" registry. The trigger values are described in
<a href="#section-6.1.1">Section 6.1.1</a>, which reserves the following values:
+---------+------------------------------------+--------------+
| Value | Description | Reference |
+---------+------------------------------------+--------------+
| 0 | Reserved | [<a href="./rfc7109">RFC7109</a>] |
+---------+------------------------------------+--------------+
| 1 | Unspecified | [<a href="./rfc7109">RFC7109</a>] |
+---------+------------------------------------+--------------+
| 2 | Administrative Reason | [<a href="./rfc7109">RFC7109</a>] |
+---------+------------------------------------+--------------+
| 3 | Possible Out-of-Sync BCE State | [<a href="./rfc7109">RFC7109</a>] |
+---------+------------------------------------+--------------+
| 4-249 | Unassigned | |
+---------+------------------------------------+--------------+
| 250-255 | Reserved for Testing Purposes Only | [<a href="./rfc7109">RFC7109</a>] |
+----------------------------------------------+--------------+
Future assignments in the "Flow Binding Indication Triggers"
registry are to be made through RFC Required [<a href="./rfc5226" title="">RFC5226</a>].
Action-4
This specification defines "Flow Binding Acknowledgement Status
Codes". IANA has created a new sub-registry within the "Mobile
IPv6 parameters" registry. The status codes are described in
<a href="#section-6.1.2">Section 6.1.2</a>, which reserves the following values:
+---------+-------------------------------------+--------------+
| Value | Description | Reference |
+---------+-------------------------------------+--------------+
| 0 | Success | [<a href="./rfc7109">RFC7109</a>] |
+---------+-------------------------------------+--------------+
| 1-127 | Unassigned | |
+---------+-------------------------------------+--------------+
| 128 | Binding (target CoA) Does NOT Exist | [<a href="./rfc7109">RFC7109</a>] |
+---------+-------------------------------------+--------------+
| 129 | Action NOT Authorized | [<a href="./rfc7109">RFC7109</a>] |
+---------+-------------------------------------+--------------+
| 130-255 | Unassigned | |
+---------+-------------------------------------+--------------+
Future assignments in the "Flow Binding Acknowledgement Status
Codes" are to be made through RFC Required [<a href="./rfc5226" title="">RFC5226</a>].
<span class="grey">Yokota, et al. Experimental [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
Action-5
This specification defines two new Flow Identification sub-
options: the "Flow Binding Action" sub-option and "Target Care-of
Address" sub-option. These sub-options are described in Sections
6.2.1 and 6.2.2, and the sub-option values are 4 and 5,
respectively, as assigned in the "Flow Identification Sub-options"
registry.
Action-6
This specification defines "Flow Binding Action Values". IANA has
created a new sub-registry within the "Mobile IPv6 parameters"
registry. The action values are described in <a href="#section-6.2.1">Section 6.2.1</a>, which
reserves the following values:
+--------+-------------------------------------+--------------+
| Value | Description | Reference |
+--------+-------------------------------------+--------------+
| 0-10 | Unassigned | |
+--------+-------------------------------------+--------------+
| 11 | Add a flow binding | [<a href="./rfc7109">RFC7109</a>] |
+--------+-------------------------------------+--------------+
| 12 | Delete a flow binding | [<a href="./rfc7109">RFC7109</a>] |
+--------+-------------------------------------+--------------+
| 13 | Modify a flow binding | [<a href="./rfc7109">RFC7109</a>] |
+--------+-------------------------------------+--------------+
| 14 | Refresh a flow binding | [<a href="./rfc7109">RFC7109</a>] |
+--------+-------------------------------------+--------------+
| 15 | Move a flow binding | [<a href="./rfc7109">RFC7109</a>] |
+--------+-------------------------------------+--------------+
| 16 | Revoke a flow binding | [<a href="./rfc7109">RFC7109</a>] |
+--------+-------------------------------------+--------------+
| 17-255 | Unassigned | |
+--------+-------------------------------------+--------------+
Future assignments in the "Flow Binding Action Values" registry
are to be made through RFC Required [<a href="./rfc5226" title="">RFC5226</a>].
<span class="grey">Yokota, et al. Experimental [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
<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-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-RFC5555">RFC5555</a>] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts
and Routers", <a href="./rfc5555">RFC 5555</a>, June 2009.
[<a id="ref-RFC5846">RFC5846</a>] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
and P. Yegani, "Binding Revocation for IPv6 Mobility",
<a href="./rfc5846">RFC 5846</a>, June 2010.
[<a id="ref-RFC6088">RFC6088</a>] Tsirtsis, G., Giarreta, G., Soliman, H., and N.
Montavont, "Traffic Selectors for Flow Bindings", <a href="./rfc6088">RFC</a>
<a href="./rfc6088">6088</a>, January 2011.
[<a id="ref-RFC6089">RFC6089</a>] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", <a href="./rfc6089">RFC 6089</a>,
January 2011.
[<a id="ref-RFC6146">RFC6146</a>] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from
IPv6 Clients to IPv4 Servers", <a href="./rfc6146">RFC 6146</a>, April 2011.
[<a id="ref-RFC6275">RFC6275</a>] Perkins, C., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", <a href="./rfc6275">RFC 6275</a>, July 2011.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-PMIP6-QOS">PMIP6-QOS</a>] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
Gundavelli, "Quality of Service Option for Proxy Mobile
IPv6", Work in Progress, December 2013.
<span class="grey">Yokota, et al. Experimental [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7109">RFC 7109</a> HA-Initiated Flow Binding for MIPv6 February 2014</span>
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara
Fujimino, Saitama 356-8502
Japan
EMail: yokota@kddilabs.jp
Dae-Sun Kim
JEJU Technopark
217, Jungang-ro (St)
Jejusi, Jeju Special Self-Governing Province 690-787
Korea
EMail: dskim@jejutp.or.kr
Behcet Sarikaya
Huawei USA
5340 Legacy Drive, Building 3
Plano, TX 75024
US
Phone: +1 469-277-5839
EMail: sarikaya@ieee.org
Frank Xia
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Phone: +86-25-56625443
EMail: xiayangsong@huawei.com
Yokota, et al. Experimental [Page 18]
</pre>
|
