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
|
<pre>Internet Engineering Task Force (IETF) T. Schmidt
Request for Comments: 6224 HAW Hamburg
Category: Informational M. Waehlisch
ISSN: 2070-1721 link-lab & FU Berlin
S. Krishnan
Ericsson
April 2011
<span class="h1">Base Deployment for Multicast Listener Support</span>
<span class="h1">in Proxy Mobile IPv6 (PMIPv6) Domains</span>
Abstract
This document describes deployment options for activating multicast
listener functions in Proxy Mobile IPv6 domains without modifying
mobility and multicast protocol standards. Similar to home agents in
Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as
multicast subscription anchor points, while Mobile Access Gateways
provide Multicast Listener Discovery (MLD) proxy functions. In this
scenario, mobile nodes remain agnostic of multicast mobility
operations. Support for mobile multicast senders is outside the
scope of this document.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are 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/rfc6224">http://www.rfc-editor.org/info/rfc6224</a>.
<span class="grey">Schmidt, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
Copyright Notice
Copyright (c) 2011 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.
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>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Deployment Details . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Operations of the Mobile Node . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Operations of the Mobile Access Gateway . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. Operations of the Local Mobility Anchor . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.5">4.5</a>. Multihoming Support . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.6">4.6</a>. Multicast Availability throughout the Access Network . . . <a href="#page-12">12</a>
<a href="#section-4.7">4.7</a>. A Note on Explicit Tracking . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Message Source and Destination Address . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.1">5.1</a>. Query . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2">5.2</a>. Report/Done . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A">Appendix A</a>. Initial MLD Queries on Upcoming Links . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-B">Appendix B</a>. State of IGMP/MLD Proxy Implementations . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-C">Appendix C</a>. Comparative Evaluation of Different Approaches . . . <a href="#page-17">17</a>
<span class="grey">Schmidt, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
<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>] extends Mobile IPv6 (MIPv6)
[<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] by network-based management functions that enable IP
mobility for a host without requiring its participation in any
mobility-related signaling. Additional network entities, called the
Local Mobility Anchor (LMA) and Mobile Access Gateways (MAGs), are
responsible for managing IP mobility on behalf of the mobile node
(MN).
With these entities in place, the mobile node experiences an
exceptional access topology towards the static Internet in the sense
that the MAG introduces a routing hop in situations where the LMA
architecturally acts as the next hop (or designated) router for the
MN. In the particular case of multicast communication, group
membership management, as signaled by the Multicast Listener
Discovery (MLD) protocol [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>], requires dedicated
treatment at the network side.
Multicast routing functions need to be placed carefully within the
PMIPv6 domain in order to augment unicast transmission with group
communication services. [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] does not explicitly address
multicast communication. Bidirectional home tunneling, the minimal
multicast support arranged by MIPv6, cannot be directly transferred
to network-based management scenarios, since a mobility-unaware node
will not initiate such a tunnel after movement. Consequently, even
minimal multicast listener support in PMIPv6 domains requires an
explicit deployment of additional functions.
This document describes options for deploying multicast listener
functions in Proxy Mobile IPv6 domains without modifying mobility and
multicast protocol standards. Similar to home agents in Mobile IPv6,
PMIPv6 Local Mobility Anchors serve as multicast subscription anchor
points, while Mobile Access Gateways provide MLD proxy functions. In
this scenario, mobile nodes remain agnostic of multicast mobility
operations. This document does not address specific optimizations
and efficiency improvements of multicast routing for network-based
mobility discussed in [<a href="./rfc5757" title=""Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey"">RFC5757</a>], as such solutions would require
changes to the base PMIPv6 protocol [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>]. Support for mobile
multicast senders is also outside the scope of this document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
This document uses the terminology as defined for the mobility
protocols [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>], [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], and [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>], as well as the
multicast edge related protocols [<a href="./rfc3376" title=""Internet Group Management Protocol, Version 3"">RFC3376</a>], [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>], and [<a href="./rfc4605" title=""Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("">RFC4605</a>].
<span class="grey">Schmidt, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overview</span>
The reference scenario for multicast deployment in Proxy Mobile IPv6
domains is illustrated in Figure 1. Below, LMAA and MN-HNP are the
LMA Address and Mobile Node's Home Network Prefix as defined in
[<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>].
+-------------+
| Content |
| Source |
+-------------+
|
*** *** *** ***
* ** ** ** *
* *
* Fixed Internet *
* *
* ** ** ** *
*** *** *** ***
/ \
+----+ +----+
|LMA1| |LMA2| Multicast Anchor
+----+ +----+
LMAA1 | | LMAA2
| |
\\ //\\
\\ // \\
\\ // \\ Unicast Tunnel
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1 || || Proxy-CoA2
+----+ +----+
|MAG1| |MAG2| MLD Proxy
+----+ +----+
| | |
MN-HNP1 | | MN-HNP2 | MN-HNP3
MN1 MN2 MN3
Figure 1: Reference Network for Multicast Deployment in PMIPv6
An MN in a PMIPv6 domain will decide on multicast group membership
management completely independent of its current mobility conditions.
It will submit MLD Report and Done messages, based on application
triggers, using its link-local source address and multicast
destination addresses according to [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] or [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>]. These
<span class="grey">Schmidt, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
link-local signaling messages will arrive at the currently active MAG
via one of its downstream local (wireless) links. A multicast-
unaware MAG would simply discard these MLD messages.
To facilitate multicast in a PMIPv6 domain, an MLD proxy function
[<a href="./rfc4605" title=""Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("">RFC4605</a>] needs to be deployed on the MAG that selects the tunnel
interface corresponding to the MN's LMA for its upstream interface
(cf., <a href="./rfc5213#section-6">Section 6 of [RFC5213]</a>). Thereby, each MAG-to-LMA tunnel
interface defines an MLD proxy domain at the MAG, and it contains all
downstream links to MNs that share this specific LMA. According to
standard proxy operations, MLD Report messages will be aggregated and
then forwarded up the tunnel interface to the MN's corresponding LMA.
Serving as the designated multicast router or an additional MLD
proxy, the LMA will transpose any MLD message from a MAG into the
multicast routing infrastructure. Correspondingly, the LMA will
create appropriate multicast forwarding states at its tunnel
interface. Traffic of the subscribed groups will arrive at the LMA,
and the LMA will forward this traffic according to its group/source
states. In addition, the LMA will act as an MLD querier, seeing its
downstream tunnel interfaces as multicast-enabled links.
At the MAG, MLD queries and multicast data will arrive on the
(tunnel) interface that is assigned to a group of access links as
identified by its Binding Update List (cf., <a href="./rfc5213#section-6.1">Section 6.1 of
[RFC5213]</a>). As specified for MLD proxies, the MAG will forward
multicast traffic and initiate related signaling down the appropriate
access links to the MNs. Hence, all multicast-related signaling and
the data traffic will transparently flow from the LMA to the MN on an
LMA-specific tree, which is shared among the multicast sources.
In case of a handover, the MN (unaware of IP mobility) will not send
unsolicited MLD reports. Instead, the MAG is required to maintain
group memberships in the following way. On observing a new MN on a
downstream access link, the MAG sends a MLD General Query. Based on
its outcome and the multicast group states previously maintained at
the MAG, a corresponding Report will be sent to the LMA aggregating
group membership states according to the proxy function. Additional
Reports can be omitted when the previously established multicast
forwarding states at the new MAG already cover the subscriptions of
the MN.
In summary, the following steps are executed on handover:
1. The MAG-MN link comes up and the MAG discovers the new MN.
2. Unicast address configuration and PMIPv6 binding are performed
after the MAG determines the corresponding LMA.
<span class="grey">Schmidt, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
3. Following IPv6 address configuration, the MAG should send an
(early) MLD General Query to the new downstream link as part of
its standard multicast-enabled router operations.
4. The MAG should determine whether the MN is admissible to
multicast services; if it's not, then stop here.
5. The MAG adds the new downstream link to the MLD proxy instance
with up-link to the corresponding LMA.
6. The corresponding proxy instance triggers an MLD General Query on
the new downstream link.
7. The MN Membership Reports arrive at the MAG, in response either
to the early query or to the query sent by the proxy instance.
8. The Proxy processes the MLD Report, updates states, and reports
upstream if necessary.
After Re-Binding, the LMA is not required to issue a MLD General
Query on the tunnel link to refresh forwarding states. Multicast
state updates should be triggered by the MAG, which aggregates
subscriptions of all its MNs (see the call flow in Figure 2).
<span class="grey">Schmidt, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
MN1 MAG1 MN2 MAG2 LMA
| | | | |
| Join(G) | | | |
+--------------->| | | |
| | Join(G) | | |
| |<---------------+ | |
| | | | |
| | Aggregated Join(G) | |
| +================================================>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | |
| Mcast Data | Mcast Data | | |
|<---------------+--------------->| | |
| | | | |
| < Movement of MN 2 to MAG2 & PMIP Binding Update > |
| | | | |
| | |--- Rtr Sol -->| |
| | |<-- Rtr Adv ---| |
| | | | |
| | | MLD Query | |
| | |<--------------+ |
| | | | |
| | | Join(G) | |
| | +-------------->| |
| | | Aggregated Join(G)
| | | +===============>|
| | | | |
| | Mcast Data | | |
| |<================================================+
| | | | Mcast Data |
| | | |<===============+
| Mcast Data | | | |
|<---------------+ | Mcast Data | |
| | |<--------------+ |
| | | | |
Figure 2: Call Flow of Multicast-Enabled PMIP
with "MLD Membership Report" Abbreviated by "Join"
These multicast deployment considerations likewise apply for mobile
nodes that operate with their IPv4 stack enabled in a PMIPv6 domain.
PMIPv6 can provide IPv4 home address mobility support [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>].
Such mobile nodes will use IGMP [<a href="./rfc2236" title=""Internet Group Management Protocol, Version 2"">RFC2236</a>] [<a href="./rfc3376" title=""Internet Group Management Protocol, Version 3"">RFC3376</a>] signaling for
multicast, which is handled by an IGMP proxy function at the MAG in
an analogous way.
<span class="grey">Schmidt, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
Following these deployment steps, multicast management transparently
interoperates with PMIPv6. It is worth noting that MNs -- while
being attached to the same MAG, but associated with different LMAs --
can subscribe to the same multicast group. Thereby, data could be
distributed redundantly in the network and duplicate traffic could
arrive at a MAG. Additionally, in a point-to-point wireless link
model, a MAG might be forced to transmit the same data over one
wireless domain to different MNs. However, multicast traffic
arriving at one interface of the MN will always remain unique, i.e.,
the mobile multicast distribution system will never cause duplicate
packets arriving at an MN (see <a href="#appendix-C">Appendix C</a> for further
considerations).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Deployment Details</span>
Multicast activation in a PMIPv6 domain requires to deploy general
multicast functions at PMIPv6 routers and to define their interaction
with the PMIPv6 protocol in the following way.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Operations of the Mobile Node</span>
A mobile node willing to manage multicast traffic will join,
maintain, and leave groups as if located in the fixed Internet. No
specific mobility actions nor implementations are required at the MN.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Operations of the Mobile Access Gateway</span>
A Mobile Access Gateway is required to assist in MLD signaling and
data forwarding between the MNs that it serves and the corresponding
LMAs associated to each MN. It therefore needs to implement an
instance of the MLD proxy function [<a href="./rfc4605" title=""Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("">RFC4605</a>] for each upstream tunnel
interface that has been established with an LMA. The MAG decides on
the mapping of downstream links to a proxy instance (and hence an
upstream link to an LMA) based on the regular Binding Update List as
maintained by PMIPv6 standard operations (cf., <a href="./rfc5213#section-6.1">Section 6.1 of
[RFC5213]</a>). As links connecting MNs and MAGs change under mobility,
MLD proxies at MAGs must be able to dynamically add and remove
downstream interfaces in their configurations.
On the reception of MLD reports from an MN, the MAG must identify the
corresponding proxy instance from the incoming interface and perform
regular MLD proxy operations: it will insert/update/remove multicast
forwarding state on the incoming interface and will merge state
updates into the MLD proxy membership database. It will then send an
aggregated Report via the upstream tunnel to the LMA when the
membership database (cf., <a href="./rfc4605#section-4.1">Section 4.1 of [RFC4605]</a>) changes.
Conversely, on the reception of MLD queries, the MAG proxy instance
will answer the Queries on behalf of all active downstream receivers
<span class="grey">Schmidt, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
maintained in its membership database. Queries sent by the LMA do
not force the MAG to trigger corresponding messages immediately
towards MNs. Multicast traffic arriving at the MAG on an upstream
interface will be forwarded according to the group-specific or
source-specific forwarding states as acquired for each downstream
interface within the MLD proxy instance. At this stage, it is
important to note that IGMP/MLD proxy implementations capable of
multiple instances are expected to closely follow the specifications
of <a href="./rfc4605#section-4.2">Section 4.2 in [RFC4605]</a>, i.e., treat proxy instances in isolation
of each other while forwarding. In providing isolated proxy
instances, the MAG will uniquely serve its downstream links with
exactly the data that belong to whatever group is subscribed on the
particular interface.
After a handover, the MAG will continue to manage upstream tunnels
and downstream interfaces as specified in the PMIPv6 specification.
It must dynamically associate new access links to proxy instances
that include the upstream connection to the corresponding LMA. The
MAG detects the arrival of a new MN by receiving a router
solicitation message and by an upcoming link. To learn about
multicast groups subscribed by a newly attaching MN, the MAG should
send a General Query to the MN's link. Querying an upcoming
interface is a standard operation of MLD queriers (see <a href="#appendix-A">Appendix A</a>)
and is performed immediately after address configuration. In
addition, an MLD query should be initiated by the proxy instance, as
soon as a new interface has been configured for downstream. In case
the access link between MN and MAG goes down, interface-specific
multicast states change. Both cases may alter the composition of the
membership database and this will trigger corresponding Reports
towards the LMA. Note that the actual observable state depends on
the access link model in use.
An MN may be unable to answer MAG multicast membership queries due to
handover procedures, or its report may arrive before the MAG has
configured its link as the proxy downstream interface. Such
occurrences are equivalent to a General Query loss. To prevent
erroneous query timeouts at the MAG, MLD parameters should be
carefully adjusted to the mobility regime. In particular, MLD timers
and the Robustness Variable (see <a href="./rfc3810#section-9">Section 9 of [RFC3810]</a>) should be
chosen to be compliant with the time scale of handover operations and
proxy configurations in the PMIPv6 domain.
In proceeding this way, the MAG is able to aggregate multicast
subscriptions for each of its MLD proxy instances. However, this
deployment approach does not prevent multiple identical streams
arriving from different LMA upstream interfaces. Furthermore, a
multipoint channel forwarding into the wireless domain is prevented
by the point-to-point link model in use.
<span class="grey">Schmidt, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Operations of the Local Mobility Anchor</span>
For any MN, the Local Mobility Anchor acts as the persistent home
agent and at the same time as the default multicast querier for the
corresponding MAG. It implements the function of the designated
multicast router or a further MLD proxy. According to MLD reports
received from a MAG (on behalf of the MNs), the LMA establishes/
maintains/removes group-/source-specific multicast forwarding states
at its corresponding downstream tunnel interfaces. At the same time,
it procures for aggregated multicast membership maintenance at its
upstream interface. Based on the multicast-transparent operations of
the MAGs, the LMA treats its tunnel interfaces as multicast-enabled
downstream links, serving zero to many listening nodes. Multicast
traffic arriving at the LMA is transparently forwarded according to
its multicast forwarding information base.
After a handover, the LMA will receive Binding De-Registrations and
Binding Lifetime Extensions that will cause a re-mapping of home
network prefix(es) to a new Proxy-CoA in its Binding Cache (see
<a href="./rfc5213#section-5.3">Section 5.3 of [RFC5213]</a>). The multicast forwarding states require
updating, as well, if the MN within an MLD proxy domain is the only
receiver of a multicast group. Two different cases need to be
considered:
1. The mobile node is the only receiver of a group behind the
interface at which a De-Registration was received: the membership
database of the MAG changes, which will trigger a Report/Done
sent via the MAG-to-LMA interface to remove this group. The LMA
thus terminates multicast forwarding.
2. The mobile node is the only receiver of a group behind the
interface at which a Lifetime Extension was received: the
membership database of the MAG changes, which will trigger a
Report sent via the MAG-to-LMA interface to add this group. The
LMA thus starts multicast distribution.
In proceeding this way, each LMA will provide transparent multicast
support for the group of MNs it serves. It will perform traffic
aggregation at the MN-group level and will assure that multicast data
streams are uniquely forwarded per individual LMA-to-MAG tunnel.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. IPv4 Support</span>
An MN in a PMIPv6 domain may use an IPv4 address transparently for
communication as specified in [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]. For this purpose, LMAs can
register IPv4-Proxy-CoAs in its Binding Caches, and MAGs can provide
IPv4 support in access networks. Correspondingly, multicast
membership management will be performed by the MN using IGMP. For
<span class="grey">Schmidt, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
multicast support on the network side, an IGMP proxy function needs
to be deployed at MAGs in exactly the same way as for IPv6.
[<a href="./rfc4605" title=""Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("">RFC4605</a>] defines IGMP proxy behavior in full agreement with IPv6/
MLD. Thus, IPv4 support can be transparently provided following the
obvious deployment analogy.
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
should choose multicast signaling according to address configurations
on the link, but may submit IGMP and MLD queries in parallel, if
needed. It should further be noted that the infrastructure cannot
identify two data streams as identical when distributed via an IPv4
and IPv6 multicast group. Thus, duplicate data may be forwarded on a
heterogeneous network layer.
A particular note is worth giving the scenario of [<a href="./rfc5845" title=""Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6"">RFC5845</a>] in which
overlapping private address spaces of different operators can be
hosted in a PMIP domain by using Generic Routing Encapsulation (GRE)
with key identification. This scenario implies that unicast
communication in the MAG-LMA tunnel can be individually identified
per MN by the GRE keys. This scenario still does not impose any
special treatment of multicast communication for the following
reasons.
MLD/IGMP signaling between MNs and the MAG is on point-to-point links
(identical to unicast). Aggregated MLD/IGMP signaling between the
MAG proxy instance and the LMA remains link-local between the routers
and independent of any individual MN. So the MAG-proxy and the LMA
should not use GRE key identifiers, but plain GRE to exchange MLD
queries and reports. Similarly, multicast traffic sent from an LMA
to MAGs proceeds as router-to-router forwarding according to the
multicast forwarding information base (MFIB) of the LMA and
independent of MN's unicast addresses, while the MAG proxy instance
distributes multicast data down the point-to-point links (interfaces)
according to its own MFIB, independent of MN's IP addresses.
It remains an open issue how communication proceeds in a multi-
operator scenario, i.e., from which network the LMA pulls multicast
traffic. This could be any mobility Operator itself, or a third
party. However, this backbone routing in general is out of scope of
the document, and most likely a matter of contracts.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Multihoming Support</span>
An MN can connect to a PMIPv6 domain through multiple interfaces and
experience transparent unicast handovers at all interfaces (cf.,
<a href="./rfc5213#section-5.4">Section 5.4 of [RFC5213]</a>). In such simultaneous access scenarios, it
can autonomously assign multicast channel subscriptions to individual
interfaces (see [<a href="./rfc5757" title=""Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey"">RFC5757</a>] for additional details). While doing so,
<span class="grey">Schmidt, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
multicast mobility operations described in this document will
transparently preserve the association of channels to interfaces in
the following way.
Multicast listener states are kept per interface in the MLD state
table. An MN will answer to an MLD General Query received on a
specific (re-attaching) interface according to the specific
interface's state table. Thereafter, multicast forwarding is resumed
for channels identical to those under subscription prior to handover.
Consequently, an MN in a PMIPv6 domain may use multiple interfaces to
facilitate load balancing or redundancy, but cannot follow a 'make-
before-break' approach to service continuation on handovers.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Multicast Availability throughout the Access Network</span>
There may be deployment scenarios where multicast services are
available throughout the access network, independent of the PMIPv6
infrastructure. Direct multicast access at MAGs may be supported
through native multicast routing within a flat access network that
includes a multicast router, via dedicated (tunnel or VPN) links
between MAGs and designated multicast routers, or by deploying
Automatic Multicast Tunneling (AMT) [<a href="#ref-AUTO-MULTICAST">AUTO-MULTICAST</a>].
Multicast deployment can be simplified in these scenarios. A single
proxy instance at MAGs with up-link to the multicast cloud, for
instance, could serve group communication purposes. MAGs could
operate as general multicast routers or AMT gateways as well.
Common to these solutions is that mobility management is covered by
the dynamics of multicast routing, as initially foreseen in the
Remote Subscription approach, i.e., join via a local multicast router
as sketched in [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>]. Care must be taken to avoid avalanche
problems or service disruptions due to tardy multicast routing
operations and to adapt to different link-layer technologies
[<a href="./rfc5757" title=""Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey"">RFC5757</a>]. The different possible approaches should be carefully
investigated beyond the initial sketch in <a href="#appendix-C">Appendix C</a>. Such work is
beyond the scope of this document.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. A Note on Explicit Tracking</span>
An IGMPv3/MLDv2 Querier may operate in combination with explicit
tracking as described in <a href="./rfc3376#appendix-A.2">Appendix A.2 of [RFC3376]</a>, or <a href="./rfc3810#appendix-A.2">Appendix A.2
of [RFC3810]</a>. This mechanism allows routers to monitor each
multicast receiver individually. Even though this procedure is not
standardized yet, it is widely implemented by vendors as it supports
faster leave latencies and reduced signaling.
<span class="grey">Schmidt, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
Enabling explicit tracking on downstream interfaces of the LMA and
MAG would track a single MAG and MN respectively per interface. It
may be used to preserve bandwidth on the MAG-MN link.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Message Source and Destination Address</span>
This section describes source and destination addresses of MLD
messages and encapsulating outer headers when deployed in the PMIPv6
domain. This overview is for clarification purposes only and does
not define a behavior different from referenced standards in any way.
The interface identifier A-B denotes an interface on node A, which is
connected to node B. This includes tunnel interfaces. Destination
addresses for MLD/IGMP messages shall be as specified in <a href="./rfc2710#section-8">Section 8 of
[RFC2710]</a> for MLDv1, and Sections <a href="#section-5.1.15">5.1.15</a> and <a href="#section-5.2.14">5.2.14</a> of [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] for
MLDv2.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Query</span>
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| | LMAA | Proxy-CoA | outer |
+ LMA-MAG +----------------+----------------------+----------+
| | LMA-link-local | [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>], [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] | inner |
+-----------+----------------+----------------------+----------+
| MAG-MN | MAG-link-local | [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>], [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] | -- |
+-----------+----------------+----------------------+----------+
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Report/Done</span>
+===========+================+======================+==========+
| Interface | Source Address | Destination Address | Header |
+===========+================+======================+==========+
| MN-MAG | MN-link-local | [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>], [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] | -- |
+-----------+----------------+----------------------+----------+
| | Proxy-CoA | LMAA | outer |
+ MAG-LMA +----------------+----------------------+----------+
| | MAG-link-local | [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>], [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] | inner |
+-----------+----------------+----------------------+----------+
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document does not introduce additional messages or novel
protocol operations. Consequently, no additional threats are
introduced by this document beyond those identified as security
concerns of [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>], [<a href="./rfc4605" title=""Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("">RFC4605</a>], [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], and [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>].
<span class="grey">Schmidt, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
However, particular attention should be paid to implications of
combining multicast and mobility management at network entities. As
this specification allows mobile nodes to initiate the creation of
multicast forwarding states at MAGs and LMAs while changing
attachments, threats of resource exhaustion at PMIP routers and
access networks arrive from rapid state changes, as well as from
high-volume data streams routed into access networks of limited
capacities. In addition to proper authorization checks of MNs, rate
controls at replicators may be required to protect the agents and the
downstream networks. In particular, MLD proxy implementations at
MAGs should carefully procure automatic multicast state extinction on
the departure of MNs, as mobile multicast listeners in the PMIPv6
domain will not actively terminate group membership prior to
departure.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
This memo follows initial requirements work presented in "Multicast
Support Requirements for Proxy Mobile IPv6" (July 2009), and is the
outcome of extensive previous discussions and a follow-up of several
initial documents on the subject. The authors would like to thank
(in alphabetical order) Jari Arkko, Luis M. Contreras, Greg Daley,
Gorry Fairhurst, Dirk von Hugo, Liu Hui, Seil Jeon, Jouni Korhonen,
Guang Lu, Sebastian Meiling, Akbar Rahman, Imed Romdhani, Behcet
Sarikaya, Pierrick Seite, Stig Venaas, and Juan Carlos Zuniga for
advice, help, and reviews of the document. Funding by the German
Federal Ministry of Education and Research within the G-LAB
Initiative is gratefully acknowledged.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2710">RFC2710</a>] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", <a href="./rfc2710">RFC 2710</a>,
October 1999.
[<a id="ref-RFC3376">RFC3376</a>] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", <a href="./rfc3376">RFC 3376</a>, October 2002.
[<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-RFC3810">RFC3810</a>] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", <a href="./rfc3810">RFC 3810</a>, June 2004.
<span class="grey">Schmidt, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
[<a id="ref-RFC4605">RFC4605</a>] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", <a href="./rfc4605">RFC 4605</a>, August 2006.
[<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-RFC5844">RFC5844</a>] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", <a href="./rfc5844">RFC 5844</a>, May 2010.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-AUTO-MULTICAST">AUTO-MULTICAST</a>]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", Work in Progress, March 2010.
[<a id="ref-RFC2236">RFC2236</a>] Fenner, W., "Internet Group Management Protocol, Version
2", <a href="./rfc2236">RFC 2236</a>, November 1997.
[<a id="ref-RFC5757">RFC5757</a>] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
Mobility in Mobile IP Version 6 (MIPv6): Problem Statement
and Brief Survey", <a href="./rfc5757">RFC 5757</a>, February 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">Schmidt, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Initial MLD Queries on Upcoming Links</span>
According to [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] and [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>], when an IGMP-/MLD-enabled
multicast router starts operating on a subnet, by default it
considers itself as querier and sends several General Queries. Such
initial query should be sent by the router immediately, but could be
delayed by a (tunable) Startup Query Interval (see Sections <a href="#section-7.6.2">7.6.2</a> and
9.6 of [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>]).
Experimental tests on Linux and Cisco systems have revealed immediate
IGMP Queries followed a link trigger event (within a fraction of 1
ms), while MLD queries immediately followed the autoconfiguration of
IPv6 link-local addresses at the corresponding interface.
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. State of IGMP/MLD Proxy Implementations</span>
The deployment scenario defined in this document requires certain
proxy functionalities at the MAGs that implementations of [<a href="./rfc4605" title=""Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("">RFC4605</a>]
need to contribute. In particular, a simultaneous support of IGMP
and MLD is needed, as well as a configurable list of downstream
interfaces that may be altered during runtime, and the deployment of
multiple proxy instances at a single router that can operate
independently on separated interfaces.
A brief experimental trial undertaken in February 2010 revealed the
following divergent statuses of selected IGMP/MLD proxy
implementations.
Cisco Edge Router: Software-based commodity edge routers (test
device from the 26xx-Series) implement IGMPv2/v3 proxy functions
only in combination with Protocol Independent Multicast - Sparse
Mode (PIM-SM). There is no support of MLD proxy. Interfaces are
dynamically configurable at runtime via the command line
interface, but multiple proxy instances are not supported.
Linux igmpproxy: IGMPv2 Proxy implementation that permits a static
configuration of downstream interfaces (simple bug fix required).
Multiple instances are prevented by a lock (corresponding code
reused from a previous Distance Vector Multicast Routing Protocol
(DVMRP) implementation). IPv6/MLD is unsupported. Project page:
<a href="http://sourceforge.net/projects/igmpproxy/">http://sourceforge.net/projects/igmpproxy/</a>.
Linux gproxy: IGMPv3 Proxy implementation that permits configuration
of the upstream interface, only. Downstream interfaces are
collected at startup without dynamic extension of this list. No
support of multiple instances or MLD.
<span class="grey">Schmidt, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
Linux ecmh: MLDv1/2 Proxy implementation without IGMP support that
inspects IPv4 tunnels and detects encapsulated MLD messages.
Allows for dynamic addition of interfaces at runtime and multiple
instances. However, downstream interfaces cannot be configured.
Project page: <a href="http://sourceforge.net/projects/ecmh/">http://sourceforge.net/projects/ecmh/</a>
<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>. Comparative Evaluation of Different Approaches</span>
In this section, we briefly evaluate two orthogonal PMIP concepts for
multicast traffic organization at LMAs. In scenario A, multicast is
provided by combined unicast/multicast LMAs as described in this
document. Scenario B directs traffic via a dedicated, central
multicast router ("LMA-M") that tunnels packets to MAGs independent
of unicast handoffs.
Neither approach establishes native multicast distribution between
the LMA and MAG; instead, they use tunneling mechanisms. In scenario
A, a MAG is connected to different multicast-enabled LMAs and can
receive the same multicast stream via multiple paths depending on the
group subscriptions of MNs and their associated LMAs. This problem,
a.k.a. the tunnel convergence problem, may lead to redundant traffic
at the MAGs. In contrast, scenario B configures MAGs to establish a
tunnel to a single, dedicated multicast LMA for all attached MNs and
relocates overhead costs to the multicast anchor. This eliminates
redundant traffic but may result in an avalanche problem at the LMA.
We quantify the costs of both approaches based on two metrics: the
amount of redundant traffic at MAGs and the number of simultaneous
streams at LMAs. Realistic values depend on the topology and the
group subscription model. To explore scalability in a large PMIP
domain of 1,000,000 MNs, we consider the following two extreme
multicast settings.
1. All MNs participate in distinct multicast groups.
2. All MNs join the same multicast group.
A typical PMIP deployment approximately allows for 5,000 MNs attached
to one MAG, while 50 MAGs can be served by one LMA. Hence 1,000,000
MNs require approximately 200 MAGs backed by 4 LMAs for unicast
transmission. In scenario A, these LMAs also forward multicast
streams, while in scenario B one additional dedicated LMA (LMA-M)
serves multicast. In the following, we calculate the metrics
described above. In addition, we display the number of packet
streams that cross the interconnecting (wired) network within a
PMIPv6 domain.
<span class="grey">Schmidt, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
Setting 1:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 0 | 250,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 1,000,000 | 1,000,000 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to distinct multicast groups.
Setting 2:
+===================+==============+================+===============+
| PMIP multicast | # of redund. | # of simul. | # of total |
| scheme | streams | streams | streams in |
| | at MAG | at LMA/LMA-M | the network |
+===================+==============+================+===============+
| Combined Unicast/ | 3 | 200 | 800 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
| Dedicated | 0 | 200 | 200 |
| Multicast LMA | | | |
+-------------------+--------------+----------------+---------------+
1,000,000 MNs are subscribed to the same multicast group.
These considerations of extreme settings show that packet duplication
and replication effects apply in changing intensities for different
use cases of multicast data services. However, tunnel convergence,
i.e., duplicate data arriving at a MAG, does cause much smaller
problems in scalability than the stream replication at LMAs
(avalanche problem). For scenario A, it should also be noted that
the high stream replication requirements at LMAs in setting 1 can be
attenuated by deploying additional LMAs in a PMIP domain, while
scenario B does not allow for distributing the LMA-M, as no handover
management is available at LMA-M.
<span class="grey">Schmidt, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6224">RFC 6224</a> Multicast Listeners in PMIPv6 April 2011</span>
Authors' Addresses
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
EMail: schmidt@informatik.haw-hamburg.de
URI: <a href="http://inet.cpt.haw-hamburg.de/members/schmidt">http://inet.cpt.haw-hamburg.de/members/schmidt</a>
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin 10318
Germany
EMail: mw@link-lab.net
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
EMail: suresh.krishnan@ericsson.com
Schmidt, et al. Informational [Page 19]
</pre>
|
