Internet DRAFT - draft-zhx-pce-stateful-lsp-sync
draft-zhx-pce-stateful-lsp-sync
Network Working Group Xian Zhang
Internet-Draft Gang Xie
Intended status: Standard Track Dhruv Dhody
Huawei
Expires: January 04, 2014 July 05, 2013
LSP Synchronization for Stateful Path Computation Element (PCE)
draft-zhx-pce-stateful-lsp-sync-00.txt
Abstract
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
[Stateful-pcep] specifies a set of extensions to PCEP to enable
stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via
PCEP and maintaining of these LSPs at the stateful PCE. This
document describes the mechanisms for incremental LSP Database (LSP-
DB) synchronization as well as PCE control of the LSP-DB
synchronization process.
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
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 January 04, 2014.
Zhang et al Expires December 2014 [Page 1]
draft-zhx-pce-stateful-lsp-sync-00.txt July 2013
Copyright Notice
Copyright (c) 2013 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 ................................................ 2
1.1. Motivation ............................................. 3
1.2. Conventions used in this document .......................4
2. PCEP Requirements and Objective ..............................4
3. LSP Synchronization Procedure................................ 4
3.1. New PCEP extensions .....................................4
3.2. Procedure .............................................. 4
4. IANA Considerations ......................................... 6
5. Manageability Considerations .................................6
6. Security Considerations ......................................6
7. Contributors ................................................ 6
8. References .................................................. 7
8.1. Normative References.................................... 7
Authors' Addresses ............................................. 7
1. Introduction
[Stateful-pcep] describes a Label Switched Path (LSP) state
synchronization mechanism between Path Computation Clients (PCCs)
and PCEs for a stateful PCE. It includes mechanisms for LSP state
synchronization and avoidance between a PCC and a PCE when the PCEP
session restarts. After PCEP session set up, PCC compares the LSP
State Database version with the PCE. If the database version is
mismatched, state synchronization will be performed. During state
synchronization, a PCC sends the information of all its LSPs (full
LSP-DB) to the stateful PCE.
This document proposes a mechanism for incremental (Delta) LSP
Database (LSP-DB) synchronization as well as allowing PCE to control
the timing of the LSP-DB synchronization process.
Zhang et al Expires January 2014 [Page 2]
draft-zhx-pce-stateful-lsp-sync-00.txt July 2013
1.1. Motivation
If a PCE restarts and its LSP-DB survived, all PCCs with mismatched
LSP State Database version will send all their LSPs information
(full LSP-DB) to the stateful PCE, even if only a small number of
LSPs underwent state change. It can take a long time and consume
large communication channel bandwidth. Moreover, the stateful PCE
can get overloaded with all the PCC performing full synchronization
with it at the same time.
Figure 1 shows an example of LSP state synchronization.
+-----+
| PCE |
+-----+
/
/
/
/
+------+ +------+
| PCC1 |------------| PCC2 |
+------+ +------+
| |
| |
+------+ +------+
| PCC3 |------------| PCC4 |
+------+ +------+
Assuming there are 320 LSPs in the network, with each PCC having 80
LSPs. During the time when the PCEP session is down, 20 LSPs of each
PCC (i.e., 80 LSPs in total), are changed. Hence when PCEP session
restarts, the stateful PCE needs to synchronize 320 LSPs with all
PCCs. But actually, 240 LSPs stay the same. If performing full LSP
state synchronization, it can take a long time to carry out the
synchronization of all LSPs. It is especially true when only a low
bandwidth communication channel is available and there is a
substantial number of LSPs in the network. Another disadvantage of
full LSP synchronization is that it is a waste of communication
bandwidth to perform full LSP synchronization given the fact that
the number of LSP changes can be small during the time when PCEP
session is down.
An incremental (Delta) LSP Database (LSP-DB) state synchronization
is described in this document, where only the LSPs underwent state
change are synchronized between the session restart. This may
include new/modify/deleted LSPs. Furthermore, to avoid overloading
the PCE, the proposed method enable a stateful PCE to control the
LSP synchronization timing.
Zhang et al Expires January 2014 [Page 3]
draft-zhx-pce-stateful-lsp-sync-00.txt July 2013
1.2. 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].
2. PCEP Requirements and Objective
PCEP extensions for stateful PCEs to perform LSP synchronization
SHOULD allow:
- Incremental LSP state synchronization between session restarts.
Note this does not exclude the need for a stateful PCE to
request a full LSP DB synchronization.
- A stateful PCE to control the timing of PCC synchronizing its
LSP state with the PCE.
3. LSP Synchronization Procedure
[Stateful-pcep] describes state synchronization as well as state
synchronization avoidance by using LSP-DB-VERSION TLV in its OPEN
object. This document extends this idea to only synchronize the
delta (changes) in case of version mismatch as well as to allow a
stateful PCE to control the timing of this process.
3.1. New PCEP extensions
Two new bits are added in the STATEFUL-PCE-CAPABILITY TLV defined in
[Stateful-pcep] for incremental (delta) LSP synchronization and PCE
control:
D (DELTA-LSP-SYNC-CAPABILITY - 1 bit): if set to 1 by a PCEP
speaker, the D Flag indicates that the PCEP speaker allows delta or
incremental state synchronization.
C (PCE-CONTROL-SYNC - 1 bit): if set to 1 by a stateful PCE, the
C Flag indicates that the PCE will control the triggering of LSP
state synchronization. This bit is not used by a PCC and MUST be set
to 0 and ignored by the PCE upon receipt.
3.2. Procedure
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN
Object and the TLV values match, the PCC MAY skip state
synchronization. Otherwise, the PCC MUST perform state
synchronization. Instead of dumping full LSP-DB to PCE again, the
PCC synchronizes the delta (changes) as described in figure 1 when D
flag is set to 1 by both PCC and PCE. Other combinations of D flag
setting by PCC and PCE result in full LSP-DB synchronization
procedure as described in [Stateful-pcep].
Zhang et al Expires January 2014 [Page 4]
draft-zhx-pce-stateful-lsp-sync-00.txt July 2013
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| IDB=1 \ / DBv=42 |
| D=1 \/ IDB=1 |
| /\ C=1 |
| / \ D=1 |
| / `-------->| (Expect Delta sync)
(Do sync) |<--------` | (Do not Purge LSP State)
(Delta) | |
(Wait for PCE to | |
trigger LSP state | |
sync) | |
|<-----PCUpd, S=1--------| (ask for LSP Sync, PLSP-ID =0)
| |
(Delta Sync starts) |--PCRpt,DBv=43,SYNC=1-->|
| . |
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=0-->| (Sync done, PLSP-ID=0)
| |
| |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
A stateful PCE MAY choose to control the LSP-DB synchronization
process. To allow PCE to do so, it MUST set C bit to 1 to indicate
this. If the LSP DB version is mis-matched, it can send a PCUpd
message with PLSP-ID = 0 and S =1 in order to trigger the LSP-DB
synchronization process. In this way, the PCE can control the
sequence of LSP synchronization among all the PCCs that re-
establishing PCEP sessions with it. When the capability of PCE
control is enable, only after a PCC receives this message, it will
then start sending information that PCE does not possess, which is
Zhang et al Expires January 2014 [Page 5]
draft-zhx-pce-stateful-lsp-sync-00.txt July 2013
inferred from the LSP DB Version information exchange in the OPEN
message.
As per [Stateful-pcep], the LSP State Database version is
incremented each time a change is made to the PCC's local LSP State
Database. Each LSP is associated with the DB version at the time of
its state change. This is needed to determine which LSP and what
information needs to be synchronized in incremental state
synchronization.
In the example shown in Figure 1, PCC synchronizes all LSPs that are
updated between DB Version 43 to 46. A PCC SHOULD remember the
deleted LSP as well, so that PCRpt message with deleted status can
be sent to the stateful PCE.
4. IANA Considerations
4.1. STATEFUL-PCE-CAPABILITY TLV
As discussed in Section 3.1, two new STATEFUL-PCE-CAPABILITY TLV
Flag Field has been defined. IANA has made the following allocation
from the PCEP "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry:
Bit Description Reference
TBD DELTA-LSP-SYNC-CAPABILITY [This I.D.]
TBD PCE-CONTROL-SYNC-CAPABILITY [This I.D.]
5. Manageability Considerations
The procedure defined in this document does not incur new
manageability issues and the issues described in [Stateful-pcep]
should be followed.
6. Security Considerations
NONE
7. Contributors
Young Lee
Huawei Technologies
5360 Legacy Dr. Building 3
Plano, TX 75024
USA
Phone: (469) 277-5838
Email: leeyoung@huawei.com
Zhang et al Expires January 2014 [Page 6]
draft-zhx-pce-stateful-lsp-sync-00.txt July 2013
8. References
8.1. Normative References
[Stateful-pcep] Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-pce,
work in progress.
Authors' Addresses
Xian Zhang
Huawei Technologies
Research Area F3-1B,
Huawei Industrial Base,
Shenzhen, 518129, China
Phone: +86-755-28972645
Email: zhang.xian@huawei.com
Gang Xie
Huawei Technologies
Research Area F3
Huawei Industrial Base,
Shenzhen, 518129, China
Email xiegang09@huawei.com
Dhruv Dhody
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
Email: dhruv.dhody@huawei.com
Zhang et al Expires January 2014 [Page 7]
