[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07

PCE Working Group                                                Y. Lee
                                                               D. Dhody
Internet-Draft                                      Huawei Technologies
Intended Status: Standards track                          D. Ceccarelli
                                                               Ericsson
Expires: August 2016




                                                      February 25, 2016



    PCEP Extensions for Establishing Relationships Between Sets of LSPs
                           and Virtual Networks



                 draft-leedhody-pce-vn-association-00.txt


Abstract

   This document describes how to extend PCE association mechanism
   introduced by [PCE-Association] to further associate sets of LSPs
   with a higher-level structure such as a virtual network requested by
   clients or applications. This extended association mechanism can be
   used to facilitate virtual network control using PCE architecture.



Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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





Lee & Dhody, et al.    Expires August 25, 2016                 [Page 1]


Internet-Draft           PCEP VN Association              February 2016


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 25, 2016.

Copyright Notice

   Copyright (c) 2016 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...................................................2
      1.1. Requirements Language.....................................3
   2. Terminology....................................................4
   3. Operation Overview.............................................4
   4. Extensions to PCEP.............................................4
   5. Applicability to H-PCE architecture............................6
   6. Security Considerations........................................7
   7. IANA Considerations............................................7
      7.1. Association Object Type Indicator.........................7
      7.2. PCEP TLV Type Indicator...................................8
      7.3. PCEP Error................................................8
   8. References.....................................................8
      8.1. Normative References......................................8
      8.2. Informative References....................................9
   Author's Addresses................................................9

1. Introduction

   The Path Computation Element communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path


Lee & Dhody, et al.    Expires August 25, 2016                 [Page 2]


Internet-Draft           PCEP VN Association              February 2016


   computations in response to Path Computation Clients' (PCCs)
   requests.

   [I-D.ietf-pce-stateful-pce-app] describes general considerations for
   a stateful PCE deployment and examines its applicability and
   benefits, as well as its challenges and limitations through a number
   of use cases.  [I-D.ietf-pce-stateful-pce] describes a set of
   extensions to PCEP to provide stateful control.  A stateful PCE has
   access to not only the information carried by the network's Interior
   Gateway Protocol (IGP), but also the set of active paths and their
   reserved resources for its computations.  The additional state
   allows the PCE to compute constrained paths while considering
   individual LSPs and their interactions.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance
   and teardown of PCE-initiated LSPs under the stateful PCE model.
   Within the hierarchical PCE architecture, a PCE is used to initiate
   or delete LSPs to a PCC.

   [I-D.ietf-pce-association-group] introduces a generic mechanism to
   create a grouping of LSPs. This grouping can then be used to define
   association between sets of LSPs or between a set of LSPs and a set
   of attributes.

   [ACTN-REQ] describes various Virtual Network (VN) operations
   initiated by a customer/application. In this context, there is a
   need for associating a set of LSPs with a VN "construct" to
   facilitate VN operations in PCE architecture. This association
   allows the PCEs to identify which LSPs belong to a certain VN.

   This document specifies a PCEP extension to associate a set of LSPs
   based on Virtual Network or customer.

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






Lee & Dhody, et al.    Expires August 25, 2016                 [Page 3]


Internet-Draft           PCEP VN Association              February 2016


2. Terminology

   The terminology is as per [RFC4655], [RFC5440], [RFC6805], and [I-
   D.ietf-pce-stateful-pce].

3. Operation 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. In this draft, this grouping is used to define
   associationsbetween a set of LSPs and a virtual network.

   One new optional Association Object-type is defined based on the
   generic Association object -

      o  VN Association Group (VNAG)

   Thus this document define one new association type called "VN
   Association Type" of value TBD1.  The scope and handling of VNAG
   identifier is similar to the generic association identifier defined
   in [I-D.ietf-pce-association-group].



4. Extensions to PCEP

    [I-D.ietf-pce-association-group] introduces the ASSOCIATION object,
   the format of VNAG is as follows:





















Lee & Dhody, et al.    Expires August 25, 2016                 [Page 4]


Internet-Draft           PCEP VN Association              February 2016



    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 VNAG Object formats

   Please refer to [I-D.ietf-pce-association-group] for the definition
   of each field in Figure 1. This document defines one mandatory TLV.

   o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier.



   The format of VIRTUAL-NETWORK-TLV is as follows.










Lee & Dhody, et al.    Expires August 25, 2016                 [Page 5]


Internet-Draft           PCEP VN Association              February 2016


    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 (variable)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                   Virtual Network Name                      //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 2: The VIRTUAL-NETWORK-TLV formats

   Type: TBD2 (to be allocated by IANA)

   Length: Variable Length

   Virtual Network Name(variable): symbolic name for the VN.

   The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP
   speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
   MUST send a PCErr message with Error-Type= 6 (mandatory object
   missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and
   close the session.


5. Applicability to H-PCE architecture

   The ability to compute shortest constrained TE LSPs in Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
   multiple domains has been identified as a key motivation for PCE
   development.  [RFC6805] describes a Hierarchical PCE (H-PCE)
   architecture which can be used for computing end-to-end paths for
   inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched
   Paths (LSPs).  Within the hierarchical PCE architecture, the parent
   PCE is used to compute a multi-domain path based on the domain
   connectivity information.  A child PCE may be responsible for a
   single domain or multiple domains, it is used to compute the intra-
   domain path based on its domain topology information.

   [I-D.ietf-dhodylee-stateful-HPCE] introduces general considerations
   for stateful PCE(s) in hierarchical PCE architecture.  In



Lee & Dhody, et al.    Expires August 25, 2016                 [Page 6]


Internet-Draft           PCEP VN Association              February 2016


   particular, the behavior changes and additions to the existing
   stateful PCE mechanisms in the context of a H-PCE architecture.


   In Stateful H-PCE architecture, the Parent PCE receives a virtual
   network creation request by its client over its Northbound API. This
   VN is uniquely identified by an Association ID in VNAG as well as
   the VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the
   network in a single domain or across multiple domains.

   As the Parent PCE computes the optimum E2E paths for each tunnel in
   VN, it MUST associate each LSP with the VN to which it belongs.
   Parent PCE sends a PCInitiate Message with this association
   information in the VNAG Object (See Section 4 for details). This in
   effect binds an LSP that is to be instantiated at the child PCE with
   the VN.

   Whenever changes occur with the instantiated LSP in a domain
   network, the domain child PCE reports the changes using a PCRpt
   Message in which the VNAG Object indicates the relationship between
   the LSP and the VN.

   Whenever an update occurs with VNs in the Parent PCE (via the
   client's request), the parent PCE sends an PCUpd Message to inform
   each affected child PCE of this change.



6. Security Considerations

   TDB

7. IANA Considerations

7.1. Association Object Type Indicator

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



      Value     Name                        Reference

      TBD1      VN Association Type         [This I.D.]




Lee & Dhody, et al.    Expires August 25, 2016                 [Page 7]


Internet-Draft           PCEP VN Association              February 2016


7.2. PCEP TLV Type Indicator

   This document defines the following new PCEP TLV; IANA is requested
   to make the following allocations from this registry at
   http://www.iana.org/assignments/pcep/pcep.xhtml; see PCEP TLV Type
   Indicators.



      Value     Name                        Reference

      TBD2      VIRTUAL-NETWORK-TLV         [This I.D.]

7.3. PCEP Error

   IANA is requested to make the following allocations from this
   registry at http://www.iana.org/assignments/pcep/pcep.xhtml; see
   PCEP-ERROR Object Error Types and Values.

   This document defines new Error-Type and Error-Value for the
   following new error conditions:



       Error-Type  Meaning

          6        Mandatory Object missing

                    Error-value=TBD3: VIRTUAL-NETWORK TLV missing

8. References

8.1. Normative References

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

   [I-D.ietf-pce-pce-initiated-lsp] E. Crabbe, et. al., "PCEP
             Extensions for PCE-initiated LSP Setup in a Stateful PCE
             Model", draft-ietf-pce-pce-initiated-lsp, work in
             progress.

   [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for
             Establishing Relationships Between Sets of LSPs", draft-
             ietf-pce-association-group, work in progress.



Lee & Dhody, et al.    Expires August 25, 2016                 [Page 8]


Internet-Draft           PCEP VN Association              February 2016


   [I-D.ietf-dhodylee-stateful-HPCE] Dhody, D. and Lee, Y.,
             "Hierarchical Stateful Path Computation Element (PCE)",
             draft-dhodylee-pce-stateful-hpce, work in progress.

8.2. Informative References

   [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
             Computation Element (PCE)-Based Architecture", RFC 4655,
             August 2006.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
             Element (PCE) Communication Protocol (PCEP)", RFC 5440,
             March 2009.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC6805] A. Farrel and D. King, "The Application of the Path
             Computation Element Architecture to the Determination of a
             Sequence of Domains in MPLS and GMPLS", RFC 6805, November
             2012.

   [I-D.ietf-pce-stateful-pce-app] Zhang, X., ED, and Minei, I., ED,
             "Applicability of a Stateful Path Computation Element
             (PCE)", draft-ietf-pce-stateful-pce-app, work-in-progress.

   [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D.
             Ceccarelli, "Requirements for Abstraction and Control of
             TE Networks", draft-ietf-teas-actn-requirements, work in
             progress.

 Author's Addresses


   Young Lee (Editor)
   Huawei Technologies
   5340 Legacy Drive, Building 3
   Plano, TX 75023, USA

   Email: leeyoung@huawei.com









Lee & Dhody, et al.    Expires August 25, 2016                 [Page 9]


Internet-Draft           PCEP VN Association              February 2016


   Dhruv Dhody (Editor)
   Huawei Technologies
   Divyashree Technopark, Whitefield
   Bangalore, Karnataka  560037
   India

   EMail: dhruv.ietf@gmail.com

   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm, Sweden

   EMail: daniele.ceccarelli@ericsson.com


   Xian Zhang
   Huawei Technologies

   Email: zhang.xian@huawei.com





























Lee & Dhody, et al.    Expires August 25, 2016                [Page 10]


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