PCE Working Group I. Minei
Internet-Draft Google, Inc.
Intended status: Standards Track E. Crabbe
Expires: January 3, 2016
S. Sivabalan
Cisco Systems, Inc.
H. Ananthakrishnan
Juniper Networks, Inc.
X. Zhang
Huawei Technologies
Y. Tanaka
NTT Communications Corporation
July 2, 2015
PCEP Extensions for Establishing Relationships Between Sets of LSPs
draft-minei-pce-association-group-01
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 the active and passive modes of a
stateful PCE as well as a 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 January 3, 2016 [Page 1]
Internet-Draft PCE association group July 2015
This Internet-Draft will expire on January 3, 2016.
Copyright Notice
Copyright (c) 2015 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.
Minei, et al. Expires January 3, 2016 [Page 2]
Internet-Draft PCE association group July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operation overview . . . . . . . . . . . . . . . . . . . . 5
4. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Object Definition . . . . . . . . . . . . . . . . . . . . 5
4.2. Object Encoding in PCEP messages . . . . . . . . . . . . . 7
4.3. Processing Rules . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Minei, et al. Expires January 3, 2016 [Page 3]
Internet-Draft PCE association group July 2015
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 the active and passive modes of a stateful PCE and a stateless
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 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 configuration parameters or behaviors with
the request.
Minei, et al. Expires January 3, 2016 [Page 4]
Internet-Draft PCE association group July 2015
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. For LSPs originating at the
same head end, the association can be initiated by either the PCC
(head end) or by a PCE. Only a stateful PCE can initiate an
association for LSPs originating at different head ends. For both
cases, the association is uniquely identified by the combination of
an association identifier and the address of the PCE peer that
created the association.
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. An LSP may join multiple association groups, of different or
of the same type.
In the case of a stateless PCE, associations are created out of band,
and PCEP peers should be aware of the association and its
significance outside of the protocol.
4. ASSOCIATION Object
4.1. Object Definition
Creation of an association group and modifications to its membership
can be initiated by either the PCE or the PCC. Association groups
and their memberships are defined using the ASSOCIATION object for
stateful PCE.
ASSOCIATION Object-Class is to be assigned by IANA (TBD).
ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in
Figure 1:
Minei, et al. Expires January 3, 2016 [Page 5]
Internet-Draft PCE association group July 2015
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 | Flags |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The IPv4 ASSOCIATION Object format
ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in
Figure 2:
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 | Flags |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The IPv6 ASSOCIATION Object format
Type: 4 bits - the association type (for example protection). The
association type will be defined in separate documents.
Flags: 12 bits - 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.
Reserved: MUST be set to 0 and ignored upon receipt.
Association ID: 32 bits - the identifier of the association group.
Minei, et al. Expires January 3, 2016 [Page 6]
Internet-Draft PCE association group July 2015
When combined with Type and Association Source, this value uniquely
identifies an association group. The value 0xffffffff and 0x0 are
reserved. The value 0xffffffff is used to indicate all association
groups.
Association Source: 4 or 16 bytes - An IPv4 or IPv6 address, which is
associated to the PCE peer that originated the association.
Optional TLVs: Variable - no TLVs are defined in this document.
4.2. Object Encoding in 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 (PCinit) 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. Unless, a PCE wants to delete an
association from an LSP, it does not need to carry the ASSOCIATION
object while updating other LSP attributes using the PCUpd message.
The PCRpt message is defined in [I-D.ietf-pce-stateful-pce] and
updated as below:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
[<association-list>]
<path>
Where:
<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 or in a PCInit message. A
stateful PCE can also remove a delegated LSP from one or more
association groups by setting the R flag to 1.
Minei, et al. Expires January 3, 2016 [Page 7]
Internet-Draft PCE association group July 2015
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: <association-list> ::= <ASSOCIATION> [<association-list>]
The PCInitiate message is defined in [I-D.ietf-pce-pce-initiated-lsp]
and updated as below:
<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>]
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 might be further informed via PCRpt message in case of
passive stateful PCE later or it might be created out of band in case
of stateless PCE.
Minei, et al. Expires January 3, 2016 [Page 8]
Internet-Draft PCE association group July 2015
The PCReq message is defined in [RFC5440] and updated in [I-D.ietf-
pce-stateful-pce], it is further updated below for association:
<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.
4.3. Processing Rules
Both a PCC and a PCE can create one or more association groups for an
LSP. But a PCE peer cannot add new members for association group
created by another peer. If a PCC receives a PCUpd or a PCInitiate
message including an ASSOCIATION Object but the sender address does
not match the association source, a PCErr message MUST be sent with
Error-Type = TBD2 (Association Error) and Error-value= 1 (association
source and sender source mismatch in PCUpd). Error handling for
situations such as PCE failures after association groups are created
and other scenarios will be included in future versions of this
draft.
If a PCE peer does not recognize the ASSOCIATION object, it MUST
return a PCErr message with Error-Type "Unknown Object" as described
in [RFC5440]. 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].
Minei, et al. Expires January 3, 2016 [Page 9]
Internet-Draft PCE association group July 2015
5. IANA Considerations
The "PCEP Parameters" registry contains a subregistry "PCEP Objects".
This document request IANA to allocate the values from this registry.
Object-Class Value Name Reference
TBD Association This document
Object-Type
1: IPv4
2: IPv6
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 document
This document defines new Error Type and Error-Value for the
following new error conditions:
Error-Type Meaning Reference
TBD Error-Value=1: association source and This document
sender source does not match
6. 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.
7. Acknowledgements
We would like to thank Yuji Kamite and Joshua George for their
contributions to this document. Also Thank Venugopal Reddy for his
useful comments to this draft.
Minei, et al. Expires January 3, 2016 [Page 10]
Internet-Draft PCE association group July 2015
8. Contributors
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
Email: dhruv.ietf@gmail.com
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-04 (work in
progress), April 2015.
[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-11 (work in progress),
April 2015.
[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.
Minei, et al. Expires January 3, 2016 [Page 11]
Internet-Draft PCE association group July 2015
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
Authors' Addresses
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: inaminei@google.com
Edward Crabbe
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
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 January 3, 2016 [Page 12]
Internet-Draft PCE association group July 2015
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 January 3, 2016 [Page 13]