Internet DRAFT - draft-kondreddy-pce-frr-boundary-node-app
draft-kondreddy-pce-frr-boundary-node-app
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]