PCE Working Group I. Minei
Internet-Draft E. Crabbe
Intended status: Standards Track Google, Inc.
Expires: December 29, 2014 S. Sivabalan
Cisco Systems, Inc.
H. Ananthakrishnan
Juniper Networks, Inc.
X. Zhang
Huawei Technologies
Y. Tanaka
NTT Communications Corporation
June 27, 2014
PCEP Extensions for establishing relationships between sets of LSPs
draft-minei-pce-association-group-00
Abstract
This document introduces a generic mechanism to create a grouping of
LSPs in the context of stateful 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 the active and passive modes
of stateful 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."
This Internet-Draft will expire on December 29, 2014.
Minei, et al. Expires December 29, 2014 [Page 1]
Internet-Draft PCE association group June 2014
Copyright Notice
Copyright (c) 2014 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Operation overview . . . . . . . . . . . . . . . . . . . 3
4. LSP association groups . . . . . . . . . . . . . . . . . . . 4
5. Using the LSP association group . . . . . . . . . . . . . . . 4
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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) 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].
Minei, et al. Expires December 29, 2014 [Page 2]
Internet-Draft PCE association group June 2014
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 the active and passive modes of stateful PCE.
2. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, 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 reoptimized 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. Rather than
creating separate mechanisms for each use case, this draft defines a
generic one.
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 are locally meaningful at the LSP head-end,
and can only be applied to LSPs originating at that head end. Thus,
the association identifiers are unique at each head end, but not
necessarily across the network, and are owned and managed by the head
end.
Multiple types of groups can exist, each with their own identifiers
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. There is support for removal of all LSPs from an association
as well. An LSP may join multiple association groups, of different
or of the same type.
Minei, et al. Expires December 29, 2014 [Page 3]
Internet-Draft PCE association group June 2014
4. LSP association groups
Association groups are owned by the PCC, but the PCE may request
creation of an association group (for example before instantiating
LSPs that belong to that group). Membership in an association group
can be initiated by either the PCE or the PCC. Association groups
and their memberships are defined using the Association object.
The Association Object is an optional object in the PCupd, PCRpt and
PCinit messages.
The format of the Association object is shown Figure 1:
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 | Generic flags |R| Type-specific flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association group id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Association Object format
Type - the association type (for example protection or make-before-
break). The association type will be defined in separate documents.
Generic flags - flags for the association object. A single one is
defined, the R flag indicating removal from the association group.
Type-specific flags - specific to the association type, will be
defined at the time of the association type.
Association group id - identifier of the association group. The
values 0 and 0xffffffff are reserved. Value 0 is used when the PCE
requests allocation of an association group. Value 0xffffffff
indicates all association groups.
5. Using the LSP association group
Membership in an association group is reported in PCRpt messages by
including the association object along with the LSP object. Removal
of the LSP from the association group on the PCC (for example through
configuration) is reported by including the association object with
the R flag set. When an LSP belongs to multiple association groups,
Minei, et al. Expires December 29, 2014 [Page 4]
Internet-Draft PCE association group June 2014
multiple association objects are included in the PCRpt, one for each
association the LSP belongs to. A PCE can associate an LSP that was
delegated to it (the candidate LSP) with an existing association
group, by sending a PCUpd for the candidate LSP, including the
Association Object for the association group. Error handling for
this operation will be defined in a future version of this draft.
An association group can be created locally at the PCC (for example
through configuration) or it can be requested by the PCE. A PCE may
request the creation of an association group by sending a PCUpd
message with the reserved value 0. In response to this request, the
PCC will allocate an association group id and report it in the PCRpt
message. Error handling will be defined in a future version of this
draft. Note that this operation includes creation of the group and
association of one LSP with this group. Requesting the creation of
an association group before the LSP exists will be handled in a
future version of this draft.
6. IANA considerations
This document defines the following new PCEP Object-classes and
Object-values:
Object-Class Value Name Reference
TBD Association This document
Object-Type
1
This document requests that a registry is created to manage the Flags
field of the Association object. New values are to be assigned by
Standards Action [RFC5226].
7. Security Considerations
The security considerations described in [I-D.ietf-pce-stateful-pce]
apply to the extensions described in this document. Additional
considerations related to a malicious PCE are introduced, as the PCE
may now create additional state on the PCC through the creation of
association groups.
8. Acknowledgements
We would like to thank Yuji Kamite and Joshua George for their
contributions to this document.
Minei, et al. Expires December 29, 2014 [Page 5]
Internet-Draft PCE association group June 2014
9. References
9.1. Normative References
[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-01 (work in
progress), June 2014.
[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-09 (work in progress), June 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
9.2. Informative References
[I-D.tanaka-pce-stateful-pce-mbb]
Tanaka, Y., Kamite, Y., and D. Dhody, "Make-Before-Break
MPLS-TE LSP restoration and reoptimization procedure using
Stateful PCE", draft-tanaka-pce-stateful-pce-mbb-03 (work
in progress), February 2014.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
Authors' Addresses
Minei, et al. Expires December 29, 2014 [Page 6]
Internet-Draft PCE association group June 2014
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: inaminei@google.com
Edward Crabbe
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: edc@google.com
Siva Sivabalan
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
Email: msiva@cisco.com
Hariharan Ananthakrishnan
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: hanantha@juniper.net
Xian Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhang.xian@huawei.com
Minei, et al. Expires December 29, 2014 [Page 7]
Internet-Draft PCE association group June 2014
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, 2014 [Page 8]