PCE Working Group I. Minei
Internet-Draft Google, Inc.
Intended status: Standards Track E. Crabbe
Expires: March 5, 2018 Individual Contributor
S. Sivabalan
Cisco Systems, Inc.
H. Ananthakrishnan
Packet Design
D. Dhody
Huawei
Y. Tanaka
NTT Communications Corporation
September 1, 2017
PCEP Extensions for Establishing Relationships Between Sets of LSPs
draft-ietf-pce-association-group-04
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 stateful PCE (active and passive modes)
and stateless PCE.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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
Minei, et al. Expires March 5, 2018 [Page 1]
Internet-Draft PCE association group September 2017
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 March 5, 2018.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4
3.3. Operator-configured Association Range . . . . . . . . . . 5
4. Operator-configured Association Range TLV . . . . . . . . . . 5
4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7
5. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . . 7
5.1. Object Definition . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Global Association Source TLV . . . . . . . . . . . . 9
5.1.2. Extended Association ID TLV . . . . . . . . . . . . . 9
5.2. Object Encoding in PCEP messages . . . . . . . . . . . . 10
5.2.1. Stateful PCEP messages . . . . . . . . . . . . . . . 10
5.2.2. Request Message . . . . . . . . . . . . . . . . . . . 12
5.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Association Flags . . . . . . . . . . . . . . . . . . . . 15
6.4. Association Type . . . . . . . . . . . . . . . . . . . . 16
6.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Manageability Considerations . . . . . . . . . . . . . . . . 17
8.1. Control of Function and Policy . . . . . . . . . . . . . 17
8.2. Information and Data Models . . . . . . . . . . . . . . . 17
Minei, et al. Expires March 5, 2018 [Page 2]
Internet-Draft PCE association group September 2017
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 18
8.6. Impact On Network Operations . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 stateful PCE (active and passive modes) and stateless PCE. The
associations could be created dynamically and conveyed to a PCEP peer
within PCEP, or it could be configured by an operator on the PCEP
peers. Refer Section 3.2 for more details.
2. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer.
This document uses the following terms defined in [RFC8051]: Stateful
PCE, Delegation.
This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, LSP State
Report, LSP Update Request.
Minei, et al. Expires March 5, 2018 [Page 3]
Internet-Draft PCE association group September 2017
This document uses the following terms defined in
[I-D.ietf-pce-pce-initiated-lsp]: PCE-initiated LSP, LSP Initiate.
The following term is defined in this document:
Association Timeout Interval: when a PCEP session is terminated, a
PCC waits for this time period before deleting associations created
by the 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 policy, configuration parameters or
behaviors with the request.
Some associations could be created dynamically, such as association
between the working and protections LSPs of a tunnel. Whereas some
association could be created by the operator manually, such as policy
based association, where the LSP could join an operator-configured
existing association.
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.
Some associations could be created dynamically by a PCEP speaker and
the associations (along with the set of LSPs) are conveyed to a PCEP
peer. Whereas, some associations are configured by the operator on
the PCEP peers involved before hand, a PCEP speaker then could ask
for a LSP to join the operator-configured association. Usage of
Minei, et al. Expires March 5, 2018 [Page 4]
Internet-Draft PCE association group September 2017
dynamic and configured is usually dependent on the type of the
association.
For the operator-configured association, the association identifier,
type, as well as the association source IP address is manually
configured by the operator. In case of dynamic association, the
association identifier is allocated dynamically by the PCEP speaker.
The dynamically created association can be reported to the PCEP peer
via the PCEP messages as per the stateful extensions. While the
operator-configured association are known to the PCEP peer before
hand, a PCEP peer could ask for a LSP to join the operator-configured
association via the stateful PCEP messages.
The association are properties of the LSP and thus could be stored in
the LSP state database. The dynamic association exist as long as the
LSP state. In case of PCEP session termination, the LSP state clean
up SHOULD also take care of associations.
Multiple types of associations can exist, each with their own
association identifier 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 association
type.
3.3. Operator-configured Association Range
Some association types are dynamic, some are operator-configured and
some could be both. For the association types that could be dynamic
and operator-configured, it is necessary to configure a range of
association identifiers that are marked for operator-configured
associations to avoid any association identifier clash.
A range of association identifier for each association-type are kept
for the operator-configured associations. Dynamic associations MUST
NOT use the association identifier from this range.
This range needs to be communicated to a PCEP peer in the Open
Message. A new TLV is defined in this specification for this purpose
(Section 4).
4. Operator-configured Association Range TLV
This section defines PCEP extension to support the advertisement of
the Operator-configured Association Range used for an association-
type.
Minei, et al. Expires March 5, 2018 [Page 5]
Internet-Draft PCE association group September 2017
A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association
Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried
within an OPEN object. This way, during PCEP session-setup phase, a
PCEP speaker can advertise to a PCEP peer the Operator-configured
Association Range for an association type.
The PCEP OP-CONF-ASSOC-RANGE TLV is optional. It MAY be carried
within an OPEN object sent by a PCEP speaker in an Open message to a
PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the
PCEP TLV format defined in [RFC5440]. That is, the TLV is composed
of 2 octets for the type, 2 octets specifying the TLV length, and a
Value field. The Length field defines the length of the value
portion in octets.
The PCEP OP-CONF-ASSOC-RANGE TLV has the following format:
TYPE: TBD
LENGTH: N * 8 (where N is the number of association types)
VALUE:
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 | Assoc-type #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Assoc-ID #1 | Range #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Assoc-type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Assoc-ID #N | Range #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The OP-CONF-ASSOC-RANGE TLV format
The Value portion includes the following fields, repeated for each
association type:
Reserved (2 bytes): This field MUST be set to 0 on transmission
and MUST be ignored on receipt.
Assoc-type (2 bytes): The association type.
Minei, et al. Expires March 5, 2018 [Page 6]
Internet-Draft PCE association group September 2017
Start-Assoc-ID (2 bytes): The start association identifier for the
Operator-configured Association Range for the particular
association type.
Range (2 bytes): The number of associations marked for the
Operator-configured Associations.
4.1. Procedure
A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN
object in an Open message sent to a PCEP peer in order to advertise
the Operator-configured Association Range for an association type.
The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN
object. If it appears more than once, the PCEP session MUST be
rejected with error type 1 and error value 1 (PCEP session
establishment failure / Reception of an invalid Open message).
As specified in [RFC5440], a PCEP peer that does not recognize the
OP-CONF-ASSOC-RANGE TLV will silently ignore it.
The Operator-configured Association Range SHOULD be included for each
association type that could be both dynamic and operator-configured.
For association types that are only dynamic or only operator-
configured, this TLV can be skipped, in which case the full range of
association identifier is considered dynamic or operator-configured
respectively. Each association type (that are defined in separate
documents) can specify the default value for the operator-configured
association range for their respective association type.
The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be
interpreted as an absence of explicit Operator-configured Association
Range at the PCEP peer. In which case, the default behavior as per
each association type would be applied.
5. ASSOCIATION Object
5.1. Object Definition
Association groups and their memberships are defined using a new
ASSOCIATION object.
ASSOCIATION Object-Class is to be assigned by IANA (TBD).
ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in
Figure 2:
Minei, et al. Expires March 5, 2018 [Page 7]
Internet-Draft PCE association group September 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 | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The IPv4 ASSOCIATION Object format
ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in
Figure 3:
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 | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The IPv6 ASSOCIATION Object format
Reserved (2-byte): MUST be set to 0 and ignored upon receipt.
Flags (2-byte): 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. This flag is used
for ASSOCIATION object in PCRpt and PCUpd message, the flag is
ignored in other PCEP messages.
Association type (2-byte): the association type (for example
protection). The association type are defined in separate documents.
Minei, et al. Expires March 5, 2018 [Page 8]
Internet-Draft PCE association group September 2017
Association ID (2-byte): the identifier of the association group.
When combined with Type and Association Source, this value uniquely
identifies an association group. The value 0xffff and 0x0 are
reserved. The value 0xffff is used to indicate all association
groups.
Association Source: 4 or 16 bytes - An IPv4 or IPv6 address. This
could be the IP address of the PCEP speaker that created a dynamic
association, an operator configured IP address, or an IP address
selected as per the local policy. The value such as 0.0.0.0 or
::/128 are acceptable.
Optional TLVs: The optional TLVs follow the PCEP TLV format of
[RFC5440]. This document defines two optional TLVs. Other documents
can define more TLVs.
5.1.1. Global Association Source TLV
The Global Association Source TLV is an optional TLV for use in the
Association Object.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Global Association Source TLV format
Type: To be allocated by IANA.
Length: Fixed value of 4 bytes.
Global Association Source: as defined in [RFC6780].
5.1.2. Extended Association ID TLV
The Extended Association ID TLV is an optional TLV for use in the
Association Object.
Minei, et al. Expires March 5, 2018 [Page 9]
Internet-Draft PCE association group September 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Association ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Extended Association ID TLV format
Type: To be allocated by IANA.
Length: variable.
Extended Association ID: as defined in [RFC6780].
5.2. Object Encoding in PCEP messages
5.2.1. Stateful 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 (PCInitiate) 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 in the ASSOCIATION object. Unless,
a PCE wants to delete an association from an LSP, it does not need to
carry the ASSOCIATION object in future messages.
The PCRpt message is defined in [I-D.ietf-pce-stateful-pce] and
updated as below:
Minei, et al. Expires March 5, 2018 [Page 10]
Internet-Draft PCE association group September 2017
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
[<association-list>]
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<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. A stateful PCE can also
remove a delegated LSP from one or more association groups by setting
the R flag to 1 in the ASSOCIATION object.
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:
<path>::= <intended-path><intended-attribute-list>
<association-list> ::= <ASSOCIATION> [<association-list>]
A PCE initiating a new LSP, can include the association group
information. This is done by including the ASSOCIATION Object in a
PCInitiate message. The PCInitiate message is defined in
[I-D.ietf-pce-pce-initiated-lsp] and updated as below:
Minei, et al. Expires March 5, 2018 [Page 11]
Internet-Draft PCE association group September 2017
<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>]
5.2.2. Request Message
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 (and the other LSPs) should be known to the PCE before
hand. These could be operator-configured or dynamically learned
before. The R flag in ASSOCIATION object within PCReq message MUST
be set to 0 while sending and ignored on receipt.
The PCReq message is defined in [RFC5440] and updated in [I-D.ietf-
pce-stateful-pce], it is further updated below for association:
Minei, et al. Expires March 5, 2018 [Page 12]
Internet-Draft PCE association group September 2017
<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
mode.
5.3. Processing Rules
Association groups can be operator-configured on the necessary PCC
and PCE. In addition, a PCC or a PCE can create association groups
dynamically. The PCEP speaker can reports the association to its
peer via PCEP messages. If a PCEP speaker does not recognize the
ASSOCIATION object, it will return a PCErr message with Error-Type
"Unknown Object" as described in [RFC5440]. If a PCEP speaker
understand the ASSOCIATION object but does not support the
association-type, it MUST return a PCErr message with Error-Type TBD
"Association Error" and Error-Value 1 "Association-type is not
supported". On receiving a PCEP message with ASSOCIATION, if a PCEP
speaker finds that too many LSPs belong to the association group, it
MUST return a PCErr message with Error-Type TBD "Association Error"
and Error-Value 2 "Too many LSPs in the association group". If a
PCEP speaker cannot handle a new associations, it MUST return a PCErr
message with Error-Type TBD "Association Error" and Error-Value 3
"Too many association groups". These number MAY be set by operator
or decided based on a local policy.
If a PCE speaker receives ASSOCIATION in PCReq message, and the
association information is not known (association is not configured,
or created dynamically, or learned from a PCEP peer), it MUST return
Minei, et al. Expires March 5, 2018 [Page 13]
Internet-Draft PCE association group September 2017
a PCErr message with Error-Type TBD "Association Error" and Error-
Value 4 "Association unknown". If the association information
received from the peer does not match with the local operator
configured information, it MUST return a PCErr message with Error-
Type TBD "Association Error" and Error-Value 5 "Operator-configured
association information mismatch". On receiving association
information that does not match with the association information
previously received about the same association from a peer, it MUST
return a PCErr message with Error-Type TBD "Association Error" and
Error-Value 6 "Association information mismatch". 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]. On receiving a PCEP
message with ASSOCIATION, if a PCEP speaker could not add the LSP to
the association group for any reason, it MUST return a PCErr message
with Error-Type TBD "Association Error" and Error-Value 7 "Cannot
join the association group".
The association information is cleared along with the LSP state
information as per the [I-D.ietf-pce-stateful-pce]. When a PCEP
session is terminated, after expiry of State Timeout Interval at PCC,
the LSP state associated with that PCEP session is reverted to
operator-defined default parameters or behaviors. Same procedure is
also followed for the association information. On session
termination at the PCE, when the LSP state reported by PCC is
cleared, the association information is also cleared. Where there
are no LSPs in a association group, the association is considered to
be deleted.
In case the LSP is delegated to another PCE on session failure, the
association information set by the PCE remains intact, unless updated
by the new PCE.
Upon LSP delegation revocation, the PCC MAY clear the association
created by the PCE, but in order to avoid traffic loss, it can
perform this in a make-before-break fashion, which is the same as
what is defined in [I-D.ietf-pce-stateful-pce] for handling LSP state
cleanup.
If a PCE speaker receives ASSOCIATION object with R bit set for
removal, and the association information is not known, it MUST return
a PCErr message with Error-Type TBD "Association Error" and Error-
Value 4 "Association unknown".
Minei, et al. Expires March 5, 2018 [Page 14]
Internet-Draft PCE association group September 2017
6. IANA Considerations
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry at <http://www.iana.org/assignments/pcep>.
6.1. PCEP Object
The "PCEP Numbers" registry contains a subregistry "PCEP Objects".
This document request IANA to allocate code points from this
registry.
Object-Class Value Name Reference
TBD Association [This I-D]
Object-Type
0: Reserved
1: IPv4
2: IPv6
6.2. PCEP TLV
IANA is requested to make the assignment of the new code points for
the existing "PCEP TLV Type Indicators" registry as follows:
Value Meaning Reference
TBD Operator-configured [This I-D]
Association Range
TBD Global Association Source [This I-D]
TBD Extended Association Id [This I-D]
6.3. Association Flags
This document requests IANA to create a subregistry of the "PCEP
Numbers" for the bits carried in the Flags field of the ASSOCIATION
object. The subregistry is called "ASSOCIATION Flags Field". New
values are assigned by Standards Action [RFC8126]. 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
Bit Description Reference
15 R (Removal) [This I-D]
Minei, et al. Expires March 5, 2018 [Page 15]
Internet-Draft PCE association group September 2017
6.4. Association Type
This document requests IANA to create a subregistry of the "PCEP
Numbers" for the Association Type field of the the ASSOCIATION
object. The subregistry is called "ASSOCIATION Type Field". New
values are to be assigned by Standards Action [RFC8126]. Each value
should be tracked with the following qualities:
o Type
o Name
o Reference
There are no association type specified in this document, future
document should request the assignment of association types from this
subregistry.
6.5. PCEP-Error Object
IANA is requested to allocate new error values within the "PCEP-ERROR
Object Error Types and Values" sub-registry of the "PCEP Numbers"
registry, as follows:
Error-Type Meaning
TBD Association Error [This I-D]
Error-value=1:
Association-type is not supported
Error-value=2:
Too many LSPs in the association group
Error-value=3:
Too many association groups
Error-value=4:
Association unknown
Error-value=5:
Operator-configured association
information mismatch
Error-value=6:
Association information mismatch
Error-value=7:
Cannot join the association group
Minei, et al. Expires March 5, 2018 [Page 16]
Internet-Draft PCE association group September 2017
7. Security Considerations
The security considerations described in [I-D.ietf-pce-stateful-pce]
and [RFC5440] apply to the extensions described in this document as
well. Additional considerations related to a malicious PCEP speaker
are introduced, as associations could be spoofed and could be used as
an attack vector. An attacker could report too many associations in
an attempt to load the PCEP peer. The PCEP peer responds with PCErr
as described in Section 5.3. An attacker could impact LSP operations
by creating bogus associations. Further, association information
could provides an adversary with the opportunity to eavesdrop on the
relationship between the LSPs. Thus securing the PCEP session using
Transport Layer Security (TLS) [I-D.ietf-pce-pceps], as per the
recommendations and best current practices in [RFC7525], is
RECOMMENDED.
8. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440]
and [I-D.ietf-pce-stateful-pce] apply to PCEP protocol extensions
defined in this document. In addition, requirements and
considerations listed in this section apply.
8.1. Control of Function and Policy
A PCE or PCC implementation MUST allow operator-configured
associations as described in this document. The identifier MUST be
from the operator-configured identifier range Section 3.3.
8.2. Information and Data Models
An implementation SHOULD allow the operator to view the associations
configured or created dynamically. Further implementation SHOULD
allow to view associations reported by each peer, and the current set
of LSPs in the association . To serve this purpose, the PCEP YANG
module [I-D.ietf-pce-pcep-yang] can be extended to include
association information.
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].
Minei, et al. Expires March 5, 2018 [Page 17]
Internet-Draft PCE association group September 2017
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] and [I-D.ietf-pce-stateful-pce].
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 [RFC5440] and [I-D.ietf-pce-stateful-pce] also
apply to PCEP extensions defined in this document.
9. Acknowledgements
We would like to thank Yuji Kamite and Joshua George for their
contributions to this document. Also thanks to Venugopal Reddy,
Cyril Margaria and Rakesh Gandhi for their useful comments.
10. Contributors
Stephane Litkowski
Orange
Email: stephane.litkowski@orange.com
Xian Zhang
Huawei Technologies
F3-1-B RnD Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
China
Email: zhang.xian@huawei.com
Mustapha Aissaoui
Nokia
Email: mustapha.aissaoui@nokia.com
Minei, et al. Expires March 5, 2018 [Page 18]
Internet-Draft PCE association group September 2017
11. References
11.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, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, <https://www.rfc-
editor.org/info/rfc5440>.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
ASSOCIATION Object Extensions", RFC 6780,
DOI 10.17487/RFC6780, October 2012, <https://www.rfc-
editor.org/info/rfc6780>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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-21 (work in progress), June 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-10 (work in
progress), June 2017.
11.2. Informative References
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
Minei, et al. Expires March 5, 2018 [Page 19]
Internet-Draft PCE association group September 2017
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, <https://www.rfc-
editor.org/info/rfc8051>.
[I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-16 (work in
progress), August 2017.
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)",
draft-ietf-pce-pcep-yang-05 (work in progress), June 2017.
Authors' Addresses
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: inaminei@google.com
Edward Crabbe
Individual Contributor
Email: edward.crabbe@gmail.com
Siva Sivabalan
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
Email: msiva@cisco.com
Minei, et al. Expires March 5, 2018 [Page 20]
Internet-Draft PCE association group September 2017
Hariharan Ananthakrishnan
Packet Design
Email: hari@packetdesign.com
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, KA 560066
India
Email: dhruv.ietf@gmail.com
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 March 5, 2018 [Page 21]
