One document matched: draft-dhody-pce-pcep-ds-04.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="exp" docName="draft-dhody-pce-pcep-ds-04" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="DS">Encoding of Data Structure (DS) in the Path Computation Element Communication Protocol (PCEP)</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies India Pvt Ltd</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.dhody@huawei.com</email>
</address>
</author>
<author initials="U" surname="Palle" fullname="Udayasree Palle">
<organization>Huawei Technologies India Pvt Ltd</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>udayasree.palle@huawei.com</email>
</address>
</author>
<date month="August" year="2013" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for point-to-point (P2P) and point-to-multipoint (P2MP) scenarios. Backward-Recursive Path Computation (BRPC) <xref target="RFC5441"/> defines Virtual Shortest Path Tree (VSPT) as a default de-facto data structure for path reply message in inter-domain scenarios. </t>
<t>As Path Computation Element (PCE) will get used in newer scenarios like inter-domain, protection, P2MP etc. As well as PCE is being explored to be used in Cross Stratrum Optimization (CSO) environment (see <xref target="CSO-PCE"/>) as well as in <xref target="ABNO"/>. Limiting PCE communication Protocol (PCEP) to just one data structure limits the usage of PCEP. Its important to keep PCEP generic enough to use differnt data structure and apply different algorithms. </t>
<t>This document defines extensions to the PCEP to allow multiple data structures. Extensions are defined for PCE to indicate the set of Data Structure (DS) it supports; also Path Computation Client (PCC) or PCE can indicate in a path computation request the required DS, and a PCE can report in a path computation reply the Data Structure that was used in the path reply message.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The PCE architecture is defined in <xref target="RFC4655"/>. <xref target="RFC5441"/> describe a PCE-based path computation procedure to compute optimal inter-domain constrained (G)MPLS TE LSPs. It also defines Virtual Shortest Path Tree (VSPT) which is the only data structure and is used in all inter-domain scenarios. </t>
<t>This document describes the need for multiple data structure (DS). It may be useful for a PCC/PCE to discover the set of Data Structure (DS) supported by a PCE. Furthermore, PCC/PCE requires the ability to indicate in a path computation request a required/desired Data Structure, as well as optional function parameters. </t>
<t>For these purposes, this document extends the PCE communication Protocol (PCEP). It defines PCEP extensions that allow a PCE to advertise a list of supported Data Structure (DS), as well as extensions to carry Data Structure (DS) in PCEP request and reply messages. It complements the PCEP base specification <xref target="RFC5440"/>.</t>
<t>Note that OSPF and IS-IS-based PCE discovery mechanisms are defined in <xref target="RFC5088"/> and <xref target="RFC5089"/>. These mechanisms are dedicated to the discovery of a few generic parameters, while more detailed PCE parameters should be discovered using the PCE communication Protocol.</t>
<t>Data Structure (DS) are in this second category; thus, the Data Structure discovery procedure is handled by PCEP.</t>
<t>A new PCEP TLV, named the DS-List TLV, is defined in Section 4. The DS-List TLV is carried in the PCEP OPEN object and allows a PCE to list, during PCEP session-setup phase, the Data Structure (DS) that it supports.</t>
<t>A new PCEP object, the DS object, is defined in Section 5. The DS object is carried within a PCReq (Path Computation Request) message to indicate the required/desired data structure to be applied by a PCE, or in a PCRep (Path Computation Reply) message to indicate the data structure that was used for path computation and the reply message. </t>
<section title="Requirements Language" toc="default">
<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"/>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t>
<list style="hanging">
<t hangText="BRPC:">Backward Recursive Path Computation.</t>
<t hangText="DS:">Data Structure.</t>
<t hangText="H-PCE:">Hierarchical PCE.</t>
<t hangText="IGP:">Interior Gateway Protocol. Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).</t>
<t hangText="IS-IS:">Intermediate System to Intermediate System.</t>
<t hangText="OF:">Objective Function.</t>
<t hangText="OSPF:">Open Shortest Path First.</t>
<t hangText="PCC:">Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element.</t>
<t hangText="PCE:">Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.</t>
<t hangText="P2MP:">Point-to-Multipoint</t>
<t hangText="P2P:">Point-to-Point</t>
<t hangText="TE LSP:">Traffic Engineering Label Switched Path.</t>
<t hangText="TLV:">Type-Length-Variable data encoding.</t>
<t hangText="VSPT:">Virtual Shortest Path Tree as defined in <xref target="RFC5441"/>.</t>
</list>
</t>
</section>
<section title="Need for multiple Data Structure" toc="default">
<section title="Point to Multipoint (P2MP)" toc="default">
<t><xref target="PCE-P2MP-PROCEDURES"/> describes the need for an extended VSPT for computation of the best core-tree. In case of Core tree based path computation, the PCE in a downstream domain does the pruning and returns the single optimal sub-path to its previous PCE, BRPC insures that the ingress PCE will get all the best optimal sub-paths for each LN (Leaf Border Nodes), but the combination of these single optimal sub-paths into a P2MP tree is not necessarily optimal even if each S2L (Source-to-Leaf) sub-path is optimal. Without trimming, the ingress PCE will get all the possible S2L sub-paths set for LN, and eventually by looking through all the combinations, and taking one sub-path from each set to built one P2MP tree it finds the optimal tree. </t>
</section>
<section title="Synchronized Dependent Path Computations" toc="default">
<t><xref target="RFC6007"/> describes the need for disjoint VSPT in case of Synchronized Dependent Path Computations.</t>
<t>The BRPC procedure constructs a VSPT to inform the enquiring PCE of potential paths to the destination node.</t>
<t>In the end-to-end diverse path computation, diversity (or disjointness) information among the potential paths must be preserved in the VSPT to ensure an end-to-end disjoint path. In order to preserve diversity (or disjointness) information, disjoint VSPTs are sent in the PCEP PCRep message. The PCReq containing a SVEC object with the appropriate diverse flag set would signal that the PCE should compute a disjoint VSPT.</t>
<t>A definition of the disjoint VSPT is a collection of VSPTs, in which each VSPT contains a potential set of primary and secondary paths.</t>
</section>
<section title="Hierarchical PCE" toc="default">
<t>In Hierarchical PCE model (<xref target="RFC6805"/>), Parent PCE MAY be used to return the domain-sequence which may be further applied by the ingress PCE to do the BRPC path computation; or Parent PCE MAY do the full end to end path computation.</t>
<t>In full end to end path computation model, Parent PCE MAY ask the child PCE to do the intra domain path computation between - </t>
<t>
<list style="symbols">
<t>Ingress Domain: Ingress to Exit Boundary Nodes</t>
<t>Transit Domain(s): Entry Boundary Nodes to Exit Boundary Nodes</t>
<t>Egress Domain: Entry Boundary Nodes to Egress</t>
</list>
</t>
<t>Here the results are a list of best paths between the nodes listed above, is is not a VSPT, which clearly defines it self as a P2MP Tree from entry boundary nodes to egress. </t>
<t>There exist clear instances like this where VSPT is not the only data structure in use.</t>
</section>
<section title="Others" toc="default">
<t>VSPT does not work well with boundary constraints like HOP-LIMIT in inter-domain scenarios. Since there maybe a not-the-best-path in a domain which would have satisfied the end to end contraint, but was prunded.</t>
<t>Since PCEP allow multiple Objective Function (OF) <xref target="RFC5541"/>; it is natural to extend PCEP to support multiple Data Structure based on path computation scenarios.</t>
</section>
<section title="PCE in future" toc="default">
<t><xref target="CSO-PCE"/> describes the use of PCE in Cross Stratrum Optimization (CSO) environment. A request can be made to the PCE with different sets of computation mode that are not currently supported by PCE. For instance, NCG may request PCE a multi-destination and multi-source path computation request. This scenario arises when there are many possible Data Center choices for a given application request and there could be multiple sources for this request. Multi-destination with a single source (aka., anycast) is a default case for multi-destination and multi-source path computation.</t>
<t>In addition, with this architecture, NCG may have different sets of objectives and constraints than typical path computation requests. For instance, multi-criteria objective functions that combine the bandwidth requirement and latency may be very useful for some applications. </t>
<t><xref target="ABNO"/> describes Application-Based Network Operations using PCE.</t>
<t>Its important to keep PCEP generic to support new requirements in the future.</t>
</section>
<section title="Others Techniques" toc="default">
<t>This is being achieved in some extent by an RP object bit. </t>
<t>For example, if P2MP bit is set and Objective function (OF) is Minimum Cost Tree (MCT), the extended VSPT should be used. We beleive this not a sustainable mechanism.</t>
<t>Making PCEP generic allowing use of multiple DS will make PCEP protocol behave in a better way.</t>
</section>
</section>
<section title="Discovery of PCE Data Structure" toc="default">
<t>This section defines PCEP extensions (see <xref target="RFC5440"/>) so as to support the advertisement of the Data Structure (DS) supported by a PCE. </t>
<t>A new PCEP DS-List (Data Structure list) TLV is defined. The PCEP DS-List TLV is carried within an OPEN object. This way, during PCEP session-setup phase, a PCE can advertise to a PCEP peer the list of data structure it supports.</t>
<section title="DS-List TLV" toc="default">
<t>The PCEP DS-List TLV is optional. It MAY be carried within an OPEN object sent by a PCE in an Open message to a PCEP peer so as to indicate the list of supported data structures.</t>
<t>The DS-List TLV format is compliant with the PCEP TLV format defined in <xref target="RFC5440"/>. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a Value field. The Length 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 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>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
The PCEP DS-List TLV has the following format:
TYPE: 4
LENGTH: N * 2 (where N is the number of Data Structures)
VALUE: list of 2-byte data structure code points, identifying
the data structures supported by the sender of the Open
message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Code #1 | DS Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DS Code (2 bytes): Data Structure code point identifier. IANA
manages the "PCE Data Structure" code point registry
(see Section 6).]]></artwork>
</figure>
</t>
</section>
<section title="Elements of Procedure" toc="default">
<t>A PCE MAY include a DS-List TLV within an OPEN object in an Open message sent to a PCEP peer in order to advertise a set of one or more supported Data Structures. The DS-List TLV MUST NOT appear more than 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 establishment failure / Reception of an invalid Open message). The absence of the DS-List TLV in an OPEN object MUST be interpreted as an absence of information on the list of supported data structures by the PCE, default data stricture VSPT is always supported. </t>
<t>As specified in <xref target="RFC5440"/>, a PCEP peer that does not recognize the DS-List TLV will silently ignore it.</t>
</section>
</section>
<section title="Data Structure in PCEP Path Computation Request and Reply Messages" toc="default">
<t>This section defines PCEP extensions <xref target="RFC5440"/> so as to support the communication of Data Structure (DS) in PCEP path computation request and reply messages. A new PCEP DS (Data Structure) object is defined, to be carried within a PCReq message in order for the PCC/PCE to indicate the required/desired data structure. </t>
<t>The PCEP DS object may also be carried within a PCRep message in order for the PCE to indicate the data structure that was used by the PCE and used in the reply message.</t>
<t>A new flag is defined in the RP (Request Parameters) object. The flag is used in a PCReq message to indicate that the PCE MUST include a DS object in the PCRep message to indicate the data structure that was used during path computation and encoded in the reply message.</t>
<t>Also, new PCEP error types and values are defined.</t>
<section title="DS Object" toc="default">
<t>The PCEP DS (Data Structure) object is optional. It MAY be carried within a PCReq message so as to indicate the desired/required data structure to be applied by the PCE during path computation or within a PCRep message so as to indicate the data structure that was used by the PCE during path computation and in the reply message.</t>
<t>The DS object format is compliant with the PCEP object format defined in <xref target="RFC5440"/>.</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
The DS Object-Class is <TBA by IANA>.
The DS Object-Type is 1.
The format of the DS object body is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DS Code (2 bytes): The identifier of the Data Structure. IANA
manages the "PCE Data Structure" code point registry
Reserved (2 bytes): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Optional TLVs may be defined in the future.]]></artwork>
</figure>
</t>
<section title="Elements of Procedure" toc="default">
<t>To request the use of a specific data structure by the PCE, a PCC/PCE includes a DS object in the PCReq message.</t>
<t><xref target="RFC5440"/> specifies a bit flag, referred to as the P bit, carried in the common PCEP object header. The P bit is set by a PCC/PCE to mandate that a PCE must take the information carried in the object into account during the path computation.</t>
<t>If the P bit is set in the DS object, the data structure is mandatory (required data structure) and the PCE MUST use the data structure during path computation. If the P bit is clear in the DS object, the data structure is optional (desired data structure) and the PCE SHOULD apply the data structure if it is supported but MAY choose to apply a different data structure, according to local capabilities and policies.</t>
<t>On receipt of a PCReq message with a DS object, a PCE MUST proceed as follows:</t>
<t>
<list style="symbols">
<t>If the DS object is unknown/unsupported, the PCE MUST follow procedures defined in <xref target="RFC5440"/>. That is, if the P bit is set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request MUST be discarded. If the P bit is cleared, the PCE is free to ignore the object.</t>
<t>If the data structure is unknown/unsupported and the P bit is set, the PCE MUST send a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 4 (Unrecognized/Unsupported parameter), and the related path computation request MUST be discarded.</t>
<t>If the data structure is unknown/unsupported and the P bit is cleared, the PCE SHOULD apply another (default) data structure.</t>
<t> If the data structure is supported but policy does not permit applying it and if the P bit is set, the PCE MUST send a PCErr message with the PCEP error type "policy-violation" (type 5) and a new error value, "data structure not allowed", which is defined in this document.</t>
<t>If the data structure is supported but policy does not allow applying it and if the P bit is cleared, the PCE SHOULD apply another (default) data structure. </t>
<t>If the data structure is supported and policy allows applying it and if the P bit is set, the PCE MUST apply the requested data structure. Otherwise, if the P bit is cleared, the PCE is free to apply any other data structure.</t>
</list>
</t>
<t>The default data structure is VSPT or may be locally configured.</t>
</section>
</section>
<section title="Carrying The DS Object In a PCEP Message" toc="default">
<t>The DS object MAY be carried within a PCReq message. If a data structure is to be applied to a set of synchronized path computation requests, the DS object MUST be carried just after the corresponding SVEC (Synchronization VECtor) object and MUST NOT be repeated for each elementary request.</t>
<t>A DS object specifying a data structure that applies to an individual path computation request (non-synchronized case) MUST follow the RP object for which it applies.</t>
<t>The format of the PCReq message is updated as follows. </t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<DS>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<DS>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
<metric-list> ::= <METRIC>[<metric-list>] ]]></artwork>
</figure>
</t>
<t>The DS object MAY be carried within a PCRep message to indicate the data structure used by the PCE during path computation and in the reply message.</t>
<t>When the PCE wants to indicate to the PCC/PCE the data structure that was used for the synchronized computation of a set of paths, the PCRep message MUST include the corresponding SVEC object directly followed by the DS object, which MUST NOT be repeated for each elementary request. </t>
<t>A DS object specifying a data structure used for an individual path computation (non-synchronized case) MUST follow the RP object for which it applies.</t>
<t>The format of the PCRep message is updated as follows. </t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<DS>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
and where:
<attribute-list> ::= [<OF>]
[<DS>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC> [<metric-list>]]]></artwork>
</figure>
</t>
<t>Note: The DS object MAY be associated to a negative reply, i.e., a reply with a NO-PATH object.</t>
</section>
<section title="New RP Object Flag" toc="default">
<t>In some cases, where no data structure is specified in the request or an optional data structure is desired (P flag cleared in the DS object common header) but the PCE does not follow the request, the PCC/PCE may desire to know the data structure that was used by the PCE during path computation. To that end, a new flag is defined in the RP object, named the DS flag, allowing a PCC/PCE to request for the inclusion in the path computation reply of the data structure that was used by the PCE during path computation.</t>
<t>The following new bit flag of the RP object is defined:
The Supply DS on response flag (bit number <TBA>). When set in a PCReq message, this indicates that the PCE MUST provide the applied data structure in the PCRep message. When set in a PCRep message, this indicates that the data structure that was used during path computation is included.
</t>
<section title="Elements of Procedure" toc="default">
<t>If the PCC/PCE wants to know the data structure used by the PCE during path computation for a given request, it sets the DS flag in the RP object.</t>
<t>On receipt of a PCReq message with the DS flag in the RP object set, the PCE proceeds as follows:</t>
<t>
<list style="symbols">
<t>If policy permits, it MUST include in the PCRep message a DS object indicating the data structure it used during path computation.</t>
<t>If policy does not permit, it MUST send a PCErr message with the PCEP error code "policy-violation" (type 5) and a new error value, "data structure indication not allowed", which is defined in this document.</t>
</list>
</t>
<t>Note that a legacy PCE might not recognize the DS flag in the RP object. According to the definition of the Flags field for the RP object (Section 7.4.1 of <xref target="RFC5440"/>), the legacy PCE will ignore the unknown flag, resulting in it sending a PCRep that does not contain a DS object. In this case, the PCC/PCE’s behavior is an implementation choice. It might:</t>
<t>
<list style="symbols">
<t>Discard the PCRep because it really wanted the DS object returned.</t>
<t>Accept the PCRep without the knowledge of the DS that was applied.</t>
</list>
</t>
<t>Note also that these procedures can give rise to the situation where a PCC/PCE receives a PCRep that contains a DS object with a data structure identifier that the PCC/PCE does not recognize. In this situation, the PCC/PCE behavior is dependent on implementation and configuration. The PCC/PCE could choose any of the following (or some other action):</t>
<t>
<list style="symbols">
<t>Ignore the DS object and use the computed path.</t>
<t>Add the data structure to its view of the PCE’s repertoire for inclusion in future computation requests.</t>
<t>Discard the PCRep (i.e., the computed path) and send a PCReq to another PCE.</t>
<t>Discard the PCRep (i.e., the computed path) and send another PCReq to the same PCE explicitly requiring the use of some other data structure (i.e., by setting the P bit in the DS object).</t>
</list>
</t>
</section>
</section>
</section>
<section title="IANA Considerations" toc="default">
<section title="PCE Data Structure Sub-Registry" toc="default">
<t>This document defines a 16-bit PCE data structure identifier to be carried within the PCEP DS object, and also defines the PCEP DS-List TLV. IANA should create and manages the 16-bit "PCE Data Structure" code point registry. Values are TBD.</t>
</section>
<section title="PCEP Code Points" toc="default">
<section title="DS Object" toc="default">
<t>IANA manages the PCEP Objects code point registry (see <xref target="RFC5440"/>). This is maintained as the "PCEP Objects" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. This document defines a new PCEP object, the DS object, to be carried in PCReq and PCRep messages. </t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ IANA should make the following allocation:
Object Name Object Name Reference
Class Type
------------------------------------------------------------
TBA DS 1 Data Structure This ID]]></artwork>
</figure>
</t>
</section>
<section title="DS-List TLV" toc="default">
<t>IANA manages the PCEP TLV code point registry (see <xref target="RFC5440"/>). This is maintained as the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. This document defines a new PCEP TLV, the DS-List TLV, to be carried in the OPEN object. </t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ IANA should make the following allocation:
Type TLV name References
-----------------------------------------------
TBA DS-List This ID
]]></artwork>
</figure>
</t>
</section>
<section title="PCEP Error Values" toc="default">
<t>IANA maintains a registry of Error-types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ Two new Error-values are defined for the Error-type "policy
violation" (type 5):
Error-type Meaning and error values Reference
------------------------------------------------------
5 Policy violation
Error-value=TBA: data This ID
structure not
allowed (request rejected)
Error-value=TBA: DS bit This ID
of the RP object set
(request rejected) ]]></artwork>
</figure>
</t>
</section>
<section title="RP Object Flag" toc="default">
<t>A new flag of the RP object (specified in <xref target="RFC5440"/>) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ IANA should make the following allocation:
Bit Description Reference
----------------------------------------------
TBA Supply DS on response This ID]]></artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>PCEP security mechanisms are described in <xref target="RFC5440"/> and are used to secure entire PCEP messages. Nothing in this document changes the message flows or introduces any new messages, so the security mechanisms set out in <xref target="RFC5440"/> continue to be applicable.</t>
<t>This document introduces a single new object that may optionally be carried on PCEP messages and will be automatically secured using the mechanisms described in <xref target="RFC5440"/>.</t>
<t>If a PCEP message is vulnerable to attack (for example, because the security mechanisms are not used), then the DS object could be used as part of an attack; however, it is likely that other objects will provide far more significant ways of attacking a PCE or PCC in this case.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>It MUST be possible to configure the activation/deactivation of data structure discovery in PCEP. In addition to the parameters already listed in Section 8.1 of <xref target="RFC5440"/>, a PCEP implementation SHOULD allow configuring a list of authorized data structure on a PCE. This may apply to any session the PCEP speaker participates in, to a specific session with a given PCEP peer, or to a specific group of sessions with a specific group of PCEP peers. Note that it is not mandatory for an implementation to support all data structure defined. It MUST be possible to configure a default data structure used for path computation when a path request is received that requests to use an optional data structure.</t>
</section>
<section title="Information and Data Models" toc="default">
<t>The PCEP MIB Module defined in [PCEP-MIB] could be extended to include data structure.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in <xref target="RFC5440"/>.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in <xref target="RFC5440"/>.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>Mechanisms defined in this document do not imply any requirements on other protocols in addition to those already listed in <xref target="RFC5440"/>.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in <xref target="RFC5440"/>.</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Pradeep Shastry, Suresh babu, Quintin Zhao and Chen Huaimo for their useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5088.xml" ?>
<?rfc include="reference.RFC.5089.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5441.xml" ?>
<?rfc include="reference.RFC.5541.xml" ?>
<?rfc include="reference.RFC.6007.xml" ?>
<?rfc include="reference.RFC.6805.xml" ?>
<!--PCE-P2MP-PROCEDURES-->
<reference anchor="PCE-P2MP-PROCEDURES">
<front>
<title>PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths (draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05)</title>
<author initials="Q" surname="Zhao" fullname="Zhao Q">
<organization />
</author>
<author initials="D" surname="Dhody" fullname="Dhody D">
<organization />
</author>
<author initials="Z" surname="Ali" fullname="Ali Z">
<organization />
</author>
<author initials="T" surname="Saad," fullname="Saad T">
<organization />
</author>
<author initials="S" surname="Sivabalan," fullname="Sivabalan S">
<organization />
</author>
<author initials="R" surname="Casellas" fullname="Casellas R">
<organization />
</author>
<date month="July" year="2013" />
</front>
</reference>
<!--CSO-PCE-->
<reference anchor="CSO-PCE">
<front>
<title>Cross Stratum Optimization enabled Path Computation. (draft-dhody-pce-cso-enabled-path-computation-02)</title>
<author initials="D" surname="Dhody" fullname="Dhody D">
<organization />
</author>
<author initials="Y" surname="Lee" fullname="Lee Y">
<organization />
</author>
<author initials="N" surname="Ciulli" fullname="Ciulli N">
<organization />
</author>
<author initials="L" surname="Contreras" fullname="Contreras L">
<organization />
</author>
<author initials="O" surname="Gonzalez de Dios" fullname="Gonzalez de Dios O">
<organization />
</author>
<date month="September" year="2012" />
</front>
</reference>
<!--ABNO-->
<reference anchor="ABNO">
<front>
<title>A PCE-based Architecture for Application-based Network Operations. (draft-farrkingel-pce-abno-architecture-05)</title>
<author initials="A" surname="Farrel" fullname="Farrel A">
<organization />
</author>
<author initials="D" surname="King" fullname="King D">
<organization />
</author>
<date month="July" year="2013" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:57:15 |