PCE Working Group Zafar Ali
Internet Draft Siva Sivabalan
Intended status: Standard Track Clarence Filsfils
Expires: December 29, 2018 Cisco Systems
Robert Varga
Pantheon Technologies
Victor Lopez
Oscar Gonzalez de Dios
Telefonica I+D
Xian Zhang
Huawei
June 30, 2018
Path Computation Element Communication Protocol (PCEP)
Extensions for remote-initiated GMPLS LSP Setup
draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
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 https://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 31, 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
(https://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.
Expires December 2018 [Page 1]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
Abstract
RFC8281 specifies procedures that can be used for creation
and deletion of PCE-initiated LSPs in the active stateful PCE model.
However, this specification focuses on MPLS networks, and does not
cover remote instantiation of paths in GMPLS-controlled networks.
This document complements RFC8281 by addressing the requirements
for remote-initiated GMPLS LSPs.
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
1. Introduction ............................................ 3
2. Requirements for Remote-Initiated GMPLS LSPs ............ 3
3. PCEP Extensions for Remote-Initiated GMPLS LSPs ......... 4
3.1. Generalized Endpoint in LSP Initiate Message ........ 4
3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message. 5
3.3. Protection Attributes in LSP Initiate Message ....... 5
3.4. ERO in LSP Initiate Object .......................... 5
3.4.1. ERO with explicit label control ............... 5
3.4.2. ERO with Path Keys ............................ 6
3.4.3. Switch Layer Object ........................... 6
3.5. LSP delegation and cleanup .......................... 7
4. Security Considerations ................................. 7
5. IANA Considerations ..................................... 7
5.1. PCEP-Error Object ................................... 7
6. Contributing Authors .................................... 7
7. Acknowledgments ......................................... 7
8. References .............................................. 7
8.1. Normative References ................................ 7
8.2. Informative References .............................. 8
Authors Addresses .......................................... 8
Expires December 2018 [Page 2]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
1. Introduction
The Path Computation Element communication Protocol (PCEP)
provides mechanisms for Path Computation Elements (PCEs) to
perform route computations in response to Path Computation
Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP
Setup in a Stateful PCE Model draft [RFC 8231] describes a set
of extensions to PCEP to enable active control of MPLS-TE and
GMPLS network.
[RFC 8281] describes the setup and teardown of PCE-initiated LSPs
under the active stateful PCE model, without the need for local
configuration on the PCC. This enables realization of a dynamic
network that is centrally controlled and deployed. However, this
specification is focused on MPLS networks, and does not cover the
GMPLS networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies).
This document complements [RFC 8281] by addressing the requirements
for remote-initiated GMPLS LSPs. These requirements are covered in
Section 2 of this draft. The PCEP extensions for remote initiated
GMPLS LSPs are specified in Section 3.
2. Requirements for Remote-Initiated GMPLS LSPs
[RFC 8281] specifies procedures
that can be used for creation and deletion of PCE-initiated LSPs
under the active stateful PCE model. However, this specification
does not address GMPLS requirements outlined in the following:
- GMPLS support multiple switching capabilities on per TE link
basis. GMPLS LSP creation requires knowledge of LSP switching
capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used
[RFC3471], [RFC3473].
- GMPLS LSP creation requires knowledge of the encoding type
(e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.)
to be used by the LSP [RFC3471], [RFC3473].
- GMPLS LSP creation requires information of the generalized
payload (G-PID) to be carried by the LSP [RFC3471], [RFC3473].
- GMPLS LSP creation requires specification of data flow
specific traffic parameters (also known as Tspec), which are
technology specific.
- GMPLS also specifics support for asymmetric bandwidth
requests [RFC6387].
Expires December 2018 [Page 3]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
- GMPLS extends the addressing to include unnumbered interface
identifiers, as defined in [RFC3477].
- In some technologies path calculation is tightly coupled with
label selection along the route. For example, path calculation
in a WDM network may include lambda continuity and/ or lambda
feasibility constraints and hence a path computed by the PCE
is associated with a specific lambda (label). Hence, in such
networks, the label information needs to be provided to a PCC
in order for a PCE to initiate GMPLS LSPs under the active
stateful PCE model. I.e., explicit label control may be
required.
- GMPLS specifics protection context for the LSP, as defined in
[RFC4872] and [RFC4873].
3. PCEP Extensions for Remote-Initiated GMPLS LSPs
LSP initiate (PCInitiate) message defined in [RFC 8281] needs to
be extended to include GMPLS specific PCEP objects as follows:
3.1. Generalized Endpoint in LSP Initiate Message
This document does not modify the usage of END-POINTS object for
PCE initiated LSPs as specified in [RFC 8281]. It augments the
usage as specified below.
END-POINTS object has been extended by [I-D. draft-ietf-pce-gmpls-
pcep-extensions] to include a new object type called "Generalized
Endpoint". PCInitiate message sent by a PCE to a PCC to trigger
a GMPLS LSP instantiation SHOULD include the END-POINTS with
Generalized Endpoint object type. Furthermore, the END-POINTS
object MUST contain "label request" TLV. The label request TLV
is used to specify the switching type, encoding type and GPID of
the LSP being instantiated by the PCE.
If the END-POINTS Object of type Generalized Endpoint is missing
the label request TLV, the PCC MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value= TBA
(label request TLV missing).
If the PCC does not support the END-POINTS Object of type
Generalized Endpoint, the PCC MUST send a PCErr message with
Error-type = 3 (Unknown Object), Error-value = 2(unknown object
type).
Expires December 2018 [Page 4]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
The unnumbered endpoint TLV can be used to specify unnumbered
endpoint addresses for the LSP being instantiated by the PCE.
The END-POINTS MAY contain other TLVs defined in [I-D. draft-
ietf-pce-gmpls-pcep-extensions].
3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message
LSP initiate message defined in [RFC 8281] can optionally include
the BANDWIDTH object. However, the following possibilities cannot
be represented in the BANDWIDTH object:
- Asymmetric bandwidth (different bandwidth in forward and
reverse direction), as described in [RFC6387].
- Technology specific GMPLS parameters (e.g., Tspec for
SDH/SONET, G.709, ATM, MEF, etc.) are not supported.
GENERALIZED-BANDWIDTH object has been defined in [I-D. draft-
ietf-pce-gmpls-pcep-extensions] to address the above-mentioned limitation
of the BANDWIDTH object.
This document specifies the use of GENERALIZED-BANDWIDTH object
in PCInitiate message. Specifically, GENERALIZED-BANDWIDTH
object MAY be included in the PCInitiate message. The
GENERALIZED-BANDWIDTH object in PCInitiate message is used to
specify technology specific Tspec and asymmetrical bandwidth
values for the LSP being instantiated by the PCE.
3.3. Protection Attributes in LSP Initiate Message
This document does not modify the usage of LSPA object for PCE
initiated LSPs as specified in [RFC 8281]. It augments the usage of LSPA object in LSP
Initiate Message to carry the end-to-end protection context this
also includes the protection state information.
The LSP Protection Information TLV of LSPA in the PCInitiate
message can be used to specify protection attributes of the LSP
being instantiated by the PCE.
3.4. ERO in LSP Initiate Object
This document does not modify the usage of ERO object for PCE
initiated LSPs as specified in [RFC 8281]. It augments the usage as specified in the
following sections.
3.4.1. ERO with explicit label control
As mentioned earlier, there are technologies and scenarios where
active stateful PCE requires explicit label control in order to
instantiate an LSP.
Explicit label control (ELC) is a procedure supported by RSVP-
TE, where the outgoing label(s) is (are) encoded in the ERO. [I-
D. draft-ietf-pce-gmpls-pcep-extensions] extends the <ERO> object of PCEP
Expires December 2018 [Page 5]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
to include explicit label control. The ELC procedure enables the
PCE to provide such label(s) directly in the path ERO.
The extended ERO object in PCInitiate message can be used to
specify label along with ERO to PCC for the LSP being
instantiated by the active stateful PCE.
3.4.2. ERO with Path Keys
There are many scenarios in packet and optical networks where
the route information of an LSP may not be provided to the PCC
for confidentiality reasons. A multi-domain or multi-layer
network is an example of such networks. Similarly, a GMPLS User-
Network Interface (UNI) [RFC4208] is also an example of such
networks.
In such scenarios, ERO containing the entire route cannot be
provided to PCC (by PCE). Instead, PCE provides an ERO with Path
Keys to the PCC. For example, in the case UNI interface between
the router and the optical nodes, the ERO in the LSP Initiate
Message may be constructed as follows:
- The first hop is a strict hop that provides the egress
interface information at PCC. This interface information is
used to get to a network node that can extend the rest of the
ERO. (Please note that in the cases where the network node is
not directly connected with the PCC, this part of ERO may
consist of multiple hops and may be loose).
- The following(s) hop in the ERO may provide the network node
with the path key [RFC5520] that can be resolved to get the
contents of the route towards the destination.
- There may be further hops but these hops may also be encoded
with the path keys (if needed).
This document does not change encoding or processing roles for
the path keys, which are defined in [RFC5520].
3.4.3. Switch Layer Object
[draft-ietf-pce-inter-layer-ext-07] specifies the SWITCH-LAYER
object which defines and specifies the switching layer (or
layers) in which a path MUST or MUST NOT be established. A
switching layer is expressed as a switching type and encoding
type. [I-D. draft-ietf-pce-gmpls-pcep-extensions], which defines the GMPLS
extensions for PCEP, suggests using the SWITCH-LAYER object.
Thus, SWITCH-LAYER object can be used in the PCInitiate message
Expires December 2018 [Page 6]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
to specify the switching layer (or layers) of the LSP being
remotely initiated.
3.5. LSP delegation and cleanup
LSP delegation and cleanup procedure specified in [I-D. draft-
ietf-pce-gmpls-pcep-extensions] are equally applicable to GMPLS LSPs and
this document does not modify the associated usage.
4. Security Considerations
To be added in future revision of this document.
5. IANA Considerations
5.1. PCEP-Error Object
This document defines the following new Error-Value:
Error-Type Error Value
6 Error-value=TBA: Label Request TLV missing
6. Contributing Authors
Sajal Agarwal
Cisco Systems
Email: sajaagar@cisco.com
7. Acknowledgments
The authors would like to thank George Swallow and Jan Medved
for their comments.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 8281] Crabbe, E., Minei, I.,
Sivabalan, S., Varga, R., "PCEP Extensions for PCE-
initiated LSP Setup in a Stateful PCE Model", RFC 8281,
December 2017.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, September 2009.
Expires December 2018 [Page 7]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
[RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures
for Dynamically Signaled Hierarchical Label Switched
Paths", RFC 6107, February 2011.
8.2. Informative References
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism",
RFC 5520, April 2009.
Authors Addresses
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
Clarence Filsfils
Expires December 2018 [Page 8]
Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt
Cisco Systems
Email: cfilsfil@cisco.com
Robert Varga
Pantheon Technologies
Victor Lopez
Telefonica I+D
Email: vlopez@tid.es
Oscar Gonzalez de Dios
Telefonica I+D
Email: ogondio@tid.es
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Expires December 2018 [Page 9]
