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

Contents Problem Statements Characteristics Principle Fault Processing Multicast FRR Attribute

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

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

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

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

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 OIF2 E IIF2 C OIF4 F IIF3 Receiver1 IF1 PJ D BJ Data Receiver2 Applicable almost to all multicast topology by precise control

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

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

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