rfc8697xml2.original.xml   rfc8697.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<?rfc tocompact="yes"?> category="std" consensus="true" docName="draft-ietf-pce-association-group-1
<?rfc tocdepth="3"?> 0" number="8697" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocIncl
<?rfc tocindent="yes"?> ude="true" symRefs="true" sortRefs="false" version="3">
<?rfc symrefs="yes"?> <!-- xml2rfc v2v3 conversion 2.32.0 -->
<?rfc sortrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pce-association-group-10" ipr="trust2009
02">
<front> <front>
<title abbrev="PCE association group"> <title abbrev="PCE Association Group">
Path Computation Element Communication Protocol (PCEP) Extensions for Establ Path Computation Element Communication Protocol (PCEP) Extensions for Establ
ishing Relationships Between Sets of Label Switched Paths (LSPs)</title> ishing Relationships between Sets of Label Switched Paths (LSPs)</title>
<seriesInfo name="RFC" value="8697"/>
<author fullname="Ina Minei" initials="I." surname="Minei"> <author fullname="Ina Minei" initials="I." surname="Minei">
<organization>Google, Inc.</organization> <organization>Google, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>inaminei@google.com</email> <email>inaminei@google.com</email>
</address> </address>
</author> </author>
<author fullname="Edward Crabbe" initials="E." surname="Crabbe"> <author fullname="Edward Crabbe" initials="E." surname="Crabbe">
<organization>Individual Contributor</organization> <organization>Individual Contributor</organization>
<address> <address>
<email>edward.crabbe@gmail.com</email> <email>edward.crabbe@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>170 West Tasman Dr.</street> <street>170 West Tasman Dr.</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>msiva@cisco.com</email> <email>msiva@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Hariharan Ananthakrishnan" initials="H." surname="Ananthak rishnan"> <author fullname="Hariharan Ananthakrishnan" initials="H." surname="Ananthak rishnan">
<organization>Netflix</organization> <organization>Netflix</organization>
<address> <address>
<email>hari@netflix.com</email> <email>hari@netflix.com</email>
</address> </address>
</author> </author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>Divyashree Techno Park, Whitefield</street> <street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>KA</region> <region>KA</region>
<code>560066</code> <code>560066</code>
<country>India</country> <country>India</country>
</postal> </postal>
skipping to change at line 71 skipping to change at line 59
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>Divyashree Techno Park, Whitefield</street> <street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>KA</region> <region>KA</region>
<code>560066</code> <code>560066</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>dhruv.ietf@gmail.com</email> <email>dhruv.ietf@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Yosuke Tanaka" initials="Y." surname="Tanaka"> <author fullname="Yosuke Tanaka" initials="Y." surname="Tanaka">
<organization>NTT Communications Corporation</organization> <organization>NTT Communications Corporation</organization>
<address> <address>
<postal> <postal>
<street>Granpark Tower 3-4-1 Shibaura, Minato-ku <street>Granpark Tower 3-4-1 Shibaura, Minato-ku</street>
</street> <region>Tokyo</region>
<city>Tokyo</city> <code>108-8118</code>
<region></region> <country>Japan</country>
<code>108-8118</code> </postal>
<country>Japan</country> <email>yosuke.tanaka@ntt.com</email>
</postal>
<email>yosuke.tanaka@ntt.com</email>
</address> </address>
</author> </author>
<date year="2020" month="January"/>
<date year="2019" /> <keyword>PCE</keyword>
<keyword>PCEP</keyword>
<workgroup>PCE Working Group</workgroup> <keyword>Association</keyword>
<keyword>PCE, PCEP, Association, Group</keyword> <keyword>Group</keyword>
<abstract> <abstract>
<t>This document introduces a generic mechanism to create a grouping of Labe l Switched Paths (LSPs) in the <t>This document introduces a generic mechanism to create a grouping of La bel Switched Paths (LSPs) in the
context of a Path Computation Element (PCE). context of a Path Computation Element (PCE).
This grouping can then be used to define associations between sets of LSP s or between a This grouping can then be used to define associations between sets of LSP s or between a
set of LSPs and a set of attributes (such as configuration parameters or set of LSPs and a set of attributes (such as configuration parameters
behaviours), or behaviors), and it is equally applicable to the stateful PCE (active a
and is equally applicable to the stateful PCE (active and passive modes) nd passive modes) and the stateless PCE.
as well as the stateless PCE.
</t>
</abstract>
<note title="Requirements Language">
<t><!--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 <xref target="RFC2119"/>.--
>
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> </t>
</abstract>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t><xref target="RFC5440"/> describes the Path Computation Element (PCE) <name>Introduction</name>
Communication Protocol (PCEP). PCEP enables the communication between a P <t><xref target="RFC5440" format="default"/> describes the Path Computatio
ath Computation n Element (PCE)
Client (PCC) and a PCE, or between PCE and PCE, Communication Protocol (PCEP). PCEP enables communication between a
for the purpose of computation of Multiprotocol Label Switching (MPLS) as Path Computation Client (PCC) and a PCE, or between a PCE and another
well PCE, for the purpose of the computation of Multiprotocol Label Switching
as Generalized MPLS (GMPLS) Traffic (MPLS) as well as Generalized MPLS (GMPLS) Traffic Engineering Label
Engineering Label Switched Path (TE LSP) characteristics. Switched Path (TE LSP) characteristics.
</t> </t>
<t><xref target="RFC8231" format="default"/> specifies a set of extensions
<t><xref target='RFC8231'></xref> specifies a to PCEP
set of extensions to PCEP to enable stateful to enable stateful control of TE LSPs within and across PCEP sessions in
control of TE LSPs within and across PCEP sessions in compliance with compliance with <xref target="RFC4657" format="default"/>. It includes mec
<xref target="RFC4657"/>. It includes mechanisms to effect LSP State Synch hanisms to
ronization between PCCs and PCEs, effect LSP State Synchronization between PCCs and PCEs, delegation of
delegation of control over LSPs to PCEs, and PCE control of timing control over LSPs to PCEs, and PCE control of timing and sequence of
and sequence of path computations within and across PCEP sessions. The model path computations within and across PCEP sessions. The operational model
of whereby LSPs are initiated from the PCE is described in <xref target="RFC8
operation where LSPs are initiated from the PCE is described in 281" format="default"/>.
<xref target='RFC8281'></xref>.
</t> </t>
<t><xref target="RFC4872" format="default"/> defines the RSVP ASSOCIATION
<t><xref target='RFC4872'/> defines the RSVP ASSOCIATION object, which was object, which
defined in the context of was defined in the context of GMPLS-controlled LSPs to be used to
GMPLS-controlled Label Switched Paths (LSPs) to be used to associate recov associate recovery LSPs with the LSP they are protecting. This object
ery LSPs with the LSP they are protecting. also has broader applicability as a mechanism to associate RSVP
This object also has broader applicability as a mechanism to state. <xref target="RFC6780" format="default"/> describes how the ASSOCIA
associate RSVP state and <xref target='RFC6780'/> described how the ASSOCIATI TION object can
ON be more generally applied by defining the Extended ASSOCIATION
object can be more generally applied by defining the Extended ASSOCIATION Obj object.</t>
ect.</t> <t> This document introduces a generic mechanism to create a grouping of L
SPs.
<t> This document introduces a generic mechanism to create a grouping of
LSPs.
This grouping can then be used to define associations between sets of LSP s or between a This grouping can then be used to define associations between sets of LSP s or between a
set of LSPs and a set of attributes (such as configuration parameters or set of LSPs and a set of attributes (such as configuration parameters
behaviours), or behaviors), and it is equally applicable to the stateful PCE (active
and is equally applicable to stateful PCE (active and passive modes) and and passive modes) and the stateless PCE.
stateless PCE. The associations could be created dynamically and conveyed to a PCEP
The associations could be created dynamically and conveyed to a PCEP peer peer within PCEP, or they could be configured manually by an operator
within PCEP, or on the PCEP peers. Refer to <xref target="Operation-overview" format="def
it could be configured manually by an operator on the PCEP peers. Refer < ault"/> for
xref target="Operation-overview"/> for more details. more details.
</t> </t>
<section numbered="true" toc="default">
</section> <!-- Introduction --> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<section title="Terminology"> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
<t>This document uses the following terms defined in <xref "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
target="RFC5440"/>: PCC, PCE, PCEP Peer, Path Computation Request (PCReq), "<bcp14>SHOULD NOT</bcp14>",
Path Computation Reply (PCRep), and PCEP Error (PCErr).</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>This document uses the following terms defined in <xref "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
target="RFC8051"/>: Stateful PCE, Active Stateful PCE, Passive Stateful PC to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
E, and Delegation.</t> <xref target="RFC8174"/> when, and only when, they appear in all capitals,
<t>This document uses the following terms defined in <xref as shown here.</t>
target="RFC8231"/>: LSP State </section>
Report (PCRpt), LSP Update Request (PCUpd), and State Timeout Interval.</t> </section>
<t>This document uses the following terms defined in <xref <section numbered="true" toc="default">
target='RFC8281'/>: PCE-initiated LSP, and LSP Initiate Request (PCIniti <name>Terminology</name>
ate).</t> <t>This document uses the following terms defined in <xref target="RFC5440
" format="default"/>:</t>
<!-- No longer needed! <t> The following term is defined in this document: <ul spacing="normal">
</t> <li>PCC</li>
<li>PCE</li>
<t> Association Timeout Interval: when a PCEP session is terminated, <li>PCEP Peer</li>
a PCC waits for this time period before deleting associations created by t <li>Path Computation Request (PCReq)</li>
he PCEP peer. <li>Path Computation Reply (PCRep)</li>
</t>--> <li>PCEP Error (PCErr)</li>
</section> <!-- Terminology --> </ul>
<t>This document uses the following terms defined in <xref target="RFC8051
<section anchor="Overview" title="Architectural Overview"> " format="default"/>:</t>
<section anchor="Motivation" title="Motivation"> <ul spacing="normal">
<t> <li>Stateful PCE</li>
<!--Stateful PCE provides the ability to update existing LSPs and to in <li>Active Stateful PCE</li>
stantiate new ones. <li>Passive Stateful PCE</li>
To enable support for PCE-controlled make-before-break and for protecti <li>Delegation</li>
on, there is a need </ul>
to define associations between LSPs. For example, the association betwe <t>This document uses the following terms defined in <xref target="RFC8231
en the original " format="default"/>:</t>
and the re-optimized path in the make-before break scenario, or between <ul spacing="normal">
the <li>LSP State Report (PCRpt)</li>
working and protection path in end-to-end protection. Another use for L <li>LSP Update Request (PCUpd)</li>
SP grouping is for <li>State Timeout Interval</li>
applying a common set of configuration parameters or behaviors to a set </ul>
of LSPs.--> <t>This document uses the following terms defined in <xref target="RFC8281
" format="default"/>:</t>
Stateful PCE provides the ability to update existing LSPs and to <ul spacing="normal">
instantiate new ones. There are various situations where several <li>PCE-initiated LSP</li>
LSPs need to share common information. E.g., to support for <li>LSP Initiate Request (PCInitiate)</li>
PCE-controlled make-before-break, an association between the original </ul>
and the re-optimized path is desired. Similarly, for end-to-end protect </section>
ion, the association <section anchor="Overview" numbered="true" toc="default">
between working and protection LSPs is required (see <xref target="I-D. <name>Architectural Overview</name>
ietf-pce-stateful-path-protection"/>). For diverse paths, an association between <section anchor="Motivation" numbered="true" toc="default">
a group of LSPs could be used (see <xref target="I-D.ietf-pce-association-diver <name>Motivations</name>
sity"/>). Another use for the LSP grouping is for <t>A stateful PCE provides the ability to update existing LSPs and to
applying a common set of configuration parameters or behaviours to a se instantiate new ones. There are various situations where several
t of LSPs. LSPs need to share common information. For example, to support
</t> PCE-controlled make-before-break, an association between the original
<t> path and the reoptimized path is desired. Similarly, for end-to-end
For a stateless PCE, it might be useful to associate a path protection, an association between working and protection LSPs is
computation request to an association group, thus enabling it to associate required (see <xref target="I-D.ietf-pce-stateful-path-protection" format="
a common set of policy, configuration parameters or behaviours with the re default"/>). For diverse paths, an
quest. association between a group of LSPs could be used (see <xref target="I-D.ie
</t> tf-pce-association-diversity" format="default"/>). Another use for an LSP group
<t>Some associations could be created dynamically, such as association betw ing would be to apply
een the working and protection LSPs of a tunnel, whereas a common set of configuration parameters or behaviors to a set of LSPs.
some associations could be created by the operator manually, such as pol </t>
icy-based association, where the LSP could join <t>
an operator-configured existing association.</t> For a stateless PCE, it might be useful to associate a PCReq message to a
<t> n association group, thus enabling it to associate
Rather than creating separate mechanisms for each use case, this document d a common set of policies, configuration parameters, or behaviors with the
efines a generic mechanism that can request.
be reused as needed. </t>
</t> <t>Some associations could be created dynamically, such as an associatio
</section><!-- Motivation --> n
<section title="Relationship with the SVEC List"> between the working and protection LSPs of a tunnel, whereas
<t>Note that, <xref target="RFC5440"/> defines a mechanism for the synchr some associations could be created by the operator manually, such as
onization of a set of path computation requests a policy-based association where the LSP could join an
by using the SVEC (Synchronization VECtor) object, that specifies the list of operator-configured existing association.</t>
synchronized <t>
requests that can either be dependent or independent. The SVEC object identif Rather than creating separate mechanisms for each use case, this document
ies the relationship between the set of path computation requests, identified by defines a generic mechanism that can be reused as needed.
'Request-ID-number' in RP (Request Parameters) object. <xref target="RFC6007"/> </t>
further clarifies the use of the SVEC list for </section>
synchronized path computations when computing dependent requests as well as d <section numbered="true" toc="default">
escribes a number of usage scenarios for SVEC <name>Relationship to the SVEC List</name>
lists within single-domain and multi-domain environments.</t> <t>Note that <xref target="RFC5440" format="default"/> defines a mechani
<t>The motivation behind the association group defined in this document sm for the
synchronization of a set of PCReq messages by using the SVEC
(Synchronization VECtor) object, which specifies the list of
synchronized requests that can be either dependent or independent. The
SVEC object identifies the relationship between the set of
PCReq messages, identified by "Request-ID-number" in the RP
(Request Parameters) object. <xref target="RFC6007" format="default"/> fu
rther clarifies
the use of the SVEC list for synchronized path computations when
computing dependent requests, and it describes a number of usage
scenarios for SVEC lists within single-domain and multi-domain
environments.</t>
<t>The motivations behind the association group defined in this document
and the SVEC object are quite different, though some use cases may and the SVEC object are quite different, though some use cases may
overlap. PCEP extensions that define a new association type should overlap. PCEP extensions that define a new Association Type should
clarify the relationship between the SVEC object and the association clarify the relationship between the SVEC object and the Association
type, if any.</t> Type, if any.</t>
</section> </section>
<section anchor="Operation-overview" numbered="true" toc="default">
<section anchor="Operation-overview" title="Operation Overview"> <name>Operational Overview</name>
<t> <t>
LSPs are associated with other LSPs with which they interact by LSPs are associated with other LSPs with which they interact by
adding them to a common association group. Association groups as adding them to a common association group. Association groups as
defined in this document can be applied to LSPs originating at the same hea defined in this document can be applied to LSPs originating at the same
d end headend or different headends.</t>
or different head ends.</t> <t>Some associations could be created dynamically by a PCEP speaker, and
the associations (along with the set of LSPs) are conveyed to a PCEP
<t>Some associations could be created dynamically by a PCEP speaker and the peer. Whereas some associations are configured by the operator
associations (along with the set of LSPs) are conveyed to a PCEP peer. beforehand on the PCEP peers in question, a PCEP speaker could then ask
Whereas some associations are configured by the operator on the PCEP pee an LSP to join the Operator-configured Association. Usage of dynamic and
rs involved beforehand, a PCEP speaker then could ask for a LSP to join the oper configured associations is usually dependent on the type of
ator-configured association. Usage of dynamic and configured association is usua association.</t>
lly dependent on the type of the association.</t> <t>For Operator-configured Associations, the association
parameters, such as the Association Identifier (Association ID), Association Typ
<t>For the operator-configured association, the association parameters s e, and
uch as the association identifier, association type, the Association Source IP address, are manually configured by the
as well as the association source IP address, are manually configured by th operator. In the case of a dynamic association, the association parameters,
e such as the Association ID, are allocated dynamically by the
operator. In case of dynamic association, the association parameters such as PCEP speaker. The Association Source is set as the local PCEP speaker
the association identifier, are allocated dynamically by the PCEP speaker, the a address unless local policy dictates otherwise, in which case the
ssociation source is set as local PCEP speaker address, unless local policy dict Association Source is set based on the local policy.</t>
ates otherwise, in which case association source is set based on the local polic <t>The dynamically created association can be reported to the PCEP peer
y.</t> via the PCEP messages as per the stateful extensions. When the
Operator-configured Association is known to the PCEP peer beforehand, a
<t>The dynamically created association can be reported to the PCEP peer PCEP peer could ask an LSP to join the Operator-configured Association
via the PCEP messages as per the stateful extensions. When the operator-con via the stateful PCEP messages.</t>
figured association is known to the PCEP peer beforehand, a PCEP peer could ask <t>The associations are properties of the LSP and thus could be stored i
for a LSP to join the operator-configured association via the stateful PCEP mess n
ages.</t> the LSP state database. The dynamic association exists as long as the LSP
state exists. In the case of PCEP session termination, the LSP state cleanup
<t>The associations are properties of the LSP and thus could be stored in th <bcp14>MUST</bcp14> also take care of associations.</t>
e LSP state database. The dynamic association exists as long as the LSP <t>Multiple types of associations can exist, each with its own
state exists. In case of PCEP session termination, the LSP state clean-up MUST a Association ID space. The definition of the different Association
lso take care of associations.</t> Types and their behaviors is outside the scope of this document. The
establishment and removal of the association relationship can be done on
<!--<t>For LSPs originating at the same head end, the association a per-LSP basis. An LSP may join multiple association groups that have
can be initiated by either the PCC (head end) or by a PCE. Only a statefu the same Association Type or different Association Types.</t>
l </section>
PCE can initiate an association for LSPs originating at different head ends <section anchor="Range" numbered="true" toc="default">
. <name>Operator-Configured Association Range</name>
For both cases, the association is uniquely identified by the combination o <t>Some Association Types are dynamic, some are operator configured,
f an association and some could be both. For the Association Types that could be both
identifier and the address of the node that created the association. dynamic and operator configured and use the same
</t>--> Association Source, it is necessary to distinguish a range of
Association IDs that are marked for Operator-configured
<t> Associations, to avoid any Association ID clashes within the
Multiple types of associations can exist, each with their own associati scope of the Association Source. This document assumes that these two
on identifier space. ranges are configured.
The definition of the different association types and their behaviours is
outside the scope of this document. The establishment and removal of the
association relationship can be done on a per LSP basis.
An LSP may join multiple association groups, of different or of the same as
sociation type.
</t>
<!--<t>
In the case of a stateless PCE, associations are created out of band, and
PCEP peers should be aware of the association and its significance
outside of the protocol.
</t>-->
<!--<t>
Association groups can be created by both PCC and PCE. When a PCC's
PCEP session with a PCE terminates unexpectedly, the PCC cleans up associati
ons (as per
the processing rules in this document).
</t>-->
</section><!-- Operation overview -->
<section title="Operator-configured Association Range" anchor="Range">
<t>Some association types are dynamic, some are operator-configured and
some could be both. For the association types that could be both dynamic and ope
rator-configured and use the same association source, <!--it is necessary to con
figure a range of association identifiers that are marked for operator-configure
d associations to avoid any association identifier clash within the scope of the
association source.-->it is necessary to distinguish a range of association ide
ntifiers that
are marked for operator-configured associations to avoid any
association identifier clash within the scope of the association
source. This document assumes that these two ranges are configured.
</t> </t>
<t>A range of Association IDs for each Association Type (and
<t>A range of association identifiers for each Association type (and Ass Association Source) is kept for the Operator-configured
ociation Source) are kept for the operator-configured associations. Associations. Dynamic associations <bcp14>MUST NOT</bcp14> use the
Dynamic associations MUST NOT use the association identifier from th Association ID from this range. </t>
is range. </t> <t>This range, as set at the PCEP speaker (a PCC or PCE, as an
Association Source), needs to be communicated to a PCEP peer in the
<t>This range as set at the PCEP speaker (PCC or PCE, as an association Open message. A new TLV is defined in this specification for this
source) needs to be communicated to a PCEP peer in the Open Message. purpose (<xref target="Range-tlv" format="default"/>). See <xref target="
A new TLV is defined in this specification for this purpose (<xref tar ex" format="default"/> for an
get="Range-tlv"/>). See <xref target="ex"/> for an example.</t> example.</t>
<t>The Association ID range for sources other than the PCEP
<t>Association identifier range for sources other than the PCEP speaker speaker (for example, a Network Management System (NMS)) is not
(for example an NMS system) is not communicated in PCEP and the procedure for op communicated in PCEP, and the procedure for Operator-configured
erator-configured association range setting is outside the scope of this documen Association Range settings is outside the scope of this document.</t>
t.</t>
<!--<t>All operator-configured associations MUST use identifier from
the
range 0x10000 to 0xffffF and encode it in the extended associatio
n
id TLV. (<xref target="EXT-association"/>)</t>-->
</section> </section>
</section><!-- Overview --> </section>
<section anchor="Discovery" numbered="true" toc="default">
<section anchor="Discovery" title="Discovery of Supported Association Types <name>Discovery of Supported Association Types</name>
"> <t>This section defines PCEP extensions so as to support
<t>This section defines PCEP extensions so as to support the capability advertisement of the Association Types supported by a PCEP spe
the capability advertisement of the association types supported by a PCEP spe aker.</t>
aker.</t> <t>A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. Th
e
<t>A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. The
PCEP ASSOC-Type-List TLV is carried within an OPEN object. This way, during PCEP ASSOC-Type-List TLV is carried within an OPEN object. This way, during
PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer the lis the PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer
t the list of supported Association Types.</t>
of supported Association types.</t> <section numbered="true" toc="default">
<section title="ASSOC-Type-List TLV"> <name>ASSOC-Type-List TLV</name>
<t>The PCEP ASSOC-Type-List TLV is OPTIONAL. It MAY be carried within an OPE <t>The PCEP ASSOC-Type-List TLV is <bcp14>OPTIONAL</bcp14>. It <bcp14>M
N AY</bcp14> be carried within an OPEN
object sent by a PCEP speaker in an Open message to a PCEP peer so as to object sent by a PCEP speaker in an Open message to a PCEP peer so as to
indicate the list of supported Association types.</t> indicate the list of supported Association Types.</t>
<t>The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV fo
<t>The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV format rmat defined
defined in <xref target="RFC5440" format="default"/>. That is, the TLV is composed o
in <xref target="RFC5440"/>. That is, the TLV is composed of 2 octets for th f 2 octets
e type, for the type, 2 octets specifying the TLV length, and a Value field. The Len
2 octets specifying the TLV length, and a Value field. The Length gth
field defines the length of the value portion in octets. The TLV is field defines the length of the value portion in octets. The TLV is
padded to 4-octet alignment, and padding is not included in the padded to 4-octet alignment, and padding is not included in the
Length field (e.g., a 3-octet value would have a length of three, but Length field (e.g., a 3-octet value would have a length of three, but
the total size of the TLV would be eight octets).</t> the total size of the TLV would be 8 octets).</t>
<t>The PCEP ASSOC-Type-List TLV has the following format:</t>
<t>The PCEP ASSOC-Type-List TLV has the following format: <figure anchor="ASSOC-Type-List">
<figure anchor="ASSOC-Type-List" title="The ASSOC-Type-List TLV format"> <name>The ASSOC-Type-List TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
TYPE: TBD
LENGTH: N * 2 (where N is the number of association types)
VALUE: list of 2-byte association type code points, identifying
the association types supported by the sender of the Open
message.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assoc-type #1 | Assoc-type #2 | | Assoc-Type #1 | Assoc-Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assoc-type #N | padding | | Assoc-Type #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork
>
]]></artwork></figure> </figure>
</t> <dl newline="false" spacing="normal">
<t>Assoc-type (2 bytes): Association type code point identifier. IANA <dt>Type:</dt>
manages the "ASSOCIATION Type Field" code point registry (see <xref target="i <dd>35</dd>
ana_assoc_type"/>).</t> <dt>Length:</dt>
<section title="Procedure"> <dd>N * 2 (where N is the number of Association Types).</dd>
<t>An ASSOC-Type-List TLV within an OPEN object in an Open <dt>Value:</dt>
<dd>List of 2-byte Association Type code points, identifying
the Association Types supported by the sender of the Open
message.</dd>
<dt>Assoc-Type (2 bytes):</dt>
<dd>Association Type code point identifier.
IANA manages the "ASSOCIATION Type Field" code point registry (see <xref targe
t="iana_assoc_type" format="default"/>).</dd>
</dl>
<section numbered="true" toc="default">
<name>Procedure</name>
<t>An ASSOC-Type-List TLV within an OPEN object in an Open
message is included by a PCEP speaker in order to advertise a set of one or message is included by a PCEP speaker in order to advertise a set of one or
more supported association types. The ASSOC-Type-List TLV MUST NOT appear mo re than more supported Association Types. The ASSOC-Type-List TLV <bcp14>MUST NOT</b cp14> appear more than
once in an OPEN object. If it appears more than once, the PCEP once in an OPEN object. If it appears more than once, the PCEP
session MUST be rejected with error type 1 and error value 1 (PCEP session <bcp14>MUST</bcp14> be rejected with Error-Type 1 and Error-value 1 ( PCEP
session establishment failure / Reception of an invalid Open session establishment failure / Reception of an invalid Open
message). As specified in <xref target="RFC5440"/>, a PCEP peer that does not recognize the message). As specified in <xref target="RFC5440" format="default"/>, a PCEP p eer that does not recognize the
ASSOC-Type-List TLV will silently ignore it.</t> ASSOC-Type-List TLV will silently ignore it.</t>
<t>The Association Type (to be defined in future documents) can specif
<t>Association type (to be defined in other documents) can specify if the assoc y if
iation type advertisement is mandatory for it. the Association Type advertisement is mandatory for it.
Thus, the ASSOC-Type-List TLV MUST be included if at least one mandatory associa Thus, the ASSOC-Type-List TLV <bcp14>MUST</bcp14> be included if at least one ma
tion type needs to be advertised and the ASSOC-Type-List TLV MAY be included oth ndatory
erwise. Association Type needs to be advertised, and the ASSOC-Type-List TLV <bcp14>MAY
</bcp14> be
For an association type that specifies that the advertisement is mandatory, a included otherwise. For an Association Type that specifies that the
missing Assoc-type in the ASSOC-Type-List TLV (or missing ASSOC-Type-List TLV) i advertisement is mandatory, a missing Assoc-Type in the ASSOC-Type-List TLV
s to be interpreted as the association type is not supported by the PCEP speaker (or a missing ASSOC-Type-List TLV) is to be interpreted as meaning that the
.</t> Association Type is not supported by the PCEP speaker.</t>
<t>The absence of the ASSOC-Type-List TLV in an OPEN object <bcp14>MUS
<t>The absence of the ASSOC-Type-List TLV in an OPEN object MUST be interpret T</bcp14> be
ed as an absence of information on the list of supported interpreted as an absence of information in the list of supported
Association types (rather than the Association type is not supported). <!--Th Association Types (rather than an indication that the Association Type is
e PCEP speaker could still use the ASSOCIATION object, if the peer does not supp not supported). In this case, the PCEP
ort the association, it
would react as per the procedure described in <xref target="Rules"/>.-->In th
is case, the PCEP
speaker could still use the ASSOCIATION object: if the peer does not speaker could still use the ASSOCIATION object: if the peer does not
support the association, it will react as per the procedure described support the association, it will react as per the procedure described
in <xref target="Rules"/>.</t> in <xref target="Rules" format="default"/>.</t>
<t>If the use of the ASSOC-Type-List TLV is triggered by support for a
<t><!--It is RECOMMENDED that the PCEP implementation include all supported a mandatory Association Type, then it is <bcp14>RECOMMENDED</bcp14> that the PC
ssociation-types (including optional) to ease the operations of the PCEP peer.-- EP
> implementation include all supported Association Types (including optional
In case the use of the ASSOC-Type-List TLV is triggered by support for a ma types) to ease the operations of the PCEP peer.</t>
ndatory association type, then it is RECOMMENDED that the PCEP implementation in </section>
clude all supported Association types (including optional) to ease the operation </section>
s of the PCEP peer.</t>
</section>
</section>
</section> </section>
<section anchor="Range-tlv" title="Operator-configured Association Range TLV <section anchor="Range-tlv" numbered="true" toc="default">
"> <name>Operator-Configured Association Range TLV</name>
<t>This section defines PCEP extension to support <t>This section defines a PCEP extension to support
the advertisement of the Operator-configured Association Range used for an As the advertisement of the Operator-configured Association Range used for an As
sociation type by the PCEP speaker (as an Association source).</t> sociation Type by the PCEP speaker (as an Association Source).</t>
<t>A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association Range)
<t>A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association Range) TLV TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried within an OPEN
is defined. The object. This way, during the PCEP session-setup phase, a PCEP speaker can
PCEP OP-CONF-ASSOC-RANGE TLV is carried within an OPEN object. This way, dur advertise to a PCEP peer the Operator-configured Association Range for an
ing Association Type.</t>
PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer <t>The PCEP OP-CONF-ASSOC-RANGE TLV is <bcp14>OPTIONAL</bcp14>. It <bcp14
the Operator-configured Association Range for an association type.</t> >MAY</bcp14> be carried within
an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer.
<t>The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL. It MAY be carried within an The OP-CONF-ASSOC-RANGE TLV format is compliant with the PCEP TLV format
OPEN defined in <xref target="RFC5440" format="default"/>. That is, the TLV is co
object sent by a PCEP speaker in an Open message to a PCEP peer. mposed of 2
The OP-CONF-ASSOC-RANGE TLV format is compliant with the PCEP TLV format defi bytes for the type, 2 bytes specifying the TLV length, and a Value field.
ned The Length field defines the length of the value portion in bytes.</t>
in <xref target="RFC5440"/>. That is, the TLV is composed of 2 bytes for the <t>The PCEP OP-CONF-ASSOC-RANGE TLV has the following format:</t>
type, <figure anchor="OP-CONF-ASSOC-RANGE">
2 bytes specifying the TLV length, and a Value field. The Length <name>The OP-CONF-ASSOC-RANGE TLV Format</name>
field defines the length of the value portion in bytes.</t> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3
<t>The PCEP OP-CONF-ASSOC-RANGE TLV has the following format:</t> 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
<figure anchor="OP-CONF-ASSOC-RANGE" title="The OP-CONF-ASSOC-RANGE TLV for +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mat"> | Type | Length |
<artwork><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE: 29 (Early allocation by IANA) | Reserved | Assoc-Type #1 |
LENGTH: N * 8 (where N is the number of association types) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VALUE: | Start-Assoc-ID #1 | Range #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Assoc-Type #N |
| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Assoc-ID #N | Range #N |
| Reserved | Assoc-type #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >
| Start-Assoc-ID #1 | Range #1 | </figure>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dl newline="false" spacing="normal">
// // <dt>Type:</dt>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dd>29</dd>
| Reserved | Assoc-type #N | <dt>Length:</dt>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dd>N * 8 (where N is the number of Association Types).</dd>
| Start-Assoc-ID #N | Range #N | <dt>Value:</dt>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dd>
<t>Includes the following fields, repeated for each
]]></artwork></figure> Association Type:
<t>The Value portion includes the following fields, repeated for each associatio
n type:
<list>
<t>Reserved (2 bytes): This field MUST be set to 0 on
transmission and MUST be ignored on receipt.</t>
<t>Assoc-type (2 bytes): The association type (<xref target="iana_assoc_type"
/>).
The association types are defined in separate documents.</t>
<t>Start-Assoc-ID (2 bytes): The start association identifier for the Operato
r-configured Association Range for the particular association type. The values 0
and 0xffff MUST NOT be used and on receipt of these values in the TLV, the sess
ion is rejected with error message sent (see <xref target="pro"/>).</t>
<t>Range (2 bytes): The number of associations marked for the Operator-config
ured Associations. The Range MUST be greater than 0, and it MUST be such that (S
tart-Assoc-ID + Range) do not cross the association identifier range of 0xffff.
In case this condition is not satisfied, the session is rejected with error mess
age sent (see <xref target="pro"/>).</t>
</list></t>
<section anchor="pro" title="Procedure"> </t>
<t>A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN objec <dl newline="false" spacing="normal">
t in an Open <dt>Reserved (2 bytes):</dt>
message sent to a PCEP peer in order to advertise the Operator-configured Ass <dd><bcp14>MUST</bcp14> be set to 0 on transmission and <bcp14>MUST
ociation Range for an association type. </bcp14> be
The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than ignored on receipt.</dd>
<dt>Assoc-Type (2 bytes):</dt>
<dd>The Association Type (<xref target="iana_assoc_type"
format="default"/>). The Association Types will be defined in futur
e
documents.</dd>
<dt>Start-Assoc-ID (2 bytes):</dt>
<dd>The "start association" identifier for the
Operator-configured Association Range for the particular Association
Type. The values 0 and 0xffff <bcp14>MUST NOT</bcp14> be used; on receipt of
these
values in the TLV, the session is rejected, and an error message is sent
(see <xref target="pro" format="default"/>).</dd>
<dt>Range (2 bytes):</dt>
<dd>The number of associations marked for the
Operator-configured Associations. Range <bcp14>MUST</bcp14> be greater than 0
, and it
<bcp14>MUST</bcp14> be such that (Start-Assoc-ID + Range) does not cross the
largest Association ID value of 0xffff. If this condition is not satisfied, t
he session
is rejected, and an error message is sent (see <xref target="pro" format="def
ault"/>).</dd>
</dl>
</dd>
</dl>
<section anchor="pro" numbered="true" toc="default">
<name>Procedure</name>
<t>A PCEP speaker <bcp14>MAY</bcp14> include an OP-CONF-ASSOC-RANGE TLV
within an OPEN object in an Open
message sent to a PCEP peer in order to advertise the Operator-configured Ass
ociation Range for an Association Type.
The OP-CONF-ASSOC-RANGE TLV <bcp14>MUST NOT</bcp14> appear more than
once in an OPEN object. If it appears more than once, the PCEP once in an OPEN object. If it appears more than once, the PCEP
session MUST be rejected with error type 1 and error value 1 (PCEP session <bcp14>MUST</bcp14> be rejected with Error-Type 1 and Error-value 1 ( PCEP
session establishment failure / Reception of an invalid Open session establishment failure / Reception of an invalid Open
message).</t> message).</t>
<t>As specified in <xref target="RFC5440" format="default"/>, a PCEP pee
<t>As specified in <xref target="RFC5440"/>, a PCEP peer that does not recogn r that does not recognize the
ize the
OP-CONF-ASSOC-RANGE TLV will silently ignore it.</t> OP-CONF-ASSOC-RANGE TLV will silently ignore it.</t>
<t>The Operator-configured Association Range <bcp14>SHOULD</bcp14> be in
<t>The Operator-configured Association Range SHOULD be included for each asso cluded for each
ciation type that could be both dynamic and operator-configured. For association Association Type that could be both dynamic and operator configured. For
types that are only dynamic or only operator-configured, this TLV MAY be skippe Association Types that are only dynamic or only operator configured, this
d, in which case the full range of association identifier is considered dynamic TLV <bcp14>MAY</bcp14> be skipped, in which case the full range of Associatio
or operator-configured respectively. n IDs
Each association type (that are defined in separate documents) can specify t is considered dynamic or operator configured, respectively. Each
he default value for the operator-configured association range for their respect Association Type (to be defined in future documents) can specify the default
ive association type. </t> value for its Operator-configured Association Range.</t>
<t>The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object <bcp14>M
<!--<t>An Assoc-Type MUST be present only once in the OP-CONF-ASSOC-RANGE TL UST</bcp14> be
V, if the same Assoc-Type is present more than once, the PCEP interpreted as an absence of an explicit Operator-configured Association Rang
session MUST be rejected with error type 1 and error value 1 (PCEP e at the PCEP peer.
session establishment failure / Reception of an invalid Open In this case, the default behavior as per each Association Type applies. If t
message).</t>--> he Association
Source is not a PCEP speaker, the default value for the Operator-configured A
<t>The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be ssociation Range is used for the Association Source.</t>
interpreted as an absence of explicit Operator-configured Association Range a <t>If the Assoc-Type is not recognized or supported by the PCEP speaker,
t the PCEP peer. it <bcp14>MUST</bcp14> ignore that respective (Start-Assoc-ID + Range). If the
In this case, the default behavior as per each association type applies. If t Assoc-Type is recognized/supported but Start-Assoc-ID or Range is set incorrectl
he association y, the PCEP
source is not a PCEP speaker, the default value for the operator-configured a session <bcp14>MUST</bcp14> be rejected with Error-Type 1 and Error-value 1 (
ssociation range is used for the association source.</t> PCEP
<t>If the Assoc-type is not recognized or supported by the PCEP speaker, it M
UST ignore that respective Start-Assoc-ID and Range. If the Assoc-type is recogn
ized/supported but the Start-Assoc-ID or Range are set incorrectly, the PCEP
session MUST be rejected with error type 1 and error value 1 (PCEP
session establishment failure / Reception of an invalid Open
message). The incorrect range include the case when the (Start-Assoc-ID + Ran
ge) crosses the association identifier range of 0xffff.</t>
<t>A given Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE TL
V in the case of a non-contiguous Operator-configured Association Range. The PCE
P speaker originating this TLV MUST NOT carry overlapping ranges for an associat
ion type. If a PCEP peer receives overlapping ranges for an association type, it
MUST consider the Open message malformed and MUST reject the PCEP session with
error type 1 and error value 1 (PCEP
session establishment failure / Reception of an invalid Open session establishment failure / Reception of an invalid Open
message).</t> message). The incorrect range includes the case when the
(Start-Assoc-ID + Range) crosses the largest Association ID value of
<t><!--In case, there is an operator-configured association that was configur 0xffff.</t>
ed with association parameters (such as association identifier, association type <t>A given Assoc-Type <bcp14>MAY</bcp14> appear more than once in the
and association source) at the local PCEP speaker, later the PCEP session gets OP-CONF-ASSOC-RANGE TLV in the case of a non-contiguous
established with the association source and a new operator-configured range is l Operator-configured Association Range. The PCEP speaker originating this
earned during session establishment.--> TLV <bcp14>MUST NOT</bcp14> send overlapping ranges for an Association Type.
There may be cases where an operator-configured association was If a PCEP
configured with association parameters (such as association peer receives overlapping ranges for an Association Type, it <bcp14>MUST</bcp
identifier, association type and association source) at the local 14> consider
PCEP speaker, and later the PCEP session gets established with the the Open message malformed and <bcp14>MUST</bcp14> reject the PCEP session wi
association source and a new operator-configured range is learned th
during session establishment. Error-Type 1 and Error-value 1 (PCEP session establishment failure /
At this time, the local PCEP speaker MUST remove any associations that are not Reception of an invalid Open message).</t>
in the new operator-configured range (by disassociating any LSPs that are part o <t>There may be cases where an Operator-configured Association was
f it (and notifying this change to the PCEP peer)). If a PCEP speaker receives a configured with association parameters (such as an Association ID, Associatio
n association for an operator-configured association n Type, and Association Source) at the local
and the association identifier is not in the operator-configured associati PCEP speaker, and the PCEP session is later established with the
on range for the association type and association source, it MUST generate an er Association Source and a new operator-configured range is learned
ror (as described in <xref target="Rules"/>).</t> during session establishment. At this time, the local PCEP speaker <bcp14>MUS
</section> T</bcp14>
remove any associations that are not in the new operator-configured range
(by disassociating any LSPs that are part of it (and notifying the
PCEP peer of this change)). If a PCEP speaker receives an association for an
Operator-configured Association and the Association ID is not in
the Operator-configured Association Range for the Association Type and
Association Source, it <bcp14>MUST</bcp14> generate an error (as described in
<xref target="Rules" format="default"/>).</t>
</section>
</section> </section>
<section anchor="association" title="ASSOCIATION Object"> <section anchor="association" numbered="true" toc="default">
<section anchor="Definition" title="Object Definition"> <name>ASSOCIATION Object</name>
<section anchor="Definition" numbered="true" toc="default">
<!--Creation of an association group and modifications to its membership <name>Object Definition</name>
can be initiated by either the PCE or the PCC.--> <t>Association groups and their memberships are defined using a new
<t>Association groups ASSOCIATION object.
and their memberships are defined using a new ASSOCIATION object. </t>
</t> <t>The ASSOCIATION Object-Class value is 40.</t>
<t>The ASSOCIATION Object-Type value is 1 for IPv4, and its format is
<t>ASSOCIATION Object-Class is 40 (Early allocation by IANA).</t> shown in <xref target="Association-Object-Fmt1" format="default"/>:</t>
<t> ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in <figure anchor="Association-Object-Fmt1">
<xref target="Association-Object-Fmt1"/>:</t> <name>The IPv4 ASSOCIATION Object Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure anchor="Association-Object-Fmt1" title="The IPv4 ASSOCIATION Object 0 1 2 3
format"> 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
<artwork><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
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 | Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R| | IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type | Association ID | // Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwor
| IPv4 Association Source | k>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in
<xref target="Association-Object-Fmt2"/>:</t>
<figure anchor="Association-Object-Fmt2" title="The IPv6 ASSOCIATION Object
format">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> Reserved (2-byte): MUST be set to 0 and ignored upon receipt. </t>
<t>
Flags (2-byte): The following flags are currently defined:
<list style="hanging">
<t hangText="R (Removal - 1 bit):"> when set, the requesting
PCEP peer requires the removal of an LSP from the association group.
When unset, the PCEP peer indicates that the LSP is added or retaine
d as part of the association group.
This flag is used for the ASSOCIATION object in the PCRpt and the PC
Upd message, the flag is ignored
in other PCEP messages. </t>
</list>
</t>
<t>The unassigned flags MUST be set to zero on transmission and MUST be igno
red on receipt.</t>
<t>
Association type (2-byte): the association type (<xref target="iana_assoc_ty
pe"/>).
The association types are defined in separate documents.
</t>
<t> Association ID (2-byte): the identifier of the association group. When
combined
with other association parameters, such as Association Type and Association
Source, this value uniquely identifies an association group.
The values 0xffff and 0x0 are reserved. The value 0xffff is used to indicate
all association groups and could be used with R flag to indicate removal for
all associations for the LSP within the scope of association type and associati
on source.
</t>
<t> <!--Association Source: 4 or 16 bytes - An IPv4 or IPv6 address. This co
uld be the IP
address of the PCEP speaker that created a dynamic association, an opera
tor configured IP address, or an IP
address selected as per the local policy. The value such as 0.0.0.0 or :
:/128 are acceptable.-->
Association Source: Contains a valid IPv4 address (4 bytes) if the
ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if the
ASSOCIATION Object-Type is 2. The address provides scoping for the Association
ID.
See <xref target="AssocSrc"/> for details.
</t>
<t> Optional TLVs: The optional TLVs follow the PCEP TLV format
of <xref target="RFC5440"/>. This document defines two optional TLVs. Ot
her documents can define more TLVs in future.
</t>
<section anchor="Global-association-src" title="Global Association Source TL
V">
<t> The Global Association Source TLV is an optional TLV for use in the As
sociation Object.
The meaning and the usage of Global Association Source is as per Section
4 of <xref target="RFC6780"/>.
</t>
<figure anchor="Global-Association-Object-Fmt1" title="The Global Association
Source TLV format">
<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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> </figure>
<t> Type: 30 (Early allocation by IANA). </t> <t>The ASSOCIATION Object-Type value is 2 for IPv6, and its format is
<t> Length: Fixed value of 4 bytes. </t> shown in <xref target="Association-Object-Fmt2" format="default"/>:</t>
<t> Global Association Source: as defined in Section 4 of <xref target="RFC6 <figure anchor="Association-Object-Fmt2">
780"/>. </t> <name>The IPv6 ASSOCIATION Object Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
</section> 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
<section anchor="EXT-association" title="Extended Association ID TLV"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
<t> The Extended Association ID TLV is an optional TLV for use in +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the Association Object. The meaning and the usage of Extended Association | Association Type | Association ID |
ID is as per Section 4 of <xref target="RFC6780"/>. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</t> | |
| IPv6 Association Source |
<figure anchor="Ext-id-Object-Fmt1" title="The Extended Association ID TLV | |
format"> | |
<artwork><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Association ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> </figure>
<t> Type: 31 (Early allocation by IANA). </t> <dl newline="false" spacing="normal">
<t> Length: variable. </t> <dt>Reserved (2 bytes):</dt>
<t> Extended Association ID: as defined in Section 4 of <xref target="RFC678 <dd><bcp14>MUST</bcp14> be set to 0 and ignored upon
0"/>. </t> receipt.</dd>
<dt>Flags (2 bytes):</dt>
</section> <dd>
<section title="Association Source" anchor="AssocSrc"> <t>The following flag is currently defined:
<t>The Association Source field in the ASSOCIATION object is
set to a valid IP address to identify the node that originates the associatio
n. In case of dynamic associations, the association source is usually set as the
local PCEP speaker address, unless local policy dictates otherwise, in which ca
se association source is set based on the local policy. In case of PCE redundanc
y, local policy could set the source as a virtual IP address which identifies al
l instances of
the PCE. In case of operator-configured association, the association source i
s manually configured and it could be set as one of the PCEP speakers, Network M
anagement System (NMS), or any other
valid IP address that scopes the association identifier for the association t
ype.</t>
</section>
<section title="Unique Identification for an Association Group" anchor="id">
<t>The combination of the mandatory fields Association type, Association ID
and Association Source in the ASSOCIATION object uniquely identify the associati
on group. If the optional TLVs - Global Association Source or Extended Associati
on ID are included, then they MUST be included in combination with mandatory fie
lds to uniquely identify the association group. In this document, all these fiel
ds are collectively called 'association parameters'. Note that the ASSOCIATION o
bject MAY include other optional TLVs (not defined in this document) based on th
e
association types, that provides 'information' related to the association ty
pe, this document uses the term 'association information' for it. </t>
</section>
</section> <!-- Object Definition -->
<section title="Relationship with the RSVP ASSOCIATION">
<t>The format of PCEP ASSOCIATION Object defined in this document is ali
gned with the RSVP ASSOCIATION object (<xref target="RFC6780"/>). Various Associ
ation types related to RSVP association
are defined in <xref target="RFC4872"/>, <xref target="RFC4873"/>, and <
xref target="RFC7551"/>. The PCEP extensions that define new association types,
should clarify how the PCEP associations would work with RSVP associations and v
ice-versa.</t>
</section>
<section anchor="Object-Encoding" title="Object Encoding in PCEP messages">
<t>Message formats in this document are expressed using Reduced BNF (RBNF)
as used in <xref target="RFC5440"/> and defined in <xref target="RFC5511"/>.</t>
<section title="Stateful PCEP messages">
<t> The ASSOCIATION Object MAY be carried in the Path
Computation Update (PCUpd), Path Computation Report (PCRpt) and Path
Computation Initiate (PCInitiate) messages. </t>
<t> When carried in PCRpt message, it is used to report the association
group membership pertaining to a LSP to a stateful PCE.
The PCRpt message are used for both initial state synchronization operations
(Section 5.6 of
<xref target="RFC8231"/>) as well as whenever the state of the LSP changes.
If the LSP belongs to an
association group, then the associations MUST be included during the state s
ynchronization operations.</t>
<t>The PCRpt message can also be used to remove an LSP from one or more asso
ciation groups
by setting the R flag to 1 in the ASSOCIATION object.</t>
<t>When an LSP is first reported to the PCE, the PCRpt message MUST include
all the association groups that it belongs to. Any subsequent report message SHO
ULD include only the associations that are being modified or removed.</t>
<t> The PCRpt message is defined in <xref target='RFC8231'></xref>
and updated as below:</t>
<figure>
<artwork><![CDATA[
</t>
<dl newline="false" spacing="normal">
<dt>R (Removal - 1 bit):</dt>
<dd>When set, the requesting
PCEP peer requires the removal of an LSP from the association group.
When unset, the PCEP peer indicates that the LSP is added or retained
as part of the association group. This flag is used for the ASSOCIATION
object in the Path Computation Report (PCRpt) and
Path Computation Update (PCUpd) messages. It is ignored in other
PCEP messages.</dd>
</dl>
</dd>
</dl>
<t>The unassigned flags <bcp14>MUST</bcp14> be set to 0 on transmission
and <bcp14>MUST</bcp14> be
ignored on receipt.</t>
<dl newline="false" spacing="normal">
<dt>Association Type (2 bytes):</dt>
<dd>The Association Type
(<xref target="iana_assoc_type" format="default"/>). The Association Types
will be defined in future documents.</dd>
<dt>Association ID (2 bytes):</dt>
<dd>The identifier of the association
group. When combined with other association parameters, such as an
Association Type and Association Source, this value uniquely identifies an
association group. The values 0xffff and 0x0 are reserved. The value
0xffff is used to indicate all association groups and could be used with
the R flag to indicate removal for all associations for the LSP within the
scope of the Association Type and Association Source.</dd>
<dt>Association Source:</dt>
<dd>Contains a valid IPv4 address (4 bytes)
if the ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if
the ASSOCIATION Object-Type is 2. The address provides scoping for the
Association ID. See <xref target="AssocSrc" format="default"/> for details.<
/dd>
<dt>Optional TLVs:</dt>
<dd>The optional TLVs follow the PCEP TLV format
defined in <xref target="RFC5440" format="default"/>. This document defines
two optional
TLVs. Other documents can define more TLVs in the future.</dd>
</dl>
<section anchor="Global-association-src" numbered="true" toc="default">
<name>Global Association Source TLV</name>
<t> The Global Association Source TLV is an optional TLV for use in th
e ASSOCIATION object.
The meaning and usage of the Global Association Source TLV are as per
<xref target="RFC6780" sectionFormat="of" section="4"/>.
</t>
<figure anchor="Global-Association-Object-Fmt1">
<name>The Global Association Source TLV Format</name>
<artwork name="" type="" align="left" alt=""><![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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork
>
</figure>
<dl newline="false" spacing="normal">
<dt>Type:</dt>
<dd>30</dd>
<dt>Length:</dt>
<dd>Fixed value of 4 bytes.</dd>
<dt>Global Association Source:</dt>
<dd>As defined in
<xref target="RFC6780" sectionFormat="of" section="4"/>.</dd>
</dl>
</section>
<section anchor="EXT-association" numbered="true" toc="default">
<name>Extended Association ID TLV</name>
<t> The Extended Association ID TLV is an optional TLV for use in
the ASSOCIATION object. The meaning and usage of the
Extended Association ID TLV are as per
<xref target="RFC6780" sectionFormat="of" section="4"/>.
</t>
<figure anchor="Ext-id-Object-Fmt1">
<name>The Extended Association ID TLV Format</name>
<artwork name="" type="" align="left" alt=""><![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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Association ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork
>
</figure>
<dl newline="false" spacing="normal">
<dt>Type:</dt>
<dd>31</dd>
<dt>Length:</dt>
<dd>Variable.</dd>
<dt>Extended Association ID:</dt>
<dd>As defined in
<xref target="RFC6780" sectionFormat="of" section="4"/>.</dd>
</dl>
</section>
<section anchor="AssocSrc" numbered="true" toc="default">
<name>Association Source</name>
<t>The Association Source field in the ASSOCIATION object is
set to a valid IP address to identify the node that originated the
association. In the case of dynamic associations, the Association Source is
usually set as the local PCEP speaker address unless local policy dictates
otherwise, in which case the Association Source is set based on the local
policy. In the case of PCE redundancy, local policy could set the source
as a virtual IP address that identifies all instances of the PCE. In the
case of Operator-configured Associations, the Association Source is
manually configured, and it could be set as one of the PCEP speakers, an
NMS, or any other valid IP address that scopes the Association ID for the As
sociation Type.</t>
</section>
<section anchor="id" numbered="true" toc="default">
<name>Unique Identification for an Association Group</name>
<t>The combination of the mandatory fields Association Type, Associati
on
ID, and Association Source in the ASSOCIATION object uniquely identifies
the association group. If the optional TLVs (Global Association Source and
Extended Association ID) are included, then they <bcp14>MUST</bcp14> be incl
uded in
combination with mandatory fields to uniquely identify the association
group. In this document, all these fields are collectively called
"association parameters". Note that the ASSOCIATION object <bcp14>MAY</bcp14
> include
other optional TLVs (not defined in this document) based on the
Association Types. These TLVs provide "information" related to the
Association Type. This document refers to this information as
"association information".</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Relationship to the RSVP ASSOCIATION Object</name>
<t>The format of the PCEP ASSOCIATION object defined in this document
is aligned with the RSVP ASSOCIATION object <xref target="RFC6780" format
="default"/>. Various Association Types related to RSVP
association are defined in <xref target="RFC4872" format="default"/>, <xr
ef target="RFC4873" format="default"/>, and <xref target="RFC7551" format="defau
lt"/>. The PCEP extensions
that define new Association Types should clarify how the PCEP
associations would work with RSVP associations and vice versa.</t>
</section>
<section anchor="Object-Encoding" numbered="true" toc="default">
<name>Object Encoding in PCEP Messages</name>
<t>Message formats in this document are expressed using Routing BNF
(RBNF) as used in <xref target="RFC5440" format="default"/> and defined in
<xref target="RFC5511" format="default"/>.</t>
<section numbered="true" toc="default">
<name>Stateful PCEP Messages</name>
<t>The ASSOCIATION object <bcp14>MAY</bcp14> be carried in the PCUpd,
PCRpt, and
Path Computation Initiate (PCInitiate) messages. </t>
<t>When carried in a PCRpt message, this object is used to report the
association group membership pertaining to an LSP to a stateful PCE.
The PCRpt message is used for initial State Synchronization operations
(<xref target="RFC8231" sectionFormat="of" section="5.6"/>), as well as when
ever the
state of the LSP changes. If the LSP belongs to an association group, then
the associations <bcp14>MUST</bcp14> be included during the State Synchroniz
ation
operations.</t>
<t>The PCRpt message can also be used to remove an LSP from one or mor
e
association groups by setting the R flag to 1 in the ASSOCIATION
object.</t>
<t>When an LSP is first reported to the PCE, the PCRpt message <bcp14>
MUST</bcp14>
include all the association groups that it belongs to. Any subsequent
PCRpt message <bcp14>SHOULD</bcp14> include only the associations that are b
eing
modified or removed.</t>
<t> The PCRpt message is defined in <xref target="RFC8231" format="def
ault"/>
and updated as shown below:</t>
<sourcecode type="rbnf"><![CDATA[
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
[<association-list>] [<association-list>]
<path> <path>
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<path>::= <intended-path> <path>::= <intended-path>
[<actual-attribute-list><actual-path>] [<actual-attribute-list><actual-path>]
<intended-attribute-list> <intended-attribute-list>
<association-list> ::= <ASSOCIATION> [<association-list>] <association-list> ::= <ASSOCIATION> [<association-list>]
]]></artwork> ]]></sourcecode>
</figure> <t> When an LSP is delegated to a stateful PCE, the stateful PCE can c
reate
<t> When an LSP is delegated to a stateful PCE, the stateful PCE can create a new association group for this LSP or associate it with one or more existi
a new association group for this LSP, or associate it with one or more exist ng
ing association groups. This is done by including the ASSOCIATION object in a
association groups. This is done by including the ASSOCIATION Object in a
PCUpd message. A stateful PCE can also remove a delegated PCUpd message. A stateful PCE can also remove a delegated
LSP from one or more association groups by setting the R flag to 1 in the AS SOCIATION object.</t> LSP from one or more association groups by setting the R flag to 1 in the AS SOCIATION object.</t>
<t>The PCUpd message <bcp14>SHOULD</bcp14> include the association gro
ups that are being modified or removed. There is no need to include associations
that remain unchanged.</t>
<t>The PCUpd message is defined in <xref target="RFC8231" format="defa
ult"/>
and updated as shown below:</t>
<t>The PCUpd message SHOULD include the association groups that are being mo <sourcecode type="rbnf"><![CDATA[
dified or removed, there is no need to include associations that remains unchang <PCUpd Message> ::= <Common Header>
ed.</t> <update-request-list>
]]></sourcecode>
<t> The PCUpd message is defined in <xref target='RFC8231'></xref> <t>Where:</t>
and updated as below:</t> <sourcecode type="rbnf"><![CDATA[
<figure>
<artwork><![CDATA[
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-list>] <update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
<LSP> <LSP>
[<association-list>] [<association-list>]
<path> <path>
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<path>::= <intended-path><intended-attribute-list> <path>::= <intended-path><intended-attribute-list>
<association-list> ::= <ASSOCIATION> [<association-list>] <association-list> ::= <ASSOCIATION> [<association-list>]
]]></artwork> ]]></sourcecode>
</figure> <t>Unless a PCEP speaker wants to delete an association
<t>Unless a PCEP speaker wants to delete an association from an LSP or make changes to the association, it does not need to
from an LSP or make changes to the association, it does not need to carry th include the ASSOCIATION object in future stateful messages.</t>
e ASSOCIATION <t>A PCE initiating a new LSP can also include the association groups
object in future stateful messages.</t> that this LSP belongs to. This is done by including the ASSOCIATION object in a
PCInitiate message. The PCInitiate message <bcp14>MUST</bcp14> include all t
<t>A PCE initiating a new LSP can also include the association groups that t he association groups that it belongs to.
his LSP belongs to. This is done by including the ASSOCIATION Object in a The PCInitiate message is defined in <xref target="RFC8281" format="default"
PCInitiate message. The PCInitiate message MUST include all the association />
groups that it belongs to. and updated as shown below:
The PCInitiate message is defined in <xref target='RFC8281'></xref> </t>
and updated as below: <sourcecode type="rbnf"><![CDATA[
</t>
<figure>
<artwork><![CDATA[
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: ]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>] [<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>| <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP> <PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP> <LSP>
[<END-POINTS>] [<END-POINTS>]
<ERO> <ERO>
[<association-list>] [<association-list>]
[<attribute-list>] [<attribute-list>]
]]></sourcecode>
Where: <t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<association-list> ::= <ASSOCIATION> [<association-list>] <association-list> ::= <ASSOCIATION> [<association-list>]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section numbered="true" toc="default">
<section title="Request Message"> <name>Request Message</name>
<t> <t>
In case of passive (stateful or stateless) PCE, the ASSOCIATION Object In the case of a passive (stateful or stateless) PCE, the ASSOCIATION
is OPTIONAL and MAY be carried in the Path Computation Request object is <bcp14>OPTIONAL</bcp14> and <bcp14>MAY</bcp14> be carried in the P
(PCReq) message. CReq message.
</t> </t>
<t> <t>
When carried in a PCReq message, the ASSOCIATION Object is used to associate When carried in a PCReq message, the ASSOCIATION object is used to
the path associate the path computation request to an association group. The
computation request to an association group. The association (and the other L association (and the other LSPs) should be known to the PCE
SPs) should be known to the PCE beforehand. beforehand. These could be operator configured or dynamically learned
These could be operator-configured or dynamically learned before via stateful beforehand via stateful PCEP messages. The R flag in the ASSOCIATION
PCEP messages. The R flag in ASSOCIATION object within PCReq message object within a PCReq message <bcp14>MUST</bcp14> be set to 0 while sending
MUST be set to 0 while sending and ignored on receipt. and ignored
on receipt.
</t> </t>
<t> <t>
The PCReq message is defined in <xref target="RFC5440"/> and updated in The PCReq message is defined in <xref target="RFC5440" format="default"/> and
<xref target="RFC8231"/> , it is further updated below for updated in
association: <xref target="RFC8231" format="default"/>. It is further updated below for
</t> association groups:
</t>
<figure> <sourcecode type="rbnf"><![CDATA[
<artwork><![CDATA[
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
]]></sourcecode>
<t>Where:</t>
<sourcecode type="rbnf"><![CDATA[
<svec-list>::= <SVEC>[<svec-list>]
<request-list>::= <request>[<request-list>]
Where: <request>::= <RP>
<svec-list>::= <SVEC>[<svec-list>] <END-POINTS>
<request-list>::= <request>[<request-list>] [<LSP>]
[<LSPA>]
<request>::= <RP> [<BANDWIDTH>]
<END-POINTS> [<metric-list>]
[<LSP>] [<association-list>]
[<LSPA>] [<RRO>[<BANDWIDTH>]]
[<BANDWIDTH>] [<IRO>]
[<metric-list>] [<LOAD-BALANCING>]
[<association-list>] ]]></sourcecode>
[<RRO>[<BANDWIDTH>]] <t>Where:</t>
[<IRO>] <sourcecode type="rbnf"><![CDATA[
[<LOAD-BALANCING>] <association-list> ::= <ASSOCIATION> [<association-list>]
]]></sourcecode>
Where:
<association-list> ::= <ASSOCIATION> [<association-list>]
]]></artwork>
</figure>
<t>
Note that the LSP object MAY be present for the passive stateful PCE mode.
</t>
</section>
<section title="Reply Message">
<t>
In case of passive (stateful or stateless) PCE, the ASSOCIATION Object
is OPTIONAL and MAY be carried in the Path Computation Reply
(PCRep) message with the NO-PATH object. The ASSOCIATION object in PCRep mess
age indicates the
association group that cause the PCE to fail to find a path.
</t>
<t>
The PCRep message is defined in <xref target="RFC5440"/> and updated in
<xref target="RFC8231"/> , it is further updated below for
association:
</t>
<figure> <t>
<artwork><![CDATA[ Note that the LSP object <bcp14>MAY</bcp14> be present for the passive statef
ul
PCE mode.
</t>
</section>
<section numbered="true" toc="default">
<name>Reply Message</name>
<t>
In the case of a passive (stateful or stateless) PCE, the ASSOCIATION
object is <bcp14>OPTIONAL</bcp14> and <bcp14>MAY</bcp14> be carried in the P
CRep message with the
NO-PATH object. The ASSOCIATION object in the PCRep message indicates the
association group that caused the PCE to fail to find a path.
</t>
<t>
The PCRep message is defined in <xref target="RFC5440" format="default"/> and
updated in
<xref target="RFC8231" format="default"/>. It is further updated below for as
sociation groups:
</t>
<sourcecode type="rbnf"><![CDATA[
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
Where: ]]></sourcecode>
<t>Where:</t>
<response-list>::=<response>[<response-list>] <sourcecode type="rbnf"><![CDATA[
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<association-list>]
[<attribute-list>]
[<path-list>]
Where:
<association-list> ::= <ASSOCIATION> [<association-list>]
]]></artwork>
</figure>
<t>
Note that the LSP object MAY be present for the passive stateful PCE mode.
</t>
</section>
</section> <!-- Object Encoding -->
<section anchor="Rules" title="Processing Rules">
<t> <response>::=<RP>
Association groups can be operator-configured on the necessary PCEP speakers [<LSP>]
and the PCEP speakers can join the existing association groups. [<NO-PATH>]
In addition, a PCC or a PCE can create association groups dynamically and th [<association-list>]
e PCEP speaker can also report the associations to its peer via PCEP messages. [<attribute-list>]
The operator-configured associations are created via configurations (where a [<path-list>]
ll association parameters are manually set) and exist until explicitly removed v ]]></sourcecode>
ia configurations. The PCEP speaker can add LSPs to these configured association <t>Where:</t>
s and carry this via stateful PCEP messages. The dynamic associations are create <sourcecode type="rbnf"><![CDATA[
d dynamically by the PCEP speaker (where all association parameters are populate <association-list> ::= <ASSOCIATION> [<association-list>]
d dynamically). The association group is attached to the LSP state, and the asso ]]></sourcecode>
ciation group exists till there is at least one LSP as part of the association. <t>
As described in <xref target="id"/>, the association parameters are the combinat Note that the LSP object <bcp14>MAY</bcp14> be present for the passive statef
ion of Association type, Association ID and Association Source as well as option ul
al global source and extended association identifier, that uniquely identifies a PCE mode.
n association group. The information related to the association types encoded vi </t>
a the TLVs of a particular association type (not described in this document) are </section>
the association information (<xref target="id"/>).</t> </section>
<section anchor="Rules" numbered="true" toc="default">
<name>Processing Rules</name>
<t>
Association groups can be operator configured on the necessary PCEP
speakers, and the PCEP speakers can join the existing association groups.
In addition, a PCC or a PCE can create association groups dynamically, and
the PCEP speaker can also report the associations to its peer via PCEP
messages. The Operator-configured Associations are created via
configurations (where all association parameters are manually set) and
exist until explicitly removed via configurations. The PCEP speaker can
add LSPs to these configured associations and provide this information
via stateful PCEP messages. The dynamic associations are created
dynamically by the PCEP speaker (where all association parameters are
populated dynamically). The association group is attached to the LSP
state, and the association group exists until there is at least one LSP as
part of the association. As described in <xref target="id" format="default"/
>, the
association parameters are the combination of Association Type,
Association ID, and Association Source, as well as the optional Global
Association Source and Extended Association ID TLVs; this combination
uniquely identifies an association group. The information
related to the Association Types encoded via the TLVs of a particular
Association Type (not described in this document) is the association
information (<xref target="id" format="default"/>).</t>
<!--But a PCE peer cannot add new members for association group created by <t>If a PCEP speaker does not recognize the ASSOCIATION object in the
another peer.--> stateful message, it will return a PCErr message with Error-Type "Unknown
<t>If a Object" as described in <xref target="RFC5440" format="default"/>. In the ca
PCEP speaker does not recognize the ASSOCIATION object in the stateful messa se of a PCReq
ge, it will return a PCErr message, the PCE would react based on the P flag as per <xref target="RFC544
message with Error-Type "Unknown Object" as described in <xref target="RFC5 0" format="default"/>. If a PCEP speaker understands the ASSOCIATION object
440"/>. In case of PCReq message, the PCE would react based on the P flag as per but does not support the Association Type, it <bcp14>MUST</bcp14> return a P
<xref target="RFC5440"/>. CErr message
If a with Error-Type 26 "Association Error" and
PCEP speaker understands the ASSOCIATION object but does not support the Ass Error-value 1 "Association Type is not supported". If any association
ociation type, parameters are invalid in the ASSOCIATION object, the PCEP speaker would
it MUST return a PCErr consider this object malformed and process it as a malformed message <xref t
message with Error-Type 26 (Early allocation by IANA) "Association Error" an arget="RFC5440" format="default"/>. On receiving a PCEP message with an ASSOCIAT
d Error-Value ION
1 "Association type is not supported". object, if a PCEP speaker finds that too many LSPs belong to the
If any association parameters are invalid in the ASSOCIATION object, the PCE association group, it <bcp14>MUST</bcp14> return a PCErr message with Error-
P speaker Type 26
would consider this as malformed object and handle it as malformed message < "Association Error" and Error-value 2 "Too
xref target="RFC5440"/>. many LSPs in the association group". If a PCEP speaker cannot handle a new
On receiving a PCEP association, it <bcp14>MUST</bcp14> return a PCErr message with Error-Type 2
message with ASSOCIATION, if a 6
PCEP speaker finds that too many LSPs belong to the association group, it MU "Association Error" and Error-value 3 "Too many
ST association groups". These numbers <bcp14>MAY</bcp14> be set by the operator
return a PCErr message with Error-Type 26 (Early allocation by IANA) "Associ or chosen
ation Error" and Error-Value
2 "Too many LSPs in the association group". If a PCEP speaker cannot handle
a new association, it MUST
return a PCErr message with Error-Type 26 (Early allocation by IANA) "Associ
ation Error" and Error-Value
3 "Too many association groups". These numbers MAY be set by operator or dec
ided
based on a local policy. </t> based on a local policy. </t>
<t>If a PCE peer is unwilling or unable to process the ASSOCIATION objec
<t>If a PCE t
peer is unwilling or unable to process the ASSOCIATION object in the statefu in the stateful message, it <bcp14>MUST</bcp14> return a PCErr message with
l message, it MUST return a the
PCErr message with the Error-Type "Not supported object" and follow the rele Error-Type "Not supported object" and follow the relevant procedures
vant described in <xref target="RFC5440" format="default"/>. In the case of a PCR
procedures described in <xref target="RFC5440"/>. In case of PCReq message, eq message, the
the PCE would react based on the P flag as per <xref target="RFC5440"/>. PCE would react based on the P flag as per <xref target="RFC5440" format="de
On receiving a PCEP fault"/>. On
message with ASSOCIATION, if a receiving a PCEP message with an ASSOCIATION object, if a PCEP speaker
PCEP speaker could not add the LSP to the association group for any reason, could not add the LSP to the association group for any reason, it <bcp14>MUS
it MUST T</bcp14>
return a PCErr message with Error-Type 26 (Early allocation by IANA) "Associ return a PCErr message with Error-Type 26
ation Error" and Error-Value "Association Error" and Error-value 7 "Cannot join the association
7 "Cannot join the association group".</t> group".</t>
<t>If a PCEP speaker receives an ASSOCIATION object for an Operator-conf
<t>If a PCEP speaker receives an ASSOCIATION object for an operator-configur igured Association
ed association and the Association ID is not in the Operator-configured Association Range
and the association identifier is not in the operator-configured associati for the Association Type and Association Source, it <bcp14>MUST</bcp14> re
on range turn a PCErr message with Error-Type 26
for the Association type and Association Source, it MUST return a PCErr me "Association Error" and Error-value 8 "Association ID not in range".
ssage with Error-Type 26 (Early allocation by IANA) </t>
"Association Error" and Error-Value 8 "Association identifier not in range <t>If a PCEP speaker receives an ASSOCIATION object in a PCReq message
". and the association is not known (the association is not configured,
</t> was not created dynamically, or was not learned from a PCEP peer), it <bcp
14>MUST</bcp14> return a
<t>If a PCEP speaker receives ASSOCIATION in PCReq message, and the associ PCErr message with Error-Type 26 "Association
ation Error" and Error-value 4 "Association unknown".</t>
is not known (association is not configured, or created dynamically, or lear <t>If the association information (related to the association group as a
ned from a PCEP peer), it MUST whole) received from the peer does not match the local operator-configured
return a PCErr message with Error-Type 26 (Early allocation by IANA) "Associ information, it <bcp14>MUST</bcp14> return a PCErr message with Error-Type 2
ation Error" and Error-Value 6 "Association Error" and Error-value 5
4 "Association unknown".</t> "Operator-configured association information mismatch". On receiving
association information (related to the association group as a whole) that
<t>If the association information (related to the association group as a who does not match the association information previously received about the
le) same association from a peer, it <bcp14>MUST</bcp14> return a PCErr message
received from the peer does not match with the local operator-configured with
information, it MUST Error-Type 26 "Association Error" and
return a PCErr message with Error-Type 26 (Early allocation by IANA) "Associ Error-value 6 "Association information mismatch". Note that information
ation Error" and Error-Value related to each LSP within the association as part of the association
5 "Operator-configured association information mismatch". On receiving assoc information TLVs could be different.
iation </t>
information (related to the association group as a whole) that does not matc <t>If a PCEP speaker receives an ASSOCIATION object with the R bit set f
h with the association information previously received or
about the same association from a peer, it MUST removal and the association group (identified by association parameters)
return a PCErr message with Error-Type 26 (Early allocation by IANA) "Associ is not known, it <bcp14>MUST</bcp14> return a PCErr message with Error-Type
ation Error" and Error-Value 26
6 "Association information mismatch". Note that information related to each "Association Error" and Error-value 4
LSP within the association as part of the association information TLVs could be "Association unknown".</t>
different. <t>The dynamic associations are cleared along with the LSP state
</t> information as per <xref target="RFC8231" format="default"/>. When a PCEP se
ssion is
<t>If a PCEP speaker receives an ASSOCIATION object with the R bit set for r terminated, after expiry of the State Timeout Interval at the PCC, the LSP
emoval, and the association state associated with that PCEP session is reverted to operator-defined
group (identified by association parameters) is not known, it MUST default parameters or behaviors. The same procedure is also followed for
return a PCErr message with Error-Type 26 (Early allocation by IANA) "Associ the association groups. On session termination at the PCE, when the LSP
ation Error" and Error-Value state reported by the PCC is cleared, the association groups are also
4 "Association unknown". </t> cleared. When there are no LSPs in an association group, the association
is considered empty and thus deleted.</t>
<t>The dynamic associations are cleared along with the LSP state information <t>If the LSP is delegated to another PCE on session failure,
as the associations (and association information) set by the PCE remain
per the <xref target='RFC8231'></xref>. When a intact, unless updated by the new PCE that takes over. </t>
PCEP session is terminated, <t>Upon LSP delegation revocation, the PCC <bcp14>MAY</bcp14> clear the
after expiry of State Timeout Interval at PCC, the LSP state associated association
with that PCEP session is reverted to operator-defined default created by the PCE, but in order to avoid traffic loss, it <bcp14>SHOULD</bc
parameters or behaviours. Same procedure is also followed for the associat p14>
ion groups. On session perform this action in a make-before-break fashion (same as <xref target="RF
termination at the PCE, when the LSP state reported by PCC is cleared, the C8231" format="default"/>).</t>
association groups </section>
are also cleared. When there are no LSPs in an association group, the asso </section>
ciation is considered to be empty and thus deleted. </t> <section anchor="IANA-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>In case the LSP is delegated to another PCE on session failure,
the associations (and association information) set by the PCE remains inta
ct, unless updated by the new PCE that takes over. </t>
<!--<t>
The association timeout interval is as a PCC-local value that can be
operator-configured or computed by the PCC based on local policy and is us
ed in the context
of cleaning up associations on session failure. The associatioThe associat
ion timeout
must be set to a value no larger than the state timeout interval (defined
in
<xref target='RFC8231'></xref>) and larger than the delegation
timeout interval (defined in
<xref target='RFC8231'></xref>.
</t>
<t>
When a PCC's PCEP session with the PCE terminates unexpectedly, the PCC M
UST
wait for the association timeout interval before cleaning up the associat
ion.
If this PCEP session can be re-established before the association timeout
interval time expires, no action is taken to clean the association create
d by
this PCE. During the time window of the redelegation timeout interval and
the association timeout interval, the PCE, after re-establishing the sessi
on,
can also ask for redelegation following the procedure
defined in <xref target='RFC8231'></xref> and
<xref target='RFC8281'></xref>.
When the association timeout interval timers expires,
the PCC clears all the associations which are not delegated to any PCEs.
</t>-->
<t>Upon LSP delegation revocation, the PCC MAY clear the association
created by the PCE, but in order to avoid traffic loss, it SHOULD perform t
his
in a make-before-break fashion (same as <xref target='RFC8231'/>).</t>
<!--<t>Error handling for situations for multiple PCE scenarios will be inc
luded in
future versions of this draft.
</t>-->
</section> <!-- Rules -->
</section> <!-- Association Object -->
<section anchor="IANA-considerations" title="IANA Considerations">
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" <t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry at &lt;http://www.iana.org/assignments/pcep&gt;.</t> registry at <eref brackets="angle" target="https://www.iana.org/assignments/
<section title="PCEP Object"> pcep"/>.</t>
<section numbered="true" toc="default">
<t>The "PCEP Numbers" registry contains a subregistry "PCEP Objects". <name>PCEP Object</name>
IANA is requested to confirm the early allocation of the following <t>The "Path Computation Element Protocol (PCEP) Numbers" registry
code point in the PCEP Objects registry. contains a subregistry called "PCEP Objects". IANA has allocated the
following code point in the "PCEP Objects" registry.
</t> </t>
<texttable anchor="Object-Code-Points" style="none" suppress-title="true
">
<ttcol align="center">Object-Class Value &nbsp;</ttcol>
<ttcol align="left" width='50%'>Name </ttcol>
<ttcol align="left">Reference </ttcol>
<c></c><c>&nbsp;&nbsp;&nbsp;&nbsp;</c><c></c>
<c>40 (Early allocation by IANA)</c><c>Association</c><c>[This.I-D]</c
>
<c></c><c>Object-Type</c><c></c>
<c></c><c>&nbsp;&nbsp;&nbsp;&nbsp;0: Reserved </c><c></c>
<c></c><c>&nbsp;&nbsp;&nbsp;&nbsp;1: IPv4 </c><c></c>
<c></c><c>&nbsp;&nbsp;&nbsp;&nbsp;2: IPv6 </c><c></c>
</texttable>
</section>
<section title="PCEP TLV">
<t>IANA is requested to confirm the early allocation of the following
code point in the "PCEP TLV Type Indicators" registry.
</t>
<texttable anchor="new-association-TLV-CP" style="none" suppress-title=" <table anchor="tab-1">
true"> <name>PCEP Object</name>
<ttcol align="center" width='20%'>Value</ttcol> <thead>
<ttcol align="left" width='40%'>Meaning </ttcol> <tr>
<ttcol align="left" width='40%'>Reference </ttcol> <th>Object-Class Value</th>
<c>29 (Early allocation by IANA)</c><c>&nbsp;Operator-configured Assoc <th>Name</th>
iation Range</c><c>[This.I-D]</c> <th>Object-Type</th>
<c>30 (Early allocation by IANA)</c><c>&nbsp;Global Association Source <th>Reference</th>
</c><c>[This.I-D]</c> </tr>
<c>31 (Early allocation by IANA)</c><c>&nbsp;Extended Association ID</ </thead>
c><c>[This.I-D]</c> <tbody>
</texttable> <tr>
<td rowspan="3">40</td>
<td rowspan="3">ASSOCIATION</td>
<td>0: Reserved</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>1: IPv4</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>2: IPv6</td>
<td>RFC 8697</td>
</tr>
</tbody>
</table>
<t>IANA is requested to fix the meaning for value 31 in the above regist </section>
ry to 'Extended Association ID', it is currently mentioned as 'Extended Associat <section numbered="true" toc="default">
ion Id'.</t> <name>PCEP TLV</name>
<t>IANA has allocated the following
code points in the "PCEP TLV Type Indicators" registry.
</t>
<t>IANA is also requested to make a new assignment for <table anchor="tab-2">
<name>PCEP TLV Type Indicators</name>
<thead>
<tr>
<th>Value</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>29</td>
<td>Operator-configured Association Range</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>30</td>
<td>Global Association Source</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>31</td>
<td>Extended Association ID</td>
<td>RFC 8697</td>
</tr>
</tbody>
</table>
<t>IANA has corrected the capitalization in the meaning for value 31 in
the above registry
to "Extended Association ID"; it was previously listed as "Extended
Association Id".</t>
<t>IANA has made a new assignment in
the existing "PCEP TLV Type Indicators" registry as follows: the existing "PCEP TLV Type Indicators" registry as follows:
</t> </t>
<table anchor="tab-3">
<texttable anchor="new-association-TLV-CP-2" style="none" suppress-title <name>ASSOC-Type-List PCEP TLV Type Indicator</name>
="true"> <thead>
<ttcol align="center" width='20%'>Value</ttcol> <tr>
<ttcol align="left" width='40%'>Meaning </ttcol> <th>Value</th>
<ttcol align="left" width='40%'>Reference </ttcol> <th>Meaning</th>
<c>TBD</c><c>&nbsp;ASSOC-Type-List</c><c>[This.I-D]</c> <th>Reference</th>
</texttable> </tr>
</thead>
<tbody>
<tr>
<td>35</td>
<td>ASSOC-Type-List</td>
<td>RFC 8697</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Association Flags</name>
</section> <t>Per this document, IANA has created a subregistry of the
<section title="Association Flags"> "Path Computation Element Protocol (PCEP) Numbers" registry
<t>This document requests IANA to create a subregistry of the "PCEP Numb for the bits carried in the Flags field of the ASSOCIATION object.
ers" for The subregistry is called "ASSOCIATION Flag Field". New values are
the bits carried in the Flags field of the ASSOCIATION object. assigned by Standards Action <xref target="RFC8126" format="default"/>. Eac
The subregistry is called "ASSOCIATION Flags Field". New values are h bit is
assigned by Standards Action <xref target="RFC8126"/>. Each bit should be tr tracked with the following qualities:
acked
with the following qualities:
<list style="symbols">
<t>Bit number (counting from bit 0 as the most significant bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list></t>
<texttable anchor="Association-Flags" style="none" suppress-title="true </t>
"> <ul spacing="normal">
<ttcol align="left" width='10%'>Bit</ttcol> <li>Bit number (counting from bit 0 as the most significant bit)</li>
<ttcol align="left" width='50%'>Description </ttcol> <li>Capability description</li>
<ttcol align="left" width='40%'>Reference </ttcol> <li>Defining RFC</li>
<c></c><c>&nbsp;&nbsp;&nbsp;&nbsp;</c><c></c> </ul>
<c>15</c><c>R (Removal)</c><c>[This.I-D]</c> <table anchor="tab-4">
</texttable> <name>New ASSOCIATION Flag Field</name>
<thead>
<tr>
<th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>15</td>
<td>R (Removal)</td>
<td>RFC 8697</td>
</tr>
</tbody>
</table>
</section>
<section anchor="iana_assoc_type" numbered="true" toc="default">
<name>Association Type</name>
<t>Per this document, IANA has created a subregistry of the
"Path Computation Element Protocol (PCEP) Numbers" registry for
the Association Type field of the ASSOCIATION object.
The subregistry is called "ASSOCIATION Type Field". New values are
assigned by Standards Action <xref target="RFC8126" format="default"/>.
Each
value is tracked with the following qualities:
</section> </t>
<section title="Association Type" anchor="iana_assoc_type"> <ul spacing="normal">
<t>This document requests IANA to create a subregistry of the "PCEP Nu <li>Type</li>
mbers" for <li>Name</li>
the Association Type field of the the ASSOCIATION object. <li>Reference</li>
The subregistry is called "ASSOCIATION Type Field". New values are </ul>
to be assigned by Standards Action <xref target="RFC8126"/>. Each v
alue should be
tracked with the following qualities:
<list style="symbols">
<t>Type</t>
<t>Name</t>
<t>Reference</t>
</list></t>
<t>There are no association types specified in this document, future
documents should request the
assignment of association types from this subregistry.</t>
</section> <table anchor="tab-5">
<section title="PCEP-Error Object" <name>New ASSOCIATION Type Field</name>
toc="default"> <thead>
<t>IANA is requested to confirm the early allocation of the following co <tr>
de points within <th>Type</th>
the "PCEP-ERROR Object Error Types and Values" sub-registry of the <th>Name</th>
"PCEP Numbers" registry, as follows:</t> <th>Reference</th>
<figure title="" </tr>
suppress-title="true" </thead>
align="left" <tbody>
alt="" <tr>
width="" <td>0</td>
height=""> <td>Reserved</td>
<artwork xml:space="preserve" <td>RFC 8697</td>
name="" </tr>
type="" </tbody>
align="left" </table>
alt=""
width=""
height="">
<![CDATA[
Error-Type Meaning
26 Association Error [This.I-D]
(early Error-value=0:
alloc by Unassigned
IANA) Error-value=1:
Association type is not supported
Error-value=2:
Too many LSPs in the association group
Error-value=3:
Too many association groups
Error-value=4:
Association unknown
Error-value=5:
Operator-configured association
information mismatch
Error-value=6:
Association information mismatch
Error-value=7:
Cannot join the association group
Error-value=8:
Association identifier not in range
]]>
</artwork> <t>
</figure> Values 2-65535 are Unassigned. Future
documents should request the assignment of Association Types from
this subregistry.</t>
</section> </section>
<section toc="default" numbered="true">
<name>PCEP-Error Object</name>
<t>IANA has allocated the following
code points within the "PCEP-ERROR Object Error Types and Values"
subregistry of the "Path Computation Element Protocol (PCEP) Numbers"
registry as follows:</t>
</section> <!-- IANA --> <table anchor="tab-6">
<name>PCEP-ERROR Types and Names</name>
<thead>
<tr>
<th>Error-Type</th>
<th>Meaning</th>
<th>Error-value</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="9">26</td>
<td rowspan="9">Association Error</td>
<td>0: Unassigned</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>1: Association Type is not supported</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>2: Too many LSPs in the association group</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>3: Too many association groups</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>4: Association unknown</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>5: Operator-configured association information mismatch</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>6: Association information mismatch</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>7: Cannot join the association group</td>
<td>RFC 8697</td>
</tr>
<tr>
<td>8: Association ID not in range</td>
<td>RFC 8697</td>
</tr>
</tbody>
</table>
<section anchor="Security" title="Security Considerations"> </section>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC8231" format=
"default"/> and <xref target="RFC5440" format="default"/> apply to the
extensions described in this document as well. Additional considerations
related to a malicious PCEP speaker are introduced, as associations could
be spoofed and could be used as an
attack vector. An attacker could attempt to create too many associations in
an attempt to load the PCEP peer. The PCEP peer responds with a PCErr
message as described in <xref target="Rules" format="default"/>. An attacker
could impact
LSP operations by creating bogus associations. Further, association groups
could provide an adversary with the opportunity to eavesdrop on the
relationship between the LSPs. Thus, securing the PCEP session using
Transport Layer Security (TLS) <xref target="RFC8253" format="default"/>, as
per the
recommendations and best current practices in <xref target="RFC7525" format="
default"/>, is
<bcp14>RECOMMENDED</bcp14>.
<t>The security considerations described in <xref target='RFC8231'></xref> </t>
and <xref target='RFC5440'/> <t>Much of the information carried in the ASSOCIATION object as per this
apply to the extensions described in this document as well. Additional document is not extra sensitive. It often reflects information that can
considerations related to a malicious PCEP speaker are introduced, as associa also be derived from the LSP database, but the association provides a much
tions could be spoofed and could be used as an easier grouping of related LSPs and messages. Implementations and operators
attack vector. An attacker could attempt to create too many associations in a can, and should, use indirect values in the ASSOCIATION object as a way to
n attempt to load the PCEP peer. The PCEP peer responds with hide any sensitive business relationships.</t>
PCErr as described in <xref target="Rules"/>. An attacker could impact LSP op </section>
erations by creating bogus associations. <section toc="default" numbered="true">
Further, association groups could provides an adversary with the opportunity <name>Manageability Considerations</name>
to eavesdrop on the relationship <t>
between the LSPs. All manageability requirements and considerations listed in <xref target="RFC5
Thus securing the PCEP session using Transport Layer 440" format="default"/> and <xref target="RFC8231" format="default"/> apply to P
Security (TLS) <xref target="RFC8253"/>, as per the recommendations and CEP protocol
best current practices in <xref target="RFC7525"/>, is RECOMMENDED. extensions defined in this document. In addition, requirements and
</t> considerations listed in this section apply.
<t>Much of the information carried in the ASSOCIATION object, as per this docu </t>
ment is not extra sensitive. It often reflects information <section toc="default" numbered="true">
that can also be derived from the LSP Database, but association provides a m <name>Control of Function and Policy</name>
uch easier grouping of related LSPs and messages. Implementations <t>
and operator can and should use indirect values in ASSOCIATION as a way to h A PCE or PCC implementation <bcp14>MUST</bcp14> allow Operator-configured Asso
ide any sensitive business relationships.</t> ciations and
</section> <bcp14>SHOULD</bcp14> allow the setting of the Operator-configured Association
<section title="Manageability Considerations" toc="default"> Range (<xref target="Range" format="default"/>) as described in this document.
<t> </t>
All manageability requirements and considerations listed in <xref target="RFC5 </section>
440" pageno="false" format="default" /> <section toc="default" numbered="true">
and <xref target="RFC8231" pageno="false" format="default" /> <name>Information and Data Models</name>
apply to PCEP protocol extensions defined in this document. In addition, requi <t>The PCEP YANG module is defined in <xref target="PCEP-YANG" format="d
rements and considerations listed in this section apply. efault"/>. In the
</t>
<section title="Control of Function and Policy" toc="default">
<t>
A PCE or PCC implementation MUST allow operator-configured associations and SH
OULD allow setting of the operator-configured association range (<xref target="R
ange"/>) as described in this document.
</t>
</section>
<section title="Information and Data Models" toc="default">
<t>The PCEP YANG module is defined in <xref target="I-D.ietf-pce-pcep-yang"/>.
In
future, this YANG module should be extended or augmented to provide future, this YANG module should be extended or augmented to provide
the following additional information relating to association groups.</t> the following additional information related to association groups.</t>
<t>An implementation SHOULD allow the operator to view the associations config <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view th
ured or created dynamically. Further implementation SHOULD allow to view associa e associations
tions reported by each peer, and the current set of LSPs in the association.</t> configured or created dynamically. Future implementations <bcp14>SHOULD</bcp14
<t>It might also be useful to find out how many associations for each associat > allow
ion type currently exist and to know how many free association identifiers are a the viewing of associations reported by each peer and the current set of
vailable for a particular association type and source.</t> LSPs in the association.</t>
</section> <t>It might also be useful to find out how many associations for each
<section title="Liveness Detection and Monitoring" toc="default"> Association Type currently exist and to know how many free Association IDs are
<t> available for a particular Association Type and source.</t>
Mechanisms defined in this document do not imply any new liveness detection an </section>
d monitoring requirements in addition to those already listed in <xref target="R <section toc="default" numbered="true">
FC5440" pageno="false" format="default" />. <name>Liveness Detection and Monitoring</name>
</t> <t>
</section> Mechanisms defined in this document do not imply any new liveness detection an
<section title="Verify Correct Operations" toc="default"> d monitoring requirements in addition to those already listed in <xref target="R
<t> FC5440" format="default"/>.
Mechanisms defined in this document do not imply any new operation verificatio </t>
n requirements in addition to those already listed in <xref target="RFC5440" pag </section>
eno="false" format="default" /> <section toc="default" numbered="true">
and <xref target="RFC8231" pageno="false" format="default" />. <name>Verifying Correct Operation</name>
</t> <t>
</section> Mechanisms defined in this document do not imply any new operation verificatio
<section title="Requirements on Other Protocols" toc="default"> n requirements in addition to those already listed in <xref target="RFC5440" for
<t>Mechanisms defined in this document do not imply any new requirements on ot mat="default"/>
her protocols.</t> and <xref target="RFC8231" format="default"/>.
</section> </t>
<section title="Impact on Network Operations" toc="default"> </section>
<t> <section toc="default" numbered="true">
Mechanisms defined in <xref target="RFC5440" pageno="false" format="default" / <name>Requirements on Other Protocols</name>
> <t>Mechanisms defined in this document do not imply any new requirements
on other protocols.</t>
</section>
<section toc="default" numbered="true">
<name>Impact on Network Operations</name>
<t>
Mechanisms defined in <xref target="RFC5440" format="default"/>
and and
<xref target="RFC8231" pageno="false" format="default" /> also apply to PCEP e <xref target="RFC8231" format="default"/> also apply to PCEP extensions define
xtensions defined in this document. </t> d in this document. </t>
</section> </section>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>We would like to thank Yuji Kamite and Joshua George for
their contributions to this document. Also thanks to Venugopal Reddy,
Cyril Margaria, Rakesh Gandhi, Mike Koldychev, and Adrian Farrel for their
useful comments.</t>
<t>We would like to thank Julien Meuric for shepherding this
document and providing comments with text suggestions.</t>
<t>Thanks to Stig Venaas for the RTGDIR review comments.</t>
<t>Thanks to Alvaro Retana, Mirja Kuhlewind, Martin Vigoureux, Barry Leiba, E
ric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG comments.</t>
</section> </section>
</middle>
<back>
<section anchor="Contributor" title="Contributors"> <displayreference target="I-D.ietf-pce-stateful-path-protection" to="PCE-PROTECT
ION"/>
<figure><artwork> <displayreference target="I-D.ietf-pce-association-diversity" to="PCE-DIVERSITY"
Stephane Litkowski />
Orange
Email: stephane.litkowski@orange.com
Xian Zhang
Huawei Technologies
F3-1-B RnD Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
China
Email: zhang.xian@huawei.com
Mustapha Aissaoui <references>
Nokia <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5511.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6780.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.
xml"/>
</references>
Email: mustapha.aissaoui@nokia.com <references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4657.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4873.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6007.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7551.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.
xml"/>
</artwork></figure> <!-- draft-ietf-pce-pcep-yang (I-D Exists) -->
</section><!-- Contributor --> <reference anchor='PCEP-YANG'>
<front>
<title>A YANG Data Model for Path Computation Element Communications Protocol (P
CEP)</title>
<author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor">
<organization />
</author>
<author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
<organization />
</author>
<author initials='V' surname='Beeram' fullname='Vishnu Beeram'>
<organization />
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization />
</author>
<date month='October' day='31' year='2019' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-pce-pcep-yang-13' />
</reference>
</middle> <!-- draft-ietf-pce-stateful-path-protection (RFC-EDITOR*R since 2020-01-10 -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-pce-stateful-path-protection.xml"/>
<back> <!-- draft-ietf-pce-association-diversity (IESG Eval::AD Followup) -->
<references title="Normative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211 -pce-association-diversity.xml"/>
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.544
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.551
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.678
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.752
5.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.805
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.812
6.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.823
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.828
1.xml"?>
</references> </references>
</references>
<section anchor="ex" numbered="true" toc="default">
<name>Example of an Operator-Configured Association Range</name>
<t>Consider an Association Type T1 (which allows both dynamic and
Operator-configured Associations with a default range of
&lt;0x1000, 0xffff&gt;). Consider that, because of the needs of the
network, the PCE needs to create more dynamic associations and would like
to change the Association Range to &lt;0xbffe, 0xffff&gt; instead. During
PCEP session establishment, the PCE would advertise the new range. The PCC
could skip advertising, as the default values are used. If a PCC is
creating a dynamic association (with the PCC as the Association Source),
it needs to pick a free Association ID for type T1 in the range
&lt;0x1, 0x0fff&gt;, whereas if a PCE is creating a dynamic association
(with the PCE as the Association Source), it needs to pick a free
Association ID from the range &lt;0x1, 0xbffd&gt;. Similarly, if
an Operator-configured Association is manually configured with the PCC as
the Association Source, it should be from the range &lt;0x1000,
0xffff&gt;, whereas if the PCE is the Association Source, it should be
from the range &lt;0xbffe, 0xffff&gt;. If the Association Source is
not a PCEP peer (for example, an NMS), then the default range of
&lt;0x1000, 0xffff&gt; is considered.</t>
</section>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>We would like to thank <contact fullname="Yuji Kamite"/> and <contact
fullname="Joshua George"/> for
their contributions to this document. Thanks also to <contact fullname="Ven
ugopal Reddy"/>,
<contact fullname="Cyril Margaria"/>, <contact fullname="Rakesh
Gandhi"/>, <contact fullname="Mike Koldychev"/>, and <contact fullname="Adr
ian Farrel"/> for their useful comments.</t>
<t>We would like to thank <contact fullname="Julien Meuric"/> for shepherd
ing this
document and providing comments with text suggestions.</t>
<t>Thanks to <contact fullname="Stig Venaas"/> for the RTGDIR review comme
nts.</t>
<t>Thanks to <contact fullname="Alvaro Retana"/>, <contact
fullname="Mirja Kühlewind"/>, <contact fullname="Martin Vigoureux"/>,
<contact fullname="Barry Leiba"/>, <contact fullname="Eric Vyncke"/>,
<contact fullname="Suresh Krishnan"/>, and <contact fullname="Benjamin Kad
uk"/> for the IESG comments.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<references title="Informative References"> <contact fullname="Stephane Litkowski">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657 <organization>Orange</organization>
.xml"?> <address>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4872 <postal>
.xml"?> </postal>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4873 <email>stephane.litkowski@orange.com</email>
.xml"?> </address>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6007 </contact>
.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7551
.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8253 <contact fullname="Xian Zhang">
.xml"?> <organization>Huawei Technologies</organization>
<address>
<postal>
<extaddr>F3-1-B RnD Center, Huawei Base</extaddr>
<street>Bantian, Longgang District</street>
<region>Shenzhen</region>
<code>518129</code>
<country>China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</contact>
<?rfc include="reference.I-D.ietf-pce-pcep-yang.xml"?> <contact fullname="Mustapha Aissaoui">
<?rfc include="reference.I-D.ietf-pce-stateful-path-protection.xml"?> <organization>Nokia</organization>
<?rfc include="reference.I-D.ietf-pce-association-diversity.xml"?> <address>
</references> <postal>
<section title="Example for Operator-configured Association Range" anchor="ex </postal>
"> <email>mustapha.aissaoui@nokia.com</email>
<t>Consider an association type T1 (which allows both dynamic and operator-c </address>
onfigured association with a default range of &lt;0x1000, 0xffff&gt;). Consider </contact>
that, because of need of the network, the PCE needs to create more dynamic assoc </section>
iations and would like to change the association range to &lt;0xbffe, 0xffff&gt;
instead. During PCEP session establishment the PCE would advertise the new rang
e, the PCC could skip advertising as the default values are used. If a PCC is cr
eating a dynamic association (with PCC as association source) it needs to pick a
free association identifier for type T1 in the range of &lt;0x1, 0x0fff&gt; whe
reas if a PCE is creating a dynamic association (with PCE as association source)
it needs to pick a free association identifier from the range &lt;0x1, 0xbffd&g
t;. Similarly if an operator-configured association is manually configured with
the PCC as association source, it should be from the range &lt;0x1000, 0xffff&gt
; whereas if the PCE is association source, it should be from &lt;0xbffe, 0xffff
&gt;. In case the association source is not a PCEP peer (for example an NMS syst
em), then the default range of &lt;0x1000, 0xffff&gt; is considered.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 93 change blocks. 
1353 lines changed or deleted 1402 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/