Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE
draft-tanaka-pce-stateful-pce-mbb-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Yosuke Tanaka , Yuji Kamite | ||
| Last updated | 2013-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tanaka-pce-stateful-pce-mbb-02
Network Working Group Y. Tanaka
Internet-Draft Y. Kamite
Intended status: Standards Track NTT Communications
Expires: April 24, 2014 Oct 21, 2013
Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure
using Stateful PCE
draft-tanaka-pce-stateful-pce-mbb-02
Abstract
Stateful PCE (Path Computation Element) and its corresponding
protocol extensions provide a mechanism that enables PCE to do
stateful control of MPLS Traffic Engineering Label Switched Paths (TE
LSP). Stateful PCE supports manipulating the existing LSP's state
and attributes (e.g., bandwidth and route) and also creating totally
new LSPs in the network.
In the current MPLS TE network using RSVP-TE, LSPs are often
controlled by "make-before-break (M-B-B)" signaling by headend for
the purpose of LSP restoration and reoptimization. In most cases, it
is an essential operation to reroute LSP traffic without any data
disruption.
This document specifies the procedure of applying stateful PCE's
control to make-before-break RSVP-TE signaling. In this document,
two types of restoration/reoptimization procedures are defined,
implicit mode and explicit mode. This document also specifies the
usage and handling of stateful PCEP (PCE Communication Protocol)
messages, expected behavior of PCC as RSVP-TE headend and several
extensions of additional PCEP objects.
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."
Tanaka & Kamite Expires April 24, 2014 [Page 1]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
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.
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.
Tanaka & Kamite Expires April 24, 2014 [Page 2]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Make-Before-Break LSP procedures . . . . . . . . . . . . . . . 6
5.1. Implicit Make-Before-Break Mode . . . . . . . . . . . . . 7
5.2. Explicit Make-Before-Break Mode . . . . . . . . . . . . . 8
5.2.1. Initiate Association Group for old LSP . . . . . . . . 9
5.2.2. Establish new Trial LSP . . . . . . . . . . . . . . . 10
5.2.3. Create a New Association Group . . . . . . . . . . . . 11
5.2.4. Switchover Data Traffic triggered by a PCUpd
message . . . . . . . . . . . . . . . . . . . . . . . 12
6. Objects and TLV Formats . . . . . . . . . . . . . . . . . . . 13
6.1. Trial LSP TLV in LSP Objects . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. PCEP TLV Indicators . . . . . . . . . . . . . . . . . . . 14
7.2. PCEP Error Objects . . . . . . . . . . . . . . . . . . . . 14
8. Operational Considerations . . . . . . . . . . . . . . . . . . 15
8.1. Operation in multiple PCEs . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Tanaka & Kamite Expires April 24, 2014 [Page 3]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
1. Introduction
[I-D.ietf-pce-stateful-pce] describes the stateful Path Computation
Elements(PCE). Stateful PCE defines the extensions to PCEP to enable
stateful control of LSPs between and across PCEP sessions, and it
also describes mechanisms to effect LSP state synchronization between
PCCs and PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions.
Today, however, there is no detailed procedure specified as to how to
restore and reoptimize one particular MPLS-TE LSP using stateful PCE.
In today's MPLS RSVP-TE mechanism, make-before-break (M-B-B) is a
widely common scheme supported by headend LER in order to assure no
traffic disruption during restoration and reoptimization. Hence it
is naturally desirable for stateful PCE to control M-B-B based
signaling and forwarding process.
This document specifies the definite procedures of applying stateful
PCE's control to M-B-B method. In this document, two types of
restoration/reoptimization procedures are defined, Implicit mode and
explicit mode. This document also specifies the usage and handling
of stateful PCEP (PCE Communication Protocol) messages, expected
behavior of PCC as RSVP-TE headend and several extensions of
additional objects.
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 RFC2119[RFC2119].
3. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer.
This document uses the following terms defined in [RFC3209]: make-
before-break, Path State Block.
This document uses the following terms defined in [RFC4426] and
[RFC4427]: recovery, protection, restoration.
According to their definition the term "recovery" is generically used
to denote both protection and restoration; the specific terms
"protection" and "restoration" are used only when differentiation is
required. The subtle distinction between protection and restoration
Tanaka & Kamite Expires April 24, 2014 [Page 4]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
is made based on the resource allocation done during the recovery
period. Hence the protection allocates LSP resource in advance of a
failure, while the restoration allocates LSP resource after a failure
occur.
4. Motivation
As for current MPLS mechanism, make-before-break(M-B-B) concept is
outlined in [RFC3209], which allows adaptive and smooth RSVP-TE LSP
rerouting that does not disrupt traffic or adversely impact network
operations while rerouting is in progress. M-B-B is applicable for
reoptimizing LSP's route and resources for several use cases, for
example, to adopt better path for reversion after failure, to change
traversing node/links for planned maintenance, to change bandwidth of
LSPs. M-B-B is also used for global restoration scenario in case of
failure, which is effective if operators do not want to reserve both
working and standby LSPs' bandwidth in advance. Once failure occur,
LSP becomes down, however PSB (Path State Block) of a headend node
remains and keep resources. Using M-B-B, the headend node is able to
resignals working LSP while the PSB remains until new restoration LSP
is successfully established. In real deployment, it can also be
operated with local protection scheme FRR (Fast ReRoute).
Since M-B-B operational scheme is universally common in MPLS network
today, it is naturally much desirable to utilize it under the
architecture of stateful PCE.
The basic procedure of the Make-Before-Break method is outlined as
follows:
1. Establish a new LSP
2. Transfer data traffic from old LSP onto the new LSP
3. Tear down the old LSP (Release old PSB)
In M-B-B, it is an important behavior that headend node handles the
sequence of data traffic switchover. The headend is able to "make"
one or more new LSPs for a particular Tunnel (i.e., it is allowed to
signal multiple RSVP sessions with different LSP-IDs that share a
common Tunnel IDs), and the headend will switch the traffic upon only
one (or some) of those LSPs. In some use cases about stateful PCE,
it is expected that operators can watch and control when the data is
switched over and which LSPs are used. Therefore, this document
covers such a procedure and related message extensions.
Tanaka & Kamite Expires April 24, 2014 [Page 5]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
5. Make-Before-Break LSP procedures
There are possibly two modes introduced for Make-Before-Break
procedure under stateful PCE. The first one is "implicit M-B-B
mode", where the operation is triggered by a PC Update Request(PCUpd)
message from a PCE, and a PCC handles whole Make-Before-Break steps
(signaling and transferring data traffic) for itself. This mode
utilizes the existing messages as defined in
[I-D.ietf-pce-stateful-pce] .
The second one is "explicit M-B-B mode", where the operation is
triggered by a PCUpd message with TRIAL LSP TLV, which is defined in
Section 6.1. A PCE also controls timing and sequence of the M-B-B
steps that a PCC takes. This procedure additionally uses a new
extended TLV that is defined in
[I-D.tanaka-pce-stateful-pce-data-ctrl].
Both types of procedure require at least two LSPs residing in a
single MPLS-TE tunnel, working LSP and trial LSPs. An ingress node
is currently transporting data traffic on the working LSP, and then
it establishes one or more trial LSPs. As per [RFC3209] Section 2.5.
"LSP ID" of a restoration LSP, which is newly signaled, differs from
that of a working LSP. Note that it is used for LSP-ID in LSP
Ideitifiers TLVs in PCEP messages, and it differs from PLSP-ID. In
this document, LSP ID of a working LSP describes "old" and that of a
trial LSP describes "new" as a simple example.
Implicit mode has high affinity with most existing MPLS edge node
implementations which perform entire steps of M-B-B automatically at
once. This mode is particularly applicable for migration scenario
for the existing deployment where service providers want their
recovery/reoptimization operation be delegated to centralized PCE.
Explicit mode is much more flexible than Implicit mode since it
allows PCEs to manage each LSP step-by-step. Explicit mode is
applicable to several new use cases that require split control of
signaling and data switchover. For example, if end-to-end data path
is created by connecting multiple individual LSPs across different
segments (e.g., LSP stitching), in reoptimization scenario, data
flowing cannot be started unless all signaling of all LSPs is
completed. Similarly, there is a case under Software Defined
Networking (SDN) applications, where MPLS domain is connected to
other non-MPLS domains, and the end-to-end data switchover timing
should be carefully coordinated with various different methods of
path/flow setup in each domain.
PCC and PCE can distinguish which mode, implicit mode or explicit
mode, is to be performed by checking the type of PCEP messages that
Tanaka & Kamite Expires April 24, 2014 [Page 6]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
are exchanged. The implementation MAY support both modes, but for
each restoration/reoptimization operation, either one of them SHOULD
be exclusively selected.
5.1. Implicit Make-Before-Break Mode
This specifies the detailed procedure of M-B-B LSP restoration and
reoptimization using exsisting messages which are defined in
[I-D.ietf-pce-stateful-pce] . This procedure is based on the current
existing messages/TLVs and no extended TLV is used. Once a PCC
receives PCUpd message from a PCE, the PCC automatically executes the
implicit M-B-B procedure as described in [I-D.ietf-pce-stateful-pce]
Section 6.2.
First, A PCUpd message is sent from a PCE to trigger M-B-B procecure.
Once a PCC received the PCUpd message, the PCC starts signaling a new
restoration/reoptimization LSP and it replies back to the PCE a PCRpt
message with LSP-IDENTIFIERS TLV in the LSP Object to notify the
result of signaling. If the new LSP failed in setup, the PCC sends
to the PCE the detail of the result in a PCErr message with the same
SRP (Stateful PCE Request Parameters) object as that of the PCUpd
message and it MAY wait for a next instruction from the PCE.
Second, once a new LSP is successfully established, a PCC transfers
data traffic from working LSP to new LSP.
Finally, when a PCC successfully transfered data traffic to the new
LSP, the PCC tears down the (previous) working LSP by RSVP-TE
signaling, then the PCC MUST send another PCRpt message. That PCRpt
message MUST carry a LSP Object with LSP-IDENTIFIERS TLV which
indicates the value of RSVP-TE signaling the PCC has just torn down.
As per [I-D.ietf-pce-stateful-pce], the message has to have SRP-ID
set to 0x00000000.
Following Figure 1 illustrates the example of implicit M-B-B
procedure, in following conditions. Tunnel ID and LSP ID are
included in an LSP Identifiers TLV in a LSP Object.
working LSP : ERO=a-b, Tunnel ID=T1, LSP ID=old
restoration LSP : ERO=a-c-b, Tunnel ID=T1, LSP ID=new
Tanaka & Kamite Expires April 24, 2014 [Page 7]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| | |
| Data on old LSP =>)))))))))))))))))))))))|
| | : |
|--PCUpd(PLSP-ID=X,->| : |
| SRP-ID=Y, | |
| ERO=a-c-b) |---Path(ERO=a-c-b-, --> |
| | LSP ID new) |
| | |
| | <-----Resv-------------|
| <- PCRpt(PLSP-ID=X,| |
| O=Up, | |
| SRP-ID=Y, | |
| Tunnel ID=T1, | |
| LSP ID=new) | |
| | |
| | |
| Transfer data |))))))))))))))))))))))))|
| from old to new =>}}}}}}}}}}}}}}}}}}}}}}}}|
| | : |
| | : |
| |---PathTear(ERO=a-b, -> |
| | LSP ID old) |
| <- PCRpt(PLSP-ID=X,| |
| O=Dn,R=1, | |
| SRP-ID=0, | |
| Tunnel ID=T1, | |
| LSP ID=old) | |
O flag = Operational flag in LSP object.
R flag = Remove flag in LSP object.
Figure 1: Implicit Make-Before-Break Procedure
5.2. Explicit Make-Before-Break Mode
Comparing to the implicit M-B-B mode, explicit M-B-B mode allows a
PCE to control timing and sequence of subsequent make-before-break
steps as follows.
Prior to start of explicit M-B-B mode, the PCE initiates Association
Group for working LSP by sending a PCUpd message with ASSOCIATION-
GROUP TLV in the LSP Object that are defined in
[I-D.tanaka-pce-stateful-pce-data-ctrl].
Tanaka & Kamite Expires April 24, 2014 [Page 8]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
First step of the explicit M-B-B, the PCE triggers PCC's signaling of
a new LSP by sending a PCUpd message with TRIAL-LSP TLV that are
defined in this document. The PCC sends back to the PCE a PCRpt
message to notify the result of signaling new LSP.
Second, the PCE creates a new Association Group for the new LSP by
sending a PCUpd message with both TRILAL-LSP TLV and ASSOCIATION-
GROUP TLV in a LSP Object.
Third, the PCE instructs the PCC to transfer data traffic from old
LSP to new LSP by sending a PCUpd message with DATA-CONTROL TLV. The
PCC automatically tears down the (previous) working LSP once the
traffic switchover successfully is executed. Then it sends back to
the PCE a PCRpt message to notify the result of the switchover.
The operator may want to separate the third step into traffic
switchover and tearing down old LSP. It is further study about the
separate operation of third step.
The following subsections specify each Make-Before-Break step in
detail.
5.2.1. Initiate Association Group for old LSP
The very first of step before starting explicit M-B-B is to initiate
association group for working LSP. The PCE sends to the PCC a PCUpd
message that contain both TRIAL-LSP TLV and DATA-CONTROL TLV in a LSP
object. RSVP-TE LSP ID that the PCE knows from LSP Identifiers TLVs
in a PCRpt message MUST be set to LSP-ID of TRIAL-LSP TLV. The PCE
assignes ASSOCIATION-GROUP ID in DATA-CONTROL TLV that is unique in
the PCEP session.
Figure 2 illustrates an example of working LSP(PLSP-ID P1, Tunnel ID
T1, LSP-ID old, Association Group ID G1 and ERO Ingress-a-b-Egress).
Tanaka & Kamite Expires April 24, 2014 [Page 9]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| data traffic on old LSP |
| |))))))))))))))))))))))))|
|--PCUpd ------>| : |
| LSP Object | : |
| PLSP-ID=P1 | : |
| +TRIAL-LSP TLV | |
| LSP ID=old | |
| +DATA-CTRL TLV | |
| ASSOC-G-ID=G1 | |
| | |
Figure 2: Initiate Associate Group for old LSP
5.2.2. Establish new Trial LSP
As a first step of M-B-B procedure, a PCC establishes a new LSP for
restoration once PCC receives a PCUpd message with TRIAL-LSP TLV from
a PCE. We call this newly established LSPs for restoration "trial
LSP". A trial LSP is signaled the same RSVP-TE Tunnel ID but
different LSP ID from active working LSP, and both the active working
LSP and new trial LSPs MUST be signaled with Shared Explicit style as
describes in [RFC3209].
TRIAL-LSP TLV triggers explicit mode M-B-B. A PCE do not have to
assign RSVP-TE LSP ID for trial LSP signaling, LSP-ID in the TRIAL-
LSP TLV SHOULD be set to 0x0000. The PCC assigns new LSP-ID to
signal new LSP on the same RSVP-TE tunnel.
When a new trial LSP was signaled successfully, the PCC sends a PCRpt
message toward the PCE to notify the result. The PCRpt message from
the PCC MUST have the LSP object with LSP-IDENTIFIERS TLV that
indicates RSVP-TE Tunnel ID and LSP ID the PCC has just established.
If a new trial LSP failed to be established by some reason of RSVP-TE
signaling, the PCC MUST send to the PCE a PCRpt message carrying LSP-
IDENTIFIERS TLV and RSVP-ERROR-SPEC TLV as defined in
[I-D.ietf-pce-stateful-pce] Section 7.3.4..
A PCC SHOULD accept multiple PCUpd messages with TRIAL-LSP TLV in a
LSP Object. And a PCC SHOULD establish as many trial lsps as the
number of PCUpd messages it receives.
Figure 3 illustrates a example, working LSP(PLSP-ID P1,Tunnel ID T1,
Tanaka & Kamite Expires April 24, 2014 [Page 10]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
LSP-ID old, ERO Ingress-a-b-Egress), trial LSP(Tunnel ID T1, LSP-ID
new, ERO Ingress-a-c-b-Egress).
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| data traffic on old LSP |
| |))))))))))))))))))))))))|
|--PCUpd ------>| : |
| LSP Object | : |
| PLSP-ID=P1 | : |
| +TRIAL-LSP TLV | |
| LSP ID=0 | |
| ERO Obj=a-c-b |---Path(LSP ID=new, --> |
| | ERO=a-c-b) |
| | |
| | <----- Resv------------|
|<--PCRpt ---------| |
| LSP Object | : |
| PLSP-ID=P1, |))))))))))))))))))))))))|
| tunnel ID=T1, | : |
| LSP ID=new, | : |
| RRO Obj=a-c-b | : |
| | |
Figure 3: Establish new LSP
5.2.3. Create a New Association Group
As a second step, the PCE creates a new Association Group for the new
LSP by sending a PCUpd message with both TRILAL-LSP TLV and
ASSOCIATION-GROUP TLV in a LSP Object. The PCE assignes a new
ASSOCIATION-GROUP-ID, which MUST be different from that of working
LSP and be unique in the PCEP session. LSP-ID in the TRIAL-LSP TLV
MUST be the RSVP-TE LSP ID of the newly established LSP on the
previous step.
If the PCUpd message has invalid either ASSOCIATION-GROUP-ID or
LSP-ID of TRIAL-LSP, the PCC sends a PCErr message with Error-type=19
(Invalid Operation) and Error-vale=TBD (Specified LSP-ID/
ASSOCIATION-GROUP-ID is not existing).
Figure 4 illustrates an example to create a new ASSOCIATION-GROUP-ID
G2 for a new trial LSP(PLSP-ID P1, Tunnel ID T1, LSP-ID new and ERO
Ingress-a-b-Egress).
Tanaka & Kamite Expires April 24, 2014 [Page 11]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| data traffic on old LSP |
| |))))))))))))))))))))))))|
|--PCUpd ------>| : |
| LSP Object | : |
| PLSP-ID=P1 | : |
| +TRIAL-LSP TLV | |
| LSP ID=new | |
| +DATA-CTRL TLV | |
| ASSOC-G-ID=G2 | |
| | |
Figure 4: Create a new Associate Group for new LSP
5.2.4. Switchover Data Traffic triggered by a PCUpd message
As a third step, the PCC(Ingress) transfers data traffic from a
working LSP to a trial LSP. To specify desired LSP for transferring
data traffic, a PCUpd message from a PCE MUST have a DATA-CONTROL TLV
in a LSP Object.
Data switchover from old (origin) ASSOCIATION-GROUP to new (target)
has to be executed in the same manner as described in
[I-D.tanaka-pce-stateful-pce-data-ctrl].
The PCC SHOULD tear down the old working LSP and other trial LSPs
which the data traffic is no longer used immediately once the data
traffic succesfully switched over (See Figure 5). In OPTIONAL, a PCC
tears down old lsp separately. The PCC sends to the PCE a PCRpt
message to notify the removal of both old LSP and other trial LSPs,
which SRP-ID is set to 0x00000000.
Tanaka & Kamite Expires April 24, 2014 [Page 12]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| | |
| |))))))))))))))))))))))))| data on old LSP
|--PCUpd ------> |))))))))))))))))))))))))|
| LSP Object |}}}}}}}}}}}}}}}}}}}}}}}}| data on new LSP
| PLSP ID=P1 |}}}}}}}}}}}}}}}}}}}}}}}}|
| +DATA-CTRL TLV | : |
| | : |
| | : |
| <-- PCRpt --------| |
| LSP Object | |
| PLSP ID=P1, | |
| Tunnel ID=T1, | |
| LSP-ID=new, | |
| +DATA-CTRL TLV | |
| +DATA-REPORT TLV| |
| |--PathTear(ERO a-b, -->| Tear down old
| | Tunnel=T1,LSP ID=old) | automatically
| | |
| <-- PCRpt(O=Dn,R=1,| |
| PLSP ID=P1, | |
| Tunnel ID=T1, | |
| LSP-ID=old) | |
| | |
| | |
O flag = Operational flag in LSP object.
R flag = Remove flag in LSP object.
Figure 5: Transfer data traffic from old LSP to new LSP
6. Objects and TLV Formats
6.1. Trial LSP TLV in LSP Objects
This document defines a new TLV named TRIAL-LSP TLV.
Tanaka & Kamite Expires April 24, 2014 [Page 13]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be Zero | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TRIAL-LSP TLV format
TRIAL-LSP TLV is sub-TLV of the LSP Object and is used in a PCUpd
message especially to perform explicit mode M-B-B. A PCC signals a
trial LSP once it receives a PCUpd in which LSP object has a TRIAL-
LSP TLV(LSP-ID=0x0000).
LSP-ID: This field MUST be zero in a PCUpd message when a PCE
requests a PCC to signal new trial LSP. It MUST be non-zero and
fill in the RSVP-TE LSP ID when a PCE sends a PCUpd message to
initiate or to create Association Groups for a working/trial LSP.
7. IANA Considerations
7.1. PCEP TLV Indicators
This document defines the following new PCEP TLVs:
Value Meaning Reference
TBD TRIAL-LSP TLV This document
7.2. PCEP Error Objects
This document defines new Error-Type and Error-Value for the
following new error conditions:
Error-Type Meaning
6 Mandatory Object missing
Error-value=TBD: LSP Identifiers TLV missing
19 Invalid operation
Error-value=TBD: Specified ASSOCIATION-GROUP-ID
is not existing for explicit mode
Error-value=TBD: Specified LSP-ID is not existing.
for explicit mode
Tanaka & Kamite Expires April 24, 2014 [Page 14]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
8. Operational Considerations
8.1. Operation in multiple PCEs
In addition to basic operations under multiple PCEs as described in
[I-D.ietf-pce-stateful-pce], a PCC supports both types of M-B-B
operations.
Implicit mode M-B-B requires only one PCUpd message to trigger M-B-B
process, therefore a PCC accepts a message from a primary PCE whom
the PCC delegates the LSPs to. An attempt to update parameters of a
non-delegated LSP results in the PCC sending a PCErr message as
defined in [I-D.ietf-pce-stateful-pce].
Explicit mode M-B-B requires at least three PCUpd messages(1. for
trial-LSP signaling, 2. for new Association-Group creation, 3. for
traffic switchover) to trigger each subsequent step. All steps MUST
be taken by one primary PCE because state synchronization of trial-
LSPs between the primary and backup PCE may be complex. If the PCC
revokes LSP delegations after a Redelegation Timeout Interval, the
PCC MUST tear down all trial-LSPs and redelegate a working LSP to
alternate PCE. An attempt to trigger either step of explicit mode
M-B-B of a non-delegeted LSP results in the PCC sending the same
PCErr as implicit mode M-B-B.
9. Security Considerations
TBD
10. Acknowledgments
Many thanks to Ina Minei, Adrian Farrel, Yimin Shen, Xian Zhang and
Dhruv Dhody for their ideas and feedback in documentation.
11. References
11.1. Normative References
[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-05 (work in progress),
July 2013.
[I-D.tanaka-pce-stateful-pce-data-ctrl]
Tanaka & Kamite Expires April 24, 2014 [Page 15]
Internet-Draft M-B-B procedure using Stateful PCE Oct 2013
Tanaka, Y., Kamite, Y., and I. Minei, "Stateful PCE
Extensions for Data Plane Switchover and Balancing",
draft-tanaka-pce-stateful-pce-data-ctrl-00 (work in
progress), July 2013.
[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.
11.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou,
"Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March 2006.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
Authors' Addresses
Yosuke Tanaka
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: yosuke.tanaka@ntt.com
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: y.kamite@ntt.com
Tanaka & Kamite Expires April 24, 2014 [Page 16]