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
|
<pre>Internet Engineering Task Force (IETF) H. Liu
Request for Comments: 5790 W. Cao
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 H. Asaeda
Keio University
February 2010
<span class="h1">Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and</span>
<span class="h1">Multicast Listener Discovery Version 2 (MLDv2) Protocols</span>
Abstract
This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
IGMPv3 and MLDv2. The interoperability with the full versions and
the previous versions of IGMP and MLD is also taken into account.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5790">http://www.rfc-editor.org/info/rfc5790</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Liu, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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-4">4</a>
<a href="#section-3">3</a>. Simplification Method Overview ..................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Behavior of Group Members ..................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Behavior of Multicast Routers ..............................<a href="#page-5">5</a>
<a href="#section-4">4</a>. LW-IGMPv3 Protocol for Group Members ............................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Query and Report Messages ..................................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Action on Change of Interface State ........................<a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. Action on Reception of a Query .............................<a href="#page-7">7</a>
<a href="#section-4.4">4.4</a>. LW-IGMPv3 Group Record Types ...............................<a href="#page-7">7</a>
<a href="#section-5">5</a>. LW-IGMPv3 Protocol for Multicast Routers ........................<a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Group Timers and Source Timers in the Lightweight Version ..9
<a href="#section-5.2">5.2</a>. Source-Specific Forwarding Rules ..........................<a href="#page-10">10</a>
<a href="#section-5.3">5.3</a>. Reception of Current-State Records ........................<a href="#page-10">10</a>
5.4. Reception of Source-List-Change and
Filter-Mode-Change Records ................................<a href="#page-12">12</a>
<a href="#section-6">6</a>. Interoperability ...............................................<a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Interoperation with the Full Version of IGMPv3/MLDv2 ......<a href="#page-13">13</a>
<a href="#section-6.1.1">6.1.1</a>. Behavior of Group Members ..........................<a href="#page-13">13</a>
<a href="#section-6.1.2">6.1.2</a>. Behavior of Multicast Routers ......................<a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. Interoperation with IGMPv1/IGMPv2 .........................<a href="#page-14">14</a>
<a href="#section-6.2.1">6.2.1</a>. Behavior of Group Members ..........................<a href="#page-14">14</a>
<a href="#section-6.2.2">6.2.2</a>. Behavior of Multicast Routers ......................<a href="#page-14">14</a>
<a href="#section-6.3">6.3</a>. Interoperation with MLDv1 .................................<a href="#page-15">15</a>
<a href="#section-7">7</a>. Implementation Considerations ..................................<a href="#page-15">15</a>
<a href="#section-7.1">7.1</a>. Implementation of Source-Specific Multicast ...............<a href="#page-15">15</a>
<a href="#section-7.2">7.2</a>. Implementation of Multicast Source Filter (MSF) APIs ......<a href="#page-16">16</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-16">16</a>
<a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-16">16</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">Liu, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
IGMP version 3 [<a href="#ref-2" title=""Internet Group Management Protocol, Version 3"">2</a>] and MLD version 2 [<a href="#ref-3" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">3</a>] implement source filtering
capabilities that are not supported by their earlier versions, IGMPv1
[<a href="#ref-4" title=""Host extensions for IP multicasting"">4</a>], IGMPv2 [<a href="#ref-5" title=""Internet Group Management Protocol, Version 2"">5</a>], and MLDv1 [<a href="#ref-6" title=""Multicast Listener Discovery (MLD) for IPv6"">6</a>]. An IGMPv3- or MLDv2-capable host can
tell its upstream router which group it would like to join by
specifying which sources it does or does not intend to receive
multicast traffic from. IGMPv3 and MLDv2 add the capability for a
multicast router to learn sources that are of interest or that are
not of interest for a particular multicast address. This information
is used during forwarding of multicast data packets.
INCLUDE and EXCLUDE filter-modes are introduced to support the source
filtering function. If a host wants to receive from specific
sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to
INCLUDE. If the host does not want to receive from some sources, it
sends a report with filter-mode set to EXCLUDE. A source-list for
the given sources shall be included in the Report message.
INCLUDE and EXCLUDE filter-modes are also defined in a multicast
router to process the IGMPv3 or MLDv2 reports. When a multicast
router receives the Report messages from its downstream hosts, it
forwards the corresponding multicast traffic by managing requested
group and source addresses. Group timers and source timers are used
to maintain the forwarding state of desired groups and sources under
certain filter-modes. When a group report arrives or a certain timer
expires, a multicast router may update the desired or undesired
source-lists, reset related timer values, change filter-mode, or
trigger group queries. With all of the above factors correlating
with each other, the determination rules become relatively complex,
as the interface states could be frequently changed.
The multicast filter-mode improves the ability of the multicast
receiver to express its desires. It is useful to support Source-
Specific Multicast (SSM) [<a href="#ref-7" title=""Source-Specific Multicast for IP"">7</a>] by specifying interesting source
addresses with INCLUDE mode. However, practical applications do not
use EXCLUDE mode to block sources very often, because a user or
application usually wants to specify desired source addresses, not
undesired source addresses. Even if a user explicitly refuses
traffic from some sources in a group, when other users in the same
shared network have an interest in these sources, the corresponding
multicast traffic will still be forwarded to the network. It is
generally unnecessary to support the filtering function that blocks
sources.
This document proposes simplified versions of IGMPv3 and MLDv2, named
Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2).
LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2.
<span class="grey">Liu, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
They support both Any-Source Multicast (ASM) and SSM communications
without a filtering function that blocks sources. Not only are they
compatible with the standard IGMPv3 and MLDv2, but also the protocol
operations made by hosts and routers (or switches performing IGMPv3/
MLDv2 snooping) are simplified to reduce the complicated operations.
Since LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and
MLDv2, hosts or routers that have implemented the full version do not
need to implement or modify anything to cooperate with LW-IGMPv3/
LW-MLDv2 hosts or routers.
<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">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
In addition, the following terms are used in this document.
(*,G) join:
An operation triggered by a host that wants to join a group G. In
this case, the host receives from all sources sending to group G.
This is typical in ASM communication.
(S,G) join:
An operation triggered by a host that wants to join a group G,
specifying a desired source S. In this case, the host receives
traffic only from source S sending to group G.
INCLUDE (S,G) join:
An operation triggered by a host that wants to join a group G under
INCLUDE filter-mode, specifying a desired source S. Same meaning as
(S,G) join.
EXCLUDE (*,G) join:
An operation triggered by a host that wants to join a group G under
EXCLUDE filter-mode. Same meaning as (*,G) join.
EXCLUDE (S,G) join:
An operation triggered by a host that wants to join a group G under
EXCLUDE filter-mode, specifying an undesired source S. This
operation is not supported by LW-IGMPv3/LW-MLDv2.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Simplification Method Overview</span>
The principle is to simplify the host's and router's behavior as much
as possible to improve efficiency, while guaranteeing
interoperability with the full versions, and introducing no side
effects on applications.
<span class="grey">Liu, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
For convenience, this document mainly discusses IGMPv3, since MLDv2
inherits the same source filtering mechanism, but this document
additionally shows MLDv2's unique specifications when needed.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Behavior of Group Members</span>
LW-IGMPv3 inherits the service interface model of IGMPv3.
IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list )
In the lightweight protocol, INCLUDE mode on the host part has the
same usage as the full version for INCLUDE (S,G) join, while EXCLUDE
mode on the host part is preserved only for excluding null source-
lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/MLDv1.
The detailed host operation of LW-IGMPv3/LW-MLDv2 is described in
<a href="#section-4">Section 4</a>.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Behavior of Multicast Routers</span>
In IGMPv3, router filter-mode is defined to optimize the state
description of a group membership [<a href="#ref-2" title=""Internet Group Management Protocol, Version 3"">2</a>]. As a rule, once a member
report is in EXCLUDE mode, the router filter-mode for the group will
be set to EXCLUDE. When all systems cease sending EXCLUDE mode
reports, the filter-mode for that group may transit back to INCLUDE
mode. The group timer is used to identify such a transition.
In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can
request an EXCLUDE (*,G) join, which can be interpreted by the router
as a request to include all sources. Without the more general form
of EXCLUDE requests, it is unnecessary for the router to maintain the
EXCLUDE filter-mode, and the state model for multicast routers can be
simplified as:
(multicast address, group timer, (source records))
Here a group timer is kept to represent a (*,G) join. Its basic
behavior is: when a router receives a (*,G) join, it will set its
group timer and keep the source-list for sources specified in the
previously received source records. When the group timer expires,
the router may change to reception of the listed sources only. The
definition of the source record is the same as in the full version.
The elimination of the filter-mode will greatly simplify the router
behavior. The details of router operation are described in
<a href="#section-5">Section 5</a>.
<span class="grey">Liu, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. LW-IGMPv3 Protocol for Group Members</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Query and Report Messages</span>
LW-IGMPv3 uses the same two sets of messages, Query and Report
messages, as the full version protocols. There is no difference
between the definition and usage of the Query message. But the
report types in lightweight protocols are reduced because an
operation that triggers EXCLUDE (S,G) join is omitted.
There are three Group Record Types defined in the full IGMPv3: the
Current-State Record denoted by MODE_IS_INCLUDE (referred to as
IS_IN) or MODE_IS_EXCLUDE (IS_EX), the Filter-Mode-Change Record
denoted by CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE
(TO_EX), and the Source-List-Change Record denoted by
ALLOW_NEW_SOURCES (ALLOW) or BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3
inherits the actions on change of interface state and on reception of
a query, but the IS_IN and IS_EX record types are eliminated and
Current-State Records are replaced by other records. The following
sections explain the details.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Action on Change of Interface State</span>
When the state of an interface of a group member host is changed, a
State-Change Report for that interface is immediately transmitted
from that interface. The type and contents of the Group Record(s) in
that report are determined by comparing the filter-mode and source-
list for the affected multicast address before and after the change.
While the requirements for the computation are the same as for the
full version, in a lightweight version host the interface state
change rules are simplified due to the reduction of message types.
The contents of the new transmitted report are calculated as follows
(Group Record Types are described in <a href="#section-4.4">Section 4.4</a>):
Old State New State State-Change Report Sent
----------- ----------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B)
INCLUDE (A) EXCLUDE ({}) TO_EX({})
INCLUDE ({}) EXCLUDE ({}) TO_EX({})
EXCLUDE ({}) INCLUDE (B) TO_IN(B)
<span class="grey">Liu, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
As in the full version, to cover the possibility of the State-Change
Report being missed by one or more multicast routers, it is
retransmitted [Robustness Variable]-1 more times, at intervals chosen
at random from the range (0, [Unsolicited Report Interval]). (These
values are defined in [<a href="#ref-2" title=""Internet Group Management Protocol, Version 3"">2</a>][3].)
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Action on Reception of a Query</span>
As in the full version, when a lightweight version host receives a
query, it does not respond immediately. Instead, it delays its
response by a random amount of time, bounded by the Max Resp Time
value derived from the Max Resp Code in the received Query message
[<a href="#ref-2" title=""Internet Group Management Protocol, Version 3"">2</a>][3]. The system may receive a variety of queries on different
interfaces and of different kinds (e.g., General Queries, Group-
Specific Queries, and Group-and-Source-Specific Queries), each of
which may require its own delayed response.
Before scheduling a response to a query, the system must first
consider previously scheduled pending responses and in many cases
schedule a combined response. Therefore, the lightweight version
host must be able to maintain the following state:
o A timer per interface for scheduling responses to General Queries.
o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries.
o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query.
LW-IGMPv3 inherits the full version's rules that are used to
determine if a report needs to be scheduled. The difference is
regarding the simplification of EXCLUDE filter-mode and the type of
report as detailed in <a href="#section-4.4">Section 4.4</a>.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. LW-IGMPv3 Group Record Types</span>
Among the Group Record Types defined in the full IGMPv3, several
record types are not used in LW-IGMPv3 as some of the processes
related to the filter-mode change to the EXCLUDE mode are eliminated
and some of the Report messages are converged into a record having a
null source address list. All of the record types of Report messages
used by the full and lightweight version protocols are shown as
follows:
<span class="grey">Liu, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
IGMPv3 LW-IGMPv3 Comments
--------- --------- -------------------------------------
IS_EX({}) TO_EX({}) Query response for (*,G) join
IS_EX(x) N/A Query response for EXCLUDE (x,G) join
IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join
ALLOW(x) ALLOW(x) INCLUDE (x,G) join
BLOCK(x) BLOCK(x) INCLUDE (x,G) leave
TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join
TO_IN({}) TO_IN({}) (*,G) leave
TO_EX(x) N/A Change to EXCLUDE (x,G) join
TO_EX({}) TO_EX({}) (*,G) join
where "x" represents a non-null source address list and "({})"
represents a null source address list. For instance, IS_EX({}) means
a report whose record type is IS_EX with a null source address list.
"N/A" represents not applicable (or no use) because the corresponding
operation should not occur in the lightweight version protocols.
LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source
address list. A multicast router creates the same state when it
receives a Report message containing either IS_EX({}) or TO_EX({})
record types. Therefore, LW-IGMPv3 integrates the IS_EX({})
operation with the TO_EX({}) operation.
When an LW-IGMPv3 host needs to make a query response for the state
of INCLUDE (x,G) join, it makes a response whose message type is
expressed with ALLOW(x), instead of using the IS_IN record type.
Because the router's processing of the two messages is exactly the
same, the IS_IN(x) type is eliminated for simplification.
An LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN and TO_EX
records are used for example in the following situation: the host
first launches an application (AP1) that requests INCLUDE (x,G) join,
and sends ALLOW(x). Then the host launches another application (AP2)
that joins (*,G), and it sends TO_EX({}). In this condition, when
AP2 terminates but AP1 keeps working on the lightweight version host,
the host sends a report with TO_IN(x) record type for [Robustness
Variable] times.
<span class="grey">Liu, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
Although an LW-IGMPv3 host adopts the four message types (ALLOW,
BLOCK, TO_IN, and TO_EX) for simplification, using IS_EX({}) and
IS_IN(x) (respectively, instead of TO_EX({}) and ALLOW(x)) in
response to queries is not inhibited. This will not introduce the
interoperation problem because the router process is, respectively,
the same for the mentioned two message set, as long as the router
implementation follows the rules given by full IGMPv3.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. LW-IGMPv3 Protocol for Multicast Routers</span>
The major difference between the full and lightweight version
protocols on the router part is that in the lightweight version
filter-mode is discarded and the function of the group timer is
redefined. The states maintained by the lightweight router are
reduced and the protocol operation is greatly simplified.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Group Timers and Source Timers in the Lightweight Version</span>
In lightweight and full IGMPv3 routers, a source timer is kept for
each source record and it is updated when the source is present in a
received report. It indicates the validity of the source and needs
to be referred to when the router takes its forwarding decision.
The group timer being used in the full version of IGMPv3 for
transitioning the router's filter-mode from EXCLUDE to INCLUDE is
redefined in the lightweight protocols to identify the non-source-
specific receiving state maintained for (*,G) join. Once a group
record of TO_EX({}) is received, the group timer is set to represent
this (*,G) group join. The expiration of the group timer indicates
that there are no more listeners on the attached network for this
(*,G) group. Then if at this moment there are unexpired sources
(whose source timers are greater than zero), the router will change
to receiving traffic for those sources only. The role of the group
timer can be summarized as follows:
Group Timer Value Actions/Comments
------------------ --------------------------------------
G_Timer > 0 All members in this group.
G_Timer == 0 No more listeners to this (*,G) group.
If all source timers have expired, then
delete group record. If there are
still source record timers running,
use those source records with running
timers as the source record state.
<span class="grey">Liu, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
The operation related to the group and source timers has some
differences compared to the full IGMPv3. In the full version, if a
source timer expires under the EXCLUDE router filter-mode, its
corresponding source record is not deleted until the group timer
expires for indicating undesired sources. In the lightweight
version, since there is no need to keep such records for blocking
specific sources, if a source timer expires, its source record should
be deleted immediately, not waiting for the time-out of the group
timer.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Source-Specific Forwarding Rules</span>
A full version multicast router needs to consult IGMPv3 state
information when it makes decisions on forwarding a datagram from a
source, based on the router filter-mode and source timer. In LW-
IGMPv3, because of the absence of the router filter-mode, the group
timer and source timer could be used for such decisions. The
forwarding suggestion made by LW-IGMPv3 to the routing protocols is
summarized as follows:
Group Timer Source Timer Action
------------ ------------------ -----------------------
G_Timer == 0 S_Timer > 0 Suggest forwarding
traffic from source
G_Timer == 0 S_Timer == 0 Suggest stopping
forwarding traffic from
source and remove
source record. If there
are no more source
records for the group,
delete group record
G_Timer == 0 No Source Elements Suggest not forwarding
traffic from source
G_Timer > 0 S_Timer >= 0 Suggest forwarding
traffic from source
G_Timer > 0 No Source Elements Suggest forwarding
traffic from source
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Reception of Current-State Records</span>
When receiving Current-State Records, the LW-IGMPv3 router resets its
group or source timers and updates its source-list within the group.
For source-specific group reception state (when G_Timer == 0 and
<span class="grey">Liu, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
S_Timer > 0), the source-list contains sources whose traffic will be
forwarded by the router, while in non-source-specific group reception
(when G_Timer > 0), the source-list remembers the valid sources to
receive traffic from after toggling to source-specific reception
state.
Although the LW-IGMPv3 host only sends a subset of the messages of
the full version, the LW-IGMPv3 router should be able to process as
many messages as possible to be compatible with the full version
host. Note that if the report type is IS_EX(x) with a non-empty
source-list, the router will treat it as the same type of report with
an empty source-list. The following table describes the action taken
by a multicast router after receiving Current-State Records. The
notations have the same meaning as those in the full IGMPv3 protocol.
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -----------
G_Timer == 0 A IS_IN(B) A+B (B)=GMI
G_Timer == 0 A IS_EX({}) A G_Timer=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI
G_Timer > 0 A IS_EX({}) A G_Timer=GMI
The above table could be further simplified since the processes are
exactly the same for the two values of the G_Timer:
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ -----------
A IS_IN(B) A+B (B)=GMI
A IS_EX({}) A G_Timer=GMI
Without EXCLUDE filter-mode, a router's process on receiving a
Current-State Record is simple: when a router receives an IS_IN
report, it appends the reported source addresses to the previous
source-list with their source timers set to GMI. Upon receiving an
IS_EX({}) report, the router sets the non-source-specific receiving
states by resetting the group timer value and keeps the previous
source-list without modification.
<span class="grey">Liu, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Reception of Source-List-Change and Filter-Mode-Change Records</span>
On receiving Source-List-Change and Filter-Mode-Change Records, the
LW-IGMPv3 router needs to reset its group and source timers, update
its source-list within the group, or trigger group queries. The
queries are sent by the router for the sources that are requested to
be no longer forwarded to a group. Note that if the report type is
TO_EX(x) with a non-empty source-list, the router will treat it as
the same type of report with an empty source-list. The table below
describes the state change and the actions that should be taken.
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -------------
G_Timer == 0 A ALLOW(B) A+B (B)=GMI
G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer == 0 A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
G_Timer == 0 A TO_EX({}) A G_Timer=GMI
G_Timer > 0 A ALLOW(B) A+B (B)=GMI
G_Timer > 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer > 0 A TO_IN(B) A+B (B)=GMI
SendQ(G,A-B)
Send Q(G)
G_Timer > 0 A TO_EX({}) A G_Timer=GMI
The table could be further simplified by merging duplicate lines:
<span class="grey">Liu, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ ----------------------
A ALLOW(B) A+B (B)=GMI
A BLOCK(B) A Send Q(G,A*B)
A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
If G_Timer>0 Send Q(G)
A TO_EX({}) A G_Timer=GMI
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Interoperability</span>
LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and
routers of the full version [<a href="#ref-2" title=""Internet Group Management Protocol, Version 3"">2</a>][3]. Also, LW-IGMPv3/LW-MLDv2 hosts
and routers must interoperate gracefully with hosts and routers
running IGMPv1/v2 or MLDv1.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Interoperation with the Full Version of IGMPv3/MLDv2</span>
LW-IGMPv3/LW-MLDv2 do not introduce any change on the message formats
of the group Query and Report messages that the full version
protocols use.
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Behavior of Group Members</span>
An LW-IGMPv3 host's compatibility mode is determined from the Host
Compatibility Mode variable, which can be in one of three states:
IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its
interface as LW-IGMPv3, its Host Compatibility Mode of that interface
is set to IGMPv3, and the host sends a subset of IGMPv3 Report
messages, which can be recognized by a multicast router running the
full or the lightweight IGMPv3 protocol on the same LAN.
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Behavior of Multicast Routers</span>
An LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x)
and TO_EX(x) reports that are used by the full version. When an LW-
IGMPv3/LW-MLDv2 router receives these Report messages from full
version hosts, it MUST translate them internally to IS_EX({}) and
TO_EX({}) respectively and behave accordingly.
<span class="grey">Liu, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Interoperation with IGMPv1/IGMPv2</span>
Since the lightweight protocols can be treated as a parallel version
of the full version of IGMPv3/MLDv2, its compatibility principle and
method with the older version are generally the same as that of full
IGMPv3/MLDv2.
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Behavior of Group Members</span>
The Host Compatibility Mode of an interface is set to IGMPv2 and its
IGMPv2 Querier Present timer is set to Older Version Querier Present
Timeout seconds (defined in [<a href="#ref-2" title=""Internet Group Management Protocol, Version 3"">2</a>]) whenever an IGMPv2 General Query is
received on that interface. The Host Compatibility Mode of an
interface is set to IGMPv1 and its IGMPv1 Querier Present timer is
set to Older Version Querier Present Timeout seconds whenever an
IGMPv1 Membership Query is received on that interface.
In the presence of older version group members, LW-IGMPv3 hosts may
allow its Report message to be suppressed by either an IGMPv1 or
IGMPv2 membership report. However, because the transmission of
IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system,
as a potential protection mechanism, the choice to enable or disable
the use of backward compatibility may be configurable.
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Behavior of Multicast Routers</span>
The behavior of an LW-IGMPv3 router when placed on a network where
there are routers that have not been upgraded to IGMPv3 is exactly
the same as for a full IGMPv3 router in this situation [<a href="#ref-2" title=""Internet Group Management Protocol, Version 3"">2</a>].
A full IGMPv3 router uses Group Compatibility Mode (whose value is
either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate
which version of IGMP protocol it applies to the group. This value
is set according to the version of the received IGMP reports. When
Group Compatibility Mode is IGMPv3, the lightweight router performs
the LW-IGMPv3 protocol for that group.
When Group Compatibility Mode is IGMPv2, an LW-IGMPv3 router inherits
this compatibility mechanism with the following rules:
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v2 Report TO_EX({})
v2 Leave TO_IN({})
<span class="grey">Liu, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
When Group Compatibility Mode is IGMPv1, an LW-IGMPv3 router
internally translates the following IGMPv1 and IGMPv2 messages for
that group to their LW-IGMPv3 equivalents:
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v1 Report TO_EX({})
v2 Report TO_EX({})
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Interoperation with MLDv1</span>
LW-MLDv2 hosts and routers MUST interoperate with hosts and routers
running MLDv1. The method is the same as described in <a href="#section-6.2">Section 6.2</a>.
The difference is that when an LW-MLDv2 router has a MLDv1 listener
on its network, it translates the following MLDv1 messages to their
LW-MLDv2 equivalents:
MLDv1 Message LW-MLDv2 Equivalent
------------- -------------------
Report TO_EX({})
Done TO_IN({})
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Implementation Considerations</span>
The lightweight protocols require no additional procedure for the
implementation of the related protocols or systems, e.g., IGMP/MLD
snooping, multicast routing protocol, and operation of application
sockets, while the processing loads on the switches and routers that
run IGMPv3/MLDv2 (snooping) and multicast routing protocols may be
greatly decreased.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Implementation of Source-Specific Multicast</span>
[<a id="ref-8">8</a>] specifies the requirements for the implementation of Source-
Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The
lightweight protocol follows the same rules as given in [<a href="#ref-8" title=""Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast"">8</a>] except
for the change of the message types due to the simplification.
An LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e.,
TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for applications whose
multicast addresses are in the SSM address range. An upstream LW-
IGMPv3/LW-MLDv2 router MUST NOT establish forwarding state and MAY
log an error on reception of them as described in [<a href="#ref-7" title=""Source-Specific Multicast for IP"">7</a>].
<span class="grey">Liu, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Implementation of Multicast Source Filter (MSF) APIs</span>
[<a id="ref-9">9</a>] defines the following Multicast Source Filter (MSF) APIs: (1)
IPv4 Basic MSF APIs, (2) IPv4 Advanced MSF APIs, (3) Protocol-
Independent Basic MSF APIs, and (4) Protocol-Independent Advanced MSF
APIs.
According to the MSF API definition, an LW-IGMPv3 host should
implement either the IPv4 Basic MSF API or the Protocol-Independent
Basic MSF API, and an LW-MLDv2 host should implement the Protocol-
Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and
Protocol-Independent Advanced MSF API, are optional to implement in
an LW-IGMPv3/LW-MLDv2 host.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The security considerations are the same as that of the full version
of IGMPv3/MLDv2.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors would like to thank MBONED and MAGMA working group
members. Special thanks is given to Marshall Eubanks, Guo Feng, Mark
Fine, Alfred Hoenes, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang
Wendong, and Gong Xiangyang for their valuable suggestions and
comments on this document.
<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-1">1</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-2">2</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-3">3</a>] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", <a href="./rfc3810">RFC 3810</a>, June 2004.
[<a id="ref-4">4</a>] Deering, S., "Host extensions for IP multicasting", STD 5,
<a href="./rfc1112">RFC 1112</a>, August 1989.
[<a id="ref-5">5</a>] Fenner, W., "Internet Group Management Protocol, Version 2",
<a href="./rfc2236">RFC 2236</a>, November 1997.
<span class="grey">Liu, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5790">RFC 5790</a> Lightweight IGMPv3 and MLDv2 February 2010</span>
[<a id="ref-6">6</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-7">7</a>] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
<a href="./rfc4607">RFC 4607</a>, August 2006.
[<a id="ref-8">8</a>] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast Listener
Discovery Protocol Version 2 (MLDv2) for Source-Specific
Multicast", <a href="./rfc4604">RFC 4604</a>, August 2006.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-9">9</a>] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", <a href="./rfc3678">RFC 3678</a>,
January 2004.
Authors' Addresses
Hui Liu
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
EMail: Liuhui47967@huawei.com
Wei Cao
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
EMail: caowayne@huawei.com
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
EMail: asaeda@wide.ad.jp
Liu, et al. Standards Track [Page 17]
</pre>
|
