Network Working Group Feng Guo Internet Draft Huawei Technologies Co., Ltd. Expires: December 2007 June 28, 2007 Multicast Forwarding Equivalence Class [MFEC] draft-guo-mboned-mfec-framework-00.txt 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 Abstract At present, the multimedia services such as IPTV are gaining importance. Multicast technologies play an inevitable role in these multimedia services. The main factors affecting the multicast technologies are the convergence speed and the capacity of the multicast routing table. One of the easiest and the most commonly practiced methods in nowadays multicast deployment is to push the data to the end router by static configurations (igmp static group). This will reduce the delay in channel switching. The data flow of multiple channels from Guo Expires December 28, 2007 [Page 1] Internet-Draft Multicast Forwarding Equivalence Class June 2007 one or several servers are transmitted along the distribution tree. The distribution tree for multiple channels may be composed of only one same distribution tree. A router, however, maintains separate protocol-status and provides separate protocol-packets content for each channel. This prolongs the route convergence, increases the status-space and reduces the exchange rate of protocol-packets. This document proposes a solution to speed up the route convergence, reduce the states in the multicast forwarding table and increase the exchange rate of packets. This can be achieved by using the same state for the data flows that passes the same path in the distribution tree. This same state is called Multicast Forwarding Equivalent Class (MFEC). In other words, MFEC is a group of multicast packets that are forwarded over the same path with the same traffic handling treatment. This solution extends various multicast protocols such as PIM- SSM, PIM-SM, Bidir-PIM, PIM-DM and DVMRP, and perfects application of multicast. 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 . Table of Contents 1. Introduction................................................3 1.1. Background.............................................3 1.2. Purpose................................................3 2. Definitions and Abbreviations...............................4 3. Framework for MFEC..........................................4 3.1. MFEC defining..........................................5 3.2. Principles of MFEC.....................................6 3.2.1. Dynamic MFEC Principle............................6 3.2.2. Static MFEC Principle.............................7 3.3. Procedure of Application...............................7 4. Security Considerations....................................10 5. IANA Considerations........................................10 6. Acknowledgments............................................10 7. References.................................................10 7.1. Normative References..................................10 7.2. Informative References................................10 Author's Addresses............................................11 Intellectual Property Statement...............................11 Disclaimer of Validity........................................11 Guo Expires December 28, 2007 [Page 2] Internet-Draft Multicast Forwarding Equivalence Class June 2007 Copyright Statement...........................................11 1. Introduction 1.1. Background The current multicast routing protocols, such as PIM-SSM, PIM-SM, Bidir-PIM, PIM-DM and DVMRP, take (S/*, G) as the minimum unit. Even though the data flow of multiple channels is transmitted along the same path in the distribution tree, it is maintained by a router as different (S/*, G)s. These different (S/*, G)s are expressed by different segments of protocol-packets. But in actual application some bundles of multicast sources and groups are normally centralized to deploy, and most of multicast traffic have to share the same path in the distribution tree. The router maintains many (S/*, G)s and each (S/*, G) corresponds to a distribution tree. This prolongs the route convergence and reduces the efficiency for packet generation and exchange , and also may occupy too much memory under general conditions. Moreover, the terminal device needs to notify the router about the address pair (source address and group address) of the interested program. This requires the router to create and maintain a (S/*, G) for each address pair. As a result, the router can be easily attacked by the terminal device(if the environment is unsecured). In the existing multicast deployments like IPTV we try to push all of the programs to the edge-network by configuring igmp static join, or at least push to the end of core network. Here the core or the intermediate routers are also burdened with the entire multicast (S/*, G) states. 1.2. Purpose The purpose of this memo is to provide a generalized framework for merging these redundant states. Thus we can reduce the state information and maintenance cost in the core or intermediate routers. By reducing the state information we can also increase the state scalability of the multicast and prevent it from easy attacks. This framework can also be a basis for future work to enhance multicast expansibility and stability. Guo Expires December 28, 2007 [Page 3] Internet-Draft Multicast Forwarding Equivalence Class June 2007 The scope of this document is not to propose a detailed protocol instead we propose the idea of MFEC at an abstract level. 2. Definitions and Abbreviations The document introduces the following definitions: Multicast Forwarding Equivalent Class (MFEC): is a set of multicast data packets that are forwarded in the same way, for example, a set of the data packets that pass the same multicast distribution tree or sub-tree and receive the same forwarding processing. By forwarding processing also includes QoS treatment. MFEC distribution tree: is the distribution tree that the MFEC passes. It may be a traditional multicast distribution tree that takes the source or RP as the root and takes receivers as leaves, a sub-tree or a branch. Egress router of MFEC distribution tree: is the leaf router of the MFEC distribution tree. It is called Egress router for short. Ingress router of MFEC distribution tree: is the root router of the MFEC distribution tree. It is called Ingress router for short. Transit router of MFEC distribution tree: is the router that exists between the root router and the leaf router of the MFEC distribution tree. It is called Transit router for short. Abbreviations: PIM Protocol Independent Multicast PIM SM Protocol Independent Multicasts Sparse Mode PIM SSM Protocol Independent Multicast Source-Specific Multicast MLD Multicast Listener Discovery IGMP Internet Group Management Protocol (S/*, G) (S, G) or (*, G) state as defined in PIM MFIB Multicast Forwarding Information Base 3. Framework for MFEC The basic idea for MFEC is to make data flow that passes the same distribution tree or sub-tree to use the same status. This speeds up route convergence and reduces space occupation. Moreover, the protocol state machine and protocol packets take MFEC rather than (S, G) or (*, G) as the minimum unit. This improves the processing Guo Expires December 28, 2007 [Page 4] Internet-Draft Multicast Forwarding Equivalence Class June 2007 efficiency of the state machine and the exchange rate of protocol- packets. The multicast based on MFEC can be applied to general multicast network or VPN network. A general high-level framework can be represented as follows. +-------+ +-------+ --------- +-------+ +-------+ |Server |--|Ingress|<===>/ MFEC \<===>|Egress |--|Host | | | |Router | \ NETWORK / |Router | | | +-------+ +-------+ --------- +-------+ +-------+ Figure 1.Basic Model of a MFEC network Take the application of Multicast in IPTV as an example. As shown in Figure 1, multiple programs of different channels are sent by the same source (a server or multiple servers) to the router nearest to receivers. The multiple multicast data flows, therefore, are transmitted along the same path. The set of these data packets is considered as an MFEC. The protocol status and packet exchange takes MFEC as the minimum unit. 3.1. MFEC defining MFEC can either be defined explicitly or implicitly. The data that belongs to the same MFEC is forwarded by using the same forwarding entry and corresponds to the same MFEC status. Examples of MFEC are (source address, group address/mask), (source address/mask, group address), (source address/mask, group address/mask) etc. MFEC is divided into dynamic MFEC and static MFEC accordingly. They can be applied to multicast network or VPN network. Dynamic MFEC: refers to the MFEC distribution tree that is dynamically generated by the modified protocols. That is, MFEC status can be switched from (S/*, G) automatically. According to the MFEC mapping, once receiving IGMP/MLD Report or PIM join/prune packets, the routers switch the (S/*, G) status to MFEC status. The multicast distribution tree of MFEC is then established. Static MFEC: refers to the MFEC distribution tree formed by the statically configured MFEC routing entries or forwarding entries. The static MFEC can be used to directly guide the data forwarding. That Guo Expires December 28, 2007 [Page 5] Internet-Draft Multicast Forwarding Equivalence Class June 2007 is, the Egress router that runs IGMP/MLD can be statically configured to receive (S, G/M). MFEC routing entries or forwarding entries can be statically configured on routers to forward (S, G/M). Both the dynamic MFEC and the static MFEC can be used in combination. Some nodes in the network use the dynamic MFEC while other nodes use the static MFEC. 3.2. Principles of MFEC Following are the set of principles to be considered for MFEC. The state machine takes the MFEC instead of (S, G) or (*, G) as the minimum unit. For example, if the data of (S, G/M) belongs to an MFEC, the state machine is downstream per-interface (S, G/M). The "M" in the (S, G/M) indicates the mask. 3.2.1. Dynamic MFEC Principle The application of dynamic MFEC refers to MFEC status that is switched from (S/*, G). According to the MFEC mapping, once receiving IGMP/MLD Report or PIM packets, the routers switch the (S/*, G) status to MFEC status, or, Egress router that runs IGMP/MLD is statically configured to receive (S, G/M). The multicast distribution tree of MFEC is then established. Principles 1 to 4 are schemes for modifying existing multicast protocols. 1) Downstream per-interface (S, G/M) state machine: In the protocol- packets, MFEC is used to replace (S, G) or (*, G). If the data of (S, G/M) belongs to an MFEC, the G segment in (S, G) Join/Prune message is filled in with M. 2) Multicast routing table: MFEC is used to replace (S, G) or (*, G) in multicast routing table. If the data of (S, G/M) belongs to an MFEC, the routing entry is expressed as (S, G/M, GE1/0/1, {GE 2/0/0, GE 3/0/0}). 3) Multicast forwarding table: MFEC is used to replace (S, G) or (*, G) in multicast forwarding table. If the data of (S, G/M) belongs to an MFEC, the forwarding entry is expressed as (S, G/M, GE 1/0/1, {GE 2/0/0, GE 3/0/0}). Therefore the data forwarding is based on longest prefix match lookup table (multicast forwarding table). Guo Expires December 28, 2007 [Page 6] Internet-Draft Multicast Forwarding Equivalence Class June 2007 4) Mapping from (S/*, G) to MFEC: Ingress router defines the mapping from (S/*, G) to MFEC. If the data of (S, G) belongs to an MFEC, the multicast flow of (S, G) is mapped to the multicast flow of (S, G/M). When a router receives the data of (S, G), it directly creates the (S, G/M) status for the data. The mapping can be explicitly or implicitly defined, or implemented by the dynamic extension of protocols. Principle 5, 6 and 7 can be used separately or in combination as required. 5) Mapping of MFEC to (S/*, G): Egress router defines the mapping from MFEC to (S/*, G). If the data of (S, G/M) or (*, G/M) belongs to an MFEC, the (S, G) or (*, G) PIM Join/Prune messages or that of the IGMP/MLD Report messages is mapped from (S, G/M) or (*, G/M), and the (S, G/M) or (*, G/M) status is created. The mapping can be explicitly or implicitly defined, or implemented by the dynamic extension of protocols. 3.2.2. Static MFEC Principle The application of the static MFEC refers to the MFEC distribution tree formed by the statically configuring MFEC routing entries or forwarding entries. The static MFEC can be used to directly guide the data forwarding. Moreover, you can set an active incoming interface and a standby incoming interface for each MFEC status to enhance the robustness of the multicast forwarding. 6) Statically joining the MFEC distribution tree: Configure Egress router that runs IGMP/MLD to receive MFEC. The data of (S, G/M) or (*, G/M) belongs to the same MFEC, the router creates (S, G/M) or (*, G/M) status when configured to receive the data of (S, G/M) or (*, G/M). 7) Configure the status of the static MFEC to generate the multicast routing table and forwarding table: If (S, G/M) belongs to an MFEC, the routing entry and forwarding entry of static (S, G/M) can be directly configured. The same MFEC can import data flow to the same physical interface or tunnel interface (can be either multi-point tunnel or single-point tunnel) such as the MTI in multicast VPN. 8) Statically configured MFEC-based MROUTE and MFIB: The outgoing interface can be a tunnel (e.g. mvpn, p2mp) or a normal interface. 3.3. Procedure of Application To be understood clearly, the following is a detailed procedure for MFEC, taking PIM-SSM protocol with dynamic MFEC as example: Guo Expires December 28, 2007 [Page 7] Internet-Draft Multicast Forwarding Equivalence Class June 2007 The basic procedures are applicable to IP multicast, including IPv4 multicast and IPv6 multicast, and also most multicast protocols, such as the PIM-SM, PIM-DM, IGMP, and MLD etc. +------+ |Source| +------+ | |DATA (S,G/M) V +-----------------+ <-- +-----------------+ |INGRESS ROUTER | PIM JOIN |TRANSIT ROUTER | |6.Creates (S,G/M)| (S,G/M) |5.Creates (S,G/M)| |add outgoing |------------|with downstream |---------+ |interface | 7.DATA |interface | | +-----------------+ (S,G/M) +-----------------+ | --> | | | | +-------------+ <-- +----------------+ <-- | |HOST | DATA |EGRESS ROUTER | 8.DATA | |1.needs to | (S,G/M) |3.MFEC switches | (S,G/M) | |receive (S,G)|--------------|(S,G) to (S,G/M)|------------+ |information | 2.IGMPV3 | | 4.PIM JOIN +-------------+ IS_IN(S,G) +----------------+ (S,G/M) --> --> Figure 2. logistic procedure of PIM-SSM MFEC 1) Egress router and Ingress router define the mapping from (*, G) or (S, G) to (*, G/M) or (S, G/M) in advance (Static MFEC). 2) The receiver wants to receive the multicast flow of (S, G). 3) The receiver sends the IGMPv3/MLDv2 (S, G) Report message. 4) According to Principle 6, Egress router receives the IGMPv3/MLDv2 (S, G) and switches it to (S, G/M). Or, according to Principle 7, Egress router that runs IGMP/MLD is statically configured to receive (S, G/M). The outgoing interface is then added to (S, G/M). Establishment of PIM-SSM multicast distribution tree is triggered. Guo Expires December 28, 2007 [Page 8] Internet-Draft Multicast Forwarding Equivalence Class June 2007 5) According to Principle 1, Egress router calculates the state machine of (S, G/M) and sends PIM Join message of (S, G/M) to the source according to Principle 2. 6) The Transit router creates (S, G/M) status according to Principle 1, 3 and 4, adds the outgoing interface and then sends the PIM-Join message of (S, G/M) to the source according to Principle 2. 7) Ingress router creates (S, G/M) status according to Principle 1, 3 and 4 and adds the outgoing-interface. If no Layer 3 device exists between Ingress router and the multicast source, the data flow sent by the multicast source is forwarded in accordance with the MFEC status. If routers which do not support MFEC exist between the Ingress router and the multicast source, do as follows: (1) Configure the upstream router to forward data to Ingress router according to Principle 8. (2) According to Principle 5, configure Ingress router to switch MFEC to multiple (S, G)s based on the mapping and then to send PIM- Join message to the upstream router. 8) According to Principle 4, after the multicast source sends the data flow, Ingress router forwards the data based on the (S, G/M) status. 9) According to Principle 4, after receiving the multicast data flow, Transit router forwards the data to the downstream router based on the (S, G/M) status. Finally, the data is forwarded to the Egress router that forwards the data to the receiver. From above procedure, we can also observe the following significant points: The original protocols or implementations are described with (S/*, G) as the minimum unit and this document extends the minimum unit to MFEC. The improved protocol takes the MFEC as the minimum unit. The data that belongs to the same MFEC corresponds to the same protocol status and routing forwarding entry. Therefore, the running of a protocol is not for a single address pair (source address, group address) but for a set of multiple address pairs. Exchange of protocol packets is based on MFEC. So the number of protocol packets exchanged between MFEC enabled routers will be reduced. Guo Expires December 28, 2007 [Page 9] Internet-Draft Multicast Forwarding Equivalence Class June 2007 The data packets of the same MFEC are forwarded by the same multicast forwarding entry. Multicast protocol state machine and protocol-packets take MFEC instead of (S, G) or (*, G) as the minimum unit. The multicast routing table and forwarding table use MFEC to replace (*, G) or (S, G) status. The same MFEC can be imported to the same physical interface or tunnel interface (multi-point tunnel or one-point tunnel) such as Multicast Tunnel Interface (MTI) in multicast VPN. 4. Security Considerations MFEC do not have any added impact on the security issues. At the same MFEC is not adding any security improvements to the existing multicast protocols. But due to the reduced state information storage, the attack by the terminal devices on intermediate routers is reduced. 5. IANA Considerations This document has no IANA considerations. 6. Acknowledgments I would like to express special thanks to Muhammad Yaaseen and Liangru for their inputs to this work. 7. References 7.1. Normative References i Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. ii Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. iii P. Savola, R. Lehtonen, D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006. Guo Expires December 28, 2007 [Page 10] Internet-Draft Multicast Forwarding Equivalence Class June 2007 7.2. Informative References Author's Addresses Feng Guo Huawei Technologies Co., Ltd. No.3 Xinxi Rd. Shang-Di Information Industry Base, Beijing P.R.China Phone: 8610-82836841 Email: guofeng@huawei.com Intellectual Property Statement 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, 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. Guo Expires December 28, 2007 [Page 11] Internet-Draft Multicast Forwarding Equivalence Class June 2007 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. Guo Expires December 28, 2007 [Page 12]