Internet DRAFT - draft-whh-pce-capability-advertize
draft-whh-pce-capability-advertize
PCE Working Group M. Wang
Internet-Draft L. Han
Intended status: Informational China Mobile
Expires: 26 September 2022 M. Huang
Z. Han
J. Dai
CICT
25 March 2022
PCEP Extension for INTERACTING-CAPBILITY
draft-whh-pce-capability-advertize-00
Abstract
The PCE communication Protocol (PCEP) is used to convey path
computation requests and responses both between Path Computation
Clients (PCCs), Path Computation Elements (PCEs) and cooperating
PCEs, support of traffic engineering in Multiprotocol Label Switching
(MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR) networks.
In PCEP, due to the different implementing of PCC tunnel capability,
especially bidirectional SR tunnels, the PCE can only provides path
computation functions between the PCCs which adopt identical
mechanisms.
With the introduction and evolvement of 5G and other network
scenarios, the scale of bearing and transport network has developed
to a high level. On the other hand, with the improvement of network
slicing ability, network equipments can provide network slicing
service, such as enhanced VPNs (VPN+). Transport network employing
time slot isolation technology, such as FlexE,MTN,can provide
advanced timeslot slicing for the high quality customer services.
The high quality customer services, for example industry production
service, demand for superior SLA and end-to-end timeslot service
slicing, regardless of whether it is across of different network
equipment providers or across of different regions. Therefore, there
is an urgent need of a method to support PCE to provide end-to-end
path computation and establishment of SR tunnels regardless of PCC
enables different protocol selections.
This document specifies the extensions to PCE communication Protocol
(PCEP) to carry bidirectional SR tunnel capability advertisement
information in PCEP message to enhance PCE ability to perceive the
protocol mechanism supported by PCC.
Requirements Language
Wang, et al. Expires 26 September 2022 [Page 1]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
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.
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 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 26 September 2022.
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SR Tunnel Capability Notification in PCEP . . . . 4
4. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Wang, et al. Expires 26 September 2022 [Page 2]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[RFC5440]describes the Path Computation Element (PCE) Communication
Protocol (PCEP). PCEP defines the communication between a Path
Computation Client (PCC) and a PCE, or between PCE and PCE, enabling
computation of Multiprotocol Label Switching (MPLS) for 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.ietf-pce-segment-routing] specifies extensions to the Path
Computation Element Protocol (PCEP)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.li-pce-sr-path-segment] specifies a mechanism to carry the SR
path identification information in PCEP messages.
[I-D.ietf-pce-binding-label-sid] specifies the binding value as an
MPLS label or Segment Identifier. It further specifies an approach
for reporting binding label/Segment Identifier (SID) by a Path
Computation Client (PCC) to the Path Computation Element (PCE) to
support PCE-based Traffic Engineering policies.
Two different implementation mechanisms of PCEP are defined in the
standard protocol: Passive Stateful PCE and Active Stateful PCE. For
Passive Stateful PCE, the PCC sends a path computation request to the
PCE, the PCE triggers a path computation and returns either a
positive or a negative reply to the PCC. For Active Stateful PCE, to
create or update LSP, PCE MUST send LSP Update Request to PCC using
PCUpd message or using PCInt message.
[I-D.li-pce-sr-path-segment] specifies various modes of operations
for SR-path segment. Path Segment can be either allocated by Egress
PCC or PCE. This leads to different implementation methods for the
extension of Path Segment. Meanwhile PCEP procedure is divided into
PCC-initiated and PCE-initiated LSPs[RFC9059].For example,
Association ID is used for bidirectional SR tunnel binding. The
difference of Association ID allocation between PCC-initiated and
PCE-initiated is as follows: In PCC-initiated, the PCE needs to
Wang, et al. Expires 26 September 2022 [Page 3]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
control whether the PCC reports the Association ID or not. If the
PCE receives the Association ID reported by the PCC through PCRpt, it
will be issued according to the Association ID reported by the PCC;
if the PCE has not received the Association ID through the PCC, the
PCE will directly assign an ID to the PCC. In PCE-initiated,the PCE
directly assigns the AssociationID.
This document specifies a new OPTIONAL TLV for multiple PCC
interworking scenarios. PCC can employ this TLV to report PCC
abilities of supporting different mechanisms of bidirectional SR
tunnels. PCE can perceive the specific implementation mode of PCC by
parsing this TLV,in order to achieve the compatibility of multiple
sets of PCEP standard processes in the management and control system.
Particularly, Vendor TLV[RFC7470] can be used as a special
implementation mechanism when various capability distinctions have
been reconciled in advance.
2. Terminology
This memo makes use of the terms defined in [RFC4655],
[RFC5440],[I-D.li-pce-sr-path-segment],
[I-D.ietf-pce-binding-label-sid] and [RFC8042].
3. Overview of SR Tunnel Capability Notification in PCEP
SR-PCE-INTERACTING-CAPBILITY TLV clarifies various capability
distinctions of PCC. Through this TLV,the PCC sends its own
capability information to the PCE,which is used to determine the
bidirectional segment routing tunnel capability supported by the PCC,
whether the tunnel creation is initiated by the PCC or the PCE, and
whether the distribution is supported by the label allocation to the
PCC or the PCE,etc.
The PCE determines the bidirectional SR tunnel capability supported
by the PCC through the acquired capability information of the PCC,
and performs corresponding management on the PCC that supports
different capabilities according to the capability. The PCE parses
this TLV. Through the analysis results of different fields in this
tlv, it can preceive which mode of the PCEP standard process is
currently supported by PCC,in order to achieve PCEP interoperability.
This solution can realize the PCEP implementation to compatible with
different PCCs.
Wang, et al. Expires 26 September 2022 [Page 4]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
4. TLV
The SR-PCE-INTERACTING-CAPBILITY is an optional TLV associated with
the OPEN Object to exchange SR Tunnel Capability Notification of PCEP
speakers. When the PCEP session is created, PCC sends an Open
message with an OPEN object containing the SR-PCE-INTERACTING-
CAPBILITY TLV.
When the PCE receives the Open message with a SR-PCE-INTERACTING-
CAPBILITY TLV, the PCE can parse the TLV. According to the results
of the analysis of each capability field of the TLV, it can realize
how the PCC implements the SR tunnel as a basis to send the
corresponding PCEP message. In an Open message, a PCC MAY insert one
SR-PCE-INTERACTING-CAPBILITY-TLV, PCC can assign different values to
the corresponding fields to announce its own PCEP capability.
The format of SR-PCE-INTERACTING-CAPBILITY TLV is defined as follows:
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 = TDB | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | N |FLAGS|S|C|P|B|T|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 SR-PCE-INTERACTING-CAPBILITY TLV format
The code point for the TLV type is to be defined by IANA. The TLV
length is 4 octets.
The 32-bit value is formatted as follows. The "Reserved" is unused.
The" Flags "(2 bits) field is unused, and MUST be set to zero on
transmission and ignored on reception. This document defines the
following flag:
o N(Number of PCInt messages sent when creating a tunnel-8 bits):
This field indicates the number of times that PCInt messages need to
be sent to create a tunnel. If set to 1 by a PCC means sending it
once, If set to 2 by a PCC means sending it twice, and supports
expansion.
o S (SR tunnel initiator-1 bit): This field is used to distinguish
the tunnel initiator. If set to 1 by a PCC means that the PCC
initiates the tunnel request. If set to 0 by a PCC means that the
PCE sends the tunnel information.
Wang, et al. Expires 26 September 2022 [Page 5]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
o C (Configuration tunnel-1bit): This field is used to indicate
whether the PCE is configured with a tunnel. If set to 1 by a PCC,
the PCE configures the tunnel. If set to 0 by a PCC, the PCE does
not configure the tunnel.
o P (Path Segment label assignment-1 bit): This field is used to
indicate Path Segment label allocation. If set to 1 by a PCC, the
Path Segment label is allocated by PCC, If set to 0 by a PCC, the
Path Segment label is allocated by PCE.
o B (Binding label-1bit): This field is used to indicate the
allocation of the adhesive label. If set to 1 by a PCC, the Binding
label is allocated by the PCC, If set to 1 by a PCC, the Binding
label is allocated by the PCE.
o T (Time sequence dependency-1bit): This field indicates whether
there is a timing dependency in the protocol interaction. If set to
1 by a PCC, it means that there is a strong dependence between PCEP
message interaction and time sequence. If set to 0 by a PCC, it
means that there is no timing dependency.
o A (Association ID 1bit): This field indicates the assignment of the
Association ID. If set to 1 by a PCC, it means that the Association
ID is allocated by PCC. If set to 0 by a PCC, it means that the
association id is allocated by PCE.
5. IANA Considerations
IANA is requested to make allocations from the registry, as follows:
+======+==============================+=================+
| Type | TLV | Reference |
+======+==============================+=================+
| TBD1 | SR-PCE-INTERACTING-CAPBILITY | [this document] |
+------+------------------------------+-----------------+
6. Security Considerations
TBD
7. References
7.1. Normative References
Wang, et al. Expires 26 September 2022 [Page 6]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>.
[RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part
Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016,
<https://www.rfc-editor.org/info/rfc8042>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
Wang, et al. Expires 26 September 2022 [Page 7]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs)",
RFC 9059, DOI 10.17487/RFC9059, June 2021,
<https://www.rfc-editor.org/info/rfc9059>.
7.2. Informative References
[I-D.ietf-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. L. (editor), "Carrying Binding Label/Segment
Identifier (SID) in PCE-based Networks.", Work in
Progress, Internet-Draft, draft-ietf-pce-binding-label-
sid-15, 20 March 2022, <https://www.ietf.org/archive/id/
draft-ietf-pce-binding-label-sid-15.txt>.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", Work in
Progress, Internet-Draft, draft-ietf-pce-segment-routing-
16, 4 March 2019, <https://www.ietf.org/archive/id/draft-
ietf-pce-segment-routing-16.txt>.
[I-D.li-pce-sr-path-segment]
Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R.,
and Q. Xiong, "Path Computation Element Communication
Protocol (PCEP) Extension for Path Segment in Segment
Routing (SR)", Work in Progress, Internet-Draft, draft-li-
pce-sr-path-segment-08, 19 August 2019,
<https://www.ietf.org/archive/id/draft-li-pce-sr-path-
segment-08.txt>.
Authors' Addresses
Minxue Wang
China Mobile
Beijing
China
Email: wangminxue@chinamobile.com
Liuyan Han
China Mobile
Beijing
China
Email: hanliuyan@chinamobile.com
Wang, et al. Expires 26 September 2022 [Page 8]
Internet-Draft PCEP Extension for INTERACTING-CAPBILITY March 2022
Mianzhang Huang
CICT
Wuhan
China
Email: mzhuang@fiberhome.com
Zhen Han
CICT
Wuhan
China
Email: zhhan@fiberhome.com
Jinyou Dai
CICT
Wuhan
China
Email: djy@fiberhome.com
Wang, et al. Expires 26 September 2022 [Page 9]
