PCE Working Group Quintin Zhao
Internet-Draft Katherine Zhao
Intended status: Standards Track Robin Li
Expires: April 24, 2014 Huawei Technologies
Zekun Ke
Tencent Holdings Ltd.
October 21, 2013
The User cases for Using PCE as the Central Controller(PCECC) of LSPs
draft-zhao-pce-central-controller-user-cases-00
Abstract
In certain deployment networks deployment scenarios, service
providers would like to keep all the existing MPLS functionalities in
both MPLS and GMPLS network while removing the complexity of existing
signaling protocols such as LDP and RSVP-TE. In this document, we
propose to use the PCE as a central controller so that LSP can be
calculated/signaled/initiated/downloaded through a centralized PCE
server to each network devices along the LSP path while leveraging
the existing PCE technologies as much as possible.
This draft describes the user cases for using the PCE as the central
controller where LSPs are calculated/setup/initiated/downloaded
through extending the existing PCE architectures and extending the PCEP.
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 April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhao, et al. Expires April 24, 2014 [Page 1]
Internet-Draft PCECC October 2013
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
1.1. Using the PCE as the Central Controller (PCECC)
Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. MPLS Label Resource Reservation through PCECCP . . . . . . 5
1.3. Using PCECCP to Distribute the LSP Forwarding Entry
from PCECC server to each PCECC clients . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4. User Cases for PCECC's Label Resource Reservations . . . . . . 7
5. User Cases for PCECC for LSP Setup in the New PCECC
Enabled Network . . . . . . . . . . . . . . . . . . . . . . . 8
6. User Cases for PCECC for LSP Setup in the Network Migration . 8
7. Using Extended PCEP to download LSP infor for Each Network
Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. The Considerations for PCECC Procedure and PCEP extensions . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Zhao, et al. Expires April 24, 2014 [Page 2]
Internet-Draft PCECC October 2013
1. Introduction
In certain network deployment scenarios, service providers would like
to have the ability to dynamically adapt to a wide range of
customer's requests for the sake of flexible network service
delivery, SDN has provides additional flexibility in how the network
is operated comparing the traditional network.
The existing networking ecosystem has become awfully complex and
highly demanding in terms of robustness, performance, scalability,
flexibility, agility, etc. By migrating to the SDN enabled network
from the existing network, service providers and network operators
must have a solution which they can evolve easily from the existing
network into the SDN enabled network while keeping the network
services remain scalable, guarantee robustness and availability etc.
Taking the smooth transition between traditional network and the new
SDN enabled network into account, especially from a cost impact
assessment perspective, using the existing PCE components from the
current network to function as the central controller of the SDN
network is one choice, which not only achives the goal of having a
centralized controller to provide the functionalities needed for the
central controller, but also leverages the existing PCE network
components.
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 MPLS network that is centrally controlled and deployed.
[I-D.draft-ali-pce-remote-initiated-gmpls-lsp-01] complements [I-D.
draft-crabbe-pce-pce-initiated-lsp] by addressing the requirements
for remote-initiated GMPLS LSPs.
SR technology leverages the source routing and tunneling paradigms.
A source node can choose a path without relying on hop-by-hop
signaling protocols such as LDP or RSVP-TE. Each path is specified
as a set of "segments" advertised by link-state routing protocols
(IS-IS or OSPF). [I-D.filsfils-rtgwg-segment-routing] provides an
introduction to SR technology. The corresponding IS-IS and OSPF
Zhao, et al. Expires April 24, 2014 [Page 3]
Internet-Draft PCECC October 2013
extensions are specified in [I-D.previdi-isis-segment-routing-
extensions] and [I-D.psenak-ospf-segment-routing-extensions],
respectively.
A Segment Routed path (SR path) can be derived from an IGP Shortest
Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE
paths) may not follow IGP SPT. Such paths may be chosen by a
suitable network planning tool and provisioned on the source node of
the SR-TE path.
It is possible to use a stateful PCE for computing one or more SR-TE
paths taking into account various constraints and objective
functions. Once a path is chosen, the stateful PCE can instantiate
an SR-TE path on a PCC using PCEP extensions specified in
[I-D.crabbe-pce-pce-initiated-lsp] using the SR specific PCEP
extensions described in [I-D.draft-sivabalan-pce-segment-routing].
By using the solutions provided from above drafts, LSP in both MPLS
and GMPLS network can be setup/delete/maintained/synchronized through
a centrally controlled dynamic MPLS network. Since in these
solutions, the LSP is need to be signaled through the head end LER to
the tail end LER, there are either RSVP-TE signaling protocol need to
be deployed in the MPLS/GMPLS network, or extend TGP protocol with
node/adjacency segment identifiers signaling capability to be
deployed.
The PCECC solution proposed in this document allow for a dynamic MPLS
network that is eventually controlled and deployed without the
deployment of RSVP-TE protocol or extended IGP protocol with node/
adjacency segment identifiers signaling capability while providing
all the key MPLS functionalities needed by the service providers. In
the case that one LSP path consists legacy network nodes and the new
network nodes which are centrally controlled, the PCECC solution
provides a smooth transition step for users.
1.1. Using the PCE as the Central Controller (PCECC) Approach
With PCECC, it not only removes the existing MPLS signaling totally
from the control plane without losing any existing MPLS
functionalities, but also PCECC achives this goal through utilizing
the existing PCEP without introducing a new protocol into the
network.
The following diagram illustrates the PCECC architecture.
Zhao, et al. Expires April 24, 2014 [Page 4]
Internet-Draft PCECC October 2013
+------------------------------------------------------------------+
| PCECC |
| +-----------------------------------------------------+ |
| | LSP-Database RSVP-TE Signal Control Module | |
| | TE-Database LDP signaling Control Module | |
| | Label-Database LSP/label/TE MGRs | |
| +-----------------------------------------------------+ |
| ^ ^ ^ ^ ^ |
| IGP|LDP/RSVP-TE |PCEP |PCEP PCEP| IGP|LDP/RSVP-TE|
| |PCEP | | | |PCEP |
| V V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
| | |...| |...| |...| |...| | |
| | Legacy |IGP| |IGP| |IGP| PCC4 |IGP| Legacy | |
| | Node | | | | | | | | Node | |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+
Through the draft, we call the combination of the functionality for
global label range signaling and the functionality of LSP setup/
download/cleanup using the combination of global labels and local
labels as PCECC functionality.
1.2. MPLS Label Resource Reservation through PCECCP
Current MPLS label has local meaning. That is, MPLS label allocated
locally and signaled through the LDP/RSVP-TE/BGP etc dynamic
signaling protocol.
As the SDN(Service-Driven Network) technology develops, MPLS global
label has been proposed again for new solutions. [I-D.li-mpls-
global-label-usecases] proposes possible usecases of MPLS global
label. MPLS global label can be used for identification of the
location, the service and the network in different application
scenarios. From these usecases we can see that no matter SDN or
traditional application scenarios, the new solutions based on MPLS
global label can gain advantage over the existing solutions to
facilitate service provisions.
To ease the label allocation and signaling mechanism, also with the
new applications such as concentrated LSP controller is introduced,
PCE can be conveniently used as a central controller and MPLS global
label range negotiator.
The later section of this draft describes the user cases for PCE
Zhao, et al. Expires April 24, 2014 [Page 5]
Internet-Draft PCECC October 2013
server and PCE clients to have the global label range negotiation and
local label range negotiation functionality.
1.3. Using PCECCP to Distribute the LSP Forwarding Entry from PCECC
server to each PCECC clients
To empower networking with centralized controllable modules, there
are many choices for downloading the forwarding entries to the data
plane, one way is the use of the OpenFlow protocol, which helps
devices populate their forwarding tables according to a set of
instructions to the data plane. There are other andidate protocols
to convey specific configuration information towards devices also.
Since the PCEP protocol is already deployed in some of the service
network, to leverave the PCEP to populated the MPLS forwarding table
is a possible good choice.
2. Terminology
The following terminology is used in this document.
IGP: Interior Gateway Protocol. Either of the two routing
protocols, Open Shortest Path First (OSPF) or Intermediate System
to Intermediate System (IS-IS).
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
TE: Traffic Engineering.
3. PCEP Requirements
Following key requirements associated PCECC should be considered when
designing the PCECC based solution:
1. Path Computation Element (PCE) clients supporting this draft MUST
have the capability to advertise its PCECC capability to the
PCECC.
2. Path Computation Element (PCE) supporting this draft MUST have
the capability to negotiate a global label range for a group of
clients.
Zhao, et al. Expires April 24, 2014 [Page 6]
Internet-Draft PCECC October 2013
3. Path Computation Client (PCC) MUST be able ask for global label
range assigned in path request message .
4. PCE are not required to support label reserve service.
Therefore, it MUST be possible for a PCE to reject a Path
Computation Request message with a reason code that indicates no
support for label reserve service.
5. PCEP SHOULD provide a means to return global label range and LSP
label assignments of the computed path in the reply message.
6. PCEP SHOULD provide a means to download the MPLS forwarding entry
to the PCECC's clients.
4. User Cases for PCECC's Label Resource Reservations
Example 1 to 3 are based on network configurations illustrated using
the following figure:
+------------------------------+ +------------------------------+
| PCE DOMAIN 1 | | PCE DOMAIN 2 |
| +--------+ | | +--------+ |
| | | | | | | |
| | PCECC1 |<------------------------>| PCECC2| |
| | | | | | | |
| | | | | | | |
| +--------+ | | +--------+ |
| ^ ^ | | ^ ^ |
| / \ | | / \ |
| V V | | V V |
| +--------+ +--------+ | | +--------+ +--------+ |
| |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| |
| | | ...... | | | | | | ...... | | |
| | PCECC | | PCECC | | | | PCECC | |PCECC | |
| |Enabled | | Enabled| | |Enabled | |Enabled | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Example 1: global Label Range Reservation
o Node11 sends a label request message to PCECC1 with global label
reservation range 100 to 1000.
o PCECC1 sends a reply message with global label reservation range
100 to 1000 confirmed to node1, ..., node1n
Zhao, et al. Expires April 24, 2014 [Page 7]
Internet-Draft PCECC October 2013
o PCECC1 sends a indication message with global label reservation
range 100 to 1000 confirmed to PCECC2.
o PCECC2 sends indication messages with global label reservation
range 100 to 1000 confirmed to Node21,..., node2n
5. User Cases for PCECC for LSP Setup in the New PCECC Enabled Network
Example 2: Tunnel Head End Initiated LSP Setup Using Global Label
Range Reserved
o Node1 sends a path request message for LSP setup from Node11 to
Node2n.
o PCE1 sends a indication message LSP setup with [Label(to2n),
Node2n] to Node12, ..., Node1n.
o PCE1 sends a indication message LSP setup with [Label(to2n),
Node2n] to PCE2;
o PCE2 sends a indication message LSP setup with [Label(to2n),
Node2n] to Node22, ..., Node2n.
Example 3: LSP Delete Using global Label Range Reserved
o Node1 sends a path request message for LSP cleanup from Node11 to
Node2n.
o PCE1 sends a indication message LSP cleanup with [Label(to2n),
Node2n] to Node12, ..., Node1n.
o PCE1 sends a indication message LSP cleanup with [Label(to2n),
Node2n] to PCE2;
o PCE2 sends a indication message LSP cleanup with [Label(to2n),
Node2n] to Node22, ..., Node2n.
6. User Cases for PCECC for LSP Setup in the Network Migration
Example 4 is based on network configurations illustrated using the
following figure:
Zhao, et al. Expires April 24, 2014 [Page 8]
Internet-Draft PCECC October 2013
+------------------------------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------------------------+ |
| | PCECC | |
| +-----------------------------------------------------+ |
| ^ ^ ^ ^ |
| |if11 RSVP-TE | if33 if44|RSVP-TE |i55 |
| V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
| | |...| |...| |...| |...| | |
| | Legacy |if1| Legacy |if2|PCCEC |if3| PCECC |if4| Legacy | |
| | Node | | Node | |Enabled | |Enabled | | Node | |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+
Example 4: PCECC Initiated LSP Setup In the Network Migration
In this example, there five nodes for the LSP from head end (node1)
to the tail end (node5). Where the node3 and node4 with the PCECC
capability, and other nodes are legacy nodes.
o Node1 sends a path request message for LSP setup to Node5.
o PCE sends a reply message for LSP setup with path (node1, i1),
(node2, i2), (node-PCECC, if33), (node-PCECC, if55), Nnode5.
o PCE sends an indication message for LSP segment setup with
[Label(toN5), Node5] for node3 to node4.
o Node1, Node2, Node-PCECC, Node-PCECC, Node 5 will setup the LSP to
Node5 normally using the local label as normal. After the LSP is
setup, then the PCECC will program the node 3 and node 4 to
replace the LSP segment from node3-node-pcecc-node5 to node3-
node4-node5.
7. Using Extended PCEP to download LSP infor for Each Network Device
The existing PCEP is used to communicate between the PCE server and
PCE's client PCC for exchanging the path request and reply
information regarding to the LSP info. With minor extensions, we can
use the PCEP to download the complete LSP forwarding entries for each
node in the network.
In the example 4, the LSP segment between node3 and node4 for
destination node5 is setup from PCECC and downloaded into node3 and
Zhao, et al. Expires April 24, 2014 [Page 9]
Internet-Draft PCECC October 2013
node4 directly from PCECC through the extended PCEP.
+------------------------------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------------------------+ |
| | PCECC | |
| +-----------------------------------------------------+ |
| PCEP | PCEP| |
| MPLS Forwarding | | MPLS Forwarding |
| Entry Download V V Entry Download |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
| | |...| |...| |...| |...| | |
| | Legacy |if1| Legacy |if2|PCCEC |if3| PCECC |if4| Legacy | |
| | Node | | Node | |Enabled | |Enabled | | Node | |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+
8. The Considerations for PCECC Procedure and PCEP extensions
The PCECC's procedures and PCEP extensions will be defined in a
separate document.
9. Acknowledgments
We would like to thank Robert Tao, Changjing Yan, Tieying Huang for
their useful comments and suggestions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key
words for use in RFCs
to Indicate
Requirement Levels",
BCP 14, RFC 2119,
March 1997.
[RFC5440] Vasseur, JP. and JL.
Le Roux, "Path
Computation Element
(PCE) Communication
Protocol (PCEP)",
RFC 5440, March 2009.
Zhao, et al. Expires April 24, 2014 [Page 10]
Internet-Draft PCECC October 2013
10.2. Informative References
[RFC5441] Vasseur, JP., Zhang,
R., Bitar, N., and JL.
Le Roux, "A Backward-
Recursive PCE-Based
Computation (BRPC)
Procedure to Compute
Shortest Constrained
Inter-Domain Traffic
Engineering Label
Switched Paths",
RFC 5441, April 2009.
[RFC5541] Le Roux, JL., Vasseur,
JP., and Y. Lee,
"Encoding of Objective
Functions in the Path
Computation Element
Communication Protocol
(PCEP)", RFC 5541,
June 2009.
[I-D.ietf-pce-stateful-pce] Crabbe, E., Medved,
J., Minei, I., and R.
Varga, "PCEP
Extensions for
Stateful PCE", draft-
ietf-pce-stateful-pce-
07 (work in progress),
October 2013.
[I-D.crabbe-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-crabbe-pce-pce-
initiated-lsp-03 (work
in progress),
October 2013.
[I-D.ali-pce-remote-initiated-gmpls-lsp] Ali, Z., Sivabalan,
S., Filsfils, C.,
Varga, R., Lopez, V.,
and O. Dios, "Path
Computation Element
Zhao, et al. Expires April 24, 2014 [Page 11]
Internet-Draft PCECC October 2013
Communication Protocol
(PCEP) Extensions for
remote-initiated GMPLS
LSP Setup", draft-ali-
pce-remote-initiated-
gmpls-lsp-01 (work in
progress), July 2013.
[I-D.previdi-isis-segment-routing-extensions] Previdi, S., Filsfils,
C., Bashandy, A.,
Gredler, H., and S.
Litkowski, "IS-IS
Extensions for Segment
Routing", draft-
previdi-isis-segment-
routing-extensions-03
(work in progress),
October 2013.
[I-D.psenak-ospf-segment-routing-extensions] Psenak, P., Previdi,
S., Filsfils, C.,
Gredler, H., Shakir,
R., and W. Henderickx,
"OSPF Extensions for
Segment Routing", draf
t-psenak-ospf-segment-
routing-extensions-03
(work in progress),
October 2013.
[I-D.sivabalan-pce-segment-routing] Sivabalan, S., Medved,
J., Filsfils, C.,
Crabbe, E., and R.
Raszuk, "PCEP
Extensions for Segment
Routing", draft-
sivabalan-pce-segment-
routing-02 (work in
progress),
October 2013.
[I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., and
T. Yang, "Usecases of
MPLS Global Label", dr
aft-li-mpls-global-
label-usecases-00
(work in progress),
July 2013.
Zhao, et al. Expires April 24, 2014 [Page 12]
Internet-Draft PCECC October 2013
Authors' Addresses
Quintin Zhao
Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
US
EMail: quintin.zhao@huawei.com
Katherine Zhao
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
EMail: Katherine.zhao@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
EMail: lizhenbin@huawei.com
Zekung Ke
Tencent Holdings Ltd.
Shenzhen
China
EMail: kinghe@tencent.com
Zhao, et al. Expires April 24, 2014 [Page 13]