Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Venugopal Reddy Kondreddy , Dhruv Dhody
Last updated 2012-07-09
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kondreddy-pce-frr-boundary-node-app-00
PCE Working Group                                           V. Kondreddy
Internet-Draft                                                  D. Dhody
Intended status: Informational             Huawei Technologies India Pvt
Expires: January 10, 2013                                            Ltd
                                                            July 9, 2012

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

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.  In case of boundary node
   protection when PCE confidentiality (path key) is enabled, new
   mechanisms are suggested in this document.

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 January 10, 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

Kondreddy & Dhody       Expires January 10, 2013                [Page 1]
Internet-Draft               PCE-FRR-BN-APP                    July 2012

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   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 . . . . . . . . . . . . . . . . . . . . 11
   4.  Manageability Considerations . . . . . . . . . . . . . . . . . 11
     4.1.  Control of Function and Policy . . . . . . . . . . . . . . 11
     4.2.  Information and Data Models  . . . . . . . . . . . . . . . 11
     4.3.  Liveness Detection and Monitoring  . . . . . . . . . . . . 11
     4.4.  Verify Correct Operations  . . . . . . . . . . . . . . . . 11
     4.5.  Requirements On Other Protocols  . . . . . . . . . . . . . 11
     4.6.  Impact On Network Operations . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12

Kondreddy & Dhody       Expires January 10, 2013                [Page 2]
Internet-Draft               PCE-FRR-BN-APP                    July 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  Is a backup tunnel intersecting a protected TE LSP on a downstream
      node exists?

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

   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 January 10, 2013                [Page 3]
Internet-Draft               PCE-FRR-BN-APP                    July 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 January 10, 2013                [Page 4]
Internet-Draft               PCE-FRR-BN-APP                    July 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 January 10, 2013                [Page 5]
Internet-Draft               PCE-FRR-BN-APP                    July 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 determine
   whether a backup tunnel intersecting a protected TE LSP on a
   downstream node exists and can also find the MP address regardless of
   RRO IPv4 or IPv6 sub-objects (interface address or LSR ID).

   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 January 10, 2013                [Page 6]
Internet-Draft               PCE-FRR-BN-APP                    July 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 January 10, 2013                [Page 7]
Internet-Draft               PCE-FRR-BN-APP                    July 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).  Note that there isn't a way to identify the MP
   when path-key is enabled i.e. using node-id subobject will not work.

3.2.3.1.1.  Option 1: New MP Subobject

   In Figure 4, on receiving ERO at R3 with PKS, it SHOULD request the
   PCE identified by PCE-ID in path key subobject to expand the path
   segment and on receiving RRO it should replace the CPS with the same
   PKS and append its own RRO subobjects.  The boundary node can also
   append the identity of the MP.

   Note that the RRO in Path Reserve Messages can be carried as it is as
   ERO in Path Message.  So if we use the same node-id object as
   described in [RFC4561] along with PKS it will lead to a looping issue

Kondreddy & Dhody       Expires January 10, 2013                [Page 8]
Internet-Draft               PCE-FRR-BN-APP                    July 2012

   as explained below -

   In Figure 4, at R1 the RRO received will be [R1->R2->R3->R4->PKS->R9]
   with R4 as the node-id subobject added by R3. if this path is
   signaled using the ERO, after expansion of PKS at node R3, will lead
   to presence of R4 twice leading to loop.  Note that the issue exists
   irrespective of the ordering of PKS and Node-id subobject.

   Hence there is a need for a new sub-object to identify the MP incase
   of path-key.  This sub-object should be added by the boundary node
   (R3) during the RRO Path key processing.  The PLR can use the MP sub-
   object to identify the MP.  To avoid the looping issue, the immediate
   upstream LSR (usually PLR) should remove this sub-object from the RRO
   at the time of RRO processing.

   [RFC3209] defines the IPv4 and IPv6 RRO subobjects.

   In this document, we define the following new flag:

   MP-id: 0x40 (TBA)

   When set, this indicates that the address specified in the RRO's IPv4
   or IPv6 sub-object is a MP-id address, which refers to the "Router
   Address" of the MP as defined in [RFC3630], or "Traffic Engineering
   Router ID" as defined in [RFC5305].

   An IPv4 or IPv6 RRO sub-object with the MP-id flag set is also called
   a MP-id sub-object.  The problem of finding an MP address when
   pathkey is enabled in a network with inter-domain TE LSP is solved by
   inserting a MP-id sub-object (an RRO "IPv4" and "IPv6" sub-object
   with the 0x40 flag (TBA) set) in the RRO object carried in the RSVP
   Path Reserve message.

3.2.3.1.2.  Option 2: PCE Path-key Handling

   In Figure 4, when path-key is enabled, PCE-2 will replace the segment
   [R3->R4->R5->R9] with [R3->PKS->R9].  To enable FRR protection with
   path-key, following change should be done -

   o  Scope of confidential path segment is relaxed to immediate
      downstream node i.e.  [R3->R4->PKS->R9] note that R3->R4 MAYBE the
      address of the interface instead of LSR-ID.

   o  Pathkey expansion during signaling would be done at the immediate
      downstream node of the boundary node.  Note that this node must
      have PCC functionality.

Kondreddy & Dhody       Expires January 10, 2013                [Page 9]
Internet-Draft               PCE-FRR-BN-APP                    July 2012

   o  This facilitates the insertion of node-id sub-object [RFC4561] in
      the RRO object from immediate next downstream node of BN in the
      RSVP Path Reserve message and aids the PLR in previous domain to
      determine MP

   In Figure 4, during RSVP signaling, on receiving ERO at R4 with PKS,
   it SHOULD request the PCE identified by PCE-ID in path key subobject
   to expand the path segment and on receiving RRO it should replace the
   CPS with the same PKS and append its RRO subobjects including Node-id
   subobject.

   On successful signaling of primary tunnel, R2 has to build a bypass
   tunnel that protects against the failure of link [R2->R3] and node
   [R3].  Note that by above mechanism PLR (R2) knows the identity of MP
   (R4) via the RRO Node-id subobject.

   Also consider the case of R4 node protection within a single IGP
   area.  R3 is PLR and R5 should become MP.

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

                     Figure 5: Node Protection for R4

   In Figure 5, RRO received in RSVP Path Reserve message at R3 contains
   [R3->R4->PKS->R9].  Since there is no node-id sub-object in RRO
   beyond R4, R3 may not be able to find R5 as MP without expansion of
   PKS.  R3 SHOULD request the PCE identified by PCE-ID in PKS to expand
   the path segment.  Note that, the PCE should retain the pathkey for
   some time as multiple expansion requests will be issued.  R3 can now
   find the identity of MP (R5).

Kondreddy & Dhody       Expires January 10, 2013               [Page 10]
Internet-Draft               PCE-FRR-BN-APP                    July 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 6: 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 January 10, 2013               [Page 11]
Internet-Draft               PCE-FRR-BN-APP                    July 2012

5.  Security Considerations

   PCE(s) when computes the inter-domain path will generate PKS relaxing
   the path from BN to next immediate downstream router.  (Refer
   Section 3.2.3.1.2) This relaxation is required to find MP in case of
   BN node protection.  This may be an added security risk.  Note that
   the facility backup method requires that a PLR and its selected MP
   trust RSVP messages received from each other.

   Further analysis must be done.

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.

   [RFC3630]            Katz, D., Kompella, K., and D. Yeung, "Traffic
                        Engineering (TE) Extensions to OSPF Version 2",
                        RFC 3630, September 2003.

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

Kondreddy & Dhody       Expires January 10, 2013               [Page 12]
Internet-Draft               PCE-FRR-BN-APP                    July 2012

                        "Definition of a Record Route Object (RRO)
                        Node-Id Sub-Object", RFC 4561, June 2006.

   [RFC5305]            Li, T. and H. Smit, "IS-IS Extensions for
                        Traffic Engineering", RFC 5305, October 2008.

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

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

   [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-04)",
                        June 2012.

Authors' Addresses

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

   EMail: venugopalreddyk@huawei.com

Kondreddy & Dhody       Expires January 10, 2013               [Page 13]
Internet-Draft               PCE-FRR-BN-APP                    July 2012

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

   EMail: dhruv.dhody@huawei.com

Kondreddy & Dhody       Expires January 10, 2013               [Page 14]