| PCE WG | Quan Xiong |
| Internet-Draft | Fangwei Hu |
| Intended status: Standards Track | Greg Mirsky |
| Expires: January 8, 2020 | ZTE Corporation |
| Weiqiang Cheng | |
| China Mobile | |
| July 7, 2019 |
Stateful PCE for SR-MPLS Inter-domain
draft-xiong-pce-stateful-pce-sr-inter-domain-01
This document proposes two solutions to perform the Segment Routing with MPLS data plane (SR-MPLS) inter-domain path computation and initiation with stateful PCEs and the use of Path Segment.
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 https://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 8, 2020.
Copyright (c) 2019 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 (https://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.
The Path Computation Element (PCE) architecture is defined in [RFC4655] for MPLS Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks. The Path Computation Element Communication Protocol (PCEP) defined in [RFC5440] provides mechanisms for PCEs to perform path computations in response to Path Computation Clients (PCCs) requests.
[I-D.ietf-pce-segment-routing] proposes extensions to PCEP that allow a stateful PCE to compute TE paths in segment routing (SR) networks. As defined in [I-D.ietf-spring-mpls-path-segment], a path segment is used to identify a SR path and support bidirectional SR paths correlation. [I-D.li-pce-sr-path-segment] proposed the extension for PCEP to operate with Path Segment. [I-D.li-pce-sr-bidir-path] proposed the extension for PCEP to group two unidirectional SR Paths into an Associated Bidirectional SR Path. [I-D.xiong-spring-path-segment-sr-inter-domain] proposes the use of Path Segment in inter-domain scenarios for SR-MPLS network. It is required to perform the SR inter-domain path computation and initiation with PCE deployment.
The path computation requirments for Label Switched Paths (LSPs) across multiple domains are discussed in [RFC4105] and [RFC4216]. Inter-domain path computation can be performed by a single stateful PCE and multiple stateful PCEs. The PCE may has no ability to collect the topologies all over the domains. So the single PCE model is not applied in deployment. Three multiple PCEs models can be uesd to perform PCE-based inter-domain path computation including Per-Domain Path Computation [RFC5152], Backward-Recursive PCE-Based Computation (BRPC) [RFC5441] and Hierarchical PCE (H-PCE) [RFC6805]. Computing the optimum inter-domain path requires co-operation between multiple PCEs. But the sequence of domains need to be known before the path computation in BRPC mechanism. Stateful H-PCE architecture is appropriate to compute an optimal end-to-end path across multiple domains.
As defined in [I-D.xiong-spring-path-segment-sr-inter-domain], the SR-MPLS inter-domain models includes stitching and nesting inter-domain models between inter-Area or inter-AS domains. This document proposes two solutions to perform the SR-MPLS inter-domain path computation and initiation with stateful PCEs and the use of Path Segment.
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].
The terminology is defined as [RFC5440], [I-D.ietf-pce-segment-routing] , [I-D.ietf-spring-mpls-path-segment].
The SR-MPLS inter-domain scenario is described in [I-D.xiong-spring-path-segment-sr-inter-domain]. The domains of the networks may be IGP Areas or ASes and the inter- domain scenario may be inter-Area or inter-AS. The multiple SR-MPLS domains may be interconnect with a ABR within areas or inter-link between ASes. As the Figure 1 shown, SR-AS1, SR-AS2 and SR-AS3 interconnect with logical links and SR-Area1, SR-Area2 and SR-Area3 interconnect within border nodes. The SR end-to-end bidirectional LSP needs to be provided along the multi-domain paths. The Path 1~5 are forwarding path segments and Path 1'~5' are the related reverse path segments and these are all inter-domain path segments.
+-------+
+------------------+ H-PCE +-------------------+
| +---+---+ |
| | |
v v v
+--+--+ +--+--+ +--+--+
|PCE-1| |PCE-2| |PCE-3|
+--+--+ +--+--+ +--+--+
| | |
v v v
SR Inter-Area:
.................. ................. ....................
. . . . . .
+-----+ +-----+ +-----+ +-----+
| A | | X | | Y | | Z |
+-----+ +-----+ +-----+ +-----+
. SR-Area1 . . SR-Area2 . . SR-Area3 .
.................. ................. ....................
Forwarding Path Segments:
|------Path1------->|-----Path2------->|--------Path3------>|
Reverse Path Segments:
|<-----Path1'-------|<----Path2'-------|<--------Path3'-----|
SR Inter-AS:
.................... .................... .....................
. . . . . .
. +---+ +---+ . . +---+ +---+ . . +---+ +----+ .
. | A |------| B |-------| C |-----| X |---------| Y |-----| Z | .
. +---+ +---+ . . +---+ +---+ . . +---+ +----+ .
. SR-AS1 . . SR-AS2 . . SR-AS3 .
.................... .................... .....................
Forwarding Path Segments:
|----Path1---->|-Path2-->|----Path3--->|-Path4-->|-----Path5------>|
Reverse Path Segments:
|<---Path1'----|<-Path2'-|<---Path3'---|<-Path4'-|<----Path5'------|
Figure 1 The SR Inter-Domain with H-PCE
The hierarchical PCE architecture is described in [RFC6805], a parent PCE maintains a domain topology map that contains the child domains (seen as vertices in the topology) and their interconnections (links in the topology) but no information about the content of the child domains. Each child domain has one PCE taking in charge of computing paths across its own domain. These PCEs are known as child PCEs and have a relationship with the parent PCE. As the Figure 1 shown, H-PCE is parent PCE and PCE-1, PCE-2 and PCE-3 are child PCEs which is responsible for each own SR-AS.
When an optimal inter-domain path is required, the ingress PCE sends a request to the parent PCE or the stateful parent PCE itself to initiate the path computation. The parent PCE selects a set of candidate domain paths based on the domain topology and the state of the inter-domain links. It then sends computation requests to the child PCEs responsible for each of the domains on the candidate domain paths. The stateful child PCE in each domain performs active stateful procedure as defined [RFC8231].
The LSPs of multiple domains can be stitched together by adding them to a stitching LSP association group as defined in [I-D.hu-pce-stitching-lsp-association]. As the Figure 2 shown, the stateful H-PCE sends the PCInit message defined in [RFC8281] to initiate the inter-domain path computation adding the forwarding LSP 1~3 to Assoc#1 and reverse LSP 1'~3' to Assoc#2. The child PCEs may initiate the intra-domain LSPs when receiving the message from parent PCE.
+-------+
+------------------+ H-PCE +-----------------+
PCInit | +---+---+ |
(LSP1,Assoc#1) | PCInit(LSP2,Assoc#1)| PCInit(LSP3,Assoc#1)|
PCInit | PCInit(LSP2',Assoc#2 |PCInit(LSP3',Assoc#2 |
(LSP1',Assoc#2)| | |
v v v
+-----+ +-----+ +-----+
|PCE-1| |PCE-2| |PCE-3|
+-----+ +-----+ +-----+
PCInit/ \PCInit PCInit/ \PCInit PCInit/ \PCInit
LSP1/ \LSP1' LSP2/ \LSP2' LSP3/ \LSP3'
Assoc#1/ \Assoc#2 Assoc#1/ \Assoc#2 Assoc#1/ \Assoc#2
v v v v v v
+-----+ LSP1 +-----------+ LSP2 +-----------+ LSP3 +-----+
| A |-------->| X |--------->| Y |-------->| Z |
| |<--------| |<---------| |<--------| |
+-----+ LSP1' +-----------| LSP2' +-----------+ LSP3' +-----+
Figure 2 The SR inter-domain Stitching LSP Association
The Path Segment can be used for path stithing. The SR sub-paths can be correlated with the use of Path Segment. This section defined the path segments as stitching Labels which used to stitch per-domain LSP tunnels in order to create end-to-end path that cross multiple domains.
SR intra-domain path is setup as part of inter-domain SR path. When PCC requests the PCE or the PCE itself to initiate The SR path, the inter-domain path segments should be carried as a stitching Label with the associated link.
+-------+
+------------------+ H-PCE +-----------------+
PCInit | +---+---+ |
(LSP1,LSP1')| PCInit(LSP2,LSP2')| PCInit(LSP3,LSP3')|
SL1,SL1' | SL1,SL1',SL2,SL2' | SL2,SL2' |
v v v
.................... .................... .....................
. . . . . .
. +---+ LSP1 +---+ . . +---+ LSP2+---+ . . +---+ LSP3+----+ .
. | A |----->| B |--SL1->| C |---->| X |---SL2-->| Y |---->| Z | .
. | |<-----| |<-SL1'-| |<----| |<--SL2'--| |<----| | .
. +---+ LSP1'+---+ . . +---+LSP2'+---+ . . +---+LSP3'+----+ .
. SR-AS1 . . SR-AS2 . . SR-AS3 .
.................... .................... .....................
SL:Stiching Label
Figure 3 The SR Inter-Domain Stitching Label
The inter-domain path segment may be allocated by PCC or PCE. The PCE may be the single domain PCE which taking in charge of the respective domain. The inter-domain path segments is a unique value in the domain which PCC or PCE belongs to. The operation of path segment request and reply may be the same with that in single domain as defined in [I-D.li-pce-sr-path-segment].
As defined in [I-D.xiong-spring-path-segment-sr-inter-domain], an inter-domain path segment can be allocated by egress PCC and may be maintained on the PCC itself. The inter-domain path segment connects two domains and the ingress and egress PCC are belong to different domains. The ingress and egress PCC need to exchange messages which carrying path segment information between the two PCEs.
The Ingress PCC may request to allocate a path segment from egress PCC. Once egress PCC allocated the inter-domain path segment, it need to inform the PCE in respective domain with the PCRpt message. The PCE need to communicate with the PCE which the ingress PCC belongs to inform the value allocated.
The ingress PCC may request the inter-domain path segment to be allocated by the PCE in PCC-Initiated LSP. The PCE may allocate the inter-domain path segment on its own domain in PCEs-Initiated LSP. The allocated path segment needs to be informed to the ingress and egress PCC.
The inter-domain path segments may be allocated separately by the PCEs which control the ingress and egress PCC along with the LSP initiation.
[RFC8281] describes setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC. Similar to LSP updation, the inter-domain LSP can be initiated by the ingress PCE using the PCInitiate message to the ingress LSR. The inter-domain path segment is viewed as stitching label. Per-domain LSP may also be initiated by respective domain's PCE and stitched together.
In H-PCE [RFC6805] architecture, the parent PCE is used to compute a multi-domain path based on the domain connectivity information. The stateful H-PCE in active model can be used to initiate the inter-domain bidirectional path for SR networks. PCE sends PCInitiate message to its domain SR nodes with ERO={SID LIST} and carrying stitching association group TLV and path segments. If the SR nodes is the border nodes of the SR domain, it correlates the two path segments and the related SID list if the related association ID is the same value.
The PECP procedure for the HPCE-initiated LSP is following:
The stateful H-PCE initiates the end-to-end path computation across multiple domains and selects a set of candidate domain paths based on the topology.
The stateful H-PCE sends PCInitiate message to every PCEs which the end-to-end path traversed, carrying inter-domain path segments allocated by H-PCE, stitching LSP association group and the SID list in the ERO object.
The stateful child PCE in each domain perform active stateful procedure as defined in [I-D.li-pce-sr-path-segment].
In case of passive path computation request to the ingress PCE from the ingress LSR, the H-PCE path computation procedure is applied to compute sequence of domains or end-to-end path by using PCReq and PCRep messages among stateful PCEs in passive mode.
In case of delegation to the ingress PCE (active stateful PCE), the ingress child PCE may further delegate to parent PCE as per [I-D.ietf-pce-stateful-hpce]. The parent PCE could update the path of the inter-domain LSP.
The ingress nodes of the source AS sends the PCReq message to its PCE, then the PCE sends PCReq message to the H-PCE or stateful PCEs in other domains. The PECP procedure for the PCC-initiated LSP in H-PCE model is as follow.
The ingress PCC from the ingress domain sends a PCReq request to the PCE which is responsible for the domain containing the destination information.
The ingress PCE sends the path computation request direct to the parent PCE.
The parent PCE computes the optimal end-to-end path and initiates the inter-domain paths to the child PCEs which the path traversed.
Each PCE sends PCInitiate message to ingress or egress nodes of its domain to initiate the LSPs.
TBD.
TBD.
TBD.
| [RFC6805] | 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", RFC 6805, DOI 10.17487/RFC6805, November 2012. |