PCE Working Group Y. Lee
Internet-Draft D. Dhody
Intended Status: Standards track X. Zhang
Expires: May 1, 2017 Huawei Technologies
D. Ceccarelli
Ericsson
October 28, 2016
PCEP Extensions for Establishing Relationships Between Sets of LSPs
and Virtual Networks
draft-leedhody-pce-vn-association-01
Abstract
This document describes how to extend Path Computation Element (PCE)
Communication Protocol (PCEP) association mechanism introduced by the
PCEP Association Group specification, to further associate sets of
LSPs with a higher-level structure such as a virtual network (VN)
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 May 1, 2017 [Page 1]
Internet-Draft PCEP VN Association October, 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
computations in response to Path Computation Clients' (PCCs)
requests.
Lee & Dhody, et al. Expires May 1, 2017 [Page 2]
Internet-Draft PCEP VN Association October, 2016
[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.
[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. The PCE could then use
this association to optimize all LSPs belonging to the VN together.
The PCE could further take VN specific actions on the LSPs such as
relaxation of constraints, policy actions, setting default behavior
etc.
[I-D.dhody-pce-applicability-actn] examines the PCE and ACTN
architecture and describes how the PCE architecture is applicable to
ACTN. [RFC6805] and [I-D.dhodylee-pce-stateful-hpce] describes a
hierarchy of stateful PCEs with Parent PCE coordinating multi-domain
path computation function between Child PCE(s) and thus making it the
base for PCE applicability for ACTN.
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 May 1, 2017 [Page 3]
Internet-Draft PCEP VN Association October, 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
associations between 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:
0 1 2 3
Lee & Dhody, et al. Expires May 1, 2017 [Page 4]
Internet-Draft PCEP VN Association October, 2016
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 May 1, 2017 [Page 5]
Internet-Draft PCEP VN Association October, 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 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
Lee & Dhody, et al. Expires May 1, 2017 [Page 6]
Internet-Draft PCEP VN Association October, 2016
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.
The Child PCE could then use this association to optimize all LSPs
belonging to the same VN association together. The Child PCE could
further take VN specific actions on the LSPs such as relaxation of
constraints, policy actions, setting default behavior etc. The parent
PCE could also maintain all E2E LSP or per-domain path segments under
a single VN association.
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 May 1, 2017 [Page 7]
Internet-Draft PCEP VN Association October, 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
; 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 ; 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[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",
Lee & Dhody, et al. Expires May 1, 2017 [Page 8]
Internet-Draft PCEP VN Association October, 2016
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.
8.2. Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., 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.
[I-D.dhody-pce-applicability-actn] Dhody D., Lee Y., and D.
Ceccarelli, "Applicability of Path Computation Element
(PCE) for Abstraction and Control of TE Networks (ACTN)",
draft-dhody-pce-applicability-actn, work-in-progress.
[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.
[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 May 1, 2017 [Page 9]
Internet-Draft PCEP VN Association October, 2016
Dhruv Dhody (Editor)
Huawei Technologies
Divyashree Technopark, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Xian Zhang
Huawei Technologies
China
Email: zhang.xian@huawei.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm,
Sweden
Email: daniele.ceccarelli@ericsson.com
Lee & Dhody, et al. Expires May 1, 2017 [Page 10]