<?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="std" docName="draft-dhody-pce-association-attr-06" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="ASSOC-ATTR">Path Computation Element communication
    Protocol extension for relationship between LSPs and Attributes</title>
    <author initials="D" surname="Dhody" fullname="Dhruv Dhody">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Divyashree Techno Park, Whitefield</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560066</code>
          <country>India</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>sunseawq@huawei.com</email>
      </address>
    </author>
    <date year="2017" />
    <area>Routing</area>
    <workgroup>PCE Working Group</workgroup>
    <abstract>
   <t>
   The Path Computation Element (PCE) provides functions of path
   computation in support of traffic engineering in networks controlled
   by Multi-Protocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS).
   </t>
   <t>
   This document defines a mechanism to create associations between a
   set of LSPs and a set of attributes (such as configuration
   parameters).
   </t>
   </abstract>
  </front>
  <middle>
   <section title="Introduction" toc="default">
   <t><xref target="RFC5440"/> describes the Path Computation Element
   communication Protocol (PCEP) which enables the communication between
   a Path Computation Client (PCC) and a Path Control Element (PCE),
   or between two PCEs based on the PCE architecture
   <xref target="RFC4655"/>.</t>

   <t><xref target='I-D.ietf-pce-association-group'/> introduces a generic
   mechanism to create a grouping of LSPs which can then be used to
   define associations between a set of LSPs and a set of attributes (such
   as configuration parameters) and is equally applicable
   to the active and passive modes of a stateful PCE and a stateless PCE.</t>

   <t>This document specifies a PCEP extension to associate one or
   more LSPs with a set of attributes.</t>
   
   <t>PCEP Extensions 
   for Stateful PCE Model <xref target="I-D.ietf-pce-stateful-pce"/> 
   describes a set of extensions to PCEP to
   enable active control of MPLS-TE and GMPLS tunnels. 
   <xref target="I-D.ietf-pce-pce-initiated-lsp"/> describes the setup and teardown of
   PCE-initiated LSPs under the active stateful PCE model, without the
   need for local configuration on the PCC, thus allowing for a dynamic
   network. The mechanism described in this document is equally applicable to 
   these deployment models.   </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="AAG:">Attribute Association Group.</t>
          <t hangText="LSR:">Label Switch Router.</t>
          <t hangText="MPLS:">Multi-protocol Label Switching.</t>
          <t hangText="PAG:">Policy Association Group.</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="PCEP:">Path Computation Element Communication Protocol.</t>
        </list>
      </t>
    </section>
    <section title="Motivation" toc="default">
    <t>This section discusses in more detail the motivation and use cases
    for such an association including but not limited to - </t>
    <section title="Opaque Identifier" toc="default">
    <t>An opaque identifier may represent attributes such as
    configured parameters or constraints that a PCEP speaker may
    invoke on a peer.  Thus a PCEP speaker may only need an opaque identifier
     to invoke these attributes (parameters or constraints) rather than
     encoding them explicitly in each PCEP message.</t>
     <t>This can also be used for tagging bunch of LSP to a particular customer
     or for creation of virtual network like in case of Abstraction and 
     Control of TE Networks (ACTN) <xref target="I-D.ietf-teas-actn-requirements"/>. 
     (See <xref target="I-D.leedhody-pce-vn-association"/>)</t>
    </section>
    
    <section title="Bundled requests" toc="default">
    <t>In some scenarios(e.g.,the topology example described in
    Section 4.6 of <xref target="RFC6805"/>), there is a need to send
    multiple requests with the same constraints and attributes to the
    PCE.  Currently these requests are either sent in a separate path
    computation request (PCReq) messages or bundled together in one
    (or more) PCReq messages.  In either case, the constraints and
    attributes need to be encoded separately for each request even
    though they are exactly identical.</t>
    <t>If a association is used to identify these constraints and
    attributes shared by multiple requests and grouped together via
    association mechanism, thus simplifying the path
    computation message exchanges.</t>
    </section>
    </section>
    <section title="Overview" toc="default">
     <t>As per <xref target='I-D.ietf-pce-association-group'/>, LSPs
     are associated with other LSPs with which they interact by adding
     them to a common association group. This grouping can then be used
     to define associations between sets of LSPs or between a set of
     LSPs and a set of attributes (such as configuration parameters).

      A new optional Association Object-type is defined 
      based on the generic Association object - 
      <list style="symbols">
      <t>Attribute Association Group (AAG) </t> 
      </list>
      </t>
      
      <t>Thus this document defines a new association type called 
      "Attribute Association Type" of value TBD1.  An AAG can have one or more LSPs and its
     associated attributes. 
     The scope and handling of AAG identifier
     is similar to the generic association identifier defined in
     <xref target='I-D.ietf-pce-association-group'/>.</t>

     <t>One or more LSP are grouped via a single group identifier as
     defined in  <xref target='I-D.ietf-pce-association-group'/>. The
     attributes that may be associated with this set of LSPs may either are -</t>
     <t>
     <list style="symbols">
     <t>known to the PCEP peers via some external means like
     configuration, policy enforcement etc (can be considered as
     'out-of-band'). PCEP speaker simply use the AAG identifier in the
     PCEP message and the peer is supposed to be aware of the associated
     attributes. This is suitable for stateless PCE where the PCEP peers
     should be aware of the association and its significance
     outside of the protocol.</t>
     <t>or communicated to the PCEP peer via PCEP itself on first
     use (can be considered as 'in-band'). PCEP speaker creates a new
     AAG by using a new identifier and the associated attributes are
     communicated via TLVs in association object. This is applicable for
     stateful PCE only.</t>
     </list>
     </t>
     <t>Error handling would be taken up in future revision.</t>
    </section>
    <section title="Attribute Association Group" toc="default">
    <t>The format of the generic Association object used for AAG is shown in
    <xref target='FIG1'/>:</t>
        <figure align="left" alt="" height="" suppress-title="false"
                title="The AAG Object formats" width="" anchor="FIG1">
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve">
  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 (TBD1)  |      Association ID           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              IPv4 Association Source                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //                   Optional TLVs                             //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  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 (TBD1)  |      Association ID           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                    IPv6 Association Source                    |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //                   Optional TLVs                             //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     

</artwork>
</figure>

   <t>Type = TBD1 for the Attribute Association Type.</t>
   <t>AAG may carry optional TLVs including but not limited to -</t>
      <t>
     <list style="symbols">
     <t>ATTRIBUTE-OBJECT-TLV: Used to communicate associated attributes
     in form of PCEP objects, described in this document.</t>
     <t>VENDOR-INFORMATION-TLV: Used to communicate arbitrary behavioral
     information, described in <xref target="RFC7470"/>.</t>
     </list>
     </t>

     <section title="ATTRIBUTE-OBJECT-TLV" toc="default">
     <t>The ATTRIBUTE-OBJECT-TLV(s) maybe included in AAG object to
     associate attributes encoded in PCEP objects.</t>
     <t>The format of the ATTRIBUTE-OBJECT-TLV is shown in the
   following figure:</t>
        <figure align="left" alt="" height="" suppress-title="false"
                title="ATTRIBUTE-OBJECT-TLV format" width="" anchor="FIG2">
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve">
 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 (TBD2)         |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Flags                         |M|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class  |   OT  |Res|P|I|   Object Length (bytes)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        (Object body)                        //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    </artwork>
</figure>
<t>The type of the TLV is TBD2 and it has a variable length. The value
part consist of a 32-bit Flag filed followed by a PCEP object (including common header <xref target="RFC5440"/>
identifying the object) that is
associated with this AAG.</t>
<t>Following Flags are defined:
  <list>
    <t>R (Remove - 1 bit): This is set to indicate that the attribute
      is being removed from the attribute-list.</t>
    <t>M (Modify - 1 bit): This is set to indicate that a previous
      attribute is being modified, and the peer should overwrite the
      attribute with the new value as per the object-body.</t>  
  </list>
</t> 
<t>This TLV identifies the attributes associated
with this group. For each attribute a separate TLV is used.
Future PCEP message exchanges may only carry the AAG with no ATTRIBUTE-OBJECT-TLV. </t>



     </section>
     
</section>




    <section title="Security Considerations" toc="default">
      <t>This document defines a new types for association and a
      new ATTRIBUTE-OBJECT-TLV which do not add any new
      security concerns beyond those discussed in <xref target="RFC5440"/>,
      <xref target='I-D.ietf-pce-stateful-pce'/> and <xref target='I-D.ietf-pce-association-group'/> in itself.</t>
      <t> Some deployments may find the associations and their implications
        as extra sensitive
      and thus should employ suitable PCEP security mechanisms like TCP-AO
      or <xref target='I-D.ietf-pce-pceps'/>.</t>
    </section>

    <section title="IANA Considerations" toc="default">
    <section title="Association object Type Indicators" toc="default">
    <t>This document defines the following new association type originally
    defined in <xref target='I-D.ietf-pce-association-group'/>.</t>
<t>
 <figure title="" suppress-title="false" align="left" alt="" width="" height="">
   <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Value     Name                        Reference
TBD1      Attribute Association Type  [This I.D.]

]]></artwork>
        </figure>
      </t>
    </section>
    <section title="PCEP TLV Type Indicators" toc="default">
    <t>This document defines the following new PCEP TLV; IANA is
    requested to make the following allocations from this registry.
    http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators</t>
      <t>
 <figure title="" suppress-title="false" align="left" alt="" width="" height="">
   <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Value     Name                        Reference
TBD2      ATTRIBUTE-OBJECT-TLV        [This I.D.]
]]></artwork>
        </figure>
      </t>
    </section>
    <section title="Flag field in ATTRIBUTE-OBJECT-TLV" toc="default">
      <t>This document requests that a new sub-registry, named "ATTRIBUTE-OBJECT-TLV
   Flag Field", is created within the "Path Computation Element Protocol
   (PCEP) Numbers" registry to manage the Flag field of the ATTRIBUTE-OBJECT-TLV.
   New values are to be assigned by Standards Action <xref target="RFC5226"/>.
   Each bit should be tracked 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>
   <t>
   The following values are defined in this document:</t>
 <figure title="" suppress-title="false" align="left" alt="" width="" height="">
   <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit     Description           Reference
 31     Remove                [This I.D.]
 30     Modify                [This I.D.]
]]></artwork>
        </figure>   
    </section>
    </section>
<section title="Manageability Considerations" toc="default">
      <section title="Control of Function and Policy" toc="default">
        <t>
   An operator MUST BE allowed to configure the attribute associations at PCEP peers
   and associate it with the LSPs. </t>
      </section>
      <section title="Information and Data Models" toc="default">
        <t><xref target="RFC7420"/> describes the PCEP MIB, there are no new MIB Objects
        for this document.</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 new requirements
        on other protocols.</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>A special thanks to author of
      <xref target='I-D.ietf-pce-association-group'/>, this document borrow
      some of the text from it.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml" ?>
    
    <?rfc include="reference.RFC.5440.xml" ?>
    <?rfc include="reference.RFC.7470.xml" ?>
    <?rfc include="reference.I-D.ietf-pce-association-group"?>
    <?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
    </references>
    <references title="Informative References">
     <?rfc include="reference.RFC.4655.xml" ?>
     <?rfc include="reference.RFC.5226.xml" ?>
     <?rfc include="reference.RFC.6805.xml" ?>
     
     <?rfc include="reference.RFC.7420.xml" ?>
     <?rfc include="reference.I-D.ietf-pce-pceps"?>
     <?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
     <?rfc include="reference.I-D.ietf-teas-actn-requirements"?>
     <?rfc include="reference.I-D.ietf-pce-association-policy"?>
     <?rfc include="reference.I-D.leedhody-pce-vn-association"?>


    </references>
<section title="Policy" toc="default">
<t>An earlier version of this document also had details about
Policy association group. This has been moved to an independent
document - <xref target="I-D.ietf-pce-association-policy"/>. </t>
</section>    
<section title="Contributor Addresses" toc="default">
    <t>
    <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen  518129
P.R.China

EMail: zhang.xian@huawei.com

Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India

EMail: udayasree.palle@huawei.com

        ]]></artwork>
        </figure>
      </t>
    </section>

  </back>
</rfc>
