PCE Working Group                                           V. Kondreddy
Internet-Draft                                                  D. Dhody
Intended status: Informational             Huawei Technologies India Pvt
Expires: March 9, 2013                                               Ltd
                                                       September 5, 2012


 Applicability of Path Computation Element (PCE) for Fast Reroute (FRR)
                       Boundary Node protection.
              draft-kondreddy-pce-frr-boundary-node-app-01

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 9, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Kondreddy & Dhody         Expires March 9, 2013                 [Page 1]


Internet-Draft               PCE-FRR-BN-APP               September 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Methods to find MP and calculate the optimal backup path . . .  5
     3.1.  Intra-domain node protection . . . . . . . . . . . . . . .  5
     3.2.  Boundary node protection . . . . . . . . . . . . . . . . .  6
       3.2.1.  Area Boundary Router (ABR) node protection . . . . . .  6
       3.2.2.  Autonomous System Border Router (ASBR) node
               protection . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.3.  Boundary node protection with Path-Key
               Confidentiality  . . . . . . . . . . . . . . . . . . .  8
         3.2.3.1.  Area Boundary Router (ABR) node protection . . . .  8
         3.2.3.2.  Autonomous System Border Router (ASBR) node
                   protection . . . . . . . . . . . . . . . . . . . .  9
   4.  Manageability Considerations . . . . . . . . . . . . . . . . .  9
     4.1.  Control of Function and Policy . . . . . . . . . . . . . .  9
     4.2.  Information and Data Models  . . . . . . . . . . . . . . .  9
     4.3.  Liveness Detection and Monitoring  . . . . . . . . . . . .  9
     4.4.  Verify Correct Operations  . . . . . . . . . . . . . . . .  9
     4.5.  Requirements On Other Protocols  . . . . . . . . . . . . .  9
     4.6.  Impact On Network Operations . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10



















Kondreddy & Dhody         Expires March 9, 2013                 [Page 2]


Internet-Draft               PCE-FRR-BN-APP               September 2012


1.  Introduction

   The Path Computation Element (PCE) [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.

   As stated in [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.

   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 -

   o  The MP address regardless of RRO IPv4 or IPv6 sub-objects
      (interface address or LSR ID).

   o  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.

   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)
   [RFC5520] is enabled, finding MP is very complex.

   This document describes the mechanism to find MP and to setup bypass
   tunnel to protect a boundary node.

1.1.  Requirements Language

   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 RFC2119.

2.  Terminology

   The following terminology is used in this document.




Kondreddy & Dhody         Expires March 9, 2013                 [Page 3]


Internet-Draft               PCE-FRR-BN-APP               September 2012


   ABR:  Area Border Router.  Router used to connect two IGP areas
      (Areas in OSPF or levels in IS-IS).

   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.

   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.

   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.

   CSPF:  Constrained Shorted Path First Algorithm.

   ERO:  Explicit Route Object

   FRR:  Fast Re-Route

   IGP:  Interior Gateway Protocol.  Either of the two routing
      protocols, Open Shortest Path First (OSPF) or Intermediate System
      to Intermediate System (IS-IS).

   IS-IS:  Intermediate System to Intermediate System.

   LSP:  Label Switched Path

   LSR:  Label Switching Router

   MP:  Merge Point.  The LSR where one or more backup tunnels rejoin
      the path of the protected LSP downstream of the potential failure.

   OSPF:  Open Shortest Path First.

   PCC:  Path Computation Client: any client application requesting a
      path computation to be performed by a Path Computation Element.

   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.

   PKS:  Path Key Subobject.  A subobject of an Explicit Route Object or
      Record Route Object that encodes a CPS so as to preserve
      confidentiality.




Kondreddy & Dhody         Expires March 9, 2013                 [Page 4]


Internet-Draft               PCE-FRR-BN-APP               September 2012


   PLR:  Point of Local Repair.  The head-end LSR of a backup tunnel or
      a detour LSP.

   RRO:  Record Route Object

   RSVP:  Resource Reservation Protocol

   TE:  Traffic Engineering.

   TED:  Traffic Engineering Database.

3.  Methods to find MP and calculate the optimal backup path

   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.

   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) [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.

   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.

3.1.  Intra-domain node protection

              [R1]----[R2]----[R3]----[R4]---[R5]
                        \             /
                        [R6]--[R7]--[R8]

             Protected LSP Path: [R1->R2->R3->R4->R5]
             Bypass LSP Path:    [R2->R6->R7->R8->R4]


                     Figure 1: Node Protection for R3

   In Figure 1, R2 has to build a bypass tunnel that protects against



Kondreddy & Dhody         Expires March 9, 2013                 [Page 5]


Internet-Draft               PCE-FRR-BN-APP               September 2012


   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.

   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].

   Thus, RSVP-TE can signal bypass tunnel along the computed path.

3.2.  Boundary node protection

3.2.1.  Area Boundary Router (ABR) node protection

                             |
                   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]


                  Figure 2: Node Protection for R3 (ABR)

   In Figure 2, cooperating PCE(s) (PCE-1 and PCE-2) have computed the
   primary LSP Path [R1->R2->R3->R4->R5] and provided to R1 (PCC).

   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.

   The problem of finding the MP address in a network with inter-domain
   TE LSP is solved by inserting a node-id sub-object [RFC4561] in the
   RRO object carried in the RSVP Path Reserve message.  PLR can find



Kondreddy & Dhody         Expires March 9, 2013                 [Page 6]


Internet-Draft               PCE-FRR-BN-APP               September 2012


   out the MP from the RRO it has received in Path Reserve message from
   its downstream LSR.

   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 ([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.

3.2.2.  Autonomous System Border Router (ASBR) node protection

                              |        |
                        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]


                  Figure 3: Node Protection for R3 (ASBR)

   In Figure 3, Links [R2->R3] and [R2->R6] are inter-AS links.  IGP
   extensions ([RFC5316] and [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).

   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.

   The address of MP can be found using node-id sub-object [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.





Kondreddy & Dhody         Expires March 9, 2013                 [Page 7]


Internet-Draft               PCE-FRR-BN-APP               September 2012


3.2.3.  Boundary node protection with Path-Key Confidentiality

   [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.

   [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.

3.2.3.1.  Area Boundary Router (ABR) node protection

                             |
                   PCE-1     |     PCE-2
                             |
                  IGP area 0 |  IGP area 1
                             |
                             |
            [R1]----[R2]----[R3]----[R4]---[R5]---[R9]
                    \        |       /
                    [R6]--[R7]--[R8]
                             |
                             |
                             |


            Figure 4: Node Protection for R3 (ABR) and Path-Key

   In Figure 4, 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).

   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.

   Once MP is identified, the backup path computation using PCE is as
   described earlier.  (Section 3.2.1)






Kondreddy & Dhody         Expires March 9, 2013                 [Page 8]


Internet-Draft               PCE-FRR-BN-APP               September 2012


3.2.3.2.  Autonomous System Border Router (ASBR) node protection

                              |        |
                        PCE-1 |        | PCE-2
                              |        |
                       AS 100 |        | AS 200
                              |        |
                              |        |
                   [R1]----[R2]-------[R3]---------[R4]---[R5]
                              |\       |            /
                              | +-----[R6]--[R7]--[R8]
                              |        |
                              |        |



                  Figure 5: Node Protection for R3 (ASBR)

   The address of MP can be found using the same mechanism as explained
   above.  Thus ASBR boundary node protection is similar to ABR
   protection.

4.  Manageability Considerations

4.1.  Control of Function and Policy

   TBD

4.2.  Information and Data Models

   TBD

4.3.  Liveness Detection and Monitoring

   TBD

4.4.  Verify Correct Operations

   TBD

4.5.  Requirements On Other Protocols

   TBD

4.6.  Impact On Network Operations

   TBD




Kondreddy & Dhody         Expires March 9, 2013                 [Page 9]


Internet-Draft               PCE-FRR-BN-APP               September 2012


5.  Security Considerations

   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 [RFC3209], [RFC4090] and
   [RFC5440] protocols remain relevant.

6.  IANA Considerations

   TBD

7.  Acknowledgments

   We would like to thank Sandeep Boina & Reeja Paul for their useful
   comments and suggestions.

8.  References

8.1.  Normative References

   [RFC2119]            Bradner, S., "Key words for use in RFCs to
                        Indicate Requirement Levels", BCP 14, RFC 2119,
                        March 1997.

   [RFC4655]            Farrel, A., Vasseur, J., and J. Ash, "A Path
                        Computation Element (PCE)-Based Architecture",
                        RFC 4655, August 2006.

8.2.  Informative References

   [RFC3209]            Awduche, D., Berger, L., Gan, D., Li, T.,
                        Srinivasan, V., and G. Swallow, "RSVP-TE:
                        Extensions to RSVP for LSP Tunnels", RFC 3209,
                        December 2001.

   [RFC4090]            Pan, P., Swallow, G., and A. Atlas, "Fast
                        Reroute Extensions to RSVP-TE for LSP Tunnels",
                        RFC 4090, May 2005.

   [RFC4561]            Vasseur, J., Ali, Z., and S. Sivabalan,
                        "Definition of a Record Route Object (RRO)
                        Node-Id Sub-Object", RFC 4561, June 2006.

   [RFC5316]            Chen, M., Zhang, R., and X. Duan, "ISIS
                        Extensions in Support of Inter-Autonomous System
                        (AS) MPLS and GMPLS Traffic Engineering",
                        RFC 5316, December 2008.



Kondreddy & Dhody         Expires March 9, 2013                [Page 10]


Internet-Draft               PCE-FRR-BN-APP               September 2012


   [RFC5392]            Chen, M., Zhang, R., and X. Duan, "OSPF
                        Extensions in Support of Inter-Autonomous System
                        (AS) MPLS and GMPLS Traffic Engineering",
                        RFC 5392, January 2009.

   [RFC5440]            Vasseur, JP. and JL. Le Roux, "Path Computation
                        Element (PCE) Communication Protocol (PCEP)",
                        RFC 5440, March 2009.

   [RFC5520]            Bradford, R., Vasseur, JP., and A. Farrel,
                        "Preserving Topology Confidentiality in Inter-
                        Domain Path Computation Using a Path-Key-Based
                        Mechanism", RFC 5520, April 2009.

   [RFC5553]            Farrel, A., Bradford, R., and JP. Vasseur,
                        "Resource Reservation Protocol (RSVP) Extensions
                        for Path Key Support", RFC 5553, May 2009.

   [PCE-HIERARCHY-FWK]  King, D. and A. Farrel, "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)",
                        August 2012.

Authors' Addresses

   Venugopal Reddy Kondreddy
   Huawei Technologies India Pvt Ltd
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: venugopalreddyk@huawei.com


   Dhruv Dhody
   Huawei Technologies India Pvt Ltd
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: dhruv.dhody@huawei.com









Kondreddy & Dhody         Expires March 9, 2013                [Page 11]