[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-minei-pce-association-group) 00 01 02 03 04 05 06 07 08

PCE Working Group                                               I. Minei
Internet-Draft                                              Google, Inc.
Intended status: Standards Track                               E. Crabbe
Expires: December 29, 2017                        Individual Contributor
                                                            S. Sivabalan
                                                     Cisco Systems, Inc.
                                                      H. Ananthakrishnan
                                                           Packet Design
                                                                D. Dhody
                                                                  Huawei
                                                               Y. Tanaka
                                          NTT Communications Corporation
                                                           June 27, 2017


  PCEP Extensions for Establishing Relationships Between Sets of LSPs
                  draft-ietf-pce-association-group-03

Abstract

   This document introduces a generic mechanism to create a grouping of
   LSPs in the context of a PCE.  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 or behaviors),
   and is equally applicable to stateful PCE (active and passive modes)
   and stateless PCE.

Requirements Language

   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 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Minei, et al.           Expires December 29, 2017               [Page 1]


Internet-Draft            PCE association group                June 2017


   This Internet-Draft will expire on December 29, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Operation Overview  . . . . . . . . . . . . . . . . . . .   4
     3.3.  Operator-configured Association Range . . . . . . . . . .   5
   4.  Operator-configured Association Range TLV . . . . . . . . . .   5
     4.1.  Procedure . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  ASSOCIATION Object  . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Object Definition . . . . . . . . . . . . . . . . . . . .   7
       5.1.1.  Global Association Source TLV . . . . . . . . . . . .   9
       5.1.2.  Extended Association ID TLV . . . . . . . . . . . . .   9
     5.2.  Object Encoding in PCEP messages  . . . . . . . . . . . .  10
       5.2.1.  Stateful PCEP messages  . . . . . . . . . . . . . . .  10
       5.2.2.  Request Message . . . . . . . . . . . . . . . . . . .  12
     5.3.  Processing Rules  . . . . . . . . . . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  PCEP Object . . . . . . . . . . . . . . . . . . . . . . .  14
     6.2.  PCEP TLV  . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.3.  Association Flags . . . . . . . . . . . . . . . . . . . .  15
     6.4.  Association Type  . . . . . . . . . . . . . . . . . . . .  15
     6.5.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  16
     8.1.  Control of Function and Policy  . . . . . . . . . . . . .  16
     8.2.  Information and Data Models . . . . . . . . . . . . . . .  17
     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  17
     8.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  17
     8.5.  Requirements On Other Protocols . . . . . . . . . . . . .  17



Minei, et al.           Expires December 29, 2017               [Page 2]


Internet-Draft            PCE association group                June 2017


     8.6.  Impact On Network Operations  . . . . . . . . . . . . . .  17
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     11.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   [RFC5440] describes the Path Computation Element Protocol PCEP.  PCEP
   enables the communication between a Path Computation Client (PCC) and
   a Path Control Element (PCE), or between PCE and PCE, for the purpose
   of computation of Multiprotocol Label Switching (MPLS) as well as
   Generalzied MPLS (GMPLS) for Traffic Engineering Label Switched Path
   (TE LSP) characteristics.

   Stateful pce [I-D.ietf-pce-stateful-pce]  specifies a set of
   extensions to PCEP to enable stateful control of TE LSPs between and
   across PCEP sessions in compliance with [RFC4657] and focuses on a
   model where LSPs are configured on the PCC and control over them is
   delegated to the PCE.  The model of operation where LSPs are
   initiated from the PCE is described in
   [I-D.ietf-pce-pce-initiated-lsp].

   This document introduces a generic mechanism to create a grouping of
   LSPs.  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 or behaviors), and is equally applicable
   to stateful PCE (active and passive modes) and stateless PCE.  The
   associations could be created dynamically and conveyed to a PCEP peer
   within PCEP, or it could be configured by an operator on the PCEP
   peers.  Refer Section 3.2 for more details.

2.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer.

   This document uses the following terms defined in [RFC8051]: Stateful
   PCE, Delegation.

   This document uses the following terms defined in
   [I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, LSP State
   Report, LSP Update Request.

   This document uses the following terms defined in
   [I-D.ietf-pce-pce-initiated-lsp]: PCE-initiated LSP, LSP Initiate.



Minei, et al.           Expires December 29, 2017               [Page 3]


Internet-Draft            PCE association group                June 2017


   The following term is defined in this document:

   Association Timeout Interval: when a PCEP session is terminated, a
   PCC waits for this time period before deleting associations created
   by the PCEP peer.

3.  Architectural Overview

3.1.  Motivation

   Stateful PCE provides the ability to update existing LSPs and to
   instantiate new ones.  To enable support for PCE-controlled make-
   before-break and for protection, there is a need to define
   associations between LSPs.  For example, the association between the
   original and the re-optimized path in the make-before break scenario,
   or between the working and protection path in end-to-end protection.
   Another use for LSP grouping is for applying a common set of
   configuration parameters or behaviors to a set of LSPs.

   For a stateless PCE, it might be useful to associate a path
   computation request to an association group, thus enabling it to
   associate a common set of policy, configuration parameters or
   behaviors with the request.

   Some associations could be created dynamically, such as association
   between the working and protections LSPs of a tunnel.  Whereas some
   association could be created by the operator manually, such as policy
   based association, where the LSP could join an operator-configured
   existing association.

   Rather than creating separate mechanisms for each use case, this
   draft defines a generic mechanism that can be reused as needed.

3.2.  Operation Overview

   LSPs are associated with other LSPs with which they interact by
   adding them to a common association group.  Association groups as
   defined in this document can be applied to LSPs originating at the
   same head end or different head ends.

   Some associations could be created dynamically by a PCEP speaker and
   the associations (along with the set of LSPs) are conveyed to a PCEP
   peer.  Whereas, some associations are configured by the operator on
   the PCEP peers involved before hand, a PCEP speaker then could ask
   for a LSP to join the operator-configured association.  Usage of
   dynamic and configured is usually dependent on the type of the
   association.




Minei, et al.           Expires December 29, 2017               [Page 4]


Internet-Draft            PCE association group                June 2017


   For the operator-configured association, the association identifier,
   type, as well as the association source IP address is manually
   configured by the operator.  In case of dynamic association, the
   association identifier is allocated dynamically by the PCEP speaker.

   The dynamically created association can be reported to the PCEP peer
   via the PCEP messages as per the stateful extensions.  While the
   operator-configured association are known to the PCEP peer before
   hand, a PCEP peer could ask for a LSP to join the operator-configured
   association via the stateful PCEP messages.

   The association are properties of the LSP and thus could be stored in
   the LSP state database.  The dynamic association exist as long as the
   LSP state.  In case of PCEP session termination, the LSP state clean
   up SHOULD also take care of associations.

   Multiple types of associations can exist, each with their own
   association identifier space.  The definition of the different
   association types and their behaviors 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 association
   type.

3.3.  Operator-configured Association Range

   Some association types are dynamic, some are operator-configured and
   some could be both.  For the association types that could be dynamic
   and operator-configured, it is necessary to configure a range of
   association identifiers that are marked for operator-configured
   associations to avoid any association identifier clash.

   A range of association identifier for each association-type are kept
   for the operator-configured associations.  Dynamic associations MUST
   NOT use the association identifier from this range.

   This range needs to be communicated to a PCEP peer in the Open
   Message.  A new TLV is defined in this specification for this purpose
   (Section 4).

4.  Operator-configured Association Range TLV

   This section defines PCEP extension to support the advertisement of
   the Operator-configured Association Range used for an association-
   type.

   A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association
   Range) TLV is defined.  The PCEP OP-CONF-ASSOC-RANGE TLV is carried



Minei, et al.           Expires December 29, 2017               [Page 5]


Internet-Draft            PCE association group                June 2017


   within an OPEN object.  This way, during PCEP session-setup phase, a
   PCEP speaker can advertise to a PCEP peer the Operator-configured
   Association Range for an association type.

   The PCEP OP-CONF-ASSOC-RANGE TLV is optional.  It MAY be carried
   within an OPEN object sent by a PCEP speaker in an Open message to a
   PCEP peer.  The OP-CONF-ASSOC-RANGE TLV format is compliant with the
   PCEP TLV format defined in [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 PCEP OP-CONF-ASSOC-RANGE TLV has the following format:

      TYPE:    TBD
      LENGTH:  N * 8 (where N is the number of association types)
      VALUE:

       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 #1        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Start-Assoc-ID #1        |           Range #1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                                                             //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Reserved          |          Assoc-type #N        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Start-Assoc-ID #N        |           Range #N            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



               Figure 1: The OP-CONF-ASSOC-RANGE TLV format

   The Value portion includes the following fields, repeated for each
   association type:

      Reserved (2 bytes): This field MUST be set to 0 on transmission
      and MUST be ignored on receipt.

      Assoc-type (2 bytes): The association type.

      Start-Assoc-ID (2 bytes): The start association identifier for the
      Operator-configured Association Range for the particular
      association type.




Minei, et al.           Expires December 29, 2017               [Page 6]


Internet-Draft            PCE association group                June 2017


      Range (2 bytes): The number of associations marked for the
      Operator-configured Associations.

4.1.  Procedure

   A PCEP speaker MAY 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 Association Range for an association type.
   The OP-CONF-ASSOC-RANGE 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).

   As specified in [RFC5440], a PCEP peer that does not recognize the
   OP-CONF-ASSOC-RANGE TLV will silently ignore it.

   The Operator-configured Association Range SHOULD be included for each
   association type that could be both dynamic and operator-configured.
   For associations that are only dynamic or only operator-configured
   can be skipped, in which case the full range of association
   identifier is considered dynamic or operator-configured respectively.
   Each association type (that are defined in separate documents) can
   specify the default value for the operator-configured association
   range for their respective association type.

   The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be
   interpreted as an absence of explicit Operator-configured Association
   Range at the PCEP peer.  In which case, the default behavior as per
   each association type would be applied.

5.  ASSOCIATION Object

5.1.  Object Definition

   Association groups and their memberships are defined using a new
   ASSOCIATION object.

   ASSOCIATION Object-Class is to be assigned by IANA (TBD).

   ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in
   Figure 2:










Minei, et al.           Expires December 29, 2017               [Page 7]


Internet-Draft            PCE association group                June 2017


       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           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              IPv4 Association Source                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                   Optional TLVs                             //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 2: The IPv4 ASSOCIATION Object format

   ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in
   Figure 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |            Flags            |R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Association type         |      Association ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    IPv6 Association Source                    |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                   Optional TLVs                             //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 3: The IPv6 ASSOCIATION Object format

   Reserved (2-byte): MUST be set to 0 and ignored upon receipt.

   Flags (2-byte): The following flags are currently defined:

   R (Removal - 1 bit):  when set, the requesting PCE peer requires the
      removal of an LSP from the association group.

   Association type (2-byte): the association type (for example
   protection).  The association type are defined in separate documents.





Minei, et al.           Expires December 29, 2017               [Page 8]


Internet-Draft            PCE association group                June 2017


   Association ID (2-byte): the identifier of the association group.
   When combined with Type and Association Source, this value uniquely
   identifies an association group.  The value 0xffff and 0x0 are
   reserved.  The value 0xffff is used to indicate all association
   groups.

   Association Source: 4 or 16 bytes - An IPv4 or IPv6 address.  This
   could be the IP address of the PCEP speaker that created a dynamic
   association, an operator 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.

   Optional TLVs: The optional TLVs follow the PCEP TLV format of
   [RFC5440].  This document defines two optional TLVs.  Other documents
   can define more TLVs.

5.1.1.  Global Association Source TLV

   The Global Association Source TLV is an optional TLV for use in the
   Association Object.


       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                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



            Figure 4: The Global Association Source TLV format

   Type: To be allocated by IANA.

   Length: Fixed value of 4 bytes.

   Global Association Source: as defined in [RFC6780].

5.1.2.  Extended Association ID TLV

   The Extended Association ID TLV is an optional TLV except for
   Operator-configured Associations, for use in the Association Object.







Minei, et al.           Expires December 29, 2017               [Page 9]


Internet-Draft            PCE association group                June 2017


       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                      //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



             Figure 5: The Extended Association ID TLV format

   Type: To be allocated by IANA.

   Length: variable.

   Extended Association ID: as defined in [RFC6780].

5.2.  Object Encoding in PCEP messages

5.2.1.  Stateful PCEP messages

   The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path
   Computation Update (PCUpd), Path Computation Report (PCRpt) and Path
   Computation Initiate (PCInitiate) messages.

   When carried in PCRpt message, it is used to report the association
   group membership information pertaining to a LSP to a stateful PCE.
   It can also be used to remove an LSP from one or more association
   groups by setting the R flag to 1 in the ASSOCIATION object.  Unless,
   a PCE wants to delete an association from an LSP, it does not need to
   carry the ASSOCIATION object in future messages.

   The PCRpt message is defined in [I-D.ietf-pce-stateful-pce] and
   updated as below:
















Minei, et al.           Expires December 29, 2017              [Page 10]


Internet-Draft            PCE association group                June 2017


      <PCRpt Message> ::= <Common Header>
                             <state-report-list>
      Where:

         <state-report-list> ::= <state-report>[<state-report-list>]

         <state-report> ::= [<SRP>]
                            <LSP>
                            [<association-list>]
                            <path>
       Where:
         <path>::= <intended-path>
                   [<actual-attribute-list><actual-path>]
                   <intended-attribute-list>


         <association-list> ::= <ASSOCIATION> [<association-list>]

   When an LSP is delegated to a stateful PCE, the stateful PCE can
   initiate a new association group for this LSP, or associate it with
   one or more existing association groups.  This is done by including
   the ASSOCIATION Object in a 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 ASSOCIATION object.

   The PCUpd message is defined in [I-D.ietf-pce-stateful-pce] and
   updated as below:

       <PCUpd Message> ::= <Common Header>
                           <update-request-list>
    Where:

       <update-request-list> ::= <update-request>[<update-request-list>]

       <update-request> ::= <SRP>
                            <LSP>
                            [<association-list>]
                            <path>
    Where:
       <path>::= <intended-path><intended-attribute-list>

       <association-list> ::= <ASSOCIATION> [<association-list>]

   A PCE initiating a new LSP, can include the association group
   information.  This is done by including the ASSOCIATION Object in a
   PCInitiate message.  The PCInitiate message is defined in
   [I-D.ietf-pce-pce-initiated-lsp] and updated as below:




Minei, et al.           Expires December 29, 2017              [Page 11]


Internet-Draft            PCE association group                June 2017


   <PCInitiate Message> ::= <Common Header>
                            <PCE-initiated-lsp-list>
   Where:

   <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
                                [<PCE-initiated-lsp-list>]

   <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
                                   <PCE-initiated-lsp-deletion>)

   <PCE-initiated-lsp-instantiation> ::= <SRP>
                                         <LSP>
                                         [<END-POINTS>]
                                         <ERO>
                                         [<association-list>]
                                         [<attribute-list>]

   Where:
   <association-list> ::= <ASSOCIATION> [<association-list>]

5.2.2.  Request Message

   In case of passive stateful or stateless PCE, the ASSOCIATION Object
   is OPTIONAL and MAY be carried in the Path Computation Request
   (PCReq) message.

   When carried in a PCReq message, the ASSOCIATION Object is used to
   associate the path computation request to an association group.  The
   association (and the other LSPs) should be known to the PCE before
   hand.  These could be operator-configured or dynamically learned
   before.  The R flag in ASSOCIATION object within PCReq message MUST
   be set to 0 while sending and ignored on receipt.

   The PCReq message is defined in [RFC5440] and updated in [I-D.ietf-
   pce-stateful-pce], it is further updated below for association:
















Minei, et al.           Expires December 29, 2017              [Page 12]


Internet-Draft            PCE association group                June 2017


   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

   Where:
         <svec-list>::= <SVEC>[<svec-list>]
         <request-list>::= <request>[<request-list>]

         <request>::= <RP>
                      <END-POINTS>
                      [<LSP>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<association-list>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]

   Where:
         <association-list> ::= <ASSOCIATION> [<association-list>]

   Note that LSP object MAY be present for the passive stateful PCE
   mode.

5.3.  Processing Rules

   Association groups can be operator-configured on the necessary PCC
   and PCE.  In addition, a PCC or a PCE can create association groups
   dynamically.  The PCEP speaker can reports the association to its
   peer via PCEP messages.  If a PCEP speaker does not recognize the
   ASSOCIATION object, it MUST return a PCErr message with Error-Type
   "Unknown Object" as described in [RFC5440].  If a PCEP speaker
   understand the ASSOCIATION object but does not support the
   association-type, it MUST return a PCErr message with Error-Type TBD
   "Association Error" and Error-Value 1 "Association-type is not
   supported".  On receiving a PCEP message with ASSOCIATION, if a PCEP
   speaker finds that too many LSPs belong to the association group, it
   MUST return a PCErr message with Error-Type TBD "Association Error"
   and Error-Value 2 "Too many LSPs in the association group".  If a
   PCEP speaker cannot handle a new associations, it MUST return a PCErr
   message with Error-Type TBD "Association Error" and Error-Value 3
   "Too many association groups".  These number MAY be set by operator
   or decided based on a local policy.

   If a PCE speaker receives ASSOCIATION in PCReq message, and the
   association information is not known (association is not configured,
   or created dynamically, or learned from a PCEP peer), it MUST return



Minei, et al.           Expires December 29, 2017              [Page 13]


Internet-Draft            PCE association group                June 2017


   a PCErr message with Error-Type TBD "Association Error" and Error-
   Value 4 "Association unknown".  If the association information
   received from the peer does not match with the local operator
   configured information, it MUST return a PCErr message with Error-
   Type TBD "Association Error" and Error-Value 5 "Operator-configured
   association information mismatch".  On receiving association
   information that does not match with the association information
   previously received about the same association from a peer, it MUST
   return a PCErr message with Error-Type TBD "Association Error" and
   Error-Value 6 "Association information mismatch".  If a PCE peer is
   unwilling or unable to process the ASSOCIATION object, it MUST return
   a PCErr message with the Error-Type "Not supported object" and follow
   the relevant procedures described in [RFC5440].

   The association information is cleared along with the LSP state
   information as per the [I-D.ietf-pce-stateful-pce].  When a PCEP
   session is terminated, after expiry of State Timeout Interval at PCC,
   the LSP state associated with that PCEP session is reverted to
   operator-defined default parameters or behaviors.  Same procedure is
   also followed for the association information.  On session
   termination at the PCE, when the LSP state reported by PCC is
   cleared, the association information is also cleared.  Where there
   are no LSPs in a association group, the association is considered to
   be deleted.

   In case the LSP is delegated to another PCE on session failure, the
   association information set by the PCE remains intact, unless updated
   by the new PCE.

   Upon LSP delegation revocation, the PCC MAY clear the association
   created by the PCE, but in order to avoid traffic loss, it can
   perform this in a make-before-break fashion, which is the same as
   what is defined in [I-D.ietf-pce-stateful-pce] for handling LSP state
   cleanup.

6.  IANA Considerations

6.1.  PCEP Object

   The "PCEP Parameters" registry contains a subregistry "PCEP Objects".
   This document request IANA to allocate the values from this registry.










Minei, et al.           Expires December 29, 2017              [Page 14]


Internet-Draft            PCE association group                June 2017


     Object-Class Value  Name                               Reference

            TBD          Association                        [This I-D]
                         Object-Type
                         0: Reserved
                         1: IPv4
                         2: IPv6

6.2.  PCEP TLV

   IANA is requested to make the assignment of a new value for the
   existing "PCEP TLV Type Indicators" registry as follows:

               Value     Meaning                     Reference
                TBD      Operator-configured         [This I-D]
                         Association Range
                TBD      Global Association Source   [This I-D]
                TBD      Extended Association Id     [This I-D]

6.3.  Association Flags

   This document requests IANA to create a subregistry of the "PCEP
   Parameters" for the bits carried in the Flags field of the
   ASSOCIATION object.  The subregistry is called "ASSOCIATION Flags
   Field".

   The field contains 12 bits numbered from bit 0 as the most
   significant bit.

           Bit    Name   Description                 Reference

           15     R      Removal                     [This I-D]

6.4.  Association Type

   This document requests IANA to create a subregistry of the "PCEP
   Parameters" for the Association Type field of the the ASSOCIATION
   object.  The subregistry is called "ASSOCIATION Type Field".

   There are no association type specified in this document, future
   document should request the assignment of association types from this
   subregistry.

6.5.  PCEP-Error Object

   IANA is requested to allocate new error values within the "PCEP-ERROR
   Object Error Types and Values" sub-registry of the PCEP Numbers
   registry, as follows:



Minei, et al.           Expires December 29, 2017              [Page 15]


Internet-Draft            PCE association group                June 2017


       Error-Type  Meaning
          TBD      Association Error [This I-D]
                   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



7.  Security Considerations

   The security considerations described in [I-D.ietf-pce-stateful-pce]
   and [RFC5440] 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 report too many associations in
   an attempt to load the PCEP peer.  The PCEP peer responds with PCErr
   as described in Section 5.3.  An attacker could impact LSP operations
   by creating bogus associations.  Further, association information
   could provides an adversary with the opportunity to eavesdrop on the
   relationship between the LSPs.  Thus securing the PCEP session using
   Transport Layer Security (TLS) [I-D.ietf-pce-pceps], as per the
   recommendations and best current practices in [RFC7525], is
   RECOMMENDED.

8.  Manageability Considerations

   All manageability requirements and considerations listed in [RFC5440]
   and [I-D.ietf-pce-stateful-pce] apply to PCEP protocol extensions
   defined in this document.  In addition, requirements and
   considerations listed in this section apply.

8.1.  Control of Function and Policy

   A PCE or PCC implementation MUST allow operator-configured
   associations as described in this document.  The identifier MUST be
   from the operator-configured identifier range Section 3.3.





Minei, et al.           Expires December 29, 2017              [Page 16]


Internet-Draft            PCE association group                June 2017


8.2.  Information and Data Models

   An implementation SHOULD allow the operator to view the associations
   configured or created dynamically.  Further implementation SHOULD
   allow to view associations reported by each peer, and the current set
   of LSPs in the association .  To serve this purpose, the PCEP YANG
   module [I-D.ietf-pce-pcep-yang] can be extended to include
   association information.

8.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

8.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440] and [I-D.ietf-pce-stateful-pce].

8.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

8.6.  Impact On Network Operations

   Mechanisms defined in [RFC5440] and [I-D.ietf-pce-stateful-pce] also
   apply to PCEP extensions defined in this document.

9.  Acknowledgements

   We would like to thank Yuji Kamite and Joshua George for their
   contributions to this document.  Also thanks to Venugopal Reddy,
   Cyril Margaria and Rakesh Gandhi for their useful comments.

10.  Contributors













Minei, et al.           Expires December 29, 2017              [Page 17]


Internet-Draft            PCE association group                June 2017


   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
   Nokia

   Email: mustapha.aissaoui@nokia.com



11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
              ASSOCIATION Object Extensions", RFC 6780,
              DOI 10.17487/RFC6780, October 2012,
              <http://www.rfc-editor.org/info/rfc6780>.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-21 (work in progress), June 2017.







Minei, et al.           Expires December 29, 2017              [Page 18]


Internet-Draft            PCE association group                June 2017


   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-10 (work in
              progress), June 2017.

11.2.  Informative References

   [RFC4657]  Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol Generic
              Requirements", RFC 4657, DOI 10.17487/RFC4657, September
              2006, <http://www.rfc-editor.org/info/rfc4657>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <http://www.rfc-editor.org/info/rfc8051>.

   [I-D.ietf-pce-pceps]
              Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
              Transport for PCEP", draft-ietf-pce-pceps-14 (work in
              progress), May 2017.

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Hardwick, J., Beeram, V., and j.
              jefftant@gmail.com, "A YANG Data Model for Path
              Computation Element Communications Protocol (PCEP)",
              draft-ietf-pce-pcep-yang-02 (work in progress), March
              2017.

Authors' Addresses

   Ina Minei
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: inaminei@google.com






Minei, et al.           Expires December 29, 2017              [Page 19]


Internet-Draft            PCE association group                June 2017


   Edward Crabbe
   Individual Contributor

   Email: edward.crabbe@gmail.com


   Siva Sivabalan
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Email: msiva@cisco.com


   Hariharan Ananthakrishnan
   Packet Design

   Email: hari@packetdesign.com


   Dhruv Dhody
   Huawei
   Divyashree Techno Park, Whitefield
   Bangalore, KA  560066
   India

   Email: dhruv.ietf@gmail.com


   Yosuke Tanaka
   NTT Communications Corporation
   Granpark Tower 3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   Email: yosuke.tanaka@ntt.com














Minei, et al.           Expires December 29, 2017              [Page 20]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/