Internet DRAFT - draft-zheng-pce-stateful-pce-inter-domain-lsp
draft-zheng-pce-stateful-pce-inter-domain-lsp
PCE Working Group Xiaoping Zheng
Internet-Draft Nan Hua
Intended status: Standards Track Wangyang Liu
Expires: October 27, 2016 Yinqiu Jia
Yanlong Li
Bingkun Zhou
Tsinghua University
Guoying Zhang
China Academy of Telecom. Research
April 27, 2016
Cooperative Stateful Path Computation Element (PCE)
for Inter-Domain Inter-Vendor PCE-initiated LSP Setup
draft-zheng-pce-stateful-pce-inter-domain-lsp-03.txt
Abstract
A stateful Path Computation Element (PCE) maintains the information
of Label Switched Path (LSP) and resource availability within a
domain. Multiple stateful PCEs are able to provide traffic
engineering inter-domain LSPs through cooperating with each other.
This document introduces the applicability of cooperative stateful
PCE for establishing inter-domain inter-vendor LSPs which are
initiated by PCE.
Requirements Language
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 [RFC2119].
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."
Zheng, et al. Expires October 27, 2016 [Page 1]
Internet-Draft Cooperative Stateful PCE April 2016
This Internet-Draft will expire on October 27, 2016.
Copyright Notice
Copyright (c) 2014 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. Overview of the Stateful PCE ................................ 3
4. Multiple Stateful PCEs Deployment and Operation ............. 4
4.1. Traffic Engineering Database ........................... 5
4.2. Cooperative Inter-domain Path Computation .............. 5
4.3. Cooperative Inter-domain LSP Setup ..................... 6
4.4. Vendor-specific Message Conversion ..................... 6
5. Applicability of Cooperative Stateful PCE ................... 6
5.1. TED initialization ..................................... 6
5.2. PCE-initiated LSP Setup ................................ 7
5.2.1. Inter-domain Inter-vendor LSP Setup Request ....... 7
5.2.2. Inter-domain Path Computation ..................... 7
5.2.3. Inter-domain Path Segmentation .................... 8
5.2.4. Intra-domain LSP Setup Procedure .................. 8
5.2.5. Inter-domain Inter-vendor LSP Setup Response ...... 9
5.3. TED Synchronization .................................... 9
6. Security Considerations .................................... 10
7. IANA Considerations ........................................ 10
8. Acknowledgments ............................................ 10
9. References ................................................. 10
9.1. Normative References .................................. 10
9.2. Informative References ................................ 11
10. Authors' Addresses ........................................ 11
Zheng, et al. Expires October 27, 2016 [Page 2]
Internet-Draft Cooperative Stateful PCE April 2016
1. Introduction
This document describes the setup procedure of PCE-initiated inter-
domain inter-vendor LSPs under the cooperative stateful PCE model,
which is distributed controlled and deployed.
2. Terminology
This document uses the following terms defined in [RFC5440]: PCE.
This document uses the following terms defined in [RFC4655]: TED.
This document uses the following terms defined in [I-D.ietf-pce-
stateful-pce-09]: Stateful PCE.
This document uses the following terms defined in [I-D.ietf-pce-pce-
initiated-lsp-02]: PCE-initiated LSP.
The following terms are defined in this document:
Source-PCE: PCE that covers the source node of LSP request.
Destination-PCE: PCE that covers the destination node of LSP request.
Upstream-PCE: The previous PCE that along the reversed direction of
domain sequence.
Downstream-PCE: The next PCE that along the positive direction of
domain sequence.
3. Overview of the Stateful PCE
[RFC4655] defines a stateful PCE to be one in which the PCE maintains
"strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network."
Stateful pce [I-D.ietf-pce-stateful-pce-09] specifies a set of
extensions to PCEP to enable stateful control of TE LSPs between and
across PCEP sessions in compliance with [RFC4657]. It includes
mechanisms to effect LSP state synchronization between PCCs and PCEs,
delegation of control of LSPs to PCEs, and PCE control of timing and
sequence of path computations within and across PCEP sessions and
focuses on a model where LSPs are configured on the PCC and control
over them is delegated to the PCE.
Zheng, et al. Expires October 27, 2016 [Page 3]
Internet-Draft Cooperative Stateful PCE April 2016
4. Multiple Stateful PCEs Deployment and Operation
Multiple stateful PCEs can be deployed in a distributed way, shown in
Figure 1. Each domain contains a single stateful PCE, which is
responsible for maintaining intra-domain resource information and
controlling intra-domain LSP setup. All the PCEs are mesh-connected
and they may communicate with each other in a Virtual Local Area
Network (VLAN).
The transport devices located in different domains may be supplied by
various vendors and probably own private configuration parameters,
such as IP address, port attribute, signaling protocol, etc.
Therefore, each domain is equipped with a dedicated Interface Adapter
(IA), which can convert different vendor-specific messages into
unified interface messages.
Network Management System (NMS) is a centralized management entity,
which is aware of entire network resources and connected with all the
PCEs. NMS can initiate inter-domain LSP setup request that will be
sent to the source-PCE.
The inter-domain path is computed by a set of distributed PCEs that
collaborate during path computation. The source PCE initiates inter-
domain inter-vendor LSP setup, which is completed through cooperation
between multiple PCEs.
Zheng, et al. Expires October 27, 2016 [Page 4]
Internet-Draft Cooperative Stateful PCE April 2016
+-------+
+----------------+ NMS +------------------+
| +----+--+ |
| | |
+----+---+ | +----+---+
| | | | |
| PCE #1 +----------------------------------+ PCE #3 |
| | | | |
+----+---+ +----+---+ +----+---+
| | | | | |
| +------------+ PCE #2 +------------+ |
| | | |
| +----+---+ |
| | |
+---+---+ +---+---+ +---+---+
| IA #1 | | IA #2 | | IA #3 |
+---+---+ +---+---+ +---+---+
| | |
| | |
+-------+--------+ +-------+--------+ +-------+--------+
| | | | | |
| Domain #1 | | Domain #2 | | Domain #3 |
| (Vendor A) +----+ (Vendor B) +----+ (Vendor C) |
| | | | | |
+----------------+ +----------------+ +----------------+
Figure 1 Cooperative PCEs Deployment
4.1. Traffic Engineering Database
Each PCE may collect local topology and TE information from transport
plane. Besides, in order to complete inter-domain path computation,
each PCE may collect all the inter-domain links and domains
information from a specific management entity, such as Network
Management System (NMS), which has the global visibility of network.
4.2. Cooperative Inter-domain Path Computation
When source-PCE receives an inter-domain path computation request
from NMS, the source-PCE will first determine an optimal domain
sequence and then cooperate with other PCEs to compute an optimal
inter-domain path based on the required constraints. Considering the
TED information asynchronization and inter-domain resource changing
during the cooperative computation procedure, each PCE in the
selected domain sequence may determine a new optimal domain sequence
based on the required constraints. The source-PCE will generate the
full set of strict hops from source node to destination node.
Zheng, et al. Expires October 27, 2016 [Page 5]
Internet-Draft Cooperative Stateful PCE April 2016
4.3. Cooperative Inter-domain LSP Setup
After inter-domain path computation, source-PCE splits the inter-
domain path into multiple independent sub-paths according to the
domain ID of each node. Then, the source-PCE simultaneously sends all
the sub-paths to the relevant PCEs. Each PCE is responsible for its
corresponding intra-domain LSP setup.
The source-PCE asynchronously receives the intra-domain LSP setup
response from all the relevant PCEs. If all the intra-domain LSPs are
successfully established and there are sufficient resources in the
relevant inter-domain links, the inter-domain inter-vendor LSP is
successfully established. Otherwise, the inter-domain inter-vendor
LSP fails to be established.
4.4. Vendor-specific Message Conversion
In order to eliminate the differences in vendor-specific message
formats of various vendors' domains, each domain is equipped with a
dedicated Interface Adapter (IA), which can convert different vendor-
specific messages into unified interface messages.
5. Applicability of Cooperative Stateful PCE
5.1. TED initialization
The Traffic Engineering Database (TED) of PCE includes intra-domain
information and inter-domain information, shown in Figure 2.
In the process of TED initialization, every PCE sends TED request to
the corresponding transport plane, which contains physical nodes and
physical links. Every PCE receives TED response from the transport
plane and stores the intra-domain resource information into its TED.
Meanwhile, every PCE sends TED request to Network Management System
(NMS), which is responsible for maintaining inter-domain links and
all the PCEs in the entire network. Every PCE receives TED response
from NMS and generates a global domain topology for subsequent inter-
domain path computation. The domain topology stored in every PCE
should be the same.
Zheng, et al. Expires October 27, 2016 [Page 6]
Internet-Draft Cooperative Stateful PCE April 2016
Intra-domain TED Inter-domain TED
+------------> +---------+ <------------+
+------------+----+ PCE +---+------------+
| +---------+ |
+---+--+ |
| IA | |
+---+--+ |
| |
| |
+--------+--------+ +-----+----+
| Transport Plane | | NMS |
+-----------------+ +----------+
Figure 2 TED Initialization Procedure
5.2. PCE-initiated LSP Setup
5.2.1. Inter-domain Inter-vendor LSP Setup Request
The inter-domain inter-vendor LSP setup request is initiated through
NMS. The request contains source node information (IP address,
interface ID, timeslot), destination node information (IP address,
interface ID, timeslot), required bandwidth, granularity type,
protection type, and domain sequence. The request is sent to source-
PCE.
5.2.2. Inter-domain Path Computation
+-------------------+
| Domain Topology |
| #1----#2----#3 |
| |
+------X------------+
X
X
+-----X----+ Request +--------------+ Request +-------------+
| PCE #1 | |--------> | PCE #2 | +--------> | PCE #3 |
| (Source) +------------+(Intermediate)+------------+(Destination)|
| | <--------+ | | <--------| | |
+----------+ Response +--------------+ Response +-------------+
Figure 3 Inter-domain Path Computation Procedure
In the inter-domain path computation procedure (shown in Figure 3),
source-PCE computes an optimal domain sequence according to global
domain topology. The domain sequence is an ordered list which
contains domain IDs from source-domain to destination-domain.
Zheng, et al. Expires October 27, 2016 [Page 7]
Internet-Draft Cooperative Stateful PCE April 2016
Source-PCE forwards the path computation request to downstream-PCE
according to the domain sequence. The downstream-PCE keeps on
forwarding the path computation request to its downstream-PCE until
the request is arrived at destination-PCE.
Considering both the constraint requirements of request and local TED
information, destination-PCE computes many candidate paths from local
ingress border nodes to destination node. The path computation
response (including the candidate paths) are sent to upstream-PCE
according to the reversed domain sequence. If the upstream-PCE finds
resource in any inter-domain link of the selected domain sequence is
fully used, the upstream-PCE may determine a new optimal domain
sequence including all the downstream-PCEs, based on the current TED
information. The upstream-PCE generates an integrated topology
including local physical topology, inter-domain links and the
candidate paths derived from the downstream-PCE. The upstream-PCE
computes many candidate paths from local ingress border nodes to
destination node in the new integrated topology. The path computation
response (including the candidate paths) and new domain sequence (if
changed) are sent to its upstream-PCE. The above process is repeated
until the path computation response is sent to source-PCE. Finally,
the source PCE selects an optimal inter-domain path.
5.2.3. Inter-domain Path Segmentation
The source-PCE splits the inter-domain path into multiple independent
sub-paths according to domain ID. Different sub-path belongs to
different domain.
5.2.4. Intra-domain LSP Setup Procedure
In Figure 4, the source-PCE simultaneously sends all the sub-paths to
the relevant PCEs. Each PCE is responsible for its corresponding
intra-domain LSP setup. In the intra-domain LSP setup procedure, PCE
sends intra-domain LSP setup request to local Interface Adapter (IA).
IA converts the LSP setup request into vendor-specific message and
then sends the message to transport plane. IA receives LSP setup
response from transport plane and converts it into a unified message.
PCE receives intra-domain LSP setup response from IA and the intra-
domain LSP setup procedure is finished.
Zheng, et al. Expires October 27, 2016 [Page 8]
Internet-Draft Cooperative Stateful PCE April 2016
Response
+--------> +-------+
+--+--------+----+ NMS +------------------+
| +----+--+ |
| | |
+----+---+ Request | +----+---+
| | +--------> | | |
| PCE #1 +----------------------------------+ PCE #3 |
| | <--------+ | | |
+----+---+ Response | +----+---+
| | Request +----+---+ | |
+^ | | +--------> | | | | +^
|| | +------------+ PCE #2 +------------+ | ||
|| | <--------+ | | | ||
v+ | Response +----+---+ +^ | v+
| | || |
+---+---+ +---+---+ || +---+---+
| IA #1 | | IA #2 | v+ | IA #3 |
+---+---+ +---+---+ +---+---+
| | |
+-------+--------+ +-------+--------+ +-------+--------+
| | | | | |
| Domain #1 | | Domain #2 | | Domain #3 |
| (Vendor A) +----+ (Vendor B) +----+ (Vendor C) |
| | | | | |
+----------------+ +----------------+ +----------------+
Figure 4 Inter-domain Inter-vendor LSP Setup Procedure
5.2.5. Inter-domain Inter-vendor LSP Setup Response
The source-PCE asynchronously receives the intra-domain LSP setup
response from all the relevant PCEs. If all the intra-domain LSPs are
successfully established and there are sufficient resources in the
relevant inter-domain links, the inter-domain inter-vendor LSP is
successfully established. Otherwise, the inter-domain inter-vendor
LSP fails to be established.
5.3. TED Synchronization
In order to avoid resource conflicts, the TED stored in every PCE
must be updated in time. Once an inter-domain inter-vendor LSP is
successfully established, the modification of network resources must
be announced to all the relevant PCEs.
TED synchronization process includes intra-domain TED synchronization
process and inter-domain TED synchronization process. PCEs that are
Zheng, et al. Expires October 27, 2016 [Page 9]
Internet-Draft Cooperative Stateful PCE April 2016
involved to the inter-domain LSP should synchronize their intra-
domain resources with underlying transport plane. And every PCE
should synchronize inter-domain links to ensure that its global
domain topology is identical to other PCEs.
In the process of intra-domain TED synchronization, source-PCE sends
intra-domain links synchronization requests to the relevant PCEs.
Each relevant PCE synchronizes intra-domain links information with
underlying transport plane through message conversion by local
Interface Adapter (IA).
In the process of inter-domain TED synchronization, source-PCE sends
inter-domain links synchronization requests to all the PCEs. Every
PCE should modifies the information of inter-domain links and updates
its global domain topology for subsequent inter-domain path
computation.
6. Security Considerations
PCEP security is defined [RFC5440]. Any multi-domain operation
necessarily involves the exchange of information across domain
boundaries. This does represent a significant security and
confidentiality risk. PCEP allows individual PCEs to maintain
confidentiality of their domain path information using path-keys
[RFC5520].
For further considerations of the security issues related to inter-
domain path computation, see [RFC5376].
7. IANA Considerations
This document makes no requests for IANA action.
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
9. References
9.1. Normative References
[I-D.ietf-pce-stateful-pce-09]
E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-pce-
09 (work in progress), June 2014.
Zheng, et al. Expires October 27, 2016 [Page 10]
Internet-Draft Cooperative Stateful PCE April 2016
[I-D.ietf-pce-pce-initiated-lsp-02]
E. Crabbe, I. Minei, S. Sivabalan, and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-02 (work in
progress), October 2014.
9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC5376] Bitar, N., et al., "Inter-AS Requirements for the Path
Computation Element Communication Protocol (PCECP)", RFC
5376, November 2008.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A.,
Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path
Computation Element (PCE) Communication Protocol (PCEP)",
RFC 5440, March 2009.
[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.
10. Authors' Addresses
Xiaoping Zheng
Tsinghua University
Beijing 100084
P.R.China
Email: xpzheng@tsinghua.edu.cn
Zheng, et al. Expires October 27, 2016 [Page 11]
Internet-Draft Cooperative Stateful PCE November 2015
Nan Hua
Tsinghua University
Beijing 100084
P.R.China
Email: huan@mail.tsinghua.edu.cn
Wangyang Liu
Tsinghua University
Beijing 100084
P.R.China
Email: liuwy06@mails.tsinghua.edu.cn
Yinqiu Jia
Tsinghua University
Beijing 100084
P.R.China
Email: jiayq13@mails.tsinghua.edu.cn
Yanlong Li
Tsinghua University
Beijing 100084
P.R.China
Email: li-yl14@mails.tsinghua.edu.cn
Bingkun Zhou
Tsinghua University
Beijing 100084
P.R.China
Email: zbk-dee@tsinghua.edu.cn
Guoying Zhang
Research Institute of Telecommunications Transmission (RITT),
China Academy of Telecom. Research (CATR), MIIT
Beijing 100084
P.R.China
Email: zhangguoying@ritt.cn
Zheng, et al. Expires May 2, 2016 [Page 12]
