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]