draft-liu-pim-single-stream-multicast-frr-01

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?