Internet DRAFT - draft-lopez-pce-use-cases-initiated-pce
draft-lopez-pce-use-cases-initiated-pce
PCE Working Group Victor Lopez
Internet Draft Oscar Gonzalez de Dios
Intended status: Informational Telefonica I+D/GCTO
Expires: September 20, 2016
Zafar Ali
Cisco Systems
Xian Zhangxian
Haomian Zheng
Huawei
March 21, 2016
Use cases for remote-initiated LSPs via Path Computation Element
Communication Protocol (PCEP)
draft-lopez-pce-use-cases-initiated-pce-01.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 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 September 20, 2016.
Copyright Notice
Copyright (c) 2016 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.
Expires September 2016 [Page 1]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Abstract
Thanks to the extensions defined in [I-D. draft-ietf-pce-pce-
initiated-lsp] and [I-D.draft-ietf-pce-remote-initiated-gmpls-lsp],
it is possible to initiate LSP Setup in a Stateful PCE Model for
MPLS and GMPLS scenarios. This document complements previous
documents by providing an explanation of the use cases to use such
PCEP extensions.
This document presents single layer and multi-layer use cases,
where not only the PCE is involved, but also other modules defined
in IETF, such as Virtual Network Topology Manager and Provisioning
Manager.
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. Single-layer provisioning from active stateful PCE . 3
3. Bandwidth-on-demand for multi-layer networks ....... 4
3.1. Higher-layer signaling trigger ................. 5
3.2. NMS-VNTM cooperation model (separated flavor) .. 6
4. Provisioning manager in Application Based Network
Operations (ABNO) ..................................... 8
5. Security Considerations ............................ 8
6. References ......................................... 8
6.1. Normative References ........................... 8
Expires September 2016 [Page 2]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
6.2. Informative References ......................... 9
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 [I-D. draft-ietf-pce-
stateful-pce] describes a set of extensions to PCEP to enable
active control of MPLS-TE and GMPLS tunnels.
[I-D. draft-crabbe-pce-pce-initiated-lsp] describes the setup
and teardown of PCE-initiated LSPs under the active stateful PCE
model, without the need for local configuration on the PCC, thus
allowing for 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).
2. Single-layer provisioning from active stateful PCE
Figure 1 presents a network with MPLS control plane, where a PCE
intends to create a LSP from R1 to R2. The PCE sends a
PCInitiate message to the source router, which can then use
control plane to set up such a connection.
[Please see pdf version]
Figure 1. Single-layer provisioning from active stateful PCE in
a MPLS domain.
Similarly, Figure 2 shows a single-layer topology with optical
nodes with a GMPLS control plane. In this scenario, the active
PCE can dynamically instantiate or delete L0 services between
client interfaces. The reason to create this connections can be
a new network configuration or a re-optimization process.
Expires September 2016 [Page 3]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
[Please see pdf version]
Figure 2. Single-layer provisioning from active stateful PCE in
a GMPLS domain.
PCEs in this scenario can obtain the resources information via
control plane collecting LSAs messages or via Border Gateway
Protocol - Link State (BGP-LS). The request contains, at least
two interfaces, so PCE computes the path and sends a message to
the optical equipment with ERO path information.
3. Bandwidth-on-demand for multi-layer networks
This use case assumes there is a multi-layer network composed by
routers and optical equipments. In this scenario, there is an
entity, which decides it needs extra bandwidth between two
routers. This certain moment a GMPLS LSP connecting both routers
via the optical network can be established on-the-fly. This
entity can be a router, an active stateful PCE or even the
Network Management System (NMS) (with or without human
intervention).
It is important to note that the bandwidth-on-demand interfaces
and spare bandwidth in the optical network could be shared to
cover many under capacity scenarios in the L3 network. For
example, in this use-case, if we assume all interfaces are 10G
and there is 10G of spare bandwidth available in the optical
network, the spare bandwidth in the optical network can be used
to connect any router connected to the optical nodes, depending
on bandwidth demand of the router network. For example, if there
are three routers, it is not known a priori if the demand will
make bandwidth-on-demand interface at R1 to be connected to
bandwidth-on-demand interface at R2 or R3.
Expires September 2016 [Page 4]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
According to [RFC5623], there are four options inter-layer path
control models: (1) PCE-VNTM cooperation, (2) Higher-layer
signaling trigger, (3) NMS-VNTM cooperation model (integrated
flavor) and (4) NMS-VNTM cooperation model (separated flavor).
In all scenarios there is a certain moment when entities are
using an interface to request for path provisioning. In this
document we have selected two use cases in a scenario with
routers and optical equipments to obtain the requirements for
this draft, but it is applicable to all options listed above.
3.1. Higher-layer signaling trigger
Figure 3 depicts a multi-layer network scenario similar to the
presented in section 4.2.2. [RFC5623], with the difference that
PCE is an active stateful PCE [I-D. draft-ietf-pce-stateful-
pce].
[Please see pdf version]
Figure 3. Use case higher-layer signaling trigger.
In this example, O1, O2 and O3 are optical nodes that are
connected with router nodes R1, R2 and R3, respectively. The
network is designed such that the interface between R1-O1, R2-O2
and R3-O3 are setup to provide bandwidth-on-demand via the
optical network.
The example assumes that an active stateful PCE is used for
setting and tearing down bandwidth-on-demand connectivity.
Although the simple use-case assumes a single PCE server (PCE1),
the proposed technique is generalized to cover multiple co-
operating PCE case. Similarly, although the use case assumes
PCE1 only has knowledge of the L3 topology, the proposed
technique is generalized to cover multi-layer PCE case.
The PCE server (PCE1) is assumed to be receiving L3 topology
data. It is also assumed that PCE learns L0 (optical) addresses
Expires September 2016 [Page 5]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
associated with bandwidth-on-demand interfaces R1-O1, R2-O2 and
R3-O3. These addresses are referred by OTE-IP-R1 (optical TE
link R1-O1 address at R1), OTE-IP-R2 (optical TE link R2-O2
address at R2) and OTE-IP-R3 (optical TE link R3-O3 address at
R3), respectively. How PCE learns the optical addresses
associated with the bandwidth-on-demand interfaces is beyond the
scope of this document.
How knowledge of the bandwidth-on-demand interfaces is utilized
by the PCE is exemplified in the following. Suppose an
application requests 8 Gbps from R1 to R2 (recall all interfaces
in Figure 1 are assumed to be 10G). PCE1 satisfies this by
establishing a tunnel using R1-R4-R2 path. PCEP initiated LSP
using techniques specified in [I-D. draft-crabbe-pce-pce-
initiated-lsp] can be used to establish a PSC tunnel using the
R1-R4-R2 path. Now assume another application requests 7 Gbps
service between R1 and R2. This request cannot be satisfied
without establishing a GMPLS tunnel via optical network using
bandwidth-on-demand interfaces. In this case, PCE1 initiates a
GMPLS tunnel using R1-O1-O2-R2 path (this is referred as GMPLS
tunnel1 in the following).
As mentioned earlier, the GMPLS tunnel created on-the-fly to
satisfy bandwidth demand of L3 applications cannot be pre-
provisioned in IP network, as bandwidth-on-demand interfaces and
spare bandwidth in the optical network are shared. Furthermore,
in this example, as active stateful PCE is used for managing
PCE-initiated LSP, PCC may not be aware of the intended usage of
the PCE-initiated LSP. Specifically, when the PCE1 initiated
GMPLS tunnel1, PCC does not know the IGP instance whose demand
leads to establishment of the GMPLS tunnel1 and hence does not
know the IGP instance in which the GMPLS tunnel1 needs to be
advertised. Similarly, the PCC does not know IP address that
should be assigned to the GMPLS tunnel1. In the above example,
this IP address is labeled as TUN-IP-R1 (tunnel IP address at
R1). The PCC also does not know if the tunnel needs to be
advertised as forwarding and/ or routing adjacency and/or to be
locally used by the target IGP instance. Similarly, egress node
for GMPLS signaling (R2 node in this example) may not know the
intended usage of the tunnel (tunnel1 in this example). For
example, the R2 node does not know IP address that should be
assigned to the GMPLS tunnel1. In the above example, this IP
address is labeled as TUN-IP-R2 (tunnel IP address at R2).
3.2. NMS-VNTM cooperation model (separated flavor)
Figure 4 depicts NMS-VNTM cooperation model. This is the
separated flavor, because NMS and VNTM are not in the same
location.
A new L3 path is requested from NMS, because there is an
automated process in the NMS or after human intervention. NMS
Expires September 2016 [Page 6]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
does not have information about all network information, so it
consults L3 PCE. For shake of simplicity L3-PCE is used, but any
other multi-layer cooperating PCE model is applicable. In case
that there is enough resource in the L3 network, the L3-PCE
returns a L3 only path. On the other hand, if there is a lack of
resources at the L3 layer, the response does not have any path
or may contain a multilayer path with L3 and L0 (optical)
information in case of a ML-PCE. In case of there is not a path
in L3; NMS sends a message to the VNTM to create a GMPLS LSP in
the lower layer. When the VNTM receives this message, based on
the local policies, accepts the suggestion and sends a similar
message to the router, which can create the lower layer LSP via
UNI signaling in the routers, like in use case in section 2.3.1.
Similarly, VNTM may talk with L0-PCE to set-up the path in the
optical domain (section 2.2). This second option looks more
complex, because it requires VNTM configuring inter-layer TE-
links.
Requirements for the message from VNTM to the router are the
same than in the previous use case (section 2.3.1). Regarding
NMS to VNTM message, the requirements here depends on who has
all the information. Three different addresses are required in
this use case: (1) L3, (2) L0 and (3) inter-layer addressing. In
case there is a non-cooperating L3-PCE, information about inter-
layer connections have to be stored (or discovered) by VNTM. If
there is a ML-PCE and this information is obtained from the
network, the message would be the same as the ones in section
Expires September 2016 [Page 7]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
[Please see pdf version]
Figure 4. Use case NMS-VNTM cooperation model
4. Provisioning manager in Application Based Network Operations
(ABNO)
The Provisioning Manager is the unit in charge of configuring
the network elements in the ABNO architecture [I-D. draft-
farrkingel-pce-abno-architecture]. This module receives a
request from the ABNO controller or the active PCE and it can
configure the resources through the data plane or by triggering
a set of actions to the control plane. Therefore, the
provisioning manager can require to translate from PCEP to OF,
CLI or Netconf depending on the protocols supported by the
nodes.
[Please see pdf version]
Figure 5. Provisioning the End-to-End LSP
5. Security Considerations
To be added in future revision of this document.
6. References
6.1. Normative References
[I-D. draft-ietf-pce-stateful-pce] E. Crabbe, I. Minei, J.
Medved, R. Varga "PCEP Extensions for Stateful PCE",
work in progress.
Expires September 2016 [Page 8]
Internet-Draft draft-lopez-pce-use-cases-initiated-pce-01.txt
[I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, I.,
Sivabalan, S., Varga, R., "PCEP Extensions for PCE-
initiated LSP Setup in a Stateful PCE Model", draft-
crabbe-pce-pce-initiated-lsp, work in progress.
[I-D. draft-ietf-pce-remote-initiated-gmpls-lsp] Z. Ali, S.
Sivabalan, C. Filsfils, R. Varga, V. Lopez, O.
Gonzalez de Dios, "Path Computation Element
Communication Protocol (PCEP) Extensions for remote-
initiated GMPLS LSP Setup", draft-ietf-pce-remote-
initiated-gmpls-lsp, wrok in progress.
[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.
[I-D. draft-farrkingel-pce-abno-architecture] D. King, A. Farrel
"A PCE-based Architecture for Application-based
Network Operations", work in progress.
6.2. Informative References
Authors' Addresses
Victor Lopez
Telefonica I+D
Email: vlopez@tid.es
Oscar Gonzalez de Dios
Telefonica I+D
Email: ogondio@tid.es
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Expires September 2016 [Page 9]
