Network working group H. Liu Internet Draft L. Zheng Category: Standard Track T. Bai Created: October 18, 2010 Y. Yu Expires: April 2011 Huawei Technologies. Single Stream Multicast Fast ReRoute (SMFRR) Method draft-liu-pim-single-stream-multicast-frr-01 Abstract This document proposes an IP multicast fast reroute method based on differentiating primary and backup PIM join. The multicast stream is only sent along one of the multicast primary and backup path, which enables the efficient multicast delivery under both normal and abnormal conditions. 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. 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. Liu,et al Expires April 18, 2011 [Page 1] Internet-Draft Single Stream Multicast FRR October 2010 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 This Internet-Draft will expire on August 15, 2009. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction.................................................3 2. Principle of Single Stream Solution..........................3 2.1. Primary and Backup Path Setup...........................3 2.2. Fault Processing........................................4 2.3. Fault Recovery..........................................4 3. The Definition of packet format..............................5 3.1. Multicast FRR join Attribute............................5 3.2. PIM multicast FRR Hello Options.........................5 4. Single Stream Implementation Options.........................6 4.1. Disabling all nodes on backup path......................6 4.2. Disabling only root node on backup path.................8 5. Security Considerations......................................8 6. References...................................................8 6.1. Normative References....................................8 Authors' Addresses..............................................9 Liu.,et al Expires April 18, 2011 [Page 2] Internet-Draft Single Stream Multicast FRR October 2010 1. Introduction This document proposes an IP multicast fast reroute method based on differentiating primary and backup PIM join, which is called Single Stream multicast FRR. In this method, two multicast forwarding paths are established respectively by PIM primary join and backup join. Under normal conditions, only primary path is used to make the multicast data delivery. If the node or link on the primary path fails, the multicast data forwarding is switched to the backup path. Because either primary or backup nodes forward multicast data packets, they should be able to identify on which path they are located to make appropriate forwarding decision. One feasible solution is to include a new join attribute in a PIM backup join message to set up backup multicast path whose entries are disabled by default. If a failure is detected on the primary path, the backup nodes are notified and the entries which were previously disabled are enabled for multicast data forwarding. The Single stream FRR solution has the advantages of implementing fast multicast protection and of avoiding double multicast bandwidth occupation in both normal and abnormal situations. 2. Principle of Single Stream Solution 2.1. Primary and Backup Path Setup The backup multicast path is set up using backup PIM join. The join is sent by the initiating node (i.e. the downstream converge point of primary and backup paths) from a backup IP FRR upstream interface or from a statically configured backup interface towards the multicast source. The join is transmitted hop-by-hop upwards and is terminated when reaching the root of the multicast tree (i.e. Source DR or RP), or when merging with primary forwarding states created by primary join. On the merging point, only the primary states are maintained. The forwarding state(s) on backup path are disabled by default for data forwarding when being created by the backup joins, which requires the backup join to be flagged to be differentiated from the primary ones. A new join attribute [RFC5384] (referred to as e.g. Multicast FRR join Attribute, or MFA), is suggested to be introduced to serve this purpose and a new hello option for this attribute should be defined to negotiate this capability. The format of the Liu.,et al Expires April 18, 2011 [Page 3] Internet-Draft Single Stream Multicast FRR October 2010 attribute and its hello option are respectively defined in section 3.1 and 3.2 The establishing of primary path could be a normal PIM join process. In this case an ordinary PIM join is generated on the initiating node of primary path and is sent hop-by-hop upstream until the join arrives at the root of the tree or at the other valid forwarding branch. 2.2. Fault Processing The fault on the primary path could be detected by using some fault detection mechanism (e.g. BFD protocol), which is configured to be run between each pair of PIM neighbors. If error condition occurs, the node on the upstream or downstream of the error point will possibly detect it and should pass this error condition to the backup path, and enable multicast data forwarding on it. As the node on the primary path detects a failure, it could choose to flood the failure notification packet to all its PIM neighbors until all the PIM routers in the area get the notification. To prevent excessive transmission of these packets, the sending and forwarding of the packets should be rate-limited. There are other options such as setting up special fault notification tree with reserved multicast address and etc. After the enabling of the backup path triggered by the fault notification, the multicast data will be forwarded along the backup path to the initiating node of the backup path. The initiating point will change the backup incoming interface (IIF) as its RPF interface if no data is available from the primary IIF. 2.3. Fault Recovery If primary path heals, multicast forwarding could choose to switch back to the primary path. Once the data is received from the primary IIF, the initiating node will change its RPF interface to its primary IIF. The node may also send a PIM prune message to tear down the backup path, and may possibly after waiting for a specified period of time, re-setup the backup path without stream using the same process as described in section 2.1. Liu.,et al Expires April 18, 2011 [Page 4] Internet-Draft Single Stream Multicast FRR October 2010 3. The Definition of packet format 3.1. Multicast FRR join Attribute The format of the join attribute is defined as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E| Attr_Type | Length | Flags | Path Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ . . . ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - F-bit, Transitive Attribute. If this bit is set, the attribute is a transitive attribute; otherwise, it is a non-transitive attribute [RFC5384]. - E-bit, End of Attributes. If this bit is set, then this is the last Join Attribute appearing in the Encoded-Source Address field specified by [RFC5384]. - Attr_Type, Type of the Attribute. It should be set to a new value (e.g.) for this MFA join attribute, e.g., taking value of 8. - Length, a 1-octet field specifying the length in octets, encoded as an unsigned binary integer, of the value field. - Flags, flags for the methods of setting up of primary or backup paths. For the rightmost bit, 0 is for a primary join, 1 for backup join. Other bits are reserved for the future definition. - Path Count, the number of Path ID. - Path ID, the Identification for this path. It may be an interface ID or a logical number to identify a primary path. 3.2. PIM multicast FRR Hello Options This multicast FRR Hello options are used for the PIM neighbors to negotiate the capability of multicast FRR join attribute. It has the format prescribed in [RFC5384] and the OptionType is defined a new value representing this MFA attribute. Liu.,et al Expires April 18, 2011 [Page 5] Internet-Draft Single Stream Multicast FRR October 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - OptionType = 38 - OptionLength = 8 - OptionValue, reserved for future use 4. Single Stream Implementation Options 4.1. Disabling all nodes on backup path In this method, when backup join is transmitted to set up the backup path, the forwarding states of all backup nodes are by default disabled for multicast data forwarding when being created. When backup join arrives at a primary node that has primary forwarding state, it is ''absorbed'' and will not create any backup state there. Because each node on the backup path could be disabled or enabled for data forwarding, it is possible to implement relatively precise control of path switching. RT1 | | / RT1 - RT2 RT2 / \ | \ RT3 RT4 RT3 RT4 \ / / \ / RT5 - RT6 RT5 RT6 Figure 1 Figure 2 Figure 1 is an example of an arbitrary tree topology. Supposing RT6 has a downstream receiver and it is the initiating node of both the primary and backup path for this receiver. RT2-RT3-RT6 is setup as the primary path by primary join, and RT2-RT4-RT6 as the backup path by backup join. The backup forwarding entries for the backup path, i.e. the outgoing interfaces of RT2 (the one towards RT4) and RT4 (towards RT6), are all disabled for multicast forwarding. Only primary path imports multicast stream through RT2 to RT6 and to the receiver. If link between RT3 and RT6 goes down, the failure will be detected by RT6. The fault notification will be generated by RT6 and be Liu.,et al Expires April 18, 2011 [Page 6] Internet-Draft Single Stream Multicast FRR October 2010 notified to RT4 and RT2 on backup path, by flooding or through fault multicast tree which is pre-established on RT4 and RT2 by back join with RT6 as the source of the tree The nodes RT4 and RT2 will be enabled the data forwarding on their outgoing interfaces, and the data will be imported from RT2, through RT4, to RT6 and the receiver. In the ring topology shown in figure 2, supposing RT3 has a receiver downstream, the primary path for it is RT1-RT3 and takes the duty of data forwarding. The backup path is RT2-RT4-RT6-RT5-RT3 and the backup outgoing interface on each of them is disabled when the forwarding state is created. If node RT1 undergos failure, it will be detected by RT3 and be notified by flooding or by multicast fault tree which is pre-established on RT5, RT6, RT4, and RT2, with RT3 as the source of the tree. After enabling data forwarding for these nodes, the traffic will be delivered along backup path to RT3 and to the receiver. Each node on the ring processes in the similar manner, if it has downstream multicast receiver. If any upstream failure on the primary path occurs, the node will turn to receive reverse stream from the backup path. Because a backup node or path might provide protection for more than one primary path, the identification of the primary path should be bound to its own backup multicast entries, which requires the identification to be carried in the backup join during setting up of backup path, and in the fault notification to enable the forwarding of these entries. In normal cases, a primary path is identified by the primary IIF ID of an initiating node. In figure 1, this ID is the upstream interface ID of RT6 towards RT3. Its correlation with backup forwarding entries are maintained at RT4 and RT2. The backup path RT2-RT4-RT6 is used to protect failure detected by RT6 (i.e. RT3 node failure or RT3-RT6 link failure). To provide protection for the whole primary network, each primary node is required to have a backup interface to form disjoint backup path for the upstream node/ link to be protected, which is generally the case for ring topology and dual-homing protection tree topology. As an extension, the primary ID could also be the collection of all interface IDs of a primary path (i.e. upstream interface IDs of RT3 and RT6 in figure 1), which could be configured on the initiating point (i.e. RT6) and be carried in backup join. The fault notification still carries the interface ID of downstream detecting node. Because the backup path is set up according to the interface ID collection for the whole primary path, one backup path can Liu.,et al Expires April 18, 2011 [Page 7] Internet-Draft Single Stream Multicast FRR October 2010 provide protection for a complete primary path (i.e. RT2-RT3-RT6), rather than for only one hop distance in the former case. 4.2. Disabling only root node on backup path In this method, when backup join is sent to setup the backup path, only the root node is disabled of its multicast data forwarding. The forwarding states on other nodes on the backup path are kept normal. In normal condition, the only stream comes from the primary path established by the primary join. If error occurs on the primary path, the root node of the backup path is notified of the failure, it then enables its data forwarding and the data stream will be delivered from the backup path to the receiver. Because only the ingress node of the backup path is disabled, the method requires the backup path not to intersect with the primary path for the intermediate nodes and can be applied to multiple tree topologies. E.g., the primary join and backup join can be used to setup primary and backup trees with only primary tree makes the multicast forwarding in normal condition. When failure occurs on the primary tree, the root node of the backup tree could be notified to open its data forwarding and the multicast data will delivered over the backup tree to the receiver. 5. Security Considerations They will be described in the later version of this draft. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008 [RFC5880] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", RFC 5880, June, 2010. Liu.,et al Expires April 18, 2011 [Page 8] Internet-Draft Single Stream Multicast FRR October 2010 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 Lianshu Zheng Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China EMail: verozheng@huawei.com Tao Bai Huawei Technologies Co., Ltd. No.156 BeiQing Rd. Hai-Dian Distinct, Beijing 100094 EMail: baitao_bys@huawei.com YunFu Yu Huawei Technologies Co., Ltd. No.156 BeiQing Rd. Hai-Dian Distinct, Beijing 100094 China EMail: yuyunfu@huawei.com Liu.,et al Expires April 18, 2011 [Page 9]