<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-whh-pce-capability-advertize-00"
     ipr="trust200902">
  <front>
    <title abbrev="PCEP Extension for INTERACTING-CAPBILITY">PCEP Extension for INTERACTING-CAPBILITY
    </title>
 
   <author fullname="Minxue Wang" initials="M." surname="Wang">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>wangminxue@chinamobile.com</email>
      </address>
    </author>
  
    <author fullname="Liuyan Han" initials="L." surname="Han">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code/>

          <country>China</country>
        </postal>

        <email>hanliuyan@chinamobile.com</email>
      </address>
    </author>

 

    <author fullname="Mianzhang Huang" initials="M." surname="Huang">
      <organization>CICT</organization>

      <address>
        <postal>
          <street/>

          <city>Wuhan</city>

          <country>China</country>
        </postal>

        <email>mzhuang@fiberhome.com</email>
      </address>
    </author>

    <author fullname="Zhen Han" initials="Z." surname="Han">
      <organization>CICT</organization>

      <address>
        <postal>
          <street/>

          <city>Wuhan</city>

          <country>China</country>
        </postal>

        <email>zhhan@fiberhome.com</email>
      </address>
    </author>
    
    <author fullname="Jinyou Dai" initials="J." surname="Dai">
      <organization>CICT</organization>

      <address>
        <postal>
          <street/>

          <city>Wuhan</city>

          <country>China</country>
        </postal>

        <email>djy@fiberhome.com</email>
      </address>
    </author>
    <date day="25" month="March" year="2022"/>

    <workgroup>PCE Working Group</workgroup>

    <abstract>
      <t>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.</t>
<t>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.
</t>
<t>
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.

</t>
    </abstract>

    <note title="Requirements Language">
      <t>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
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="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.
</t>

	<t><xref target="RFC8231"/> specifies a set of extensions to PCEP to enable stateful control
of TE LSPs within and across PCEP sessions in compliance with <xref target="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 <xref target="RFC8281"/>.
</t>

      <t> <xref target="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.
   </t>

     <t> <xref target="I-D.li-pce-sr-path-segment"/> specifies a mechanism to carry the SR
   path identification information in PCEP messages.</t>
   
<t>  <xref target="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.</t>

  <t>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.</t>

  <t><xref target="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<xref target="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
   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.
</t>

    <t>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<xref target="RFC7470"/> can be used as a special
   implementation mechanism when various capability distinctions have
   been reconciled in advance.
    
</t>
    <t/>
    
    </section>

    <section title="Terminology">
      <t>   This memo makes use of the terms defined in <xref target="RFC4655"/>,
      <xref target="RFC5440"/>,<xref target="I-D.li-pce-sr-path-segment"/>,
      <xref target="I-D.ietf-pce-binding-label-sid"/> and <xref target="RFC8042"/>. </t>
  

      <t/>
    </section>

    <section title="Overview of SR Tunnel Capability Notification in PCEP">
      <t> 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.</t>

 <t> 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.</t>
  
    </section>

     <section title="TLV">
   <t> 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.</t>

    <t>  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.</t>

   <t> The format of SR-PCE-INTERACTING-CAPBILITY TLV is defined as follows:</t>
    <t><figure align="center">
          <preamble/>

          <artwork><![CDATA[    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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

          <postamble>Figure 1 SR-PCE-INTERACTING-CAPBILITY TLV format</postamble>
        </figure></t>

      <t>The code point for the TLV type is to be defined by IANA. The TLV
   length is 4 octets. </t>
      <t>The 32-bit value is formatted as follows. The "Reserved" is unused.</t>

 <t>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:</t>

   <t>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.</t>

    <t>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.</t>

  <t> 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.</t>

   <t>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.</t>

   <t>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.</t>

   <t>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.</t>

  <t>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.</t>

    </section>


    <section title="IANA Considerations">
      <t> IANA is requested to make allocations from the registry, as follows:</t>
  <t><figure align="center">
          <preamble/>

          <artwork><![CDATA[      +======+==============================+=================+
     | Type |            TLV               |    Reference    |
     +======+==============================+=================+
     | TBD1 | SR-PCE-INTERACTING-CAPBILITY | [this document] |
     +------+------------------------------+-----------------+]]></artwork>
        </figure></t>

      
    </section>

    <section title="Security Considerations">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>
       <?rfc include="reference.RFC.8174"
?>
      <?rfc include="reference.RFC.5440"
?>
      <?rfc include="reference.RFC.8231"
?>
      <?rfc include="reference.RFC.4657"
?>
      <?rfc include="reference.RFC.8281"
?>
      <?rfc include="reference.RFC.9059"
?>
      <?rfc include="reference.RFC.7470"
?>
      <?rfc include="reference.RFC.4655"
?>
      <?rfc include="reference.RFC.8042"
?>
<?rfc ?>
    </references>

    <references title="Informative References">
   
      <?rfc include='reference.I-D.ietf-pce-segment-routing'?>
      
      <?rfc include='reference.I-D.li-pce-sr-path-segment'?>

      <?rfc include='reference.I-D.ietf-pce-binding-label-sid'?>
      
      <?rfc ?>
    </references>
  </back>
</rfc>