1 / 10

Enhancing Multicast with Single Stream Multicast Fast Reroute (SMFRR) Techniques

This document discusses the Single Stream Multicast Fast Reroute (SMFRR), aimed at improving multicast video services' reliability and availability. It identifies the challenges of long recovery times during failures and introduces a multicast-only FRR approach that operates independently of unicast IP FRR methods. The paper outlines principles for setting up primary and backup paths using PIM with new attributes, enabling fast switchover in the event of link/node failures. Fault processing strategies and characteristics of the proposed solutions are also highlighted.

xannon
Télécharger la présentation

Enhancing Multicast with Single Stream Multicast Fast Reroute (SMFRR) Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Single stream Multicast Fast ReRoute SMFRR draft-liu-pim-single-stream-multicast-frr-01 Hui Liu Lianshu Zheng Tao Bai Yunfu Yu 79thIETF, Nov 2010, Beijing

  2. Contents • Problem Statements • Characteristics • Principle • Fault Processing • Multicast FRR Attribute

  3. Problem Statement • IP multicast video service usually has more strict availability requirements to improve user experience • But recovery time on failure is long due to delay of unicast route convergence and PIM message relaying • Multicast FRR is required to facilitate fast switchover • Several multicast FRR solutions proposed, each with its advantages and limitations

  4. Characteristics • A multicast only FRR method not necessarily relying on unicast IPFRR techniques • Pre-establish protection path which does not carry service data (or 1:1 protection) • Provide protection for one-hop link/node, an entire path, or a tree, with different implementation complexity • Achieve acceptable switchover speed (100ms level) with low consumption of bandwidth resources • But on the other hand require extension of PIM protocol

  5. Principle • Use PIM Primary join (PJ) and Backup join (BJ) to setup primary and backup paths from initiating point • Identify BJ by including new attribute (i.e. Multicast FRR Attribute) in PIM BJ messages • Forward service data on primary path and block backup path for forwarding • Activate backup path forwarding during failure

  6. Option 1- Disabling only root node • C sends PJ from primary incoming IIF1 to • establish primary path A-B-C carrying • normal multicast stream • C also sends BJ from backup incoming • interface IIF2 to form backup path A-D-C • D creates normal forwarding entries and • relays BJ towards A • A creates non-forwarding entries with • disabled outgoing interface OIF1 and • terminates BJ • If failure on A-B-C is detected, A is notified • and is activated for multicast forwarding. Source A OIF1 D B C IIF1 IIF2 PJ BJ Data Receiver Applicable when primary and backup paths are disjointed

  7. Option 2- Disabling all backup nodes Source/ Upstream Neighbor • C setups primary path A-B-C and backup • path A-E-C, disabling OIF1 and OIF2 • D setups primary path B-C-D and backup • path B-F-D, disabling OIF3 and OIF4 • For one-hop protection, BJ only carry • primary incoming interface ID to correlate • with backup entries (IIF2 for A-B-C, and • IIF3 for B-C-D), only one-hop upstream of • initiating point is protected. • For multiple-hop protection, multiple • interface IDs on primary path are carried • (IIF1 and IIF2 for A-B-C, and IIF2 and IIF3 • for B-C-D), multiple hops upstream of • initiating point are protected • Fault notification carry failure Interface ID • to enable related backup entries A OIF1 IIF1 OIF3 B E OIF2 IIF2 C OIF4 F IIF3 IF1 Receiver1 PJ D BJ Data Receiver2 Applicable almost to all multicast topology by precise control

  8. Fault Processing • Detect failure by regular detection measures o BFD, loss detection, low-layer alarming, and etc. • Notify the failure to backup node o For opt.1, only root of backup path needs to be notified o For opt.2, each backup node should be notified • Alternatives for fault notification: o Flood notification packets (e.g. via BFD) - Applicable to both options - Simple and fast, but inefficient and insecure o Multicast forward fault notification packet - More suitable for opt.2 - Fault notification tree has to be pre-established o Other control plane measures: sometimes too slow

  9. Multicast FRR Attribute • F/E/Length: follow the same definition as RFC5384 • Attr_Type: new value assigned for multicast FRR attribute • Flags: indicate the PIM join type and protection mode • Path Count: number of Path IDs carried in this attribute • Path ID: path or interface identification, may be set to an • interface ID or a logical number

  10. Thanks ! Is it appropriate to be adopted as a working item?

More Related