| PCE Working Group | C. Li |
| Internet-Draft | M. Chen |
| Intended status: Standards Track | J. Dong |
| Expires: December 22, 2018 | Z. Li |
| D. Dhody | |
| Huawei Technologies | |
| June 20, 2018 |
Path Computation Element Communication Protocol (PCEP) Extension for Path Identification in Segment Routing (SR)
draft-li-pce-sr-path-segment-00
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE).
Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Protocol (PCEP) to support requesting, replying, reporting and updating the path identifier between PCEP speakers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
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 December 22, 2018.
Copyright (c) 2018 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.
[RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP enables the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, for the purpose of computation of Multiprotocol Label Switching (MPLS) as well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP) characteristics.
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The model of operation where LSPs are initiated from the PCE is described in [RFC8281].
[I-D.zhao-pce-pcep-extension-for-pce-controller] specify the procedures and PCEP protocol extensions for using the PCE as the central controller for static LSPs, where LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path.
Segment routing (SR) [I-D.ietf-spring-segment-routing] leverages the source routing and tunneling paradigms. SR supports steering packets into an explicit forwarding path according to the Segment Routing Policy ( SR Policy) [I-D.ietf-spring-segment-routing-policy] at the ingress node.
An SR path needs to be identified in some use cases such as performance measurement. For identifying an SR path, [I-D.cheng-spring-mpls-path-segment] introduces a new segment that is referred to as Path Segment. [I-D.li-idr-sr-policy-path-segment-distribution] defines extensions to BGP to distribute SR policies carrying Path segment identifier.
[I-D.ietf-pce-segment-routing] specifies extensions to the Path Computation Element Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE to compute and initiate SR-TE paths, as well as a PCC to request, report or delegate SR paths. [I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR for IPv6 data plane.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the procedures and PCEP protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers (SR SID distribution in this case), in addition to computing the paths for packet flows in a segment routing network and telling the edge routers what instructions to attach to packets as they enter the network.
This document specifies a mechanism to carry the SR path identification information in PCEP messages [RFC5440] [RFC8231] [RFC8281]. The path ID can be a path segment in SR-MPLS [I-D.cheng-spring-mpls-path-segment], or a path ID in SRv6 [I-D.li-spring-passive-pm-for-srv6-np], or other IDs that can identify the SR path. This document also extends the PCECC-SR mechanism to inform the path ID to the egress PCC.
This memo makes use of the terms defined in [RFC4655], [I-D.ietf-pce-segment-routing], and [I-D.ietf-spring-segment-routing].
This document specifies a mechanism of encoding (and allocating) path ID (path segment in case of MPLS, path ID in case of IPv6, etc) in PCEP extensions. For supporting path ID in PCEP, several TLVs and flags are defined. The formats of the objects and TLVs are described in Section 4. The procedures of path ID allocation are described in Section 5.
There are various modes of operations, such as -
The path ID information to the ingress PCC and PCE is exchanged via an extension to [I-D.ietf-pce-segment-routing] and [I-D.negi-pce-segment-routing-ipv6]. The path ID information to the egress PCC is informed via an extension to the PCECC-SR procedures [I-D.zhao-pce-pcep-extension-pce-controller-sr].
For the PCE to allocate a path ID, the PCE MUST be aware of the path ID space from the PCCs. This is done via mechanism as described in [I-D.li-pce-controlled-id-space].
[Editor's note - There is currently no mechanism for the PCE to ask PCC to allocate path ID. Further discussion is needed to check if that would be useful in any way.]
[I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST) and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV to exchange information about their SR capability. The TLV includes a Flags field and one bit (L-flag) was allocated in [I-D.ietf-pce-segment-routing].
This document adds an additional flag for path ID allocation, as follows -
[I-D.negi-pce-segment-routing-ipv6] defined a new Path Setup Type (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. The TLV includes a Flags field and one bit (L-flag) was allocated in [I-D.negi-pce-segment-routing-ipv6].
This document adds an additional flag for path ID allocation, as follows -
The PCECC Capability as per [I-D.zhao-pce-pcep-extension-pce-controller-sr] MUST also be advertised on the egress PCEP session, along with the SR sub-TLVs. This is needed to ensure that the PCE can inform the egress PCC of the path ID via PCECC mechanism as described in this document.
The LSP Object is defined in Section 7.3 of [RFC8231]. This document adds the following flags to the LSP Object:
The PATH-ID TLV is an optional TLV for use in the LSP Object for path ID allocation. The type of this TLV is to be allocated by IANA. The format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IDT | Flags |E|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The PATH-ID TLV Format
The type (16-bit) of the TLV is TBA (to be allocated by IANA). The length (16-bit) has a fixed value of 8 octets. The value contains the following fields:
Only one instance of each TLV is processed, if more than one TLV of each type is included, the first one is processed and others MUST be ignored.
When the path ID allocation is enable, a PATH-ID TLV SHOULD be included in the LSP object.
If the path ID is allocated by the ingress node, a PATH-ID TLV MUST be included in a LSP object (with C-bit set and E-bit is unset) in the PCEP message from PCC. In this case the P flag in LSP object is set to 0.
If the PCC request the path ID to be allocated by the PCE, P flag in LSP object is set to 1 and Path ID TLV MAY be skipped. After the PCE has allocated a path ID, it MUST include the PATH-ID TLV in a LSP object (with C-bit unset), the E-bit is set by PCE based on the path ID space from which the allocation is made.
If the PCE allocated the path ID on its own accord, a PATH-ID TLV MUST be included in a LSP object (with C-bit unset), the E-bit is set by PCE based on the path ID space from which the allocation is made.
The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is used to specify the FEC information and MAY be carried within PCInitiate or PCRpt message for the PCECC-SR operations. The PCE MUST inform the Path Identification information to the Egress PCC. To do this, this document extends the procedures of [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC object type for Path.
FEC Object-Type is TBD 'Path'.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The path FEC object Format
One or more following TLV(s) are allowed in the 'path' FEC object -
Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of each TLV is processed, if more than one TLV of each type is included, the first one is processed and others MUST be ignored.
The Central Control Instructions (CCI) Object is used by the PCE to specify the forwarding instructions is defined in [I-D.zhao-pce-pcep-extension-for-pce-controller]. Further [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object type for SR.
The Path ID information is encoded directly in the CCI SR object. The Path ID TLV as described in the Section 4.2.1, MAY also be included in the CCI SR object.
The path ID allocation and encoding is as per the stateful PCE operations for segment routing. The procedures are as per the corresponding extensions defined in [I-D.ietf-pce-segment-routing] and [I-D.negi-pce-segment-routing-ipv6] (which are further based on [RFC8231] and [RFC8281]). The additional operations for path identification are defined in this section.
To notify the path ID to the Egress PCC, the procedures are as per the PCECC-SR [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which is based on [I-D.zhao-pce-pcep-extension-for-pce-controller]). The additional operations are defined in this section.
The Ingress PCC could allocate the Path ID and inform the PCE via the PCRpt message as per [RFC8231]. The PATH-ID TLV MUST be included in a LSP object in the PCEP message from PCC. The P flag in LSP object is set to 0. On receiving this report, the PCE updates the information in its database. The active PCE (where the LSP is delegated) further informs the egress about the path ID allocated by the PCC using the PCInitiate message as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr].
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
1) LSP State | ---- PCRpt ----> | |
Delegate and | Delegate=1 | |
Inform the | PATH-ID TLV |2) PCE update |
Path ID alloc | | the LSP-DB |
by PCC | | |
|3) PCE informs the | --- PCInitiate ---> |
| Path ID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 3: Ingress PCC Allocated Path ID
For allocating the path IDs to SR paths by the PCEs, the PCE controlled ID Spaces MUST be known at PCEs via configurations or any other mechanism. The PCE controlled ID spaces MAY be advertised as described in [I-D.li-pce-controlled-id-space].
The ingress PCC could request the path ID to be allocated by the PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) MUST also be set for this LSP. The PATH-ID TLV MAY be included with Path ID set to 0x0000. The active PCE would allocated the path ID as per the PATH-ID flags and in case PATH-ID is not included, the PCE MUST act based on the local policy. The PCE would further respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST include the PATH-ID TLV in a LSP object. The PCE would further inform the egress PCC about the path ID allocated by the PCE using the PCInitiate message as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr].
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
1) LSP State | ---- PCRpt ----> | |
Delegate | Delegate=1 | |
| P=1 |2) PCE update |
| | the LSP-DB and |
| | allocate Path ID |
|<---- PCUpd ---- |3)Paths update with |
| PATH-ID TLV | Path ID |
| | |
4) LSP State Report | ----- PCRpt ---> | |
| | |
|5) PCE informs the | --- PCInitiate ---> |
| Path ID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 4: Ingress PCC request Path ID to PCE
The PCE could allocate the path ID on its own accord for a PCE-Initiated (or delegated LSP). The allocated path ID needs to be informed to the Ingress and Egress PCC. The PCE would use the PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the Ingress PCC and MUST include the PATH-ID TLV in the LSP object. The PCE would further inform the egress PCC about the path ID allocated by the PCE using the PCInitiate message as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr].
Ingress Egress
+-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC|
+-+-+ +-+-+ +-+-+
| | |
| <--PCInitiate--- |1)Initiate LSP with |
| PATH-ID TLV | Path ID |
| | |
2)LSP delegation |---PCRpt, D=1---> | (Confirm) |
| | |
|3) PCE informs the | --- PCInitiate ---> |
| Path ID to Egress| FEC=Path |
| | |
| | <-------- PCRpt --- |
| | |
Figure 5: PCE allocated Path ID on its own
[I-D.cheng-spring-mpls-path-segment] describe a Path Segment to uniquely identify an SR path in a specific context. (e.g., in the context of the egress node or ingress node of an SR path, or within an SR domain). It further describes two solution based on 'one label' or 'two labels' solution. For the latter, two segments (Source segment and Path segment) are used to identify an SR path where the source segment is a global node segment which can uniquely identify a node within the SR domain (it is NOT used for forwarding and indicates that a Path segment immediately follows). The combination of Source segment and Path segment uniquely identify an SR Path with an SR domain.
The procedure described in this document allocates and encode the Path Segment only. It is expected that the Egress PCC is aware of the Source segment by some other procedures. These procedures could be IGP, PCECC-SR, or some other mechanisms.
TBA
TBA
| [RFC4655] | Farrel, A., Vasseur, J. and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006. |
| [RFC4657] | Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006. |
| [I-D.ietf-spring-segment-routing] | Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", Internet-Draft draft-ietf-spring-segment-routing-15, January 2018. |
| [I-D.ietf-spring-segment-routing-policy] | Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b. and P. Mattes, "Segment Routing Policy Architecture", Internet-Draft draft-ietf-spring-segment-routing-policy-01, June 2018. |
| [I-D.cheng-spring-mpls-path-segment] | Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R. and S. Zhan, "Path Segment in MPLS Based Sement Routing Network", Internet-Draft draft-cheng-spring-mpls-path-segment-01, March 2018. |
| [I-D.li-spring-passive-pm-for-srv6-np] | Li, C. and M. Chen, "Passive Performance Measurement for SRv6 Network Programming", Internet-Draft draft-li-spring-passive-pm-for-srv6-np-00, March 2018. |
| [I-D.li-idr-sr-policy-path-segment-distribution] | Li, C., Chen, M., Dong, J. and Z. Li, "Segment Routing Policies for Path Segment and Bi-directional Path", Internet-Draft draft-li-idr-sr-policy-path-segment-distribution-00, April 2018. |