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

Versions: 00 01 02 03 04 05 06

PCE Working Group                                               D. Dhody
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                     Huawei Technologies
Expires: September 13, 2017                               March 12, 2017


     Path Computation Element communication Protocol extension for
                relationship between LSPs and Attributes
                  draft-dhody-pce-association-attr-06

Abstract

   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).

   This document defines a mechanism to create associations between a
   set of LSPs and a set of attributes (such as configuration
   parameters).

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."

   This Internet-Draft will expire on September 13, 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



Dhody & Wu             Expires September 13, 2017               [Page 1]


Internet-Draft                 ASSOC-ATTR                     March 2017


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Opaque Identifier . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Bundled requests  . . . . . . . . . . . . . . . . . . . .   4
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Attribute Association Group . . . . . . . . . . . . . . . . .   5
     5.1.  ATTRIBUTE-OBJECT-TLV  . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Association object Type Indicators  . . . . . . . . . . .   8
     7.2.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .   8
     7.3.  Flag field in ATTRIBUTE-OBJECT-TLV  . . . . . . . . . . .   8
   8.  Manageability Considerations  . . . . . . . . . . . . . . . .   8
     8.1.  Control of Function and Policy  . . . . . . . . . . . . .   9
     8.2.  Information and Data Models . . . . . . . . . . . . . . .   9
     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .   9
     8.4.  Verify Correct Operations . . . . . . . . . . . . . . . .   9
     8.5.  Requirements On Other Protocols . . . . . . . . . . . . .   9
     8.6.  Impact On Network Operations  . . . . . . . . . . . . . .   9
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  Policy . . . . . . . . . . . . . . . . . . . . . . .  12
   Appendix B.  Contributor Addresses  . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

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

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



Dhody & Wu             Expires September 13, 2017               [Page 2]


Internet-Draft                 ASSOC-ATTR                     March 2017


   This document specifies a PCEP extension to associate one or more
   LSPs with a set of attributes.

   PCEP Extensions for Stateful PCE Model [I-D.ietf-pce-stateful-pce]
   describes a set of extensions to PCEP to enable active control of
   MPLS-TE and GMPLS tunnels.  [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.

1.1.  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].

2.  Terminology

   The following terminology is used in this document.

   AAG:  Attribute Association Group.

   LSR:  Label Switch Router.

   MPLS:  Multi-protocol Label Switching.

   PAG:  Policy Association Group.

   PCC:  Path Computation Client.  Any client application requesting a
      path computation to be performed by a Path Computation Element.

   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.

   PCEP:  Path Computation Element Communication Protocol.

3.  Motivation

   This section discusses in more detail the motivation and use cases
   for such an association including but not limited to -







Dhody & Wu             Expires September 13, 2017               [Page 3]


Internet-Draft                 ASSOC-ATTR                     March 2017


3.1.  Opaque Identifier

   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.

   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)
   [I-D.ietf-teas-actn-requirements].  (See
   [I-D.leedhody-pce-vn-association])

3.2.  Bundled requests

   In some scenarios(e.g.,the topology example described in Section 4.6
   of [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.

   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.

4.  Overview

   As per [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 -

   o  Attribute Association Group (AAG)

   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 [I-D.ietf-pce-association-group].






Dhody & Wu             Expires September 13, 2017               [Page 4]


Internet-Draft                 ASSOC-ATTR                     March 2017


   One or more LSP are grouped via a single group identifier as defined
   in [I-D.ietf-pce-association-group].  The attributes that may be
   associated with this set of LSPs may either are -

   o  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.

   o  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.

   Error handling would be taken up in future revision.

5.  Attribute Association Group

   The format of the generic Association object used for AAG is shown in
   Figure 1:



























Dhody & Wu             Expires September 13, 2017               [Page 5]


Internet-Draft                 ASSOC-ATTR                     March 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 (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                             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 1: The AAG Object formats

   Type = TBD1 for the Attribute Association Type.

   AAG may carry optional TLVs including but not limited to -

   o  ATTRIBUTE-OBJECT-TLV: Used to communicate associated attributes in
      form of PCEP objects, described in this document.

   o  VENDOR-INFORMATION-TLV: Used to communicate arbitrary behavioral
      information, described in [RFC7470].

5.1.  ATTRIBUTE-OBJECT-TLV

   The ATTRIBUTE-OBJECT-TLV(s) maybe included in AAG object to associate
   attributes encoded in PCEP objects.

   The format of the ATTRIBUTE-OBJECT-TLV is shown in the following
   figure:




Dhody & Wu             Expires September 13, 2017               [Page 6]


Internet-Draft                 ASSOC-ATTR                     March 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 (TBD2)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                         |M|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Object-Class  |   OT  |Res|P|I|   Object Length (bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Object body)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: ATTRIBUTE-OBJECT-TLV format

   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 [RFC5440] identifying the object) that is
   associated with this AAG.

   Following Flags are defined:

      R (Remove - 1 bit): This is set to indicate that the attribute is
      being removed from the attribute-list.

      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.

   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.

6.  Security Considerations

   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 [RFC5440], [I-D.ietf-pce-stateful-pce] and
   [I-D.ietf-pce-association-group] in itself.

   Some deployments may find the associations and their implications as
   extra sensitive and thus should employ suitable PCEP security
   mechanisms like TCP-AO or [I-D.ietf-pce-pceps].







Dhody & Wu             Expires September 13, 2017               [Page 7]


Internet-Draft                 ASSOC-ATTR                     March 2017


7.  IANA Considerations

7.1.  Association object Type Indicators

   This document defines the following new association type originally
   defined in [I-D.ietf-pce-association-group].

   Value     Name                        Reference
   TBD1      Attribute Association Type  [This I.D.]


7.2.  PCEP TLV Type Indicators

   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

   Value     Name                        Reference
   TBD2      ATTRIBUTE-OBJECT-TLV        [This I.D.]

7.3.  Flag field in ATTRIBUTE-OBJECT-TLV

   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 [RFC5226].  Each bit should be tracked with the following
   qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following values are defined in this document:

   Bit     Description           Reference
    31     Remove                [This I.D.]
    30     Modify                [This I.D.]

8.  Manageability Considerations








Dhody & Wu             Expires September 13, 2017               [Page 8]


Internet-Draft                 ASSOC-ATTR                     March 2017


8.1.  Control of Function and Policy

   An operator MUST BE allowed to configure the attribute associations
   at PCEP peers and associate it with the LSPs.

8.2.  Information and Data Models

   [RFC7420] describes the PCEP MIB, there are no new MIB Objects for
   this document.

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

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 this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].

9.  Acknowledgments

   A special thanks to author of [I-D.ietf-pce-association-group], this
   document borrow some of the text from it.

10.  References

10.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>.






Dhody & Wu             Expires September 13, 2017               [Page 9]


Internet-Draft                 ASSOC-ATTR                     March 2017


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

   [RFC7470]  Zhang, F. and A. Farrel, "Conveying Vendor-Specific
              Constraints in the Path Computation Element Communication
              Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
              <http://www.rfc-editor.org/info/rfc7470>.

   [I-D.ietf-pce-association-group]
              Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Zhang, X., and Y. Tanaka, "PCEP Extensions for
              Establishing Relationships Between Sets of LSPs", draft-
              ietf-pce-association-group-02 (work in progress), January
              2017.

   [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-18 (work in progress), December 2016.

10.2.  Informative References

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <http://www.rfc-editor.org/info/rfc4655>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              DOI 10.17487/RFC6805, November 2012,
              <http://www.rfc-editor.org/info/rfc6805>.

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <http://www.rfc-editor.org/info/rfc7420>.






Dhody & Wu             Expires September 13, 2017              [Page 10]


Internet-Draft                 ASSOC-ATTR                     March 2017


   [I-D.ietf-pce-pceps]
              Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
              Transport for PCEP", draft-ietf-pce-pceps-11 (work in
              progress), January 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-09 (work in
              progress), March 2017.

   [I-D.ietf-teas-actn-requirements]
              Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D.
              Ceccarelli, "Requirements for Abstraction and Control of
              TE Networks", draft-ietf-teas-actn-requirements-04 (work
              in progress), January 2017.

   [I-D.ietf-pce-association-policy]
              Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and
              J. Hardwick, "Path Computation Element communication
              Protocol extension for associating Policies and LSPs",
              draft-ietf-pce-association-policy-00 (work in progress),
              December 2016.

   [I-D.leedhody-pce-vn-association]
              Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP
              Extensions for Establishing Relationships Between Sets of
              LSPs and Virtual Networks", draft-leedhody-pce-vn-
              association-01 (work in progress), October 2016.






















Dhody & Wu             Expires September 13, 2017              [Page 11]


Internet-Draft                 ASSOC-ATTR                     March 2017


Appendix A.  Policy

   An earlier version of this document also had details about Policy
   association group.  This has been moved to an independent document -
   [I-D.ietf-pce-association-policy].

Appendix B.  Contributor Addresses

   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


Authors' Addresses

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: dhruv.ietf@gmail.com


   Qin Wu
   Huawei Technologies
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   EMail: sunseawq@huawei.com








Dhody & Wu             Expires September 13, 2017              [Page 12]


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