Internet DRAFT - draft-cho-pce-initiated-auto-path
draft-cho-pce-initiated-auto-path
PCE Working Group E. Cho
Internet-Draft T. Kwon
Intended status: Standards Track ETRI
Expires: April 30, 2017 October 31, 2016
PCEP Extensions for PCE-initiated Automatic Path Setup
in a Stateful PCE Model
draft-cho-pce-initiated-auto-path-00
Abstract
This document introduces an automatic setup and maintenance mechanism
to compute, create, update and delete for a packet and/or optical layer
path and pseudowire paths(PWs) via an extension to the Path Computation
Element Communication Protocol(PCEP) and DB Synchronization procedures.
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."
Cho & Kwon Expires April 30, 2017 [Page 1]
Internet-Draft PCE-initiated Automatic Path October 2016
This Internet-Draft will expire on April 30, 2017.
Copyright Notice
Copyright (c) 2016 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Support of PCE-initiated Automatic Path . . . . . . . . . . . 4
4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 4
4.2. PW-LABEL-DB Synchronization . . . . . . . . . . . . . . . 4
4.3. OAM-DB Synchronization . . .. . . . . . . . . . . . . . . 5
5. PCE-initiated LSP and PW instantiation and deletion . . . . . 6
5.1. The LSP and PW Initiate Message . . . .. . . . . . . . . 6
5.2. The D flag in the SRP Object . . . . . . . . . . . . . . 6
5.3. LSP and PW instantiation . . . . . . . . . . . . . . . . 7
5.4. LSP and PW deletion . . . . .. . . . . . . . . . . . . . 8
5.5. Automatic Restoration and Cascade Update . . . . . . . . 8
6. LSP and PW delegation and cleanup . . . . . . . . . . . . . 8
7. Manageability Considerations . . . . . . . . . . . . . . . . 9
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Cho & Kwon Expires April 30, 2017 [Page 2]
Internet-Draft PCE-initiated Automatic Path October 2016
1. Introduction
Stateful pce [I-D.ietf-pce-stateful-pce] 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
This document describes the setup, maintenance and teardown of PCE-
initiated LSPs and/or Pseudowires under the stateful PCE model
allowing for automatic setup of an transport paths.
2. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer.
This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation
Timeout, State Timeout Interval Path State Report, Path Update
Request.
The following terms are defined in this document:
PCE-initiated Automatic Path: Pseudowire and/or LSP that is
instantiated as a result of a request from the PCE.
3. Motivation
An active stateful PCE is able to provide an automated and optimized
path as the role of central controller or NMS. In addition to PCE-
initiated LSP, PCE may initiate pseudowire service automatically over LSP
with extension of information and protocol. With OAM information, PCE
would be able to trigger path restoration upon alarm notification.
Therefore, this document introduces an automatic path management method
with PCE-initiated paths setup using their pseudowire label and OAM
database. It is a useful mechanism in multi-domain and multi-layer SDN
and ACTN.
Different setup of automatic paths may be offered:
o LSP only: setup the label switched path in one request
o PW only: setup the pseudowire paths in one request
o LSP+PW: setup the LSP with the associated PWs in one request
Cho & Kwon Expires April 30, 2017 [Page 3]
Internet-Draft PCE-initiated Automatic Path October 2016
4. Support of PCE-initiated Automatic Path
A PCEP speaker indicates its ability to support PCE provisioned
dynamic LSPs and/or PWs during the PCEP Initialization phase. The
Open Object in the Open message contains the "Stateful PCE Capability"
TLV, defined in [I-D.ietf-pce-stateful-pce]. A new flag, the P (PW-
INSTANTIATION-CAPABILITY) flag is introduced to indicate support for
instantiation of PCE-initiated LSPs. A PCE can initiate LSPs
with/without PWs for PCCs that advertised this capability and a PCC will
follow the procedures described in this document only on sessions where
the PCE advertised the P flag.
4.1. Stateful PCE Capability TLV
The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the
following figure:
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 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |P|I|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
Figure 1: STATEFUL-PCE-CAPABILITY TLV format
The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it
has a fixed length of 4 octets.
The value comprises a single field - Flags (32 bits).
The I, U and S bits are defined in [I-D.ietf-pce-pce-initiated-lsp],
[I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-stateful-sync-
optimizations] respectively.
P (PW-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the
I Flag indicates that the PCC allows instantiation of an LSP by a
PCE. If set to 1 by a PCE, the P flag indicates that the PCE may
attempt to instantiate PWs over LSPs.
The PW-INSTANTIATION-CAPABILITY flag must be set by both PCC and
PCE in order to support PCE-initiated LSP instantiation.
4.2. PW-LABEL-DB Synchronization
PCECC or NMS MUST maintain the PW-LABEL-DB for each PCEP session
separately.
Cho & Kwon Expires April 30, 2017 [Page 4]
Internet-Draft PCE-initiated Automatic Path October 2016
The purpose of PW-LABEL-DB synchronization is to make sure that the
PCE's view of PW-LABEL-DB matches with the PCC's PW-LABEL-DB. The
PW-LABEL-DB synchronization MUST be performed from PCC to PCE immediately
after the LSP state synchronization. [I-D.ietf-pce-stateful-pce]
describes the basic mechanism for LSP state synchronization.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-PCLabelUpd, SYNC=1----->| (Sync start)
| |
|-PCLabelUpd, SYNC=1----->|
| . |
| . |
| . |
|-PCLabelUpd, SYNC=0----->| (End of sync marker
| | Label Update
| | PW LABEL=0)
| | (Sync done)
Figure 2: PW-LABEL-DB synchronization
Further synchronization procedures and protocol definitions will be
added after consensus on this necessity in this or a separate document.
4.3. OAM-DB Synchronization
PCECC or NMS MUST maintain the OAM-DB for each PCEP session
separately.
The purpose of OAM-DB synchronization is to make sure that the
PCE's view of OAM-DB matches with the PCC's OAM-DB. The OAM-
DB synchronization MUST be performed from PCC to PCE immediately
after the LSP state synchronization. [I-D.ietf-pce-stateful-pce]
describes the basic mechanism for LSP state synchronization.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCOAMUpd, SYNC=1----->| (Sync start)
| |
|---PCOAMUpd, SYNC=1----->|
| . |
| . |
| . |
|---PCOAMUpd, SYNC=0----->| (End of sync marker
| | Label Update
| | OAM =0)
| | (Sync done)
Figure 3: OAM-DB synchronization
Cho & Kwon Expires April 30, 2017 [Page 5]
Internet-Draft PCE-initiated Automatic Path October 2016
Upon alarm notification on link or path, PCE can compute and initiate
restoration path. For this active control, PCE may keep OAM information
such as identifiers of Maintenance Entity Group(MEP), MEG End Point(MEG),
Trail Trace Identifier(TTI). This information is maintained for each path
and has an important role in automatic and dynamic path control
environment.
For highly automated services, Attachment Circuit(AC) database also is
Additional synchronization procedures and protocol definitions will be
added after consensus on this necessity in this or a separate document.
5. PCE-initiated LSP and PW instantiation and deletion
To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The
message format, objects and TLVs are discussed separately below for
the creation and the deletion cases.
5.1. The LSP and PW Initiate Message
A Pseudowire Path Initiate Message (also referred to as PCInitiate
message) is a PCEP message sent by a PCE to a PCC to
trigger LSP instantiation or deletion. A PCInitiate message for LSP
instantiation is defined in [I-D.ietf-pce-pce-initiated-lsp].
5.2. The D flag in the SRP Object
The format of the SRP object is shown Figure 2:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |C|D|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The SRP Object format
The type object is defined in [I-D.ietf-pce-stateful-pce]. The R
bits are defined in [I-D.ietf-pce-pce-initiated-lsp].
A new flag is defined to indicate a delete operation initiated by the
PCE:
C (ML-CASCADE-DELETE - 1 bit): If set to 1, it indicates a cascade
LSP removal request initiated by the PCE.
D (PW-DELETE - 1 bit): If set to 1, it indicates a removal request
initiated by the PCE. If both R and D set to 1, it indicates a
removal request of LSP and PW initiated by the PCE.
Cho & Kwon Expires April 30, 2017 [Page 6]
Internet-Draft PCE-initiated Automatic Path October 2016
5.3. LSP and PW instantiation
LSP instantiation is done by sending an LSP Initiate Message with an
LSP object with the reserved PLSP-ID 0. The LSP is set up using
RSVP-TE, extensions for other setup methods are outside the scope of
this draft.
The END-POINTS, ERO, and LSP Object is defined in [ietf-pce-pce-
initiated-lsp].
The symbolic name used for provisioning PCE-initiated Automatic Path must
not have conflict with the LSP name of any existing LSP in the PCC.
(Existing LSPs may
be either statically configured, or initiated by another PCE).
A PCC SHOULD be able to place a limit on the number of LSPs, PWs and
OAMs the percentage of resources that are allocated to honor PCE-
initiated LSP requests.
Similarly, the PCE SHOULD be able to place a limit on the number of
LSP or PW initiation requests pending for a particular PCC, or on the
time it waits for a response (positive or negative) to a PCInitiate
request from a PCC and MAY take further action (such as closing the
session or removing all its LSPs or PWs) if this limit is reached.
On succesful completion of the LSP and PW instantiation, The PCRpt
MUST include the SRP-ID-number of the PCInitiate request that triggered
its creation. PCE-initiated LSPs are identified with the Create flag in
the LSP Object.
The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
here for easy reference.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID |Flags |C|P| O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The LSP Object format
A new flag, the PW Create (P) flag is introduced. On a PCRpt message,
the P Flag set to 1 indicates that this LSP was created via a
PCInitiate message. The P Flag MUST be set to 1 on each PCRpt
message for the duration of existence of the LSP. The Create flag
allows PCEs to be aware of which LSPs were PCE-initiated (a state
that would otherwise only be known by the PCC and the PCE that
initiated them).
Cho & Kwon Expires April 30, 2017 [Page 7]
Internet-Draft PCE-initiated Automatic Path October 2016
The optional SPEAKER-IDENTITY-ID TLV defined in
[I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP
and/or PW object in a PCRpt message, as an optional TLV for LSPs for
which the C-flag is 1. The SPEAKER-IDENTITY-ID TLV identifies the PCE
that initiated the creation of the LSP and/or PW on all PCEP sessions, a
state that would otherwise only be known by the PCC and the PCE that
initiated the LSP. If the TLV appears in a PCRpt for an LSP for which
the C flag is 0, the TLV MUST be ignored.
5.4. LSP and PW deletion
PCE-initiated removal of a PCE-initiated Automatic Path and/or PWs is
done by setting the R(LSP remove) and/or D (PW remove) flag in the SRP
Object in the PCInitiate message from the PCE. The LSP is identified by
the PLSP-ID in the LSP object.
Following the removal of the LSP and/or PW, the PCC MUST send a PCRpt
as described in [I-D.ietf-pce-stateful-pce]. The SRP object in the PCRpt
MUST include the SRP-ID-number from the PCInitiate message that triggered
the removal. The R and/or D flag in the SRP object SHOULD be set.
5.5. Automatic Restoration and Cascade Update
Upon PCNotify on link failure or CCM Error, PCE would compute and
initiate a new path. At this moment, PCE can apply the LSP policy on
mono-layer or inter-layer path. For instance, lower layer LSP may update
or delete by the policy flag on PCE-initiated deletion request. The
format will be described upon PCE WG discussion.
6. LSP and PW delegation and cleanup
PCE-initiated automatic paths are automatically delegated by the PCC
to the PCE upon instantiation.
To obtain control of a PCE-initiated LSP and PW, a PCE (either the
original or one of its backups) sends a PCInitiate message, including
just the SRP and LSP objects, and carrying the PLSP-ID.
PCE-initiated LSPs and PWs are cleaned up on the expiration of State
Timeout timer.
Cho & Kwon Expires April 30, 2017 [Page 8]
Internet-Draft PCE-initiated Automatic Path October 2016
7. Manageability Considerations
TBD
8. IANA considerations
TBD
9. Security Considerations
TBD
10. Acknowledgements
This document borrows some of the structure and text from [I-D. draft-
ietf-pce-pce-initiated-lsp] and [I-D. draft-palle-pce-controller-labeldb-
sync], and would like to thanks the authors and contributors of the
document.
11. References
11.1. Normative References
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-14 (work in progress), March 2016.
[I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-05 (work in
progress), April 2016.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010.
11.2. Informative References
[I-D.ietf-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-ietf-pce-pce-initiated-lsp-05 (work in
progress), October 2015.
[I-D.palle-pce-controller-labeldb-sync]
Palle, U. and D. Dhody, "LABEL-DB Synchronization
Procedures for a PCE as a central controller(PCECC)",
draft-palle-pce-controller-labeldb-sync-00 (work in
progress), May 2016.
Cho & Kwon Expires April 30, 2017 [Page 9]
Internet-Draft PCE-initiated Automatic Path October 2016
Authors' Addresses
Eunyoung Cho
ETRI
218 Gajeongno, Yuseonggu, Daejeon, 34129
Korea (the Republic of)
Email: eycho@etri.re.kr
Taehyun Kwon
ETRI
218 Gajeongno, Yuseonggu, Daejeon, 34129
Korea (the Republic of)
Email: thkwon@etri.re.kr
Cho & Kwon Expires April 30, 2017 [Page 10]
