One document matched: draft-liu-pim-single-stream-multicast-frr-01.txt
Differences from draft-liu-pim-single-stream-multicast-frr-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 08:56:26 |