--- 1/draft-ietf-mboned-lightweight-igmpv3-mldv2-00.txt 2007-07-03 17:12:08.000000000 +0200 +++ 2/draft-ietf-mboned-lightweight-igmpv3-mldv2-01.txt 2007-07-03 17:12:08.000000000 +0200 @@ -1,493 +1,489 @@ MBONED Working Group H. Liu Internet-Draft W. Cao -Expires: June, 2007 Huawei Technologies Co., Ltd. +Expires: December 31, 2007 Huawei Technologies Co., Ltd. H. Asaeda Keio University - December 19, 2006 + June 29, 2007 Lightweight IGMPv3 and MLDv2 Protocols - + draft-ietf-mboned-lightweight-igmpv3-mldv2-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft - Shadow Directories can be accessed at http://www.ietf.org/shadow.html + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on December 31, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). 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. Conventions used in this document 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 RFC 2119 - [KEYWORDS]. + this document are to be interpreted as described in RFC 2119 [1]. Table of Contents - 1. Introduction ................................................... 2 - 2. Simplification Method Overview ................................. 4 - 2.1. Behavior of Group Members ................................. 4 - 2.2. Behavior of Multicast Routers ............................. 4 - 3. LW-IGMPv3 Protocol for Group Members ........................... 5 - 3.1. Action on Change of Interface State ....................... 5 - 3.2. Action on Reception of a Query ............................ 6 - 3.3. Applicable Group Record Types ............................. 7 - 4. LW-IGMPv3 Protocol for Multicast Routers ....................... 8 - 4.1. Group Timers and Source Timers - in the Lightweight Version ................................ 8 - 4.2. Source-Specific Forwarding Rules .......................... 9 - 4.3. Reception of Current-State Records ....................... 10 - 4.4. Reception of Source-List-Change and - Filter-Mode-Change Records ............................... 11 - 5. Interoperability .............................................. 12 - 5.1. Interoperation with the Full Version of IGMPv3 ........... 12 - 5.2. Interoperation with IGMPv1/IGMPv2 ........................ 13 - 5.2.1. Behavior of Group Members ........................... 13 - 5.2.2. Behavior of Multicast Routers ....................... 13 - 6. Implementation Considerations ................................. 13 - 6.1. Implementation of Source-Specific Multicast .............. 14 - 6.2. Implementation of Multicast Source Filter (MSF) APIs ..... 14 - 7. Security Considerations ....................................... 14 - 8. Normative References .......................................... 14 - 9. Informative References ........................................ 15 - Intellectual Property Statement .................................. 16 - Disclaimer of Validity ........................................... 16 - Copyright Statement .............................................. 16 - Acknowledgment ................................................... 16 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Simplification Method Overview . . . . . . . . . . . . . . . . 6 + 2.1. Behavior of Group Members . . . . . . . . . . . . . . . . 6 + 2.2. Behavior of Multicast Routers . . . . . . . . . . . . . . 6 + 3. LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . . 8 + 3.1. Action on Change of Interface State . . . . . . . . . . . 8 + 3.2. Action on Reception of a Query . . . . . . . . . . . . . . 9 + 3.3. Applicable Group Record Types . . . . . . . . . . . . . . 10 + 4. LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12 + 4.1. Group Timers and Source Timers in the Lightweight + Version . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. Source-Specific Forwarding Rules . . . . . . . . . . . . . 13 + 4.3. Reception of Current-State Records . . . . . . . . . . . . 13 + 4.4. Reception of Source-List-Change and Filter-Mode-Change + Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Interoperation with the Full Version of IGMPv3 . . . . . . 16 + 5.2. Interoperation with IGMPv1/IGMPv2 . . . . . . . . . . . . 16 + 5.2.1. Behavior of Group Members . . . . . . . . . . . . . . 16 + 5.2.2. Behavior of Multicast Routers . . . . . . . . . . . . 17 + 6. Implementation Considerations . . . . . . . . . . . . . . . . 18 + 6.1. Implementation of Source-Specific Multicast . . . . . . . 18 + 6.2. Implementation of Multicast Source Filter (MSF) APIs . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . . . 22 1. Introduction - IGMP version 3 [IGMPv3] and MLD version 2 [MLDv2] implement source - filtering capability that is not suported by their earlier versions - IGMPv2 [IGMPv2] and MLDv1 [MLDv1]. An IGMPv3 or MLDv2 capable host - can tell which group it would like to join to its upstream router - with specifying which sources it does or does not intend to receive + IGMP version 3 [2] and MLD version 2 [3] implement source filtering + capabilities that are not suported by their earlier versions, IGMPv1 + [4], IGMPv2 [5] and MLDv1 [6]. 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 also learn which sources are of interest to neighboring systems, for packets sent to any particular multicast address. - The filter-modes are defined for the host and router parts of the - protocols respectively to support the source filtering function. If - a receiver 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 the report with - filter-mode set to EXCLUDE. A source list for the given sources - shall be included in the report message. + The 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 timer and source timer are used to - maintain forwarding state of desired group and source. A multicast - router decides its filter-mode, type, and value of the timers and - forwarding methods according to the specific rules when a group - report message arrives or the timer expires. The router then has to - switch its filter-mode under certain conditions. With all above - factors correlating with each other, the determination rule becomes - relatively complex as the interface states could be frequently - changed. + 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 expressing ability of the - multicast receiver. It is useful to support Source-Specific - Multicast (SSM) [SSM] by specifying interesting source addresses with - INCLUDE mode. However, practical applications do not use EXCLUDE - mode to block sources so often, because a user or application usually - wants to specify desired source addresses, not undesired source - addresses to not receive from them. Even if a user wants to - explicitly refuse traffic from some sources in a group, when other - users in the same shared network have interest in these sources, the - corresponding multicast traffic is forwarded to the network after - all. + The multicast filter-mode improves the ability of the multicast + receiver to express its desires. It is useful to support Source- + Specific Multicast (SSM) [7] 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 wants to explicitly + refuse 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 is forwarded to the network. - This document aims to propose the simplified IGMPv3 and MLDv2, being - named Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW- - MLDv2), in which EXCLUDE filter-mode that supports to exclude data - come from specified sources is eliminated. Not only LW-IGMPv3 and - LW-MLDv2 are compatible with the standard IGMPv3 and MLDv2, but also + This document proposes simplified versions of IGMPv3 and MLDv2, named + Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2), + in which EXCLUDE filter-mode is eliminated. Not only are LW-IGMPv3 + and LW-MLDv2 compatible with the standard IGMPv3 and MLDv2, but also the protocol operations made by data receiver hosts and routers or switches (performing IGMPv3/MLDv2 snooping) are simplified in the - lightweight protocol and complicated operations are hence effectively - reduced. Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the - full version of these protocols (i.e. the standard 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. + lightweight protocol, and complicated operations are hence + effectively reduced. Since LW-IGMPv3 and LW-MLDv2 are fully + compatible with the full version of these protocols (i.e., the + standard 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. 2. Simplification Method Overview The principle is to simplify the host and router parts as much as - possible to improve efficiency, while guaranteeing the - interoperability with the full versions, and introducing no side - effects on the applications. + possible to improve efficiency, while guaranteeing interoperability + with the full versions, and introducing no side effects on + applications. - For convenience, this document mainly discusses IGMPv3 since MLDv2 - inherits the same source filtering mechanism, but additionally shows - MLDv2's unique specifications when needed. + 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. 2.1. Behavior of Group Members - In the LW-IGMPv3, the same service interface model as that of IGMPv3 - is inherited: + In LW-IGMPv3, the same service interface model as that of IGMPv3 is + inherited: IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list ) In the lightweight protocol, EXCLUDE mode on the host part is - preserved only for EXCLUDE (*,G) join, which denotes non-source- + preserved only for EXCLUDE (*,G) join, which denotes a non-source- specific group report (as known as (*,G) join) and is equivalent to the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The - detailed host operation of LW-IGMPv3/LW-MLDv2 is described in section - 3. + detailed host operation of LW-IGMPv3/LW-MLDv2 is described in + Section 4. 2.2. Behavior of Multicast Routers - According to [IGMPv3], router filter-mode is defined to optimize the - state description of a group. 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. Group - timer is used to identify such transition. + Router filter-mode is defined to optimize the state description of a + group [2]. 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. Group timer is used to + identify such transition. - In LW-IGMPv3, member reports carry mainly the INCLUDE mode - information with only one exception for EXCLUDE (*,G), which means - including all sources and can also be interpreted as INCLUDE mode. - Without EXCLUDE mode report information, it is unnecessary for the - router to maintain the EXCLUDE filter-mode, and the state model for - multicast router can be simplified as: + In LW-IGMPv3, hosts primarily send INCLUDE requests. The only + exception is EXLUDE (*,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 + router can be simplified as: (multicast address, group timer, (source records)) - Here group timer is kept to represent (*,G) group join. Its basic + + Here a group timer is kept to represent (*,G) group join. Its basic behavior is: when a router receives a (*,G) group join, it will set - its group timer, and the source list for the source-specific group - will be kept. As the group timer expires, the router may change to - the reception for the listed sources. + its group timer and keep the source list for sources specified in the + source records. When the group timer expires, the router may change + to the reception for the listed sources. The definition of the + source record is the same as that of full version. The elimination of the filter-mode will greatly simplify the router behavior, e.g. the action on reception of reports and the setting of the timers. The detailed operation of router operation is described - in section 4. + in Section 4. 3. LW-IGMPv3 Protocol for Group Members LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages, being the same as the full version protocols. Although most of these message types and corresponding group records are inherited from the full version protocols, an operation that triggers EXCLUDE (S,G) join is omitted and the corresponding record types of the Report are modified on the lightweight protocols. There are three Group Record Types defined in the full IGMPv3: Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN) or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or BLOCK_OLD_SOURCES (BLOCK). 3.1. Action on Change of Interface State - When an interface state 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. + 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 are the same as the full version for the computation, in the 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 section 3.3): + (Group Record Types are described in Section 3.3): Old State New State State-Change Record Sent ----------- ----------- ------------------------ INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B) - INCLUDE (A) EXCLUDE () IS_EX() - INCLUDE () EXCLUDE () IS_EX() + INCLUDE (A) EXCLUDE () TO_EX() + + INCLUDE () EXCLUDE () TO_EX() EXCLUDE () INCLUDE (B) TO_IN(B) 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 - [IGMPv3, MLDv2].) + [2][3].) In the full version of IGMPv3, as was done with the first report, the interface state for the affected group before and after the latest change is compared, and the report records expressing the difference are built and merged with the contents of the pending report, to - create the new State-Change report. However, it is optional that a - LW-IGMPv3 host merges with the contents of the pending report. If - the LW-IGMPv3 host does not merge with the contents of the pending - report, it transmits each report sequentially. Doing so can greatly - simplified the operation for scheduling the reports. + create the new State-Change report. However, for the LW-IGMPv3 host, + this merge operation is optional. If the LW-IGMPv3 host does not + merge with the contents of the pending report, it transmits each + report sequentially. Doing so can greatly simplified the operation + for scheduling the reports. 3.2. Action on Reception of a Query 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 [IGMPv3, MLDv2]. 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 + Code in the received Query message [2][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 most of the rules that are used to determine if a - Report needs to be scheduled from the full version. The different - point is regarding the simplification of EXCLUDE filter-mode and the - type of Report to schedule as detailed in section 3.3. + Report needs to be scheduled from the full version. The difference + is regarding the simplification of EXCLUDE filter-mode and the type + of Report to schedule as detailed in Section 3.3. While it is optional that a LW-IGMPv3 host merges with the contents - of the pending report for unsolicited report (i.e. State-Change + of the pending report for unsolicited report (i.e., State-Change report) as mentioned in the previous section, if the received Query is a Group-and-Source-Specific Query and there is a pending response for this group with a non-empty source-list, then the group source list is augmented to contain the list of sources in the new Query and a single response is scheduled using the group timer as with the full version host. The new response is then scheduled to be sent at the - earliest of the remaining time for the pending report and the - selected delay. + earlier of the remaining time for the pending report and the selected + delay. 3.3. Applicable Group Record Types Among 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 with a record having null source address list. All of the record types of report messages used by the full and lightweight version protocols are shown as follows: IGMPv3 LW-IGMPv3 Comments -------- --------- ------------------------------------- - IS_EX() IS_EX() Query response for (*,G) join + 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() IS_EX() (*,G) join + TO_EX() TO_EX() (*,G) join - where "x" represents non-null source address list and "()" represents - null source address list. For instance, IS_EX() means a report whose - record type is IS_EX with null source address list. "N/A" represents - not applicable (or no use) because the corresponding operation should - not occur in the lightweight version protocols. + where "x" represents a non-null source address list and "()" + represents null source address list. For instance, IS_EX() means a + report whose record type is IS_EX with 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 non-null source - address list. And a multicast router creates the same state when it - receives a report message containing either of IS_EX or TO_EX record - types. Therefore, LW-IGMPv3 integrates the TO_EX operation to the - IS_EX operation. + 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 a LW-IGMPv3 host needs to make a query response for the state of - INCLUDE (x,G) join, the host makes the response whose message type is - expressed with ALLOW(x), instead of using IS_IN record type, for - router's processing of the two messages are completely the same, the - IS_IN(x) type is eliminated for simplification. + 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 completely + same, the IS_IN(x) type is eliminated for simplification. A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is - used with the following situation: the host firstly launches an - application (AP1) that requests INCLUDE (x,G) join, and it sends - ALLOW(x). Then the host launches another application (AP2) that - joins (*,G), and it sends IS_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. + used 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. 4. LW-IGMPv3 Protocol for Multicast Routers The major difference between the full and lightweight version - protocol on the router is that filter-mode is discarded for the - lightweight version, as section 2.2 mentioned. Then the IGMP state - maintained by the router for each attached network can be simplified - as: - - (multicast address, group timer, (source records)) - - where the source record includes pairs of source address and its - corresponding source timer. In this model, the filter-mode is - omitted and the meaning of the group timer is redefined to implement - simplified processing. + protocols on the router part is that for 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. 4.1. Group Timers and Source Timers in the Lightweight Version - The source timer is kept for each source record and it is updated - when the source is present in a received report. It indicates the + 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 sources and needs to be referred when the router takes its forwarding decision. - The group timer being used in the full version of IGMPv3 as a - mechanism for transitioning the router's filter-mode from EXCLUDE to - INCLUDE, is now redefined for the identification of the non-source- - specific receiving states, i.e., (*,G)join. Once a group record of - IS_EX() is received, the group timer is used to represent this (*,G) - group join. The expiration of the group timer indicates that there - are no 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 for those - sources. The role of the group timer can be summarized as follows: + The group timer being used in the full version of IGMPv3 for + transitioning the router's filter-mode from EXCLUDE to INCLUDE, is + now redefined to identify the non-source-specific receiving states + maintaining for (*,G) join. Once a group record of IS_EX() is + received, the group timer is used to represent this (*,G) group join. + The expiration of the group timer indicates that there are no + listeners on the attached network for this (*,G) group. If there are + unexpired sources (whose source timers are greater than zero), the + router will change to receiving traffic for those sources. 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. The operation related to the group and source timers has some difference compared with 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. They are kept 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. + 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. 4.2. Source-Specific Forwarding Rules - A multicast router needs to consult IGMPv3 state information when it - makes decisions on forwarding a datagram from a source to its - attached network. In the full IGMPv3, the router filter-mode and - source timer are taken as the necessary judging conditions. 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 can - be summarized as follows: + A full version multicast router needs to consult IGMPv3 state + information when it makes decisions on forwarding a datagram from a + source or its upstream router to its attached network, 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 to forward + G_Timer == 0 S_TIMER > 0 Suggest forwarding traffic from source - G_Timer == 0 S_TIMER == 0 Suggest to stop + 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 to forward traffic from the source - G_Timer > 0 S_TIMER >= 0 Suggest to forward + G_Timer > 0 S_TIMER >= 0 Suggest forwarding traffic from source - G_Timer > 0 No Source Elements Suggest to forward + G_Timer > 0 No Source Elements Suggest forwarding traffic from source 4.3. Reception of Current-State Records 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 (G_Timer==0), the source - list includes sources to be forwarded by the router, while in non- - source-specific group reception (G_Timer>0) the source list remembers - the sources to be forwarded after toggling to source-specific - reception state. + For source-specific group reception state (when G_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. - The following table describes the action taken by a multicast router - after receiving Current-State Records. The notations have the same - meaning as that in the full IGMPv3. + Although the Lightweight host only sends a subset of the message of + that of the full version, the LW-router should be able to process as + much messages as possible to be compatible with the full version + host. The following table describes the action taken by a multicast + router after receiving Current-State Records. The notations have the + same meaning as that 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 - And the above table could be further simplified for the processes - that are completely same for the two values of the G_Timer: + The above table could be further simplified for the processes that + are completely 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 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 with - GMI group timer value and keeps the previous source list without - modification. + report, the router sets the non-source-specific receiving states by + resetting the group timer value and keeps the previous source list + without modification. 4.4. Reception of Source-List-Change and Filter-Mode-Change Records 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. The table below describes the state change and the actions that should be taken. @@ -510,51 +506,55 @@ G_Timer > 0 A TO_IN(B) A+B (B)=GMI SendQ(G,A-B) Send Q(G) The table could be further simplified by merging duplicate lines: 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) + In this table, TO_EX() report is not included because the processing + is exactly the same as that of IS_EX(), as described in the previous + section. Section 5.1 gives the lightweight routers's transformation + behavior between the two messages. + 5. Interoperability LW-IGMPv3/LW-MLDv2 hosts and routers should interoperate gracefully - with the full version protocols [IGMPv3, MLDv2]. Also, LW-IGMPv3/LW- - MLDv2 hosts and routers should interoperate gracefully with hosts and + with the full version protocols [2][3]. Also, LW-IGMPv3/LW-MLDv2 + hosts and routers should interoperate gracefully with hosts and routers running IGMPv1/v2 or MLDv1. 5.1. Interoperation with the Full Version of IGMPv3 - Eliminating EXCLUDE filter-mode from the full version protocols - simplifies the processes inside the host and router. On the other - hand, LW-IGMPv3 does not introduce any change on the message format - of the group query and report messages the full version protocols - use. Therefore, the group member 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. + LW-IGMPv3 does not introduce any change on the message format of the + group query and report messages the full version protocols use. With + the elimination of the EXLCLUDE filter mode, the LW-IGMPv3 group + member 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. - A LW-IGMPv3 router translates IS_EX(x) and TO_EX(x) records that are - used with the full IGMPv3 but not used with LW-IGMPv3. When a LW- - IGMPv3 router receives these report messages from the full version - host, it translates them to IS_EX() records and makes the - corresponding behavior. All possible record types are compared as - follows: + A LW-IGMPv3 router does not process directly IS_EX(x) and TO_EX(x) + records that are used by the full IGMPv3. When a LW-IGMPv3 router + receives these report messages from the full version host, it + translates them to IS_EX() records and behaves accordingly. All + possible record types are compared as follows: IGMPv3 Report LW-IGMPv3 Equivalent ------------- -------------------- IS_IN(x) IS_IN(x) IS_EX(x) IS_EX() TO_IN(x) TO_IN(x) @@ -570,189 +570,207 @@ Compatibility Mode and keeps Querier Present timers for IGMPv1 and IGMPv2. Their definition and processing is the same as that of IGMPv3. 5.2.1. Behavior of Group Members A host's compatibility mode is determined from the Host Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. The Host Compatibility Mode of an interface is set to IGMPv2 and IGMPv2 Querier Present is set to Older Version Querier Present - Timeout second (defined in [IGMPv3]) whenever an IGMPv2 General Query - is received on that interface. The Host Compatibility Mode of an + Timeout second (defined in [2]) whenever an IGMPv2 General Query is + received on that interface. The Host Compatibility Mode of an interface is set to IGMPv1 and IGMPv1 Querier Present is set to Older Version Querier Present Timeout second whenever an IGMPv1 Membership Query is received on that interface. Based on the Host Compatibility Mode variable, a host acts using the IGMPv3, IGMPv2, or IGMPv1 - protocol on that interface + protocol on that interface. - While above manner is inherited from the definition of [IGMPv3], LW- - IGMPv3 may enable to configure the Host Compatibility Mode variable - by other means: when a LW-IGMPv3 host is placed on a link where there - are IGMPv1/IGMPv2 hosts, a host may allow its IGMPv3 report message - to be suppressed by an IGMPv1 or IGMPv2 report message. + While above manner is inherited from the definition of [2], LW-IGMPv3 + may enable to configure the Host Compatibility Mode variable by other + means: when a LW-IGMPv3 host is placed on a link where there are + IGMPv1/IGMPv2 hosts, a host may allow its IGMPv3 report message to be + suppressed by an IGMPv1 or IGMPv2 report message. 5.2.2. Behavior of Multicast Routers + If a LW-IGMPv3 router is on a network where at least one router + running IGMPv1 or IGMPv2 protocols, it is required that the lowest + version of querier must be used. This can be administratively + assured by supporting IGMPv1, IGMPv2 or IGMPv3 compatibility mode. + + An LW-IGMPv3 router may be placed on a network where there are hosts + that have not been upgraded to IGMPv3. In order to be compatible + with the older version, the lightweight router should keep a Group + compatibility mode for each group record, and IGMPv1 and IGMPv2 Host + present timers are kept to switch gracefully between different + versions of IGMP. + When Group Compatibility mode is IGMPv2 or IGMPv1, a LW-IGMPv3 router translates the following IGMPv2 or IGMPv1 messages for that group to - their IGMPv2 or IGMPv1 equivalents: + their LW-IGMPv3 equivalents: IGMP Message LW-IGMPv3 Equivalent ------------- -------------------- v1 Report IS_EX() v2 Report IS_EX() v2 Leave TO_IN() 6. Implementation Considerations - The lightweight protocols requires no additional burden on the + The lightweight protocols requires no additional procedure on 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 - running IGMPv3 (snooping) and multicast routing protocols could be + running IGMPv3 (snooping) and multicast routing protocols may be greatly decreased. - In the following sections, the implementation related topics are + In the following sections, the implementation related aspects are described for the lightweight version protocols. 6.1. Implementation of Source-Specific Multicast - [IGMP-SSM] illustrates the requirements of implementation of Source- - Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The - lightweight protocol does not impose any bad influences on an SSM - application. The requirements of LW-IGMPv3/LW-MLDv2 for supporting - SSM are illustrated below. + [8] illustrates the requirements of implementation of Source-Specific + Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight + protocol does not impose any bad influences on an SSM application. + The requirements of LW-IGMPv3/LW-MLDv2 for supporting SSM are + illustrated below. A LW-IGMPv3/LW-MLDv2 host should not send a non-source-specific join, - i.e. IS_EX(), and IGMPv2 Leave and MLDv1 Done messages for the + i.e., IS_EX(), and IGMPv2 Leave and MLDv1 Done messages for the application whose multicast address is in the SSM address range. The reception of a non-source-specific join with an SSM group address should indicate an error to the application. The SSM-aware router will ignore IS_EX() reports with SSM addresses. Other types of Reports should be processed normally. 6.2. Implementation of Multicast Source Filter (MSF) APIs - Multicast Source Filter (MSF) APIs [MSF] defines (1) IPv4 Basic MSF + Multicast Source Filter (MSF) APIs [9] defines (1) IPv4 Basic MSF API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF API, and (4) Protocol-Independent Advanced MSF API. According to the MSF APIs definition, a LW-IGMPv3 host should implement at least one of IPv4 Basic MSF API and Protocol-Independent Basic MSF API, and a LW-MLDv2 host should implement Protocol- Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent Advanced MSF API, are optional to implement in LW-IGMPv3/LW-MLDv2 host. 7. Security Considerations - The security consideration is the same as that of the full version of - IGMPv3/MLDv2. + The security considerations are the same as that of the full version + of IGMPv3/MLDv2. -8 Normative References +8. References - [KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate - requirement levels," RFC 2119, March 1997. +8.1. Normative References - [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and - Thyagarajan, A., "Internet Group Management Protocol, Version3," + [1] Bradner, S., "Key words for use in RFCs to indicate requirement + levels", RFC 2119, March 1997. + + [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. - [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version - 2 (MLDv2) for IPv6," RFC 3810, June 2004. + [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 + (MLDv2) for IPv6", RFC 3810, June 2004. -9 Informative References + [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, + August 1989. - [SSM] Holbrook, H. and Cain, B., "Source-Specific Multicast for IP," - RFC 4607, August 2006. + [5] Fenner, W., "Internet Group Management Protocol, Version 2", + RFC 2373, July 1997. - [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," - RFC 2236, November 1997. + [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener + Discovery (MLD) for IPv6", RFC 2710, October 1999. - [MLDv1] Deering, S., Fenner, W., and Haberman, B., "Multicast - Listener Discovery (MLD) for IPv6," RFC 2710, October 1999. + [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", + RFC 4607, August 2006. - [IGMP-SSM] Holbrook, H., Cain, B., and Haberman, B., "Using Internet - Group Management Protocol Version 3 (IGMPv3) and Multicast - Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific - Multicast," RFC 4604, August 2006. + [8] 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", RFC 4604, August 2006. - [MSF] Thaler, D., Fenner, B., and Quinn, B., "Socket Interface - Extensions for Multicast Source Filters," RFC 3678, January 2004. +8.2. Informative References -Author's Addressess + [9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface + Extensions for Multicast Source Filters", RFC 3678, + 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, + 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, + Huawei Bld., No.3 Xinxi Rd. + Shang-Di Information Industry Base + Hai-Dian Distinct, Beijing 100085 China Email: caowayne@huawei.com + Hitoshi Asaeda - Graduate School of Media and Governance Keio University - 5322 Endo, Fujisawa, Kanagawa 252-8520, + Graduate School of Media and Governance + 5322 Endo + Fujisawa, Kanagawa 252-8520 Japan Email: asaeda@wide.ad.jp -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf - ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. Acknowledgment - The author would like to thank magma and mboned mailing lists for - discussion and contribution for the ideas. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).