PCE-based Computation forInter-domain P2MP LSP

draft-zhao-pce-pcep-inter-domain-p2mp-procedures-00.txt

Quintin Zhao, Huawei Technology

David Amzallag, British TelecomDaniel King, Old Dog Consulting

Motivation• Multicast services are in demand for high-capacity applications such as multicast VPNs,

IPTV (on-demand or streaming), and content-rich media distribution.

• The PCE communication protocol (PCEP) is extended as a communication protocol between PCCs and PCEs for point-to- multipoint (P2MP) path computations and is defined in [PCE-P2MP-EXT]. However, that specification does not provide a mechanism to request path computation of inter-domain P2MP TE LSPs.

• This document describes the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs.

[PCE-P2MP-EXT] Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to- Multipoint Traffic Engineering Label Switched Paths

Requirements• General requirements include:

– Ability to compute a constrained P2MP LSP for MPLS & GMPLS multi-domain environments.– A number of requirements specified in [RFC5376]– A number of requirements specified in [PCE-P2MP-REQ]

• P2MP LSP Computation requirements include:– The P2MP LSP paths should be optimal while only considering the entry and exit nodes of each

domain as the transit, branch and leaf nodes of the P2MP LSP path subject to the OF. – The sub-tree within each domain should be optimized subject to the OF;– The grafting and pruning of multicast destinations in a domain should have no impact on other

domains or on the paths among Boundary Nodes (BNs)– Computing each sub-tree should be independent of the domain sequences.

• Per Domain computation or BRPC are applicable for P2MP TE LSP, but have limitations for the requirements outlined above.

[RFC5376] Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)[PCE-P2MP-REQ] Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)

Proposed Procedures • Core Tree Based Path Computation

– Definition of Core Tree :• A core tree is a path tree with nodes from each domain corresponding to the PCE topology

which satisfies the following conditions:– The root of the core tree is the ingress LSR in the root domain– The leaf of the core tree is the entry node in the leaf domain– The transit and branch node are from the entry and exit nodes from the transit and

branch domains.

– A Core Tree Based Solution:• This solution provides an optimal inter-domain P2MP TE LSP and looks to address the specific

requirements and objective functions outlined in the previous slides. Computing the complete P2MP LSP path tree is done in two phases:

– Procedure Phase 1: P2MP LSP Core Tree Building for the Boundary Nodes (BNs). One mechanism for a small scale CoreTree can be using the BRPC with extension.

– Procedure Phase 2: Grafting destinations to the P2MP LSP Core Tree. Once the core tree based inter-domain tree is built. The grafting of all the leaf nodes from each domain to the core tree can be achieved.

• Source Node• Boundary Node (BN)• Destination Domain BN• Transit Node

Phase 1: A P2MP LSP Core Tree is built for the Boundary Nodes (BNs).• The initiating PCE (PCE1) sends a request

message with new bit (C bit) in RP to its child PCE with all the boundary nodes from each transit domain as the transit nodes and all the entry boundary nodes from each leaf domain as the leaf nodes, and computes a P2MP LSP path core tree based on the extended Backward Recursive Path Calculation (BRPC) procedures for all the BNs.

S

T

U

A

C

E F

H

M

G

PRQ

W

V

Y

X

B

J

K PCE 4

Z

D1

PCE 1

PCE 2

PCE 5

PCE 6

PCE 3

D2

Core Tree Based Example

Phase 2: Grafting destinations to the P2MP LSP Core Tree• Once the phase procedure is complete, the initiating PCE will pass request message with the C bit cleared in

RP for all the destination nodes and also the core P2MP LSP tree to its child PCE.• If the current PCE is not the leaf PCE, then it will rebuild the PCReq message for its child PCE and pass the

message down to its child PCE.• The leaf PCE will graft all the destination nodes belonging to the leaf domain to the core tree and reply it to its parent PCE.• When a PCE receives the reply it will create a core tree and will graft all the destination nodes belonging to the current domain to the core tree and reply it to its parent PCE.• When all the destinations are built within the core tree at the initiating PCE (PCE1), the P2MP LSP tree is complete and it will reply to the PCC with the P2MP LSP tree.

Core Tree Based Example

LSR11

LSR21 LSR112

LSR22 LSR23

LSR312 LSR312LSR41

LSR411 LSR412 LSR511 LSR512

LSR51

LSR513 LSR52

LSR61

LSR611 LSR612

LSR62

621 LSR622

LSR31

domain1

domain2

domain3

domain4

domain5

domain6

LSR613

Extensions Required

Protocol Extensions: PCE Chain Object• We suggests to add one object, PCE Chain Object, to the existing PCE protocol, which needs

the new Object-class and OT. (1) In the PCE Chain object, the list of PCE IP addresses are listed from the root PCE to the leaf PCE. (2) The PCE topology tree is a list of PCE Chain Objects.(3) During the PCE capability exchange state or the first path request message,

• This PCE Chain object list is exchanged between PCEs.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-Class | OT |Res|P|I | Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for root PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for the child PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for the child PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | …… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address for the child PCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extensions Required 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Flags | C | | O | B | R | Pri | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Request-ID-number | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | // Optional TLV(s) // | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Protocol Extensions: New C bit in the RP object

• C ( RP Core Tree bit - 1 bit): 0: This indicates that the message is for the normal leaf grafting/pruning; 1: This indicates that the request associated with this RP is core tree computation request or reply.

Next Steps

• Inter-domain P2MP is within the working group charter.• This work will run in parallel to draft-ietf-pce-pcep-p2mp-extensions-

02.txt• Other co-authors of draft-ietf-pce-pcep-p2mp-extensions-02.txt have

expressed an interest to collaborate on our inter-domain P2MP procedure solution.

• Continue to review and update requirements. • Solicit feedback from working group and customers.

Thank You !