Quintin Zhao, [e-mail]

1
Update on PCEP Extensions for P2MP
LSP draft-ietf-pce-pcep-p2mp-extensions-01.txt
Quintin Zhao, qzhao_at_huawei.com Daniel King,
daniel_at_olddog.co.uk Fabien Verhaeghe,
fabien.verhaeghe_at_marben-products.com Tomonori
Takeda, takeda.tomonori_at_lab.ntt.co.jp Mohamad
Chaitou, Mohamad.Chaitou_at_orange-ftgroup.com Jean
-Louis Le Roux, Jeanlouis.Leroux_at_orange-ftgroup.
com Zafar Ali, zali_at_cisco.com IETF73,
Minneapolis, MN, USA
2
Contents

1. New Requirement
2. Proposed solution and an alternative Solution
3. Examples
4. Summary and Next Step

3
New Requirement

• Multi-Message Requests and Responses
• A single P2MP LSP may have very many
  destinations, and the computed path (tree) may
• be very extensive. In these cases it is possible
  that the entire Path Computation Request
• or Response cannot fit within one PCE message.
  Therefore, it MUST be possible for a
• single request or response to be conveyed by a
  sequence of PCE messages. Note that
• there is a requirement in RFC4657 for reliable
  and in-order message delivery, so it is
• assumed that components of the sequence will be
  delivered in order and without missing
• components.

4
PCEP Extension 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
ltmetric-listgt Where ltend-point-rro-pair-
listgtltEND-POINTSgtltrro-listgtltBANDWIDTHgt

ltend-point-rro-pair-listgt
5
Proposed Reply Message Format
ltPCRep Messagegt ltCommon Headergt
ltSVEC-listgt
ltresponse-listgt where
ltsvec-listgtltSVECgtltsvec-listgt
ltresponse-listgtltresponsegtltresponse-listgt
ltresponsegtltRP with P2MP flaggt
ltend-point-path-pair-lis
tgt ltNO-PATHgt

ltattribute-listgt where
ltend-point-path-pair-listgt
ltEND-POINTSgtltpath-listgtltend-point-path-pair-lis
tgt ltpath-listgt ltEROgtltSEROgtltpath-l
istgt ltattribute-listgtltOFgt
ltLSPAgt
ltBANDWIDTHgt

ltmetric-listgt
ltIROgt
6
Example 1 of P2MP Issue (Problem the message
which is too big to fit into one single request
message) Path Computation Request Message
ltPCReq Message1gt ltCommon Headergt
ltrequestgt where
ltrequestgtltRP with Req-ID1 and P2MP flaggt

ltend-point-rro-pair1 - new leavesgt
ltend-point-rro-pair2 Old leaves,
path can be optimizedgt
ltend-point-rro-pair3 - Old leaves,
path can not be changedgt
7
Example 1 of P2MP Solution (Solution handle
the message which is too big to fit into one
single request message) Path Computation Request
Message
ltPCReq Message1gt ltCommon Headergt
ltSEVC with Req-ID1 repeated twicegt
ltrequestgt where
ltrequestgtltRP with Req-ID1 and
P2MP flaggt
ltend-point-rro-pair1 - new leavesgt
ltend-point-rro-pair2 existing
leaves, path can be optimizedgt ltPCReq
Message2gt ltCommon Headergt
ltrequestgt where
ltrequestgtltRP with Req-ID1 and P2MP flaggt

ltend-point-rro-pair3 - existing leaves, path can
not be changedgt
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 .
8
Example 2 of P2MP Issue (Problem the message
which is too big to fit into one single reply
message) Path Computation Reply Message
ltPCRep Messagegt ltCommon Headergt
ltresponsegt
where ltresponsegtltRP with
Req-ID1 and P2MP flaggt
ltEND-POINTS1gt
ltERO1gtltSER1-1gt.ltSERO
1-100gt
ltEND-POINTS2gt ltERO2gtltSER2-1gt.ltSE
RO2-100gt
ltEND-POINTS3gt
ltERO3gtltSER3-1gt.ltSERO3-100gt
9
Example 2 of P2MP Solution (Solution handle the
message which is too big to fit into one single
reply message) Path Computation Reply Message
ltPCRep Message1gt ltCommon Headergt
ltSEVC with Req-ID1 repeated twicegt
ltresponsegt where
ltresponsegtltRP with Req-ID1 and
P2MP flaggt
ltEND-POINTS1gt
ltERO1gtltSER1-1gt.ltSERO1-100gt

ltEND-POINTS2gt
ltERO2gtltSER2-1gt.ltSERO2-100gt ltPCRep
Message2gt ltCommon Headergt
ltresponsegt
where ltresponsegtltRP
with Req-ID1 and P2MP flaggt
ltEND-POINTS3gt
ltERO3gtltSER3-1gt.ltSERO3-100gt
Note The PCE receives the first reply message
and will wait for all the reply message which has
the Req-ID1 before it starts to assemble the
complete P2MP LSP. The assumption is that the
messages are delivered with order and
reliability .
10
Alternative Solution

• An alternative solution for this new requirement
• Add one more fragmentation bit in the RP Object

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
F E M
O B R Pri
- - - - - - - - - - -
- - - - - - - - - - - -
- - - - - - - - -

Request-ID-number

- - - - - - - - - - - -
- - - - - - - - - - - - -
- - - - - - -



//
Optional TLV(s)

//



- - - - - - - - - - - - -
- - - - - - - - - - - -
- - - - - - - o F ( RP
fragmentation bit - 1 bit) 0 This
indicates that the PR is not fragmented or it is
the last piece of the fragmented
RP. 1 This indicates that the RP is
fragmented and this is not the last piece of the
fragmented RP and the receiver
need to wait until it receives an RP with the
same RP-ID and with the F bit is set to 0.
11
Example 1 of P2MP (Solution handle the message
which is too big to fit into one single request
message) Path Computation Request Message
ltPCReq Message1gt ltCommon Headergt
ltrequestgt
where ltrequestgtltRP with
Req-ID1 and P2MP flag and F bit set to 1gt

ltend-point-rro-pair1 - new leavesgt
ltend-point-rro-pair2 existing
leaves , path can be optimizedgt ltPCReq
Message2gt ltCommon Headergt
ltrequestgt where
ltrequestgtltRP with Req-ID1 and P2MP flag
and F bit set to 0gt
ltend-point-rro-pair3 - existing
leaves, path can not changed gt
Note The PCE receives the first request message
and will wait for all the request message which
has the Req-ID1 and the F bit is set to 0 before
it starts to compute the complete P2MP LSP. The
assumption is that the messages are delivered
with order and reliability .
12
Example 2 of P2MP (Solution handle the message
which is too big to fit into one single reply
message) Path Computation Reply Message
ltPCRep Message1gt ltCommon Headergt ltresponsegt
where
ltresponsegtltRP with Req-ID1 and P2MP flag and F
bit is set to 1gt
ltEND-POINTS1gt
ltERO1gtltSER1-1gt.ltSERO1-100gt

ltEND-POINTS2gt
ltERO2gtltSER2-1gt.ltSERO2-100gt ltPCRep
Message2gt ltCommon Headergt
ltresponsegt
where ltresponsegtltRP with
Req-ID1 and P2MP flag and F bit is set to 0 gt

ltEND-POINTS3gt
ltERO3gtltSER3-1gt.ltSERO3-100gt
Note The PCE receives the first reply message
and will wait until It receives the reply message
which has the Req-ID1 with F bit set to 0 before
it starts to assemble the complete P2MP LSP. The
assumption is that the messages are delivered
with order and reliability .
13
Summary

• Planned Implementations 
• We have one vendor who is planning to implement
  the solution. We are in discussions with others
  and we would like to hear from any other vendors
  considering an implementation.
• Outstanding issues
• The authors believe the majority of issues have
  been documented. We would like to hear any
  additional questions or problems. Please contact
  us or email the WG mailing list.

14
Questions and comments?