| Path Computation Element Working Group | O. Dugeon |
| Internet-Draft | J. Meuric |
| Intended status: Standards Track | Orange |
| Expires: September 14, 2017 | March 13, 2017 |
A Backward Recursive PCE-initiated inter-domain LSP Setup
draft-dugeon-brpc-stateful-00
The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE, GMPLS LSP tunnels and Segment Routing paths placement. This also include the ability to compute inter-domain LSPs or Segment Routing path following a distributed or hierarchical approach. In complement to the original stateless mode, a stateful mode has been added. In particular, the new PCInitiate message allows a PCE to directly ask a PCC to setup an MPLS-TE, GMPLS LSP tunnels or a Segment Routing path. However, once computed, the inter-domain LSPs or Segment Routing path are hard to setup in the underlying network. Especially, in operational network, RSVP-TE signaling is not enable between BGP border routers. But, such RSVP-TE signaling is mandatory to setup contiguous LSP tunnels or to stitch or nest independent LSP tunnels to form the end-to-end inter-domain LSP tunnels. This draft propose to combine a Backward Recursive method with PCInitiate message to setup independent LSP tunnels per domain and stitch or nest the different LSP tunnels to setup end-to-end inter-domain LSP tunnels without the need of inter-domain signaling between BGP border routers. A new Stitching Label definition and new LSP-TYPE code points are proposed for that purpose.
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 RFC 2119 [RFC2119].
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 September 14, 2017.
Copyright (c) 2017 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Looking to the different RFCs that describe the PCE architecture and in particular PCE based architecture [RFC4655], PCE protocol [RFC5440], BRPC [RFC5441] and H-PCE [RFC6805], the Path Computation Element (PCE) is able to compute inter-domain path in complement to intra-domain computation. Such inter-domain paths could then serve as the Explicit Route Object input for the RSVP-TE signaling to setup the LSPs tunnel within the underlying network. Three sort of end-to-end LSP tunnels could be established:
In all case, RSVP-TE signaling must be exchange between the different domains. However, from an operational point of view, looking to different networks under the responsibility of different administrative entities, only BGP protocol are setup and configured between AS Border Routers (ASBR). Indeed, to the author's knowledge, there is no example of operational networks that enable RSVP-TE between ASBR. Technology speaking, this is possible and many RFCs describe how to use RSVP-TE at the inter-domain. But, due to security, scalability, management and contract constraints, RSVP-TE is no longer exposed at the network boundary. To circumvent the security issue, RSVP-TE could be carry inside an IPsec tunnel between ASBR, but, this not eliminate the scalability aspect nor the constraints impose by seting up and end-to-end LSP tunnels.
The purpose of this memo is to take the benefit of PCE stateful mode as per draft pce stateful [I-D.ietf-pce-stateful-pce] and draft pce initiated [I-D.ietf-pce-pce-initiated-lsp] to stitch or nest inter-domain LSP tunnels directly using PCEP protocol between domain's PCE instead of using RSVP-TE signaling at the inter-domain while keeping each operator independently setup their respective part of the end-to-end LSP tunnels. PCInitiated message is used in a Backward Recursive way like the PCReq message in BRPC [RFC5441], to recursively setup the end-to-end tunnel. PCRep message is used to automatically stitch or nest the different local LSP tunnels. And, PCRep in conjunction of PCUpd messages are used to maintain, modify and remove end-to-end LSP tunnels.
In the rest of this document, we used the same references as per BRPC [RFC5441] and make the following set of assumptions (see figure below):
+----------------+ +----------------+
| Domain (B) | | Domain (C) |
| | | |
| /-------|---PCEP---|--------\ |
| / | | \ |
| [PCE-B] | | [PCE-C] |
| / (BN)<------>(BN) |
| / | Inter | |
+---|--(BN)------+ Domain +----------------+
| ^ Link
PCEP |
| | Inter-domain Link
| v
+---|--(BN)------+
| | |
| | Domain (A) |
| \ |
| [PCE-A] |
| |
| |
+----------------+
Example of the representation of 3 domains with 3 PCEs
ABR: Area Border Routers. Routers 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.
AS: Autonomous System
Border 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.
Domains: Autonomous System (AS) or IGP Area. An Autonoumous System is composed by one or more IGP area.
Entry BN of domain(i): a BN connecting domain(i-1) to domain(i) along a determined sequence of domains. Multiple entry BN(i) could be used to connect domain(i-1) to domain(i).
Exit BN of domain(i): a BN connecting domain(i) to domain(i+1) along a determined sequence of domains. Multiple exit BN(i) could be used to connect domain(i) to domain(i+1).
Inter-domain LSP tunnel: A LSP tunnel that crosses two or more domains through a per of Border Node.
Local LSP tunnel: A LSP tunnel that do not cross a domain. It is setup between entry BN to exit BN, any source to exit BN or entry BN to any destination of the same domain.
Local LSP tunnel(i): A local LSP tunnel of domain(i)
IGP-TE: Interior Gateway Protocol with Traffic Engineering support. Both OSPF-TE and IS-IS-TE are identified in this category.
Stitching Label (SL): A dedicated label that is used to stitch two RSVP-TE tunnels or two Segment Routing paths.
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.
PCE(i) is a PCE with the scope of domain(i).
This section introduce the concept of Stitching Label that allows stitching and nesting of Local LSP tunnels in order to form inter-domain LSP tunnel that cross several different domains.
The operation of stitch or nest a local LSP tunnel(i) to a local LSP tunnel(i+1) in order to form and inter-domain LSP tunnel simply consist in defining the label that the exit BN(i) will use to send its traffic to the entry BN(i+1). Indeed, the entry BN(i+1) needs to identify the incoming traffic i.e. IP packets, in order to know if this traffic must follow the local LSP tunnel(i+1) or not. Forwarding Equivalent Class (FEC) could be used for that purpose. But, when stitching or nesting tunnels, the FEC is reduce to the incoming label that the entry BN(i+1) as chosen for the local LSP tunnel(i+1).
In this memo, we introduce the named of 'Stitching Label (SL)' to designate this label. Such label is usually exchange between exit BN(i) and entry BN(i+1) with the RSVP-TE signaling. But, as we want to avoid to use RSVP-TE signaling due to operational constraints, this Stitching Label will be convey by PCEP protocol. In fact, the Explicit Route Object (ERO) and the Record Route Object (RRO) are defined in order to transport this Stitching Label in the RSVP-TE signaling. As PCEP protocol used RSVP-TE Objects, and in particular the ERO and ERO, it is able to convey the Stitching Label without any modification of the PCEP protocol nor the PCE or RSVP-TE Objects.
As per RFC4003 [RFC4003], the Stitching Label will be convey as a companion of an IP address. In our case, this is the IP address of the input interface ITF_INPUT(i+1) of BN(i+1) which is connected to the exit BN(i) and which receives the traffic from the domain(i).
However, even if PCEP could convey the Stitching Label, a PCC is not aware that a PCE requests or provides such label. For that purpose, this memo propose to use the LSP-TYPE as defined in draft lsp setup type [I-D.ietf-pce-lsp-setup-type] with new values (See IANA section of this memo) defined as follow:
This section describes how to setup inter-domain LSP tunnels than cross several different domains.
This section describes how PCInitiate and PCRpt messages are combined between PCE in order to setup inter-domain LSP tunnels between a source domain(1) to a destination domain(n). S and D are respectively the source and destination of the inter-domain LSP tunnel. Domain(1) and domain(n) are different and connected through 0 or more intermediate domains denoted domain(i) with i = (2, n-1). Domains are directly connected when n = 2.
First, the PCE(S) run standard BRPC algorithm as per RFC5441 [RFC5441] with its neighbor PCEs in order to compute the inter-domain LSP tunnel from S to D, where S and D are respectively a node in the domain(1) and domain(n). Path Key confidentiality as per RFC5520 [RFC5520] MAY be used to obfuscate the detailed ERO of the different domains(i). The resulting ERO is of the form (S, PKS(1), exit BN(1), ..., entry BN(i), PKS(i), exit BN(i), ..., entry BN(n), PKS(n), D). As subsequent domains are not aware about the final computed ERO in case of multiple VSPT, the final computed ERO MUST be send in the PCInitiate message to indicate to the subsequent PCEs which solution has been finally chosen.
The complete procedure follow the different steps described below:
Steps 1: Initialization
Once ERO(S, D) computed, PCE(1) sends a PCInitiate message to PCE(2) containing and ERO equal to {S, PKS(1), exit BN(1), ..., entry BN(i), PKS(i), exit BN(i), ..., entry BN(n), PKS(n), D}, LSP-TYPE = TBD1 and End-Points Object = (S, D). The ERO corresponds to the one PCE(1) as received from PCE(2) during the BRPC process. In case of multiple EROs, i.e. VSPT > 1, PCE(1) has chosen one of them and used the selected one for the PCInitiate message. PKS(i) could be replaced by the full ERO description if Path Key is not used by PCE(i).
When PCE(i) receives a PCInitiate message from domain(i-1) with LSP-TYPE = TBD1 and ERO = {entry BN(i), PKS(i), exit BN(i), ..., entry BN(n), PKS(n), D)}, it forwards the PCInitiate message to PCE(i+1) once remove its {entry BN(i), PKS(i), exit BN(i)} part from the ERO. All intermediate PCE(i) propagate the PCInitiate message to PCE(i+1) up to the domain(n).
Steps 2: Actions taken at the destination domain(n)
When PCInitiate message propagation reach the destination domain(n), PCE(n) retrieves the ERO from the PKS(n) if necessary and sends to entry BN(n) a PCInitiate message with the ERO(n) = {BN(n), ..., D}, LSP-TYPE= TBD2 and End-Points Object = (BN(n), D) in order to inform the PCC BN(n) that this local LSP tunnel(n) is part of an inter-domain LSP tunnel. When the PCC entry BN(n) received the PCInitiate message from its PCE(n), it setup the LSP tunnels from entry BN(n) to D by means of RSVP-TE signaling with the given ERO(n). Once the tunnel setup, it chooses a free label for the Stitching Label SL(n) and add a new entry in its MPLS LFIB with this SL(n) label. Then, it sends a PCRpt message to its PCE(n) with an RRO equal to {[ITF_INPUT(n), SL(n)], RRO(n)}. Once PCE(n) receives the PCRpt from the PCC BN(n) with the RRO and LSP-TYPE = TBD2, it sends to the PCE(n-1) a PCRpt containing the RRO equal to {[ITF_INPUT(n), SL(n)]}. PCE(n) MAY adds BN(n), D in the RRO as loose path.
Steps i: Actions performed by all intermediate domains(i), for i = 2 to n-1
Steps n: Actions performed at the source domain(1)
Once PCE(1) received the PCRpt message from PCE(2) with the RRO containing the label SL(2), it sends a PCInitiate message to PCC node S with ERO equal to {ERO(1), [ITF_INPUT(2), SL(2)]}, LSP_TYPE = 0 and End-Points Object = {S, BN(1)}. This time, the LSP_TYPE is equal to 0 as the PCC S does not need to return a Stitching Label SL i.e. it is the head-end of the inter-domain LSP tunnel. Standard PCRpt message is sent back to PCE(1) by the PCC node S.
To use Segment Routing instead of RSVP-TE to setup the LSP tunnels as defined in draft pce segment routing [I-D.ietf-pce-segment-routing], PCEs MUST send PCInitiate message with LSP-TYPE = TBD3 instead of TBD2 to advertise their respective PCC that the LSP tunnels is enforce by means of Segment Routing. SL label will be inserted in the label stack in order to become the top label in the stack when the packet reach entry BN(i+). Then, entry BN(i+1) will push a new label stack to reach the exit BN(i+1) and follow.
In the figure below, two different domains S and D are interconnected through BN respectively BN-S and BN-D. PE-S and PE-D are edge routers. All routers in the figure are connected to their respective PCE through PCEP protocol. In this example, PCE(S) would setup an intre-domain LSP tunnel between PE-S and PE-D acting as source and destination of the tunnel. Intermediate routers between (PE-S, BN-S), (BN-D and PE-D) as well as RSVP-TE messages are not represented to simplify the figure. But they are all presents. The following notation is used in the figure:
PE-S PCE-S BN-D PCE-D
| | | |
| [ -------- Standard BRPC exchange ------------]
| | | |
| | PCInitiate(ERO={BN(D), PKS(D)}, LSP-TYPE = TBD1)
| | --------------------------------------> |
| | | |
| | PCInitiate(ERO = ERO(D), LSP-TYPE = TBD2)
| | | <------- |
| | | |
| | PCRpt(RRO = {SL(D), RRO(D)}, LSP-TYPE = TBD2)
| | | ------> |
| | | |
| | PCRpt(RRO = {SL(D), PKS(D)}, LSP-TYPE = TBD1)
| | <-------------------------------------- |
| | | |
| PCInitiate(ERO={ERO(S), SL(D), BN(D)}, LSP-TYPE = 0)
| <------- | | |
| | | |
| PCRpt(RRO={RRO(S)}, LSP-TYPE = 0) | |
| -------> | | |
| | | |
+----------------------+ +----------------------+
| | | |
| +------+ | PCEP | +------+ |
| +---->|PCE(S)|<-------------------------------->|PCE(D)| |
| | +------+ | | +------+ |
| | ^ | | ^ ^ |
| | | | | | | |
| |PCEP | | | | | |
| | |PCEP | | PCEP | | PCEP |
| v | | | | | |
(PE-S) +------> (BN-S) <---------> (BN-D)<----+ +----> (PE-D)
| | Inter-Domain | |
| Domain (S) | Link | Domain (D) |
+----------------------+ +----------------------+
[--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---]
Example of end-to-end LSP tunnel setup between two domains
In case of error during LSP setup, PCRpt and or PCError messages MUST be used to signal the problem to the neighbor PCE domain backward. In particular, if new LSP-TYPE values defined in this memo are not supported by the neighbor PCE or the PCC, the PCE, receptively the PCC, MUST return a PCErr message with Error-Type = 21 (Traffic engineering path setup error) and Error-Value = 1 (Unsupported path setup type) to its neighbor PCE.
If a PCC or a PCE don't return an RRO or an RRO without the Stitching Label SL with the IP address of the associated interface following a PCInitiate message with LSP-TYPE set to the new values defined in this memo, the PCE MUST return a PCErr message with Error-Type = 21 (Traffic engineering path setup error) and Error-Value = TBD4 (No Mandatory Stitching Label is present in the RRO).
In case of completion failure, the PCE(i) MUST propagate the PCErr message up to the PCE(1). In turn, PCE(1) MUST send a PCInitate message (R flag set in the SRP Object as per draft pce initiated lsp [I-D.ietf-pce-pce-initiated-lsp] to delete this inter-domain LSP tunnel to its neighbor PCEs. PCE(i) MUST propagate the PCInitiate message and remove their Local LSP tunnel by means of PCInitiate message to their PCC entry BN(i) and send back PCRpt message to PCE(i-1).
Each domain manages their respective local LSP tunnel part of an inter-domain LSP tunnel independently of each other. In particular, Stitching Label(i) is managed by domain(i) and is of interest of domain(i-1) only. Thus, Stitching Label SL(i) is not supposed to be propagated to other domains.
If a PCE(i) needs to modify its local LSP tunnel(i) with PCUpd message, it MUST sends a new PCRpt message to its neighbor PCE(i-1) to advertise it of the modification, in particular if this concern a modification of Stitching Label SL(i).
PCE(1) could modify the inter-domain LSP tunnel. For that purpose, it MUST sends a PCUpd message to its neighbor PCEs. Each PCE(i) MUST process PCUpd message the same way they process PCInitiate message: first, propagate the PCUpd message up to the destination domain(n), then process the modification once PCRpt received from PCE(i+1) and send PCRpt to PCE(i-1) once modification done.
Modification of Local LSP tunnel, entry BN(i) and exit BN(i) is left for further study.
In case of a failure appear in domain(i), PCE(i) MUST sends a PCRpt message to its neighbor PCE(i-1) to advertise it that its local part of the inter-domain LSP tunnel is down. Once PCE(1) receives this PCRpt message indicating that the tunnel is down, it is up to the PCE(1) to take appropriate correction e.g. start a new BRPC to compute a new ERO.
The newly introduce Stitching Label SL serves to stitch or nest part of LSP tunnels to form an inter-domain LSP tunnel. Each domain is free to decide if the tunnel is stitched or nested. For example, a domain(i) may decided to nest the incoming Local LSP tunnel into a higher hierarchy of tunnel for Traffic Engineering purpose. A PCE(i) may also decided to group Local LSP tunnels part of inter-domain LSP tunnels into a higher hierarchical tunnel to carry all these Local LSP tunnels from one entry BN(i) to one exit BN(i).
The Stitching Label SL could serves to stitch Segment Path and RSVP-TE tunnel. Indeed, each domain is free to enforce its part of the inter-domain LSP tunnel with the underlying mechanism it chosen. Stitching Label SL will be part of the label stack in order to become the top label in the stack when reaching the entry BN(i+1). This Stitching Label could be swap as usual if the next domain that uses RSVP-TE tunnel. When the previous domain uses a RSVP-TE tunnel, the Stitching Label will serve as key for the entry BN(i+1) to determine which label stack it must push on top of the packet for a Segment Routing path.
In inter-layer scenario is left for further study.
Draft pce lsp setup type [I-D.ietf-pce-lsp-setup-type] defines the PATH-SETUP-TYPE TLV and requests that IANA creates a registry to manage the value of the PATH_SETUP_TYPE TLV's PST field. IANA is requested to allocate a new code point in the PCEP PATH_SETUP_TYPE TLV PST field registry, as follows:
| Value | Description | Reference |
|---|---|---|
| TBD1 | Inter-Domain Traffic engineering end-to-end path is setup using Backward Recursive method | This Document |
| TBD2 | Inter-Domain Traffic engineering local path is setup using RSVP-TE | This Document |
| TBD3 | Inter-Domain Traffic engineering local path is setup using Segment Routing | This Document |
IANA is requested to allocate code-points in the PCEP-ERROR Object Error Values registry for a new error-value or Error-Type 21 Invalid traffic engineering path setup:
| Error-Value | Description |
|---|---|
| TBD4 | Missing Mandatory Stitching Label in RRO |
No modification of PCE protocol (PCEP) has been requested by this draft which not introduce any issue regarding security. Concerning the PCEP session between PCEs, authors recommend to use the secure version of PCEP as defined in draft secure transport for PCEP [I-D.ietf-pce-pceps] or use any other secure tunnel mechanism e.g. IPsec tunnel to transport PCEP session between PCE.
The authors want to thanks PCE's WG members.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4655] | Farrel, A., Vasseur, J. and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006. |
| [RFC5440] | Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009. |
| [RFC5441] | Vasseur, JP., Zhang, R., Bitar, N. and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009. |