Head Node Protection Extensions to RSVP-TE for LSP Tunnels

draft-cao-mpls-te-p2mp-head-protection-01

caowayne@huawei.commach@huawei.com

MPLS WG, IETF 70

Background and Motivation

Background

• Multicast applications are being deployed

• TE P2MP LSP Protocol is published, FRR mechanism mature but not applicable for head

node failure

Why introduce head node protection ?

• Head node failure will cause serious (all subscriber) outages

• 1+1 backup is inefficient

• Edge more vulnerable than core nodes; higher maintenance requirement

Head node protection objectives

• Protect against single head node failure • Achieve 50ms protection• Reuse existing FRR mechanism • Minimize the impact to the devices on the P2MP LSP, only a few nodes should be involved

Scenario of TE P2MP Head Protection

H1H1

H2H2 R3R3

R2R2R1R1

R4R4 L2L2

L1L1

MHNMHN

BHNBHN

MPMP

MPMP

MHN: Main Head NodeMHN: Main Head Node

BHN: Back Head NodeBHN: Back Head Node

• Source device is multi-homed to MHN (Major head node) and B

HN (Backup Head Node)

• BHN builds backup LSP to all MHN’s downstream LSRs

• BHN does not forward the traffic but monitors the MHN status

• BHN forwards traffic to all MPs in case of MHN node failure

Solution Overview

Backup LSP Construction

• BHN is assigned by MHN

• Protected LSP information is synchronized between MHN and BHN by PATH

messages

Features

• Re-use FRR mechanism

• In the View of MP, the protection is similar to link failure protection

• Downstream devices of MP will not be affected

• Backup LSPs start from BHN to all MPs

Extension to RSVP-TE

Head Node Protection Object ( For IPv4 )

• This object is are carried in PATH and RESV message between MHN and

BHN0 1 2 3

Length (bytes) Class-Num C-type

Protected Head

Backup Head

Flags

• Protected Head IPv4 address identifying the RSVP-TE LSP Head node.• Backup Head IPv4 address identifying the LSR selected as BHN• Flags 0x01(bit0): Head protection desired 0x02(bit1): Head protection available

Applicability Consideration

Topology Requirement

• Source device has to be multi-homed to MHN and BHN, or

• Two source connected to MHN and BHN independently

• BHN must have path to all MPs

MHN node failure detection

• Multiple, diversely routed, BFD connections between MHN and BHN may

be a solution

• Node failure detection can be vendor specific

Next Step?

Revertive Operation

• How does MHN learn about LSPs after failure recovery ?

Topology maintenance issue if failure isn’t quickly

resolved (recovered from)

• Pruning and grafting issues

• Bandwidth Reservation Adjustment

Q & A

Thanks!

MPLS WG, IETF 70