1 / 14

Quintin Zhao, qzhao@huawei Daniel King, daniel@olddog.co.uk

Update on PCEP Extensions for P2MP LSP draft-ietf-pce-pcep-p2mp-extensions-01.txt. Quintin Zhao, qzhao@huawei.com Daniel King, daniel@olddog.co.uk Fabien Verhaeghe, fabien.verhaeghe@marben-products.com Tomonori Takeda, takeda.tomonori@lab.ntt.co.jp

fran
Download Presentation

Quintin Zhao, qzhao@huawei Daniel King, daniel@olddog.co.uk

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Update on PCEP Extensions for P2MP LSP draft-ietf-pce-pcep-p2mp-extensions-01.txt Quintin Zhao, qzhao@huawei.com Daniel King, daniel@olddog.co.uk Fabien Verhaeghe, fabien.verhaeghe@marben-products.com Tomonori Takeda, takeda.tomonori@lab.ntt.co.jp Mohamad Chaitou, Mohamad.Chaitou@orange-ftgroup.com Jean-Louis Le Roux, Jeanlouis.Leroux@orange-ftgroup.com Zafar Ali, zali@cisco.com IETF73, Minneapolis, MN, USA

  2. Contents • New Requirement • Proposed solution and an alternative Solution • Examples: • 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 ExtensionThe proposed Request Message Format <PCReq Message>::= <Common Header> [<SVEC-list>] <request-list> where: <svec-list>::=<SVEC>[<svec-list>] <request-list>::=<request>[<request-list>] <request>::= <RP withP2MP Ext.> <end-point-rro-pair-list> [<BANDWIDTH>] [<LSPA>] [<metric-list>] Where: <end-point-rro-pair-list>::=<END-POINTS>[<rro-list>][<BANDWIDTH>] [<end-point-rro-pair-list>]

  5. ProposedReply Message Format <PCRep Message>::= <Common Header> [<SVEC-list>] <response-list> where: <svec-list>::=<SVEC>[<svec-list>] <response-list>::=<response>[<response-list>] <response>::=<RP with P2MP flag> [<end-point-path-pair-list>] [<NO-PATH>] [<attribute-list>] where: <end-point-path-pair-list>::= [<END-POINTS>]<path-list>[<end-point-path-pair-list>] <path-list> ::= <ERO>|<SERO>[<path-list>] <attribute-list>::=[<OF>] [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>]

  6. Example 1 of P2MP: Issue (Problem: the message which is too big to fit into one single request message) Path Computation Request Message <PCReq Message1>::= <Common Header> <request> where: <request>::=<RP with Req-ID1andP2MP flag> <end-point-rro-pair1 - new leaves> <end-point-rro-pair2 – Old leaves, path can be optimized> <end-point-rro-pair3 - Old leaves, path can not be changed>

  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 <PCReq Message1>::= <Common Header> <SEVC with Req-ID1 repeated twice> <request> where: <request>::=<RP with Req-ID1andP2MP flag> <end-point-rro-pair1 - new leaves> <end-point-rro-pair2 – existing leaves, path can be optimized> <PCReq Message2>::= <Common Header> <request> where: <request>::=<RP with Req-ID1 andP2MP flag> <end-point-rro-pair3 - existing leaves, path can not be changed> 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 <PCRep Message>::= <Common Header> <response> where: <response>::=<RP with Req-ID1 and P2MP flag> <END-POINTS1> <ERO1><SER1-1>….<SERO1-100> <END-POINTS2> <ERO2><SER2-1>….<SERO2-100> <END-POINTS3> <ERO3><SER3-1>….<SERO3-100>

  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 <PCRep Message1>::= <Common Header> <SEVC with Req-ID1 repeated twice> <response> where: <response>::=<RP with Req-ID1 and P2MP flag> <END-POINTS1> <ERO1><SER1-1>….<SERO1-100> <END-POINTS2> <ERO2><SER2-1>….<SERO2-100> <PCRep Message2>::= <Common Header> <response> where: <response>::=<RP with Req-ID1 and P2MP flag> <END-POINTS3> <ERO3><SER3-1>….<SERO3-100> 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 <PCReq Message1>::= <Common Header> <request> where: <request>::=<RP with Req-ID1andP2MP flag and F bit set to 1> <end-point-rro-pair1 - new leaves> <end-point-rro-pair2 – existing leaves , path can be optimized> <PCReq Message2>::= <Common Header> <request> where: <request>::=<RP with Req-ID1 andP2MP flag and F bit set to 0> <end-point-rro-pair3 - existing leaves, path can not changed > 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 <PCRep Message1>::= <Common Header> <response> where: <response>::=<RP with Req-ID1 and P2MP flag and F bit is set to 1> <END-POINTS1> <ERO1><SER1-1>….<SERO1-100> <END-POINTS2> <ERO2><SER2-1>….<SERO2-100> <PCRep Message2>::= <Common Header> <response> where: <response>::=<RP with Req-ID1 and P2MP flag and F bit is set to 0 > <END-POINTS3> <ERO3><SER3-1>….<SERO3-100> 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?

More Related