Network working group H. Liu Internet Draft L. Zheng Category: Standard Track Y. Yu Created: July 6, 2010 Huawei Technologies. Expires: January 2011 Single Stream Multicast Fast Reroute (SMFR) Method draft-liu-pim-single-stream-multicast-frr-00 Abstract This document proposes an IP multicast fast convergence 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 January 6, 2011 [Page 1] Internet-Draft Single Stream Multicast FRR July 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 3. The Definition of packet format..............................5 3.1. Multicast FRR join Attribute............................5 3.2. PIM multicast FRR Hello Options.........................6 4. Scenario Analysis for Single Stream Forwarding...............6 4.1. Disabling all nodes on backup path......................6 4.2. Disabling only root node on backup path.................7 5. Security Considerations......................................8 6. Acknowledgement..............................................8 7. References...................................................8 7.1. Normative References....................................8 7.2. Informative References..................................8 Authors' Addresses..............................................9 Liu.,et al Expires January 6, 2011 [Page 2] Internet-Draft Single Stream Multicast FRR July 2010 1. Introduction This document proposes an IP multicast fast convergence 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 and to take appropriate forwarding action according to this information. One feasible solution is to include a new join attribute in a PIM backup join message. During the transmission of the joins hop-by-hop on the backup path, the node(s) of backup path are disabled for data forwarding when creating the multicast forwarding entries. If the failure is detected on the primary path, the backup path is notified and the forwarding entry on backup path node which was previously disabled is enabled for 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 of the backup path from the 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 January 6, 2011 [Page 3] Internet-Draft Single Stream Multicast FRR July 2010 attribute and its hello option are respectively defined in section 3.1 and 3.2 To make precise switching from a primary path to a backup path for multiple load-balancing primary paths, an additional identification for the primary path should be included in the MFA attribute of a backup join. The primary path ID could be the interface ID of a router ID, or a logic number configured for the primary path. In some cases multiple primary path IDs have to be included in the backup join and they have to be merged when backup join has to be sent upwards. PIM incremental mechanism [PORT] could be used in these cases to reduce information to be carried in the backup joins. 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 flood the failure notification packet to all its PIM neighbors. Then the notification will reach to all the PIM routers in the area. To prevent excessive transmission of these packets, the sending and forwarding of the packets should be rate-limited. The fault notification like this can be implemented by extending BFD or other protocol, which is not covered by this document. When backup node(s) receive the notification packets, they will enable the multicast forwarding which was previous disabled. To select correct data stream switching to the backup path, the information of primary path ID should be carried in the notification. And prior to that, the backup path should record the primary path ID for corresponding multicast forwarding entries during backup join operation. After the enabling of the backup path, the multicast data will be forwarded along the path downstream to the initiating node of the Liu.,et al Expires January 6, 2011 [Page 4] Internet-Draft Single Stream Multicast FRR July 2010 backup path. The backup path initiating point then changes the backup incoming interface (IIF) as its RPF interface if no data is available from the primary IIF. If primary path heals, multicast forwarding could choose to switch back to the primary path. The primary join will be generated hop- by-hop to set up the primary path, as illustrated in section 2.1. 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. 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. Liu.,et al Expires January 6, 2011 [Page 5] Internet-Draft Single Stream Multicast FRR July 2010 - Flags, flag for primary or backup join. 0 is for a primary join, 1 for backup join. - Path Count, the number of path included following Path ID. - Path ID, the Identification for this 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. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - OptionType = 38 - OptionLength = 8 - OptionValue, reserved for future use 4. Scenario Analysis for Single Stream Forwarding 4.1. Disabling all nodes on backup path In this method, when backup join is transmitted to set up the backup path, the backup forwarding states of all the 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 created any backup state there. Because each backup path will be merged at transit or root node of a multicast tree, and each node on this backup path could be disabled or enabled for data forwarding, it is possible to implement relatively precise control of path switching. Liu.,et al Expires January 6, 2011 [Page 6] Internet-Draft Single Stream Multicast FRR July 2010 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. Then RT1-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 states 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 and be notified to RT2 and RT4 on backup path. They will be enabled the data forwarding on their outgoing interface, 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 link between RT1 and RT3 breaks, the failure will be detected and be notified to RT2, RT4, RT6, and RT5. They will enable their data forwarding, and 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. 4.2. Disabling only root node on backup path In this method, when backup join is sent hop-by-hop 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 Liu.,et al Expires January 6, 2011 [Page 7] Internet-Draft Single Stream Multicast FRR July 2010 the failure, it then enables its data forwarding and the data stream will be delivered from the backup path to the receiver. The primary join and backup join in this method can be used to setup primary and backup trees. In normal condition, only primary tree makes the multicast forwarding. 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. Acknowledgement Special thanks should be given to Bai Tao for his valuable comments on the work. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [RFC4601] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC5384] Deering, S. ''Host Extensions for IP Multicasting'', RFC1112, August 1989. [RFC5880] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", RFC 5880, June, 2010. 7.2. Informative References [PORT] Farinacci, D., "A Reliable Transport Mechanism for PIM", draft-ietf-pim-port-03.txt, March, 2010. Liu.,et al Expires January 6, 2011 [Page 8] Internet-Draft Single Stream Multicast FRR July 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 YunFu Yu Huawei Technologies Co., Ltd. No.156 BeiQing Rd. Hai-Dian Distinct, Beijing 100094 China EMail: yuyunfu@huawei.com Liu.,et al Expires January 6, 2011 [Page 9]