One document matched: draft-kondreddy-pce-frr-boundary-node-app-01.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="info" docName="draft-kondreddy-pce-frr-boundary-node-app-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="PCE-FRR-BN-APP">Applicability of Path Computation Element (PCE) for Fast Reroute (FRR) Boundary Node protection.</title>
<author initials="V" surname="Kondreddy" fullname="Venugopal Reddy Kondreddy">
<organization>Huawei Technologies India Pvt Ltd</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>venugopalreddyk@huawei.com</email>
</address>
</author>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies India Pvt Ltd</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.dhody@huawei.com</email>
</address>
</author>
<date month="September" year="2012" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>Path computation element (PCE) can be used to compute a label switched path that spans across multiple domains. This document explain the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The Path Computation Element (PCE) <xref target="RFC4655"/> can be used to perform complex path computation in large single domain, multi-domain and multi-layered networks. The PCE can also be used to compute a variety of restoration and protection paths and services.</t>
<t>As stated in <xref target="RFC4090"/>, there are two independent methods (one-to-one backup and facility backup) of doing fast reroute (FRR). PCE can be used to compute backup path for both the methods. Cooperating PCEs may be used to compute inter-domain backup path. </t>
<t>In case of one to one backup method, the destination MUST be the tail-end of the protected LSP. Whereas for facility backup, destination MUST be the address of the merge point (MP) from the corresponding point of local repair (PLR). The problem of finding the MP using the interface addresses or node-ids present in Record Route Object (RRO) of protected path can be easily solved in the case of a single Interior Gateway Protocol (IGP) area because the PLR has the complete Traffic Engineering Database (TED). Thus, the PLR can unambiguously determine - </t>
<t>
<list style="symbols">
<t>The MP address regardless of RRO IPv4 or IPv6 sub-objects (interface address or LSR ID).</t>
<t>Is a backup tunnel intersecting a protected TE LSP on MP node exists? This is the case where facility backup tunnel already exist either due to another protected TE LSP or it is pre-configured.</t>
</list>
</t>
<t>It is complex for a PLR to find the MP in case of boundary node protection for computing a bypass path because the PLR doesn't have the full TED visibility. When confidentiality (via path key) <xref target="RFC5520"/> is enabled, finding MP is very complex. </t>
<t>This document describes the mechanism to find MP and to setup bypass tunnel to protect a boundary node.</t>
<section title="Requirements Language" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <!-- <xref target="RFC2119">RFC 2119</xref> -->RFC2119.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t>
<list style="hanging">
<t hangText="ABR:">Area Border Router. Router used to connect two IGP areas (Areas in OSPF or levels in IS-IS).</t>
<t hangText="ASBR:">Autonomous System Border Router. Router used to connect together ASes of the same or different service providers via one or more inter-AS links.</t>
<t hangText="BN:">Boundary Node (BN) a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the context of inter-AS Traffic Engineering.</t>
<t hangText="CPS:">Confidential Path Segment. A segment of a path that contains nodes and links that the AS policy requires not to be disclosed outside the AS.</t>
<t hangText="CSPF:">Constrained Shorted Path First Algorithm.</t>
<t hangText="ERO:">Explicit Route Object</t>
<t hangText="FRR:">Fast Re-Route</t>
<t hangText="IGP:">Interior Gateway Protocol. Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).</t>
<t hangText="IS-IS:">Intermediate System to Intermediate System.</t>
<t hangText="LSP:">Label Switched Path</t>
<t hangText="LSR:">Label Switching Router</t>
<t hangText="MP:">Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. </t>
<t hangText="OSPF:">Open Shortest Path First.</t>
<t hangText="PCC:">Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element.</t>
<t hangText="PCE:">Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.</t>
<t hangText="PKS:">Path Key Subobject. A subobject of an Explicit Route Object or Record Route Object that encodes a CPS so as to preserve confidentiality.</t>
<t hangText="PLR:">Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP.</t>
<t hangText="RRO:">Record Route Object</t>
<t hangText="RSVP:">Resource Reservation Protocol</t>
<t hangText="TE:">Traffic Engineering.</t>
<t hangText="TED:">Traffic Engineering Database.</t>
</list>
</t>
</section>
<section title="Methods to find MP and calculate the optimal backup path" toc="default">
<t>The Merge Point (MP) address is required at the PLR in order to select a bypass tunnel intersecting a protected Traffic Engineering Label Switched Path (TE LSP) on a downstream LSR.</t>
<t>Some implementations may choose to pre-configure a bypass tunnel on PLR with destination address as MP. MP's Domain to be traversed by bypass path can be administratively configured or learned via some other means (ex Hierarchical PCE (HPCE) <xref target="PCE-HIERARCHY-FWK"/>). Path Computation Client (PCC) on PLR can request its local PCE to compute bypass path from PLR to MP, excluding links and node between PLR and MP. At PLR once primary tunnel is up, a pre-configured bypass tunnel is bound to the primary tunnel, note that multiple bypass tunnel can also exist. </t>
<t>Most implementations may choose to create a bypass tunnel on PLR after primary tunnel is signaled with Record Route Object (RRO) being present in primary path's Resource Reservation Protocol (RSVP) Path Reserve message. MP address has to be determined (described below) to create a bypass tunnel. PCC on PLR can request its local PCE to compute bypass path from PLR to MP, excluding links and node between PLR and MP.</t>
<section title="Intra-domain node protection" toc="default">
<figure title="Node Protection for R3" suppress-title="false" align="left" alt="" width="" height="" anchor="fig1">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
[R1]----[R2]----[R3]----[R4]---[R5]
\ /
[R6]--[R7]--[R8]
Protected LSP Path: [R1->R2->R3->R4->R5]
Bypass LSP Path: [R2->R6->R7->R8->R4]
]]></artwork>
</figure>
<t>In <xref target="fig1"/>, R2 has to build a bypass tunnel that protects against the failure of link [R2->R3] and node [R3]. R2 is PLR and R4 is MP in this case. Since, both PLR and MP belong to the same area. The problem of finding the MP using the interface addresses or node-ids can be easily solved. Thus, the PLR can unambiguously find the MP address regardless of RRO IPv4 or IPv6 sub-objects (interface address or LSR ID) and also determine whether a backup tunnel intersecting a protected TE LSP on a downstream node (MP) already exists. </t>
<t>TED on PLR will have the information of both R2 and R4, which can be used to find MP's TE router IP address and compute optimal backup path from R2 to R4, excluding link [R2->R3] and node [R3].</t>
<t>Thus, RSVP-TE can signal bypass tunnel along the computed path.</t>
</section>
<section title="Boundary node protection" toc="default">
<section title="Area Boundary Router (ABR) node protection" toc="default" anchor="sec_abr">
<figure title="Node Protection for R3 (ABR)" suppress-title="false" align="left" alt="" width="" height="" anchor="fig2">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
|
PCE-1 | PCE-2
|
IGP area 0 | IGP area 1
|
|
[R1]----[R2]----[R3]----[R4]---[R5]
\ | /
[R6]--[R7]--[R8]
|
|
|
Protected LSP Path: [R1->R2->R3->R4->R5]
Bypass LSP Path: [R2->R6->R7->R8->R4]
]]></artwork>
</figure>
<t>In <xref target="fig2"/>, cooperating PCE(s) (PCE-1 and PCE-2) have computed the primary LSP Path [R1->R2->R3->R4->R5] and provided to R1 (PCC).</t>
<t>R2 has to build a bypass tunnel that protects against the failure of link [R2->R3] and node [R3]. R2 is PLR and R4 is MP. Both PLR and MP are in different area. TED on PLR doesn't have the information of R4.</t>
<t>The problem of finding the MP address in a network with inter-domain TE LSP is solved by inserting a node-id sub-object <xref target="RFC4561"/> in the RRO object carried in the RSVP Path Reserve message. PLR can find out the MP from the RRO it has received in Path Reserve message from its downstream LSR.</t>
<t>But the computation of optimal backup path from R2 to R4, excluding link [R2->R3] and node [R3] is not possible with running of Constrained Shortest Path First (CSPF) algorithm locally at R2. PCE can be used to compute backup path in this case. R2 acting as PCC on PLR can request PCE-1 to compute bypass path from PLR(R2) to MP(R4), excluding link [R2->R3] and node [R3]. PCE MAY use inter-domain path computation mechanism (like HPCE (<xref target="PCE-HIERARCHY-FWK"/>) etc) when the domain information of MP is unknown at PLR. Further, RSVP-TE can signal bypass tunnel along the computed path.</t>
</section>
<section title="Autonomous System Border Router (ASBR) node protection" toc="default">
<figure title="Node Protection for R3 (ASBR)" suppress-title="false" align="left" alt="" width="" height="" anchor="fig3">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
| |
PCE-1 | | PCE-2
| |
AS 100 | | AS 200
| |
| |
[R1]----[R2]-------[R3]---------[R4]---[R5]
|\ | /
| +-----[R6]--[R7]--[R8]
| |
| |
Protected LSP Path: [R1->R2->R3->R4->R5]
Bypass LSP Path: [R2->R6->R7->R8->R4]
]]></artwork>
</figure>
<t>In <xref target="fig3"/>, Links [R2->R3] and [R2->R6] are inter-AS links. IGP extensions (<xref target="RFC5316"/> and <xref target="RFC5392"/>) describe the flooding of inter-AS TE information for inter-AS path computation. Cooperating PCE(s) (PCE-1 and PCE-2) have computed the primary LSP Path [R1->R2->R3->R4->R5] and provided to R1 (PCC).</t>
<t>R2 is PLR and R4 is MP. Both PLR and MP are in different AS. TED on PLR doesn't have the information of R4.</t>
<t>The address of MP can be found using node-id sub-object <xref target="RFC4561"/> in the RRO object carried in the RSVP Path Reserve message. And Cooperating PCEs could be used to compute the inter-AS bypass path. Thus ASBR boundary node protection is similar to ABR protection.</t>
</section>
<section title="Boundary node protection with Path-Key Confidentiality" toc="default">
<t><xref target="RFC5520"/> defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. </t>
<t><xref target="RFC5553"/> states that, when the signaling message crosses a domain boundary, the path segment that needs to be hidden (that is, a CPS) MAY be replaced in the RRO with a PKS. Note that RRO in Path Reserve message carries the same PKS as originally signaled in the ERO of the Path message.</t>
<section title="Area Boundary Router (ABR) node protection" toc="default">
<figure title="Node Protection for R3 (ABR) and Path-Key" suppress-title="false" align="left" alt="" width="" height="" anchor="fig4">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
|
PCE-1 | PCE-2
|
IGP area 0 | IGP area 1
|
|
[R1]----[R2]----[R3]----[R4]---[R5]---[R9]
\ | /
[R6]--[R7]--[R8]
|
|
|
]]></artwork>
</figure>
<t>In <xref target="fig4"/>, when path-key is enabled, cooperating PCE(s) (PCE-1 and PCE-2) have computed the primary LSP Path [R1->R2->R3->PKS->R9] and provided to R1 (PCC). </t>
<t>When the ABR node (R3) replaces the CPS with PKS (as originally signaled) during the Path Reserve message handling, it MAY also add the immediate downstream node-id (R4) (so that the PLR (R2) can identify the MP (R4)). Further the PLR (R2) SHOULD remove the MP node-id (R4) before sending the path reserve message upstream to head end router. </t>
<t>Once MP is identified, the backup path computation using PCE is as described earlier. (<xref target="sec_abr"/>)</t>
</section>
<section title="Autonomous System Border Router (ASBR) node protection" toc="default">
<figure title="Node Protection for R3 (ASBR)" suppress-title="false" align="left" alt="" width="" height="" anchor="fig5">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
| |
PCE-1 | | PCE-2
| |
AS 100 | | AS 200
| |
| |
[R1]----[R2]-------[R3]---------[R4]---[R5]
|\ | /
| +-----[R6]--[R7]--[R8]
| |
| |
]]></artwork>
</figure>
<t>The address of MP can be found using the same mechanism as explained above. Thus ASBR boundary node protection is similar to ABR protection.</t>
</section>
</section>
</section>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>TBD</t>
</section>
<section title="Information and Data Models" toc="default">
<t>TBD</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>TBD</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>TBD</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>TBD</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>TBD</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document does not introduce new security issues. However, MP's node-id is carried as subobject in RRO across domain. This relaxation is required to find MP in case of BN protection. The security considerations pertaining to the <xref target="RFC3209"/>, <xref target="RFC4090"/> and <xref target="RFC5440"/> protocols remain relevant.</t>
</section>
<section title="IANA Considerations" toc="default">
<t>TBD </t>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Sandeep Boina & Reeja Paul for their useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.4655.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3209.xml" ?>
<?rfc include="reference.RFC.4090.xml" ?>
<?rfc include="reference.RFC.4561.xml" ?>
<?rfc include="reference.RFC.5316.xml" ?>
<?rfc include="reference.RFC.5392.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5520.xml" ?>
<?rfc include="reference.RFC.5553.xml" ?>
<!--PCE-HIERARCHY-FWK-->
<reference anchor="PCE-HIERARCHY-FWK">
<front>
<title>The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS. (draft-ietf-pce-hierarchy-fwk-05)</title>
<author initials="D" surname="King" fullname="King D">
<organization />
</author>
<author initials="A" surname="Farrel" fullname="Farrel A">
<organization />
</author>
<date month="August" year="2012" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 12:07:50 |