PCE Working Group Xian Zhang
Internet-Draft Young Lee
Intended status: Standards Track Fatai Zhang
Huawei
Ramon Casellas
CTTC
Oscar Gonzalez de Dios
Telefonica I+D
Zafar Ali
Cisco Systems
Expires: November 11, 2017 May 11, 2017
Path Computation Element (PCE) Protocol Extensions for Stateful PCE
Usage in GMPLS-controlled Networks
draft-ietf-pce-pcep-stateful-pce-gmpls-05.txt
Abstract
The Path Computation Element (PCE) facilitates Traffic Engineering
(TE) based path calculation in large, multi-domain, multi-region, or
multi-layer networks. The PCE communication Protocol (PCEP) has been
extended to support stateful PCE functions where the PCE retains
information about the paths already present in the network, but
those extensions are technology-agnostic. This memo provides
extensions required for PCEP so as to enable the usage of a stateful
PCE capability in GMPLS-controlled networks.
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
Zhang et al Expires November 2017 [Page 1]
Internet-Draft Stateful PCEP for GMPLS May 2017
as reference material or to cite them other than as "work in
progress."
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 November 11, 2017.
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.
Conventions used in this document
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 RFC-2119 [RFC2119].
Table of Contents
Table of Contents.................................................2
1. Introduction...................................................3
2. PCEP Extensions................................................3
2.1. Overview of Requirements..................................3
2.2. LSP Delegation in GMPLS-controlled Networks...............4
2.3. LSP Synchronization in GMPLS-controlled Networks..........5
2.4. Modification of Existing PCEP Messages and Procedures.....6
2.4.1. Modification for LSP Re-optimization.................6
2.4.2. Modification for Route Exclusion.....................7
2.5. Object Encoding...........................................8
3. IANA Considerations............................................8
Zhang et al Expires November 2017 [Page 2]
Internet-Draft Stateful PCEP for GMPLS May 2017
3.1. New PCEP Error Codes......................................8
3.2. New Subobject for the Exclude Route Object................9
4. Manageability Considerations...................................9
4.1. Requirements on Other Protocols and Functional Components.9
5. Security Considerations........................................9
6. Acknowledgement...............................................10
7. References....................................................10
7.1. Normative References.....................................10
7.2. Informative References...................................10
8. Contributors' Address.........................................11
Authors' Addresses...............................................12
1. Introduction
[RFC4655] presents the architecture of a Path Computation Element
(PCE)-based model for computing Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering Label Switched
Paths (TE LSPs). To perform such a constrained computation, a PCE
stores the network topology (i.e., TE links and nodes) and resource
information (i.e., TE attributes) in its TE Database (TED). Such a
PCE is usually referred as a stateless PCE. To request path
computation services to a PCE, [RFC5440] defines the PCE
communication Protocol (PCEP) for interaction between a Path
Computation Client (PCC) and a PCE, or between two PCEs. PCEP as
specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP
extensions needed for GMPLS-controlled networks are provided in
[PCEP-GMPLS].
Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in [RFC8051].
Further discussion of concept of a stateful PCE can be found in
[RFC7399]. In order for these applications to able to exploit the
capability of stateful PCEs, extensions to PCEP are required.
[Stateful-PCE] provides the fundamental extensions needed for
stateful PCE to support general functionality, but leaves out the
specification for technology-specific objects/TLVs. This document
focuses on the extensions that are necessary in order for the
deployment of stateful PCEs in GMPLS-controlled networks.
2. PCEP Extensions
2.1. Overview of Requirements
Zhang et al Expires November 2017 [Page 3]
Internet-Draft Stateful PCEP for GMPLS May 2017
This section notes the main functional requirements for PCEP
extensions to support stateful PCE for use in GMPLS-controlled
networks, based on the description in [RFC8051]. Many
requirements are common across a variety of network types (e.g.,
MPLS-TE networks and GMPLS networks) and the protocol extensions to
meet the requirements are already described in [Stateful-PCE]. This
document does not repeat the description of those protocol
extensions. This document presents protocol extensions for a set of
requirements which are specific to the use of a stateful PCE in a
GMPLS-controlled network.
The basic requirements are as follows:
o Advertisement of the stateful PCE capability. This generic
requirement is covered in Section 5.4. of [Stateful-PCE]. This
document does not provide any further extensions.
o LSP delegation is already covered in Section 5.5. of [Stateful-
PCE]. Section 2.3. of this document provides extension for its
application in GMPLS-controlled networks. Moreover, further
discussion of some generic details that need additional
consideration is provided.
o LSP state synchronization and LSP state report. This is a generic
requirement already covered in Section 5.6. of [Stateful-PCE].
However, there are further extensions required specifically for
GMPLS-controlled networks and discussed in Section 2.4. Reference
to LSPs by identifiers is discussed in Section 5.6. of [Stateful-
PCE]. This feature can be applied to reduce the data carried in
PCEP messages. Use cases and additional Error Codes are necessary,
as described in Section 2.5. of this document.
2.2. LSP Delegation in GMPLS-controlled Networks
[Stateful-PCE] defines the Path Computation LSP Update Request
(PCUpd) message to enable to update the attributes of an LSP.
However, that document does not define technology-specific
parameters.
A key element of the PCUpd message is the attribute-list construct
defined in [RFC5440] and extended by many other PCEP specifications.
For GMPLS purposes we note that the BANDWIDTH object used in the
attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional
TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be
included to indicate technology-specific attributes.
Zhang et al Expires November 2017 [Page 4]
Internet-Draft Stateful PCEP for GMPLS May 2017
LSP parameter update controlled by a stateful PCE in a multi-domain
network is complex and requires well-defined operational procedures
as well as protocol design and is out of scope of this document and
left for further study.
2.3. LSP Synchronization in GMPLS-controlled Networks
PCCs need to report the attributes of LSPs to the PCE to enable
stateful operation of a GMPLS network. This process is known as
LSP state synchronization. The LSP attributes include bandwidth,
associated route, and protection information etc., are stored by the
PCE in the LSP database (LSP-DB). Note that, as described in
[Stateful-PCE], the LSP state synchronization covers both the bulk
reporting of LSPs at initialization as well the reporting of new or
modified LSP during normal operation. Incremental LSP-DB
synchronization may be desired in a GMPLS-controlled network and it
is specified in [Sync-OPT].
[Stateful-PCE] describes mechanisms for LSP synchronization using
the Path Computation State Report (PCRpt) message, but does not
cover reporting of technology-specific attributes. As stated in
[Stateful-PCE], the <path> construct is further composed of a
compulsory ERO object and a compulsory attribute-list and an
optional RRO object. In order to report LSP states in GMPLS networks,
this specification allows the use within a PCRpt message both of
technology- and GMPLS-specific attribute objects and TLVs defined in
[PCEP-GMPLS] as follows:
o Extensions to the ERO, RRO, IRO, and XRO to carry label sub-
objects for SDH/SONET, OTN, and DWDM networks.
o Extended objects to support the inclusion of the label and
unnumbered links.
o END-POINTS (Generalized END-POINTS Object Type)
o BANDWIDTH (Generalized BANDWIDTH Object Type)
o PROTECTION ATTRIBUTE TLV
o IF_ID_ERROR_SPEC (extending [Stateful-PCE] section 7.3.4 that
only considers the use of RSVP ERROR_SPEC)
The END-POINTS object SHOULD be carried within the attribute-list to
specify the endpoints pertaining to the reported LSP. The XRO object
MAY be carried to specify the network resources that the reported
LSP avoids and a PCE SHOULD consider avoid these network resources
during the process of re-optimizing after this LSP is delegated to
Zhang et al Expires November 2017 [Page 5]
Internet-Draft Stateful PCEP for GMPLS May 2017
the PCE. To be more specific, the <attribute-list> is updated as
follows:
<attribute-list> ::= [<END-POINTS>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<XRO>]
<metric-list>::= <METRIC>[<metric-list>]
If the LSP being reported protects another LSP, the PROTECTION-
ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to
describe its attributes and restrictions. Moreover, if the status
of the protecting LSP changes from non-operational to operational,
this SHOULD to be synchronized to the stateful PCE using a PCRpt
message.
2.4. Modification of Existing PCEP Messages and Procedures
One of the advantages mentioned in [RFC8051] is that the stateful
nature of a PCE simplifies the information conveyed in PCEP messages,
notably between PCC and PCE, since it is possible to refer to PCE
managed state for active LSPs. To be more specific, with a stateful
PCE, it is possible to refer to an LSP with a unique identifier in
the scope of the PCC-PCE session and thus use such identifier to
refer to that LSP. Note this MAY also be applicable to packet
networks.
2.4.1. Modification for LSP Re-optimization
The Request Parameters (RP) object on a Path Computation Request
(PCReq) message carries the R bit. When set, this indicates that
the PCC is requesting re-optimization of an existing LSP. Upon
receiving such a PCReq, a stateful PCE SHOULD perform the re-
optimization in the following cases:
- The existing bandwidth and route information of the LSP to be
re-optimized is provided in the PCReq message using the BANDWIDTH
object and the ERO.
- The existing bandwidth and route information is not supplied in
the PCReq message, but can be found in the PCE's LSP-DB. In this
case, the LSP MUST be identified using an LSP identifier carried in
Zhang et al Expires November 2017 [Page 6]
Internet-Draft Stateful PCEP for GMPLS May 2017
the PCReq message, and that fact requires that the LSP identifier
was previously supplied either by the PCC in a PCRpt message or by
the PCE in a PCRep. [Stateful-PCE] defines how this is achieved
using a combination of the per-node LSP identifier (PLSP-ID) and the
PCC's address.
If no LSP state information is available to carry out re-
optimization, the stateful PCE should report the error "LSP state
information unavailable for the LSP re-optimization" (Error Type =
TBD1, Error value= TBD2).
2.4.2. Modification for Route Exclusion
[RFC5521] defines a mechanism for a PCC to request or demand that
specific nodes, links, or other network resources are excluded from
paths computed by a PCE. A PCC may wish to request the computation
of a path that avoids all link and nodes traversed by some other LSP.
To this end this document defines a new sub-object for use with
route exclusion defined in [RFC5521]. The LSP exclusion sub-object
is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Type (TBD3) | Length | Attributes | Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X bit and Attribute fields are defined in [RFC5521].
X bit: indicates whether the exclusion is mandatory (X=1) and
MUST be accommodated, or desired (X=0) and SHOULD be accommodated.
Type: Subobject Type for an LSP exclusion sub-object. Value of
TBD3. To be assigned by IANA.
Length: The Length contains the total length of the subobject in
bytes, including the Type and Length fields.
Attributes: indicates how the exclusion object is to be
interpreted. Currently, Interface (Attributes = 0), Node (Attributes
=1) and SRLG (Attributes =2) are defined in [RFC5521] and this
document does not define new values.
Flags: This field may be used to further specify the exclusion
constraint with regard to the LSP. Currently, no values are defined.
Zhang et al Expires November 2017 [Page 7]
Internet-Draft Stateful PCEP for GMPLS May 2017
PLSP-ID: This is the identifier given to a LSP and is unique in
the context of the PCC address as defined in [Stateful-PCE].
Reserved: MUST be transmitted as zero and SHOULD be ignored on
receipt.
This sub-object is OPTIONAL in the exclude route object (XRO) and
can be present multiple times. When a stateful PCE receives a PCReq
message carrying this sub-object, it SHOULD search for the
identified LSP in its LSP-DB and then exclude it from the new path
computation all resources used by the identified LSP. If the
stateful PCE cannot recognize one or more of the received LSP
identifiers, it should send an error message PCErr reporting "The
LSP state information for route exclusion purpose cannot be found"
(Error-type = TBD1, Error-value = TBD4). Optionally, it may provide
with the unrecognized identifier information to the requesting PCC
using the error reporting techniques described in [RFC5440].
2.5. Object Encoding
Note that, as is stated in Section 7 of [Stateful-PCE], the P flag
and the I flag of the PCEP objects used on PCUpd and PCRpt messages
SHOULD be set to 0 on transmission and SHOULD be ignored on receipt
since these flags are exclusively related to path computation
requests.
3. IANA Considerations
IANA is requested to allocate new Types for the TLV/Object defined
in this document.
3.1. New PCEP Error Codes
IANA is requested to make the following allocation in the "PCEP-
ERROR Object Error Types and Values" registry.
Error Type Meaning Reference
TBD1 LSP state information missing [This.I-D]
Error-value TBD2: LSP state information unavailable [This.I-D]
for the LSP re-optimization
Error-value TBD4: LSP state information for route
exclusion purpose cannot be found [This.I-D]
Zhang et al Expires November 2017 [Page 8]
Internet-Draft Stateful PCEP for GMPLS May 2017
3.2. New Subobject for the Exclude Route Object
IANA maintains the "PCEP Parameters" registry containing a
subregistry called "PCEP Objects". This registry has a subregistry
for the XRO (Exclude Route Object) listing the sub-objects that can
be carried in the XRO. IANA is requested to assign a further sub-
object that can be carried in the XRO as follows:
Value Description Reference
----------+------------------------------+-------------
TBD3 LSP identifier sub-object [This.I-D]
4. Manageability Considerations
The description and functionality specifications presented related
to stateful PCEs should also comply with the manageability
specifications covered in Section 8 of [RFC4655]. Furthermore, a
further list of manageability issues presented in [Stateful-PCE]
should also be considered.
Additional considerations are presented in the next sections.
4.1. Requirements on Other Protocols and Functional Components
When the detailed route information is included for LSP state
synchronization (either at the initial stage or during LSP state
report process), this requires the ingress node of an LSP carry the
RRO object in order to enable the collection of such information.
5. Security Considerations
This draft provides additional extensions to PCEP so as to
facilitate stateful PCE usage in GMPLS-controlled networks, on top
of [Stateful-PCE]. The PCEP extensions to support GMPLS-controlled
networks should be considered under the same security as for MPLS
networks, as noted in [RFC7025]. Therefore, the security
considerations elaborated in [RFC5440] still apply to this draft.
Furthermore, [Stateful-PCE] provides a detailed analysis of the
additional security issues incurred due to the new extensions and
possible solutions needed to support for the new stateful PCE
capabilities and they apply to this document as well.
Zhang et al Expires November 2017 [Page 9]
Internet-Draft Stateful PCEP for GMPLS May 2017
6. Acknowledgement
We would like to thank Adrian Farrel and Cyril Margaria for the
useful comments and discussions.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[Stateful-PCE] Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-pce,
work in progress.
[PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP
extensions for GMPLS", draft-ietf-pce-gmpls-pcep-
extensions, work in progress.
7.2. Informative References
[RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful
Path Computation Element (PCE) ", RFC 8051, January 2017.
[Sync-OPT] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations, work in progress.
Zhang et al Expires November 2017 [Page 10]
Internet-Draft Stateful PCEP for GMPLS May 2017
8. Contributors' Address
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruvd@huawei.com
Yi Lin
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972914
Email: yi.lin@huawei.com
Zhang et al Expires November 2017 [Page 11]
Internet-Draft Stateful PCEP for GMPLS May 2017
Authors' Addresses
Xian Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972645
Email: zhang.xian@huawei.com
Young Lee
Huawei
5340 Legacy Drive, Suite 170
Plano, TX 75023
US
Phone: +1 469 278 5838
EMail: ylee@huawei.com
Fatai Zhang
Huawei
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
P.R. China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Phone:
Email: ramon.casellas@cttc.es
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Zhang et al Expires November 2017 [Page 12]
Internet-Draft Stateful PCEP for GMPLS May 2017
Email: ogondio@tid.es
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Zhang et al Expires November 2017 [Page 13]