wdiff draft-liu-pim-single-stream-multicast-frr-00.txt draft-liu-pim-single-stream-multicast-frr-01.txt

Network working group H. Liu
Internet Draft L. Zheng
Category: Standard Track Y. Yu T. Bai
Created: July 6, October 18, 2010 Huawei Technologies. Y. Yu
Expires: January April 2011 Huawei Technologies.

Single Stream Multicast Fast Reroute (SMFR) ReRoute (SMFRR) Method
draft-liu-pim-single-stream-multicast-frr-00
draft-liu-pim-single-stream-multicast-frr-01

Abstract

This document proposes an IP multicast fast convergence 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.

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.

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.........................6 Options.........................5
4. Scenario Analysis for Single Stream Forwarding...............6 Implementation Options.........................6
4.1. Disabling all nodes on backup path......................6
4.2. Disabling only root node on backup path.................7 path.................8
5. Security Considerations......................................8
6. Acknowledgement..............................................8
7. References...................................................8
7.1.
6.1. Normative References....................................8
7.2. Informative References..................................8
Authors' Addresses..............................................9

1. Introduction

This document proposes an IP multicast fast convergence 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 and to take make appropriate forwarding action according to this
information. decision. 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
message to set up backup multicast path whose entries are disabled for data forwarding when creating the multicast
forwarding entries.
by default. If the a failure is detected on the primary path, the
backup path is nodes are notified and the forwarding entry on backup path
node entries which was were previously
disabled is 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 of (i.e. the downstream converge point
of primary and backup path paths) from the 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
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 choose
to flood the failure notification packet to all its PIM neighbors. Then the
notification will reach to neighbors
until all the PIM routers in the area. area get the notification. 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 There are other
protocol, which is not covered by this document.

When backup node(s) receive the
options such as setting up special fault 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 tree with
reserved multicast forwarding entries during backup join
operation. address and etc.

After the enabling of the backup path, path triggered by the fault
notification, the multicast data will be forwarded along the backup
path downstream to the initiating node of the backup path. The backup path initiating
point then changes 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. 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|
|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, flag flags for the methods of setting up of primary or backup join.
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 included following 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.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- OptionType = 38

- OptionLength = 8

- OptionValue, reserved for future use

4. Scenario Analysis for Single Stream Forwarding 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 backup forwarding states of all the 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 created create 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 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. Then RT1-RT2-RT3-RT6 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 entries for the backup path,
i.e. the outgoing interfaces of RT2 (the one towards RT4) and RT4
(towards RT6) 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
notified to RT2 and RT4 and RT2 on backup path. They 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 interface, 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 link between node RT1 and RT3 breaks,
the failure undergos failure, it will
be detected by RT3 and be notified to RT2, RT4, by flooding or by multicast fault
tree which is pre-established on RT5, RT6, RT4, and
RT5. They will enable their RT2, with RT3 as
the source of the tree. After enabling data forwarding, and 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
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 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 the
failure, it then enables its data forwarding and the data stream
will be delivered from the backup path to the receiver.

The

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 in this method can be used to
setup primary and backup trees. In normal condition, trees with only primary tree makes the
multicast forwarding. 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. Acknowledgement

Special thanks should be given to Bai Tao for his valuable comments
on the work.

7. References

7.1.

6.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", B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 2236, November 1997.

[RFC5384] Deering, S. ''Host Extensions for IP Multicasting'', RFC1112, 4601, August 1989. 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.

7.2. Informative References

[PORT] Farinacci, D., "A Reliable Transport Mechanism for PIM",
draft-ietf-pim-port-03.txt, March, 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