PCE Working Group WJ. He, Ed.
Internet-Draft ZTE
Intended status: Standards Track October 21, 2011
Expires: April 23, 2012
Extensions to the Path Computation Element Communication Protocol (PCEP)
for Associated Bidirectional LSP
draft-he-pce-pcep-associated-lsp-extensions-00
Abstract
The MPLS Transport Profile (MPLS-TP) requirements document[RFC5654],
describes that MPLS-TP MUST support associated bidirectional point-
to-point LSPs. Path Computation Element (PCE), see [RFC4655], may be
used for path computation of an associated bidirectional LSP. This
document defines the Path Computation Element Protocol (PCEP)-based
[RFC5440] extensions for associated bidirectional LSP.
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 23, 2012.
Copyright Notice
Copyright (c) 2011 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
He Expires April 23, 2012 [Page 1]
Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Single Sided Provisioning . . . . . . . . . . . . . . . 4
3.1.1. Concurrent Computation . . . . . . . . . . . . . . . . 4
3.1.2. Successive Computation . . . . . . . . . . . . . . . . 4
3.2. The Double Sided Provisioning . . . . . . . . . . . . . . . 5
4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. The Extension of the RP Object . . . . . . . . . . . . . . 5
4.2. REVERSE_LSP Object . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
He Expires April 23, 2012 [Page 2]
Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011
1. Introduction
The MPLS Transport Profile (MPLS-TP) requirements [RFC5654] and
control plane framework documents[RFC6373]describe that MPLS-TP MUST
support associated bidirectional point-to-point LSPs. Path
Computation Element (PCE), see [RFC4655], may be used for path
computation of a GMPLS LSP, see
[I-D.ietf-pce-gmpls-pcep-extensions],and consequently an associated
bidirectional LSP, across domains and in a single domain.
Dependent path computations are requests that need to be synchronized
in order to meet specific objectives, see [RFC6007]. For associated
bidirectional LSP, if the forward LSP and the backward LSP are
computed concurrently, the PCE can find the optimum path.
This document defines the Path Computation Element Protocol (PCEP)-
based [RFC5440] extensions for associated bidirectional LSP.
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].
3. Processing
Consider the topology described in Figure 1. (An example of
associated bidirectional LSP). The LSP1 [via nodes A,D,B] (from A to
B) and LSP2 [via nodes B,D,C,A] (from B to A) need to be established,
which can form an associated bidirectional LSP deployed by Single
Sided Provisioning model or Double Sided Provisioning
model[I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]. Node A, the
ingress LSR of LSP1, can play the role of a PCC and request the PCE
to compute the LSP1 or the associated bidirectional LSP.
A-------D-------B
\ /
\ /
\ /
C
Figure 1 : An example of associated bidirectional LSP
He Expires April 23, 2012 [Page 3]
Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011
3.1. The Single Sided Provisioning
For the single sided provisioning, the path computation can be
realized by the concurrent or successive computation. The concurrent
computation means that the head-end submits the computation request
for both two directional LSPs concurrently. As to the successive
computation, the head-end and the tail-end send the forward LSP and
backward LSP computation requests separately.
3.1.1. Concurrent Computation
The PCC sends the PCReq message to PCE for computing an associated
bidirectional LSP, whose forward and backward paths are computed
concurrently. Concurrent computation can ensure that the paths for
the associated bidirectional LSP is optimal [RFC5557].
The basic procedure are as follows:
1. The PCC node sends the PCReq message to the PCE with the A flag
of the RP object set, indicates the request is for an associated
bidirectional LSP. Except the constraint information about the
forward LSP, the REVERSE_LSP object may also be included in the
PCReq message to specify the TE parameters of the backward LSP.
2. Once receiving the PCReq message, the PCE will compute the two
reverse LSP based on the constraints, and choose the optimal LSP
for the associated bidirectional LSP. If the A bit of the RP
object set to 1, but the REVERSE_LSP object is not present in the
PCReq message, the PCE computes the path of the reverse LSP
according to the forward LSP information, such as bandwidth,
protection and so on.
3. After the successful computation, the PCE will supply the PCC
with a fully computed explicit routes of an associated
bidirectional LSP. The explicit path for the forward LSP is
carried by the ERO object and the backward LSP by the ERO
subobject inserted in the REVERSE_LSP object.
If the PCE does not support the extensions in this document,
responses with notification.
3.1.2. Successive Computation
Successive computation means that the forward LSP and the backward
LSP are computed separately. The head-end will send request to the
PCE for the forward LSP. After receiving the successful computation
result, the head-end starts to signal the forward LSP with Extended
Association object and Reverse LSP object inserted in the Path
message [I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]. Once
receiving the Path message, the tail-end will be triggered to create
He Expires April 23, 2012 [Page 4]
Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011
the backward LSP. The REVERSE_LSP object is extracted from the Path
message and may be put into the PCReq message for a path computation.
There is no need to extend the PCEP to support the successive
computation.
3.2. The Double Sided Provisioning
For the double sided provisioning, the forward and the backward LSP
configuration are send to the head-end and the tail-end separately.
The head-end and the tail-end will send the PCReq message for the
unidirectional LSP computation. After the successfully computation,
the head-end and the tail-end start to create the LSP separately.
4. PCEP Extensions
4.1. The Extension of the RP Object
The PCReq and PCRep messages will need the following additional
parameters for associated bidirectional LSP.
An A-bit is added to the flag bits of the RP object to indicate the
request is about an associated bidirectional LSP or not.
o A (RP Associated bit - 1 bit): when set, the PCC specifies that
the path computation request relates to an associated
bidirectional TE LSP that may be has the different traffic
engineering requirements including fate sharing, protection and
restoration, LSRs, TE links, and resource requirements (e.g.,
latency and jitter) in each direction. When cleared, the TE LSP
is not an associated bidirectional TE LSP .
4.2. REVERSE_LSP Object
The REVERSE_LSP object is used in a PCReq message to specify the
information of the reverse LSP for which a path computation is
requested. This object is optional. The format of the REVERSE_LSP
object is as follows:
Object-Class is TBD,Object-Type is TBD.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
He Expires April 23, 2012 [Page 5]
Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011
Figure 2 : REVERSE_LSP Object Body Format
This object MUST NOT be used when the A bit of RP object set to 0.
Subojects
The contents of a REVERSE_LSP object are a series of variable-length
data items called subobjects, which can be BANDWIDTH, IRO and XRO
object, LSPA Object, METRIC Object, etc.
5. IANA Considerations
TBD
6. Security Considerations
TBD
7. Acknowledgement
TBD
8. References
8.1. Normative References
[I-D.ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp]
Zhang, F. and R. Jing, "RSVP-TE Extensions for Associated
Bidirectional LSPs",
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02
(work in progress), October 2011.
[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.
8.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-03 (work in
He Expires April 23, 2012 [Page 6]
Internet-Draft PCEP Ext for Associated Bidirectional Lsp October 2011
progress), July 2011.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization
VECtor (SVEC) List for Synchronized Dependent Path
Computations", RFC 6007, September 2010.
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
Framework", RFC 6373, September 2011.
Author's Address
Wenjuan He (editor)
ZTE
Email: he.wenjuan1@zte.com.cn
He Expires April 23, 2012 [Page 7]