P2MP Path Computation Using PCE

1
P2MP Path Computation Using PCE
Daniel King Fabien Verhaeghe Jean-Louis Le
Roux Mohamad Chaitou Quintin Zhao Tomonori
Takeda Zafar Ali
2
Contents

• Introduction
• Requirements
• History
• Solution overview
• Message Extensions
• Object Extensions
• Examples
• Building a new P2MP tree
• Adding a new leaf to an existing P2MP tree
• Deleting a new leaf from an existing P2MP tree
• Optimizing a existing P2MP tree
• Synchronize 2 path computation requests
• Handling the big request message which is for a
  big P2MP tree
• Next Step

3
Introduction
4
Introduction P2MP Requirements

• R1 Indication of P2MP Path Computation
  Request.
• R2 Indication of P2MP Objective Functions.
• R3 Non-Support of P2MP Path Computation.
• R4 Non-Support by Back-Level PCE
  Implementations.
• R5 Specification of Destinations.
• R6 Indication of P2MP Paths.
• R7 Multi-Message Requests and Responses.
• R8 Non-Specification of Per-Destination
  Constraints and Parameters.
• R9 Path Modification and Path Diversity.
• R10 Reoptimization of P2MP TE LSPs.
• R11 Addition and Removal of Destinations from
  Existing Paths.
• R12 Specification of Applicable Branch Nodes.
• R13 Capabilities Exchange.

5
Introduction history

• Originally 2 drafts were proposed
• draft-zhao-pce-pcep-extension-p2mp-00.txt
  Defines a new END-POINT object type to advertise
  multiple destinations.
• draft-chaitou-pce-p2mp-ext-00.txt Builds a P2MP
  request as a set of synchronized P2P request
  thanks to SVEC mechanism.
• Authors of both drafts work together on a single
  solution.
• http//tools.ietf.org/id/draft-zhao-pcep-p2mp-exte
  nsion-00.txt
• Probably it will be renamed
• draft-zhao-pce-pcep-p2mp-extension-00.txt

6
Introduction Solution overview

• Both original solutions were fine but
• first solution requires a mechanism to handle
  large P2MP request/reply that cannot fit into a
  single message.
• Second solution on the other hand does not need
  such mechanism but creates extra overhead.
• Proposed solution Define a new END-POINT object
  and use SVEC mechanism to handle too large P2MP
  request.
• One important specificity of P2MP request is
  that there can be up to 4 types of destinations
• New leaves to add
• Old leaves to remove
• Old leaves which path can be modified/re-optimize
  d
• Old leaves which path must be left unchanged.
• ?In proposed solution one END-POINT object
  contain only 1 type of leaf. So one P2MP request
  can contain up to 4 END-POINT object.

7
Message Format Extension
8
The proposed Request Message Format
ltPCReq Messagegt ltCommon Headergt
ltSVEC-listgt
ltrequest-listgt where
ltsvec-listgtltSVECgtltsvec-listgt
ltrequest-listgtltrequestgtltrequest-listgt
ltrequestgt ltRP with P2MP Ext.gt
ltend-point-rro-pair-listgt
ltBANDWIDTHgt
ltLSPAgt OF
ltmetric-listgt
ltLOAD-BALANCINGgt
Where ltend-point-rro-listgtltEND-POINTSgtltR
RO-listgt ltend-point-rro-listgt
ltRRO-listgtltPROgtltPRO-listgt
ltmetric-listgtltMETRICgtltmetric-listgt
9
Proposed Reply Message Format
ltPCRep Messagegt ltCommon Headergt

ltresponsegt ltresponsegtltRP with P2MP
flaggt
ltend-point-path-pair-listgt
ltNO-PATHgt
ltattribute-listgt
ltBANDWIDTHgt
ltmetric-listgt
ltIROgt where
ltend-point-path-pair-listgt
ltEND-POINTSgtltpathgtltend-point-path-pair-listgt
ltpathgt ltEROgtltSEROgtltpathgt
ltattribute-listgtltOFgt
ltLSPAgt
ltBANDWIDTHgt
ltmetric-listgt
ltIROgt
10
Object Format Extensions
11
The Existing RP Object Format Extension

• 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
• -----------------------
  ---------
• Reserved Flags
  EM OBR Pri
• -----------------------
  ---------
• Request-ID-number
  
• -----------------------
  ---------
• 
  
  
• // Optional TLV(s)
  //
  
• 
  
  
• -----------------------
  ---------
• 
  

M ( PM2P bit - 1 bit)


0 This indicates that this is PCReq/PCRrep for
P2P.
1
This indicates that this is PCReq or PCRep
message for PM2P. E (
ERO-compression bit - 1 bit)


0 This indicates that the route is not in the
compressed format.

1 This indicates that the route is in
the compressed format.
12
The New END-POINTS Object Format (IPv4 )

• -----------------------
  ---------
• Object-Class OT ResPI Object
  Length (bytes)
• -----------------------
  ---------
• Leaf Type
  
  
• ------------------------
  --------
• IPv4 address for
  source
• ------------------------
  --------
• IPv4 address for
  destination
• -----------------------
  ---------
• 
  
  
• -----------------------
  ---------
• IPv4 address for
  destination
• -----------------------
  ---------

One new OT number will be allocated for IPv4
P2MP end point object and four leaf types are
1 New leaves to add 2 Old leaves to remove
3 Old leaves which path can be
modified/re-optimized 4 Old leaves which path
must be left unchanged
13
The New END-POINTS Object Format (IPv6)

• -----------------------
  ---------
• Object-Class OT ResPI Object
  Length (bytes)
• -----------------------
  --------
• leaf type
  
  
• ------------------------
  --------
• IPv6 address for
  source
• 
  
  
• 
  
  
• 
  
  
• ------------------------
  --------
• IPv6 address for
  destination
• 
  
  
• 
  
  
• 
  
  
• ------------------------
  --------
• ..
  
  
• -----------------------
  --------
• IPv6 address for
  destination
• 
  
  

One new OT number will be allocated for IPv6
P2MP end point object and four leaf types are
1 New leaves to add 2 Old leaves to remove
3 Old leaves which path can be
modified/re-optimized 4 Old leaves which path
must be left unchanged
14
Examples
15
Example 1 for P2MP (a New Tree with One Root and
Three leaves) Path Computation Request Message
ltPCReq Messagegt ltCommon Headergt
ltrequestgt where
ltrequestgt ltRP with P2MP flag and ERO-Compress
bitgt
ltEND-POINTS for new leafgt
ltBANDWIDTHgt
OF
ltmetric-listgt


16
Example 2 for P2MP (One Root with Three
Leaves) Path Computation Reply Message
ltPCRep Messagegt ltCommon Headergt ltresponsegt
if ERO-Compress bit was set to 1 in request
ltresponsegtltRP1 with P2MP
flaggt ltEND-POINT for
new leavesgt
ltERO1gtltSERO2gtltSERO3gt
ltBANDWIDTHgt
ltmetric-listgt if
ERO-Compress bit was set to 0 in request
ltresponsegtltRP1 with P2MP flaggt

ltEND-POINT
for new leavesgt
ltERO1gtltERO2gtltERO3gt
ltBANDWIDTHgt
ltmetric-listgt
17
Example 3 of P2MP (Add one leaf to the tree
which has 100 leaves) Path Computation Request
Message
ltPCReq Messagegt ltCommon Headergt
ltrequestgt where ltrequestgt ltRP
with P2MP flag with R bit setgt
ltEND-POINT for new leafgt
ltEND-POINT1-100 for path unchange leavesgt
ltRRO1gtltRRO2gtltRRO100gt
OF ltBANDWIDTHgt
ltmetric-listgt

18
Example 4 of P2MP (delete one leaf from the tree
which has 100 leaves) Path Computation Request
Message
ltPCReq Messagegt ltCommon Headergt
ltrequestgt where ltrequestgt ltRP
with P2MP flag with R bit setgt
ltEND-POINT for leaf deletegt
ltRRO1gt
ltEND-POINT2-100 for path change leavesgt
ltRRO2gtltRRO3gtltRRO100gt
OF

Note In the case that the delete result doesnt
need to optimize the remaining P2MP LSP, then
there is no need to send the request to PCE. In
the case that The remaining tree need to be
optimized, then it send the request with the
existing end-points and the remaining ERO/SEROs.
19
Example 5 of P2MP (synchronize two P2MP LSPs,
each has two leaves) Path Computation Request
Message
ltPCReq Messagegt ltCommon Headergt ltSVEC for
sync of LSP1 and LSP2gt
ltrequest-listgt where
ltrequest-listgt ltrequest1gtltrequest2gt
ltrequest1gt ltRP1 with P2MP flaggt

ltend-point-rro-pair-listgt
ltBANDWIDTH1gt
ltrequest2gt ltRP2 with P2MP flaggt

ltend-point-rro-pair-listgt
ltBANDWIDTH2gt


20
Example 6 of P2MP (handle the message which is
too big to fit into one single request
message) Path Computation Request Message
ltPCReq Message1gt ltCommon Headergt
ltSVEC with Req-ID1 repeated twicegt
ltrequestgt where
ltrequestgtltRP with Req-ID1 and
P2MP flaggt
ltend-point-rro-pair1 - new leavesgt
ltend-point-rro-pair2 Old
leaves to optimizedgt ltPCReq Message2gt ltCommon
Headergt ltrequestgt
where ltrequestgtltRP
with Req-ID1 and P2MP flaggt
ltend-point-rro-pair3 - Old
leaves to optimized gt
Note The PCE receives the first request message
and will wait for all the request message which
has the Req-ID1 before it starts to compute the
complete P2MP LSP. The assumption is that the
messages are delivered with order and
reliability .
21
Next step

• Need feedback from the WG to continue work on
  the solution.
• Does WG think it is ready to be adopted as
  document?