One document matched: draft-zhao-pce-pcep-extension-for-pce-controller-00.txt
PCE Working Group Quintin Zhao
Internet-Draft Katherine Zhao
Intended status: Standards Track Robin Li
Expires: Auguest 5, 2014 Dhruv Dhody
Huawei Technologies
Boris Zhang
Telus Ltd.
Feb 2014
PCEP Procedures and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs
draft-zhao-pce-pcep-extension-for-pce-controller-00
Abstract
In certain networks deployment scenarios, service providers would
like to keep all the existing MPLS functionalities in both MPLS and
GMPLS while removing the complexity of existing signaling protocols
such as LDP and RSVP-TE. In
[I-D.draft-zhao-pce-central-controller-user-cases], we propose to use
the PCE as a central controller so that LSP can be calculated/
signaled/initiated and label forwarding entries are downloaded
through a centralized PCE server to each network devices along the
LSP path while leveraging the existing PCE technologies as much as
possible.
This draft specify the procedures and PCEP protocol extensions for
using the PCE as the central controller and user cases where LSPs are
calculated/setup/initiated and label forwarding entries are
downloaded through extending the existing PCE architectures and PCEP.
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 August 5, 2014.
Zhao, et al. Expires August 5, 2014 [Page 1]
Internet-Draft PCECC November 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4. Procedures for Using the PCE as the Central Controller
(PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Procedure-1 for PCECC Capability Advertisement . . . . . . 7
4.2. Procedure-2 for PCECC's Label Resource Reservations . . . 8
4.3. Procedure-3 for PCECC for LSP Setup in the New PCECC
Enabled Network . . . . . . . . . . . . . . . . . . . . . 9
4.4. Procedure-4 for PCECC for LSP Setup in the Network
Migration . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Procedure-5 for Using Extended PCEP to download LSP
information for Each Network Device . . . . . . . . . . . 10
5. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. New Messages . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. PCEP Extension for Label Range Reservation Request . . 12
5.1.2. PCEP Extension for Label Range reservation Notify . . 13
5.1.3. The LSP Setup Request Message . . . . . . . . . . . . 14
5.1.4. The LSP Delete Request Message . . . . . . . . . . . . 14
5.1.5. PCEP Extension for LFIB Entry Downloading . . . . . . 15
5.1.6. PCEP Extension for LFIB Entry Cleanup . . . . . . . . 16
5.1.7. The PCErr Message . . . . . . . . . . . . . . . . . . 17
5.2. Object Formats . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . 17
5.2.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . 17
5.2.2. SRQ Object . . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Manageability Considerations . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Zhao, et al. Expires August 5, 2014 [Page 2]
Internet-Draft PCECC November 2013
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Zhao, et al. Expires August 5, 2014 [Page 3]
Internet-Draft PCECC November 2013
1. Introduction
In certain network deployment scenarios, service providers would like
to have the ability to dynamically adapt to a wide range of
customer's requests for the sake of flexible network service
delivery, Software Defined Networks (SDN)has provides additional
flexibility in how the network is operated compared to the
traditional network.
The existing networking ecosystem has become awfully complex and
highly demanding in terms of robustness, performance, scalability,
flexibility, agility, etc. By migrating to the SDN enabled network
from the existing network, service providers and network operators
must have a solution which they can evolve easily from the existing
network into the SDN enabled network while keeping the network
services remain scalable, guarantee robustness and availability etc.
Taking the smooth transition between traditional network and the new
SDN enabled network into account, especially from a cost impact
assessment perspective, using the existing PCE components from the
current network to function as the central controller of the SDN
network is one choice, which not only achieves the goal of having a
centralized controller, but also leverages the existing PCE network
components.
The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform route
computations in response to Path Computation Clients (PCCs) requests.
PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
draft [I-D. draft-ietf-pce- stateful-pce] describes a set of
extensions to PCEP to enable active control of MPLS-TE and GMPLS
tunnels.
[I-D. draft-ietf-pce-pce-initiated-lsp] describes the setup and
teardown of PCE-initiated LSPs under the active stateful PCE model,
without the need for local configuration on the PCC, thus allowing
for a dynamic MPLS network that is centrally controlled and deployed.
[I-D.draft-ali-pce-remote-initiated-gmpls-lsp-01] complements [I-D.
draft-ietf-pce-pce-initiated-lsp] by addressing the requirements for
remote-initiated GMPLS LSPs.
Segment Routing (SR) technology leverages the source routing and
tunneling paradigms. A source node can choose a path without relying
on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path
is specified as a set of "segments" advertised by link-state routing
protocols (IS-IS or OSPF). [I-D.filsfils-rtgwg-segment-routing]
provides an introduction to SR technology. The corresponding IS-IS
Zhao, et al. Expires August 5, 2014 [Page 4]
Internet-Draft PCECC November 2013
and OSPF extensions are specified in [I-D.previdi-isis-segment-
routing-extensions] and [I-D.psenak-ospf-segment-routing-extensions],
respectively.
A Segment Routed path (SR path) can be derived from an IGP Shortest
Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE
paths) may not follow IGP SPT. Such paths may be chosen by a
suitable network planning tool and provisioned on the source node of
the SR-TE path.
It is possible to use a stateful PCE for computing one or more SR-TE
paths taking into account various constraints and objective
functions. Once a path is chosen, the stateful PCE can instantiate
an SR-TE path on a PCC using PCEP extensions specified in [I-D.ietf-
pce-pce-initiated-lsp] using the SR specific PCEP extensions
described in [I-D.draft-sivabalan-pce-segment-routing].
By using the solutions provided from above drafts, LSP in both MPLS
and GMPLS network can be setup/delete/maintained/synchronized through
a centrally controlled dynamic MPLS network. Since in these
solutions, either the LSP is need to be signaled through the head end
LER to the tail end LER, RSVP-TE signaling protocol need to be
deployed in the MPLS/GMPLS network, or extend IGP protocol with node/
adjacency segment identifiers signaling capability to be deployed.
The PCECC solution introduced in
[I-D.draft-zhao-pce-central-controller-user-cases] allow for a
dynamic MPLS network that is eventually controlled and deployed
without the deployment of RSVP-TE protocol or extended IGP protocol
with node/adjacency segment identifiers signaling capability while
providing all the key MPLS functionalities needed by the service
providers. In the case that one LSP path consist legacy network
nodes and the new network nodes which are centrally controlled, the
PCECC solution provides a smooth transition steps for the users.
This draft specify the procedures and PCEP protocol extensions for
using the PCE as the central controller and user cases where LSPs are
calculated/setup/initiated/downloaded through extending the existing
PCE architectures and PCEP.
2. Terminology
The following terminology is used in this document.
Zhao, et al. Expires August 5, 2014 [Page 5]
Internet-Draft PCECC November 2013
IGP: Interior Gateway Protocol. Either of the two routing
protocols, Open Shortest Path First (OSPF) or Intermediate System
to Intermediate System (IS-IS).
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
TE: Traffic Engineering.
3. PCEP Requirements
Following key requirements associated PCECC should be considered when
designing the PCECC based solution:
1. PCEP speaker supporting this draft MUST have the capability to
advertise its PCECC capability to its peers.
2. Path Computation Element (PCE) supporting this draft MUST have
the capability to negotiate a global label range for a group of
clients.
3. Path Computation Client (PCC) MUST be able ask for global label
range assigned in a request message .
4. PCE are not required to support label range reserve service.
Therefore, it MUST be possible for a PCE to reject a label range
reserve message with a reason code that indicates no support for
label reserve service.
5. PCEP SHOULD provide a means to return global label range and LSP
label assignments of the computed path in a reply message.
6. PCEP SHOULD provide a means to request for LSP setup in the
request message.
7. PCEP SHOULD provide a means to download the MPLS forwarding entry
to the PCECC's clients.
4. Procedures for Using the PCE as the Central Controller (PCECC)
The procdures specified in this document are based on the following
PCECC architecture.
Zhao, et al. Expires August 5, 2014 [Page 6]
Internet-Draft PCECC November 2013
+------------------------------------------------------------------+
| PCECC |
| +-----------------------------------------------------+ |
| | LSP-Database RSVP-TE Signal Control Module | |
| | TE-Database LDP signaling Control Module | |
| | Label-Database LP/label/TE MGRs | |
| +-----------------------------------------------------+ |
| ^ ^ ^ ^ ^ |
| IGP|LDP/RSVP-TE |PCEP |PCEP PCEP| IGP|LDP/RSVP-TE|
| |PCEP | | | |PCEP |
| V V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
| | |...| |...| |...| |...| | |
| | Legacy |IGP| |IGP| |IGP| PCC4 |IGP| Legacy | |
| | Node | | | | | | | | Node | |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+
Through the draft, we call the combination of the functionality for
global label range signaling and the functionality of LSP setup/
download/cleanup using the combination of global labels and local
labels as PCECC functionality.
4.1. Procedure-1 for PCECC Capability Advertisement
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of PCECC extensions. A PCEP Speaker includes
the "PCECC Capability" TLV, described in Section 5.2.1.1. of this
document, in the OPEN Object to advertise its support for PCECC
extensions.
The presence of the PCECC Capability TLV in PCC's OPEN Object
indicates that the PCC is willing to function as a PCECC client.
The presence of the PCECC Capability TLV in PCE's OPEN message
indicates that the PCE is interested in function as a cental
controller for LSP setup/download/label-reservation.
The PCEP protocol extensions for PCECC MUST NOT be used if one or
both PCEP Speakers have not included the PCECC Capability TLV in
their respective OPEN message. If the PCEP Speakers support the
extensions of this draft but did not advertise this capability, then
a PCErr with error-type TBD (Invalid Operation), error-value TBD
(Attempted LSP setup/download/label-reservarion if PCECC capability
was not advertised) will be generated and the PCEP session will be
Zhao, et al. Expires August 5, 2014 [Page 7]
Internet-Draft PCECC November 2013
terminated.
4.2. Procedure-2 for PCECC's Label Resource Reservations
Current MPLS label has local meaning. That is, MPLS label is always
allocated by the downstream node to the upstream node. Then the MPLS
label is only identified by the neighboring upstream node and
downstream node. The label allocation is done locally and signaled
through the LDP/RSVP-TE/BGP protocol. To ease the label allocation
and signaling mechanism, also with the new applications such as
centralized LSP controllers are introduced, PCE can be conveniently
used as a central controller and MPLS global label range negotiator.
The label range reservation procedures are based on network
configurations illustrated using the following figure:
+------------------------------+ +------------------------------+
| PCE DOMAIN 1 | | PCE DOMAIN 2 |
| +--------+ | | +--------+ |
| | | | | | | |
| | PCECC1 |<------------------------>| PCECC2| |
| | | | | | | |
| | | | | | | |
| +--------+ | | +--------+ |
| ^ ^ | | ^ ^ |
| / \ | | / \ |
| V V | | V V |
| +--------+ +--------+ | | +--------+ +--------+ |
| |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| |
| | | ...... | | | | | | ...... | | |
| | PCECC | | PCECC | | | | PCECC | |PCECC | |
| |Enabled | | Enabled| | |Enabled | |Enabled | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Procedure-2 for global Label Range Reservation
o Node11 sends a label request message to PCECC1 with global label
reservation range 100 to 1000.
o PCECC1 sends a reply message with global label reservation range
100 to 1000 confirmed to node1, ..., node1n
o PCECC1 sends a indication message with global label reservation
range 100 to 1000 confirmed to PCECC2.
Zhao, et al. Expires August 5, 2014 [Page 8]
Internet-Draft PCECC November 2013
o PCECC2 sends indication messages with global label reservation
range 100 to 1000 confirmed to Node21,..., node2n
4.3. Procedure-3 for PCECC for LSP Setup in the New PCECC Enabled
Network
Procedure-3-1: Tunnel Head End PCC-Initiated LSP Setup Using Global
Label Range Reserved
o Node1 sends a path request message for LSP setup from Node11 to
Node2n.
o PCE1 sends a indication message LSP setup with [Label(to2n),
Node2n] to Node12, ..., Node1n.
o PCE1 sends a indication message LSP setup with [Label(to2n),
Node2n] to PCE2;
o PCE2 sends a indication message LSP setup with [Label(to2n),
Node2n] to Node22, ..., Node2n.
Procedure-3-2: LSP Delete Using global Label Range Reserved
o Node1 sends a path request message for LSP cleanup from Node11 to
Node2n.
o PCE1 sends a indication message LSP cleanup with [Label(to2n),
Node2n] to Node12, ..., Node1n.
o PCE1 sends a indication message LSP cleanup with [Label(to2n),
Node2n] to PCE2;
o PCE2 sends a indication message LSP cleanup with [Label(to2n),
Node2n] to Node22, ..., Node2n.
4.4. Procedure-4 for PCECC for LSP Setup in the Network Migration
procedure-4 is based on network configurations illustrated using the
following figure:
Zhao, et al. Expires August 5, 2014 [Page 9]
Internet-Draft PCECC November 2013
+------------------------------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------------------------+ |
| | PCECC | |
| +-----------------------------------------------------+ |
| ^ ^ ^ ^ |
| |if11 RSVP-TE | if33 if44|RSVP-TE |i55 |
| V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
| | |...| |...| |...| |...| | |
| | Legacy |if1| Legacy |if2|PCCEC |if3| PCECC |if4| Legacy | |
| | Node | | Node | |Enabled | |Enabled | | Node | |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+
Procedures for Using PCECC Initiated LSP Setup In the Network
Migration
In this scenaro, there are multiple nodes for the LSP from head end
(node1) to the tail end (node5). Where the node3 and node4 with the
PCECC capability, and other nodes are legacy nodes.
o Node1 sends a path request message for LSP setup to Node5.
o PCE sends a reply message for LSP setup with path (node1, i1),
(node2, i2), (node-PCECC, if33), (node-PCECC, if55), Nnode5.
o PCE sends an indication message for LSP segment setup with
[Label(toN5), Node5] for node3 to node4.
o Node1, Node2, Node-PCECC, Node-PCECC, Node 5 will setup the LSP to
Node5 normally using the local label as normal. After the LSP is
setup, then the PCECC will program the node 3 and node 4 to
replace the LSP segment from node3-node-PCECC-node5 to node3-
node4-node5.
4.5. Procedure-5 for Using Extended PCEP to download LSP information
for Each Network Device
The existing PCEP is used to communicate between the PCE server and
PCC for exchanging the path request and reply information regarding
to the LSP info. With minor extensions, we can use the PCEP to
download the complete LSP forwarding entries for each node in the
network.
Zhao, et al. Expires August 5, 2014 [Page 10]
Internet-Draft PCECC November 2013
In procedure-5, the LSP segment between node3 and node4 for
destination node5 is setup from PCECC and downloaded into node3 and
node4 directly from PCECC through the extended PCEP.
+------------------------------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------------------------+ |
| | PCECC | |
| +-----------------------------------------------------+ |
| PCEP | PCEP| |
| MPLS Forwarding | | MPLS Forwarding |
| Entry Download V V Entry Download |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
| | |...| |...| |...| |...| | |
| | Legacy |if1| Legacy |if2|PCCEC |if3| PCECC |if4| Legacy | |
| | Node | | Node | |Enabled | |Enabled | | Node | |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+
5. PCEP Extensions
As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable-length body made of a set of objects that can
be either mandatory or optional. An object is said to be mandatory
in a PCEP message when the object must be included for the message to
be considered valid. For each PCEP message type, a set of rules is
defined that specify the set of objects that the message can carry.
An implementation MUST form the PCEP messages using the object
ordering specified in this document.
5.1. New Messages
In this document, we define the following new PCEP messages:
Zhao, et al. Expires August 5, 2014 [Page 11]
Internet-Draft PCECC November 2013
(LabelRRq): a PCEP message sent by a PCC
to a PCE to ask for the gloabl label range reservation.
(LabelRN): a PCEP message sent by a PCE
to a PCC to indicate the globallabel range reserved.
(LSPSetupRq): a PCEP message sent by a PCC
to a PCE to ask for the setup of LSPs. </t>
(LSPSetupRq): a PCEP message sent by a PCC
to a PCE to ask for the delete of LSPs. </t>
(LFIBdownload): a PCEP message sent by a PCE
to a PCC to download the LFIB.
(LFIBCleanup): a PCEP message sent by a PCE
to a PCC to download the LFIB.
The new functions defined in this document are mapped onto the new
messages as shown in the following table.
+----------------------------------------+--------------------------+
| Function | Message |
+----------------------------------------+--------------------------+
| LSP Label Range Reserve Request | LabelRRq |
| LSP Label Range Reserve Notify | LabelRN |
| LSP Setup Request | LSPSetupRq |
| LSP Delete Request | LSPDeleteRq |
| LIFB Download | LFibDownLoad |
| LIFB Cleanup | LFibCleanup |
+----------------------------------------+--------------------------+
5.1.1. PCEP Extension for Label Range Reservation Request
A Label Range Request message (also referred to as LabelRRq message)
is a PCEP message sent by a PCC or an application to a PCE to request
the setup of an LSP. The Message-Type field of the PCEP common
header for the LabelRRq message is set to [TBD].
The format of a LabelRRq message is as follows:
Zhao, et al. Expires August 5, 2014 [Page 12]
Internet-Draft PCECC November 2013
<LabelRRq Message>::= <Common Header>
<label-range-request>
Where:
<label-range-request> ::= <SRQ>
<minimum-lable><maximum-label>
<lable> is as defined in [RFC3209].
There are three mandatory objects that MUST be included within each
label range Request in the labelRRq message: the SQR Object, two
label objects. If the SQR object is missing, the receiving PCE MUST
send a PCErr message. If the label object is missing, the receiving
PCE MUST send a PCErr message with Error- type=[TBD] (Mandatory
Object missing) and Error-value=[TBD] (Lable object missing).
A PCE only acts on an label range reservation equest if permitted by
the local policy configured by the network manager. Each label range
reservation Request that the PCC acts on results in an LSP setup
operation. An LSP MUST contain all LSP parameters that a PCC need to
resrve the label range. A PCC MAY set missing parameters from
locally configured defaults.
5.1.2. PCEP Extension for Label Range reservation Notify
The Label Range Notify Message (also referred to as LabelRN) is a
PCEP message sent by a PCE to a PCC to notify the global label range
reserved for the network. The Message-Type field of the PCEP common
header for the LabelRN message is set to [TBD].
The format of the LabelRN message is as follows:
<LabelRN Message>> ::= <Common Header>
[<SRQ>]
<Minimum-Lable><Maxmum-Label>
Where:
the label range is between Minumum-Lable and Maxmum-Lable, which is as defined
as the <label> object in {RFC3209].
The SRQ object is optional. If the LabelRN message is not in
response to a LableRRq message, the SRQ object MAY be omitted.
If the LabelRN message is not in response to a LableRRq message, the
SRQ object SHOULD be included and the value of the SRQ-ID-number in
the SRQ Object MUST be the same as that sent in the LabelRRq message
that triggered the LSP to be setup.
Zhao, et al. Expires August 5, 2014 [Page 13]
Internet-Draft PCECC November 2013
5.1.3. The LSP Setup Request Message
A LSP Setup Request message (also referred to as LSPSetupRq message)
is a PCEP message sent by a PCC or an application to a PCE to request
the setup of an LSP. A LSPSetupRq message can carry more than one
LSP Setup Request. The Message-Type field of the PCEP common header
for the PCUpd message is set to [TBD].
The format of a LSPSetupRq message is as follows:
<LSPSetupRq Message> ::= <Common Header>
<lspsetup-request-list>
Where:
<lspsetup-request-list> ::= <lspsetup-request>[<lspsetup-request-list>]
<lspsetup-request> ::= <SRQ>
<LSP>
[<attribute-list>]
Where:
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
<LSP> and <lable> are as defined in [RFC3209].
A PCC only acts on an LSP Setup Request if permitted by the local
policy configured by the network manager. Each LSP Setup Request
that the PCC acts on results in an LSP setup operation. An LSP Setup
Request MUST contain all LSP parameters that a PCE wishes to be set
for the LSP. A PCC MAY set missing parameters from locally
configured defaults. If the LSP specified in the Setup Request is
already up, it will be re-downloaded.
5.1.4. The LSP Delete Request Message
A LSP Delete Request message (also referred to as LSPDeleteRq
message) is a PCEP message sent by a PCC or an application to a PCE
to request the delete of an LSP. A LSPDeleteRq message can carry
more than one LSP Delete Request. The Message-Type field of the PCEP
common header for the PCUpd message is set to [TBD].
The format of a LSPDeleteRq message is as follows:
Zhao, et al. Expires August 5, 2014 [Page 14]
Internet-Draft PCECC November 2013
<LSPDeleteRq Message> ::= <Common Header>
<lspsetup-request-list>
Where:
<lspdelete-request-list> ::= <lspdelete-request>[<lspdelete-request-list>]
<lspdelete-request> ::= <SRQ>
<LSP>
There is one mandatory object that MUST be included within each LSP
delete Request in the LSPdeleteRq message: the LSPObject.
A PCE only acts on an LSP delete Request if permitted by the local
policy configured by the network manager. Each LSP Setup Request
that the PCC acts on results in an LSP delete operation. An LSP
delete Request MUST contain all LSP parameters that a PCE wishes to
be delete for the LSP. A PCE MAY set missing parameters from locally
configured defaults. If the LSP specified in the delete Request is
already delete, it will be assume the delete is done.
5.1.5. PCEP Extension for LFIB Entry Downloading
The LFIB Entry Downloading Message (also referred to as LfibDownLoad)
is a PCEP message sent by a PCE to a PCC to download the LFIB for a
LSP. The Message-Type field of the PCEP common header for the
LfibDownLoad message is set to [TBD].
The format of the LfibDownLoad message is as follows:
<LfibDownLoad Message> ::= <Common Header>
<LFIB-list>
Where:
<LFIB-list> ::= <LFIB>[<LFIB-lis>]
<LFIB>::= [<SRQ>]
<LSP>
<path>
Where:
<path>::= [in-label]<ERO>[out-label]<attribute-list>
Where:
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
The SRQ object is optional. If the LfibDownLoad message is not in
Zhao, et al. Expires August 5, 2014 [Page 15]
Internet-Draft PCECC November 2013
response to a LSPSetupRq message, the SRQ object MAY be omitted.
If the LfibDownLoad message is in response to a LSPSetuoRq message,
the SRQ object SHOULD be included and the value of the SRQ-ID-number
in the SRQ Object MUST be the same as that sent in the LfibDownLoad
message that triggered the LSP to be setup.
The LSP object is mandatory, and it MUST be included in each
Lfibbdownload message.
5.1.6. PCEP Extension for LFIB Entry Cleanup
The LFIB Entry Cleanup Message (also referred to as LfibDownLoad) is
a PCEP message sent by a PCE to a PCC to cleanup the LFIB for a LSP.
The Message-Type field of the PCEP common header for the LfibDownLoad
message is set to [TBD].
The format of the LfibCleanup message is as follows:
<LfibCleanup Message> ::= <Common Header>
<LFIB-list>
Where:
<LFIB-list> ::= <LFIB>[<LFIB-lis>]
<LFIB>::= [<SRQ>]
<LSP>
<path>
Where:
<path>::= [in-label]<ERO>[out-label]<attribute-list>
Where:
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
The SRQ object is optional. If the LfibCleanup message is not in
response to a LSPDeleteRq message, the SRQ object MAY be omitted.
If the LfibCleanup message is in response to a LSPDeleteRq message,
the SRQ object SHOULD be included and the value of the SRQ-ID-number
in the SRQ Object MUST be the same as that sent in the LfibCleanup
message that triggered the LSP to be setup.
The LSP object is mandatory, and it MUST be included in each
Lfibbdownload message.
Zhao, et al. Expires August 5, 2014 [Page 16]
Internet-Draft PCECC November 2013
5.1.7. The PCErr Message
[TBD]
5.2. Object Formats
The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440]. The P flag and the I flag of the
PCEP objects defined in this document MUST always be set to 0 on
transmission and MUST be ignored on receipt since these flags are
exclusively related to path computation requests.
5.2.1. OPEN Object
This document defines two new optional TLVs for use in the OPEN
Object.
5.2.1.1. PCECC Capability TLV
The PCECC-CAPABILITY TLV is an optional TLV for use in the OPEN
Object for PCECC capability advertisement. Its format 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=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value comprises a single field - Flags (32 bits):
U (LFIB-SETUP-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag
indicates that the PCC allows the download of LFIB; if
set to 1 by a PCE, the U Flag indicates that the PCE is capable of
download LFIB parameters. The LFIB-SETUP-CAPABILITY Flag must be
advertised by both a PCC and a PCE for LSPSetup/LfibDownload messages to be
allowed on a PCEP session.
Zhao, et al. Expires August 5, 2014 [Page 17]
Internet-Draft PCECC November 2013
Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt.
Advertisement of the PCECC capability implies support of LSPs that
are setup through PCECC, as well as the objects, TLVs and procedures
defined in this document.
5.2.2. SRQ Object
The details of format for the SRQ are [TBD].
6. IANA Considerations
[TBD].
7. Manageability Considerations
[TBD]
8. Security Considerations
[TBD]
9. Acknowledgments
We would like to thank Robert Tao, Changjing Yan, Tieying Huang for
their useful comments and suggestions.
10. References
10.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-06 (work in progress),
August 2013.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
10.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
Zhao, et al. Expires August 5, 2014 [Page 18]
Internet-Draft PCECC November 2013
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
Authors' Addresses
Quintin Zhao
Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
US
EMail: quintin.zhao@huawei.com
Katherine Zhao
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
EMail: Katherine.zhao@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
EMail: lizhenbin@huawei.com
Zhao, et al. Expires August 5, 2014 [Page 19]
Internet-Draft PCECC November 2013
Dhruv Dhody
Huawei Technologies
Leela Palace
Bagalore, Karnataka 560008
India
EMail: dhruv.ietf@gmail.com
Boris Zhang
Telus Ltd.
Toronto
Canada
EMail: Boris.Zhang@Boris.zhang@telus.com
Zhao, et al. Expires August 5, 2014 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 09:57:03 |