PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs
draft-zhao-pce-pcep-extension-for-pce-controller-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 "Replaced".
|
|
|---|---|---|---|
| Authors | Quintin Zhao , Katherine Zhao , Zhenbin Li , Dhruv Dhody , Udayasree Palle , Telus Communications | ||
| Last updated | 2015-10-07 | ||
| Replaced by | draft-ietf-pce-pcep-extension-for-pce-controller, RFC 9050 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-zhao-pce-pcep-extension-for-pce-controller-02
PCE Working Group Q. Zhao
Internet-Draft K. Zhao
Intended status: Experimental Z. Li
Expires: April 9, 2016 D. Dhody
U. Palle
Huawei Technologies
B. Zhang
Telus Ltd.
October 7, 2015
PCEP Procedures and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs
draft-zhao-pce-pcep-extension-for-pce-controller-02
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.zhao-pce-central-controller-user-cases], we propose to use the
PCE [RFC5440] as a central controller (PCECC) 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.
This document also discuss the role of PCECC in Segment Routing (SR).
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
Zhao, et al. Expires April 9, 2016 [Page 1]
Internet-Draft PCECC October 2015
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 9, 2016.
Copyright Notice
Copyright (c) 2015 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. PCECC Modes . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6
5. Procedures for Using the PCE as the Central Controller
(PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 7
5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 7
5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 8
5.4. Label Range Reservation . . . . . . . . . . . . . . . . . 8
5.5. PCEP session IP address and TEDB Router ID . . . . . . . 9
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 10
5.6.1. Basic PCECC Mode . . . . . . . . . . . . . . . . . . 10
5.6.1.1. PCECC LSP Setup . . . . . . . . . . . . . . . . . 10
5.6.1.2. Label Download . . . . . . . . . . . . . . . . . 11
5.6.1.3. Label Cleanup . . . . . . . . . . . . . . . . . . 11
5.6.1.4. PCE Initiated PCECC LSP . . . . . . . . . . . . . 12
5.6.1.5. PCECC LSP Update . . . . . . . . . . . . . . . . 13
5.6.1.6. PCECC LSP State Report . . . . . . . . . . . . . 14
5.6.2. PCECC Segment Routing (SR) . . . . . . . . . . . . . 15
5.6.2.1. PCECC SR-BE . . . . . . . . . . . . . . . . . . . 15
5.6.2.2. PCECC SR-TE . . . . . . . . . . . . . . . . . . . 16
6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. The PCLRResv message . . . . . . . . . . . . . . . . . . 17
6.2. The PCLabelUpd message . . . . . . . . . . . . . . . . . 18
Zhao, et al. Expires April 9, 2016 [Page 2]
Internet-Draft PCECC October 2015
7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 20
7.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . . 20
7.2. LABEL-RANGE Object . . . . . . . . . . . . . . . . . . . 21
7.3. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 21
7.4. Label Object . . . . . . . . . . . . . . . . . . . . . . 22
7.4.1. Address TLV . . . . . . . . . . . . . . . . . . . . . 23
7.5. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Manageability Considerations . . . . . . . . . . . . . . . . 26
9.1. Control of Function and Policy . . . . . . . . . . . . . 26
9.2. Information and Data Models . . . . . . . . . . . . . . . 26
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 26
9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 26
9.5. Requirements On Other Protocols . . . . . . . . . . . . . 26
9.6. Impact On Network Operations . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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.
Zhao, et al. Expires April 9, 2016 [Page 3]
Internet-Draft PCECC October 2015
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
[I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to
enable active control of MPLS-TE and GMPLS tunnels.
[I-D.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.ietf-pce-remote-initiated-gmpls-lsp] complements
[I-D.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.ietf-spring-segment-routing]
provides an introduction to SR technology. The corresponding IS-IS
and OSPF extensions are specified in
[I-D.ietf-isis-segment-routing-extensions] and
[I-D.ietf-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.ietf-pce-segment-routing].
PCECC may further use PCEP protocol for SR label distribution instead
of IGP extensions with some benefits.
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, PCE can be conveniently used as a central
Zhao, et al. Expires April 9, 2016 [Page 4]
Internet-Draft PCECC October 2015
controller with Label download capability. Further PCE can also be
used to manage the label range and SRGB etc.
The PCECC solution introduced in
[I-D.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.
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.
1.1. 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].
2. Terminology
The following terminology is used in this document.
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. PCECC Modes
The following PCECC modes are supported -
o Basic PCECC.
o PCECC SR.
* PCECC SR-BE (Best Effort).
Zhao, et al. Expires April 9, 2016 [Page 5]
Internet-Draft PCECC October 2015
* PCECC SR-TE (Traffic Engineered).
In basic PCECC mode, the forwarding is similar to RSVP-TE signalled
LSP without the RSVP-TE signaling. The PCECC allocates and download
the label entries along the LSP. The rest of processing is similar
to the existing stateful PCE mechanism.
In case of SR, there are two modes for SR-BE and SR-TE. For SR-BE,
the forwarding is similar to LDP LSP without LDP signaling or IGP-SR
extension. The SR Node label are allocated and distributed in the
domain centrally by the PCE via PCEP. Each node (PCC) rely on local
IGP for the nexthop calculation. For SR-TE, the forwarding uses
label stack similar to IGP based SR-TE without IGP-SR extension. The
SR node and adj labels are allocated and distributed in the domain
centrally by the PCE via PCEP by PCECC. Rest of the processing is
similar to existing stateful PCE with SR mechanism.
4. 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 Client (PCC) supporting this draft MUST have a
capability to communicate local label range or global label range
or both to PCE.
3. Path Computation Element (PCE) supporting this draft SHOULD have
the capability to negotiate a global label range for a group of
clients and communicate the final global label range to PCC.
4. PCEP speaker not supporting this draft MUST be able to reject
PCECC related message with a reason code that indicates no
support for PCECC.
5. PCEP SHOULD provide a means to identify PCECC based LSP in the
PCEP messages.
6. PCEP SHOULD provide a means to update (or cleanup) the label-
download or label-map entry to the PCC.
5. Procedures for Using the PCE as the Central Controller (PCECC)
Zhao, et al. Expires April 9, 2016 [Page 6]
Internet-Draft PCECC October 2015
5.1. Stateful PCE Model
Active stateful PCE is described in [I-D.ietf-pce-stateful-pce]. PCE
as a central controller (PCECC) reuses existing Active stateful PCE
mechanism as much as possible to control the LSP.
5.2. New LSP Functions
This document defines the following new PCEP messages and extends the
existing messages to support PCECC:
(PCLRResv): a PCEP message sent by a PCC to a PCE to ask for the
label range reservation or a PCE to a PCC to send the reserved
label range. The PCLRResv message described in Section 6.1.
(PCLabelUpd): a PCEP message sent by a PCE to a PCC to download or
cleanup the Label entry. The PCLabelUpd message described in
Section 6.2.
(PCRpt): a PCEP message described in [I-D.ietf-pce-stateful-pce].
PCRpt message MAYBE used to send PCECC LSP Reports.
(PCInitiate): a PCEP message described in
[I-D.ietf-pce-pce-initiated-lsp]. PCInitiate message is used to
setup PCE-Initiated LSP based on PCECC mechanism.
(PCUpd): a PCEP message described in [I-D.ietf-pce-stateful-pce].
PCUpd message is used to send PCECC LSP Update.
The new LSP functions defined in this document are mapped onto the
messages as shown in the following table.
+----------------------------------------+--------------------------+
| Function | Message |
+----------------------------------------+--------------------------+
| PCECC Capability advertisement | Open |
| Label Range Reservation | PCLRResv |
| Label entry Update | PCLabelUpd |
| Label entry Cleanup | PCLabelUpd |
| PCECC Initiated LSP | PCInitiate |
| PCECC LSP Update | PCUpd |
| PCECC LSP State Report | PCRpt |
| PCECC LSP Delegation | PCRpt |
+----------------------------------------+--------------------------+
Zhao, et al. Expires April 9, 2016 [Page 7]
Internet-Draft PCECC October 2015
5.3. 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 7.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 PCECC server.
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 message with Error-Type=19(Invalid Operation) and Error-
Value=[TBD] (Attempted LSP setup/download/label-range reservation if
PCECC capability was not advertised) will be generated and the PCEP
session will be terminated.
L flag and G flag defined in PCECC Capability TLV specifies the local
and global label range reservation capability.
A PCC or a PCE MUST include both PCECC-CAPABILITY TLV and STATEFUL-
PCE-CAPABILITY TLV in OPEN Object to support the extensions defined
in this document. If PCECC-CAPABILITY TLV is advertised and
STATEFUL-PCE-CAPABILITY TLV is not advertised in OPEN Object, it
SHOULD send a PCErr message with Error-Type=19 (Invalid Operation)
and Error-value=[TBD](stateful pce capability was not advertised) and
terminate the session.
5.4. Label Range Reservation
After PCEP initial state synchronization, the label range is
reserved.
If L flag is advertised in OPEN Object by PCEP speakers, a PCC
reserves a local label range and is communicated using PCLRResv
message to a PCE. The PCE maintains the local label range of each
node and further during LSP setup, a label is assigned to each node
from the corresponding local label range reserved.
If G flag is advertised in OPEN Object by PCEP speakers,a PCC
reserves a global label range and is advertised in PCLRResv message
to a PCE. The PCE MAY negotiate and reserves the global label range
Zhao, et al. Expires April 9, 2016 [Page 8]
Internet-Draft PCECC October 2015
and also sends the negotiated global label range in PCLRResv message
to the PCC. Please refer [I-D.li-mpls-global-label-framework] for
MPLS global label allocation.
A PCC MUST send PCLRResv message immediately after the initial LSP
synchronization completion. A PCE SHOULD not send PCLabelUpd message
to a PCC before PCLRResv message received. If the PCC received
PCLabelUpd message and not initiated label range reservation, it
SHOULD send a PCErr message with Error-type=[TBD] (label range not
reserved) and Error-value=[TBD].
The label range reservation sequence is shown below.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--- PCLRResv, label type=1 --->|local label range reserved
| (100-500) |global label range negotiated
| label type=2 |
| (600-1000) |
| |
|<--- PCLRResv, label type=2 ---|global label range reserved
| (700-1000) |
| |
[Editor's Note: This section of the document would be updated with
more details about Label Block Negotiation, Reservation, Adjustment
etc in a future revision of the document.]
5.5. PCEP session IP address and TEDB Router ID
PCE may construct its TEDB by participating in the IGP ([RFC3630]
and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An
alternative is offered by BGP-LS [I-D.ietf-idr-ls-distribution] and
[I-D.dhodylee-pce-pcep-ls].
PCEP [RFC5440] speaker MAY use any IP address while creating a TCP
session. It is important to link the session IP address with the
Router ID in TEDB for successful PCECC operations.
During PCEP Initialization Phase, PCC advertise the TEDB mapping
information. A PCC includes the "Local Node Descriptors TLV"
described in [I-D.dhodylee-pce-pcep-ls], in the OPEN Object for this
purpose. Various node descriptor sub-TLV are defined in
Zhao, et al. Expires April 9, 2016 [Page 9]
Internet-Draft PCECC October 2015
[I-D.dhodylee-pce-pcep-ls] which can be used to map the PCEP session
to the node in the TEDB.
If this TLV is not present, the session IP address is directly used
for the mapping purpose.
5.6. LSP Operations
The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE
TLV [I-D.sivabalan-pce-lsp-setup-type] in the SRP object to clearly
identify the PCECC LSP is intended.
5.6.1. Basic PCECC Mode
5.6.1.1. PCECC LSP Setup
Inorder to setup a LSP based on PCECC mechanism, a PCC MUST delegate
the LSP by sending a PCRpt message with Path Setup Type set for basic
PCECC (see Section 7.3) and D (Delegate) flag (see
[I-D.ietf-pce-stateful-pce]) set in the LSP object.
The LSP-ID in LSP-IDENTIFIER TLV (which usually corresponds to the
RSVP-TE LSP-ID) for PCECC LSP MUST always be generated by the PCE.
In the first PCRpt message of PCECC LSP, LSP ID of LSP-IDENTIFIER TLV
is set to zero.
When a PCE received PCRpt message with P and D flags set, it
generates LSP ID; calculates the path and assign labels along the
path; and setup the path by sending PCLabelUpd message to each node
along the path of the LSP.
The PCE SHOULD send the PCUpd message with the same PLSP-ID to the
Ingress PCC in response to the delegate PCRpt message.
The PCECC LSPs MUST be delegated to a PCE at all times.
LSP deletion operation for PCECC LSP is same as defined in
[I-D.ietf-pce-stateful-pce]. If the PCE received PCRpt message for
LSP deletion then it does Label cleanup operation as described in
Section 5.6.1.3 for the corresponding LSP.
The Basic PCECC LSP setup sequence is as shown below.
Zhao, et al. Expires April 9, 2016 [Page 10]
Internet-Draft PCECC October 2015
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |--- PCRpt,PLSP-ID=1, P=1, D=1 --->| PCECC LSP
|PCC +--------+ | (LSP ID=0) |(LSPID=1)
|Egress | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd,PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1) | download
| | | |
| |<----- PCLabelUpd,PLSP-ID=1 ----------- | Label
| | | (LSP ID=1) | download
| | | |
| | |<--- PCLabelUpd,PLSP-ID=1 ------- | Label
| | | (LSP ID=1) | download
| | | |
| | |<-- PCUpd,PLSP-ID=1, P=1, D=1 ---- | PCECC LSP
| | | (LSP ID=1) | Update
| | | |
The PCECC LSP are considered to be 'up' by default. The Ingress MAY
further choose to deploy a data plane check mechanism and report the
status back to the PCE via PCRpt message.
5.6.1.2. Label Download
Inorder to setup an LSP based on PCECC, the PCE sends a PCLabelUpd
message to each node of the LSP to download the Label entry as
described in Section 5.6.1.1.
The LSP object in PCLabelUpd MUST include the LSP-IDENTIFIER TLV.
If a node (PCC) received a PCLabelUpd message but failed to download
the Label entry, it MUST send a PCErr message with Error-type=[TBD]
(label download failed) and Error-value=[TBD].
5.6.1.3. Label Cleanup
Inorder to delete an LSP based on PCECC, the PCE sends a PCLabelUpd
message to each node along the path of the LSP to cleanup the Label
entry.
Zhao, et al. Expires April 9, 2016 [Page 11]
Internet-Draft PCECC October 2015
If the PCC received a PCLabelUpd message but does not recognize the
label, the PCC MUST generate a PCErr message with Error-Type
19(Invalid operation) and Error-Value=3, "Unknown Label".
The R flag in SRP object defined in [I-D.ietf-pce-pce-initiated-lsp]
specifies the deletion of Label Entry in the PCLabelUpd message.
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| PCECC LSP
|PCC +--------+ | (LSP ID=1) | remove
|Egress | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
5.6.1.4. PCE Initiated PCECC LSP
The LSP Instantiation operation is same as defined in
[I-D.ietf-pce-pce-initiated-lsp].
Inorder to setup a PCE Initiated LSP based on PCECC mechanism, a PCE
sends PCInitiate message with Path Setup Type set for basic PCECC
(see Section 7.3) to the Ingress PCC.
The Ingress PCC MUST also set D (Delegate) flag (see
[I-D.ietf-pce-stateful-pce]) and C (Create) flag (see
[I-D.ietf-pce-pce-initiated-lsp]) in LSP object of PCRpt message.
The PCC responds with first PCRpt message with the status as "GOING-
UP" and assigned PLSP-ID.
The rest of the PCECC LSP setup operations are same as those
described in Section 5.6.1.1.
Zhao, et al. Expires April 9, 2016 [Page 12]
Internet-Draft PCECC October 2015
The LSP deletion operation for PCE Initiated PCECC LSP is same as
defined in [I-D.ietf-pce-pce-initiated-lsp]. The PCE should further
perform Label entry cleanup operation as described in Section 5.6.1.3
for the corresponding LSP.
The PCE Initiated PCECC LSP setup sequence is shown below.
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |<---PCInitiate,PLSP-ID=0,P=1,D=1---| PCECC LSP
|PCC +--------+ | | Initiate
|Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1--->| PCECC LSP
+--------+ | | (LSP ID=0,GOING-UP) |(LSPID=2
| | | | assigned)
|<------ PCLabelUpd, PLSP-ID=2 ------------------ | Label
| | | (LSP ID=2) | download
| | | |
| |<----- PCLabelUpd, PLSP-ID=2 ----------- | Label
| | | (LSP ID=2) | download
| | | |
| | |<--- PCLabelUpd, PLSP-ID=2 ------- | Label
| | | (LSP ID=2) | download
| | | |
| | |<-- PCUpd, PLSP-ID=2, P=1, D=1---- | PCECC LSP
| | | (LSP ID=2) | Update
| | | |
5.6.1.5. PCECC LSP Update
Incase of a modification of PCECC LSP with a new path, a PCE sends a
PCUpd message to the Ingress PCC.
When a PCC received a PCUpd message for an existing LSP, a PCC MUST
follow the make-before-break procedure. On successful traffic switch
over to the new LSP, PCC sends a PCRpt message to the PCE for the
deletion of old LSP. Further the PCE does cleanup operation for the
old LSP described in Section 5.6.1.3.
The PCECC LSP Update and make-before-break sequence is shown below.
Zhao, et al. Expires April 9, 2016 [Page 13]
Internet-Draft PCECC October 2015
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | | |
|PCC +--------+ | |
|Egress | | | |
+--------+ | | |
| | | | Modify LSP
|<------ PCLabelUpd, PLSP-ID=1 ------------------ | (LSPID=3
| | | (LSP ID=3) | assigned)
| | | |
| |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label
| | | (LSP ID=3) | download
| | | |
| | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label
| | | (LSP ID=3) | download
| | | |
| | |<-- PCUpd, PLSP-ID=1, P=1, D=1---- | PCECC
| | | (LSP ID=3) | LSP Update
| | | |
| | |--- PCRpt,PLSP-ID=1,P=1,D=1,R=1--->| Delete
| | | (LSP ID=1) | old LSP
| | | |
|<------ PCLabelUpd, PLSP-ID=1 ------------------ | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| |<----- PCLabelUpd, PLSP-ID=1 ----------- | Label
| | | (LSP ID=1, R=1) | cleanup
| | | |
| | |<--- PCLabelUpd, PLSP-ID=1 ------- | Label
| | | (LSP ID=1, R=1) | cleanup
The modified PCECC LSP are considered to be 'up' by default. The
Ingress MAY further choose to deploy a data plane check mechanism and
report the status back to the PCE via PCRpt message.
5.6.1.6. PCECC LSP State Report
As mentioned before, an Ingress PCC MAY choose to apply any OAM
mechanism to check the status of LSP in the Data plane and MAY
further send its status in PCRpt message to the PCE.
Zhao, et al. Expires April 9, 2016 [Page 14]
Internet-Draft PCECC October 2015
5.6.2. PCECC Segment Routing (SR)
Segment Routing (SR) as described in
[I-D.ietf-spring-segment-routing] depends on "segments" that are
advertised by Interior Gateway Protocols (IGPs). The SR-node
allocate and advertise the SID (node, adj etc) and flood via the IGP.
This document proposes a new mechanism where PCE allocate the SID
(label) centrally and uses PCEP to advertise the SID. In some
deployments PCE (and PCEP) are better suited than IGP because of
centralized nature of PCE and direct TCP based PCEP session to the
node.
5.6.2.1. PCECC SR-BE
Each node (PCC) is allocated a node-SID (label) by the PCECC. The
PCECC sends PCLabelUpd to update the label map of each node to all
the nodes in the domain. The Node IP address is determined from the
TEDB using the maping information in the "Local Node Descriptors TLV"
described in [I-D.dhodylee-pce-pcep-ls].
It is RECOMMENDED that PCEP session with PCECC SR capability to use a
different session IP address during TCP session establishment than
the node Router ID in TEDB, to make sure that the PCEP session does
not get impacted by the SR-BE node label maps.
On receiving the label map, each node (PCC) uses the local
information to determines the next-hop and download the label
forwarding instructions accordingly. The PCLabelUpd message in this
case MUST not have LSP object but uses new FEC object.
Zhao, et al. Expires April 9, 2016 [Page 15]
Internet-Draft PCECC October 2015
+-------+ +-------+
|PCC | | PCE |
|3.3.3.3| +-------+
+------| | |
| PCC +-------+ |
| 2.2.2.2| | |
+------| | | |
|PCC +--------+ | |
|1.1.1.1 | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd, FEC=1.1.1.1----------------- | Label Map
| | | Label=X | update
|Find | | |
|Nexthop|<----- PCLabelUpd, FEC=1.1.1.1---------- | Label Map
|locally| | Label=X | update
| | | |
| | |<--- PCLabelUpd, FEC=1.1.1.1------ | Label Map
| | | Label=X | update
| | | |
The forwarding behavior and the end result is similar to IGP based
"Node-SID" in SR. Thus, from anywhere in the domain, it enforces the
ECMP-aware shortest- path forwarding of the packet towards the
related node.
PCE rely on the Node label cleanup using the same PCLabelUpd message.
5.6.2.2. PCECC SR-TE
A Segment Routed Best Effort path (SR-BE path) can be derived from an
IGP Shortest Path Tree (SPT) as explained above. On the other hand,
SR-TE paths may not follow IGP SPT. Such paths may be chosen by a
PCE and provisioned on the source node of the SR-TE path.
[I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE
to compute and initiate SR-TE paths, as well as a PCC to request a
path subject to certain constraint(s) and optimization criteria in SR
networks.
For SR-TE, apart from node-SID, Adj-SID is used where each adjacency
is allocated an Adj-SID (label) by the PCECC. The PCECC sends
PCLabelUpd to update the label map of each Adj to the corresponding
nodes in the domain. Each node (PCC) download the label forwarding
instructions accordingly. Similar to SR-BE, the PCLabelUpd message
in this case MUST not have LSP object but uses new FEC object.
Zhao, et al. Expires April 9, 2016 [Page 16]
Internet-Draft PCECC October 2015
+-------+ +-------+
|PCC | | PCE |
|3.3.3.3| +-------+
+------| | |
| PCC +-------+ |
| 2.2.2.2| | |
+------| | | |
|PCC +--------+ | |
|1.1.1.1 | | | |
+--------+ | | |
| | | |
|<------ PCLabelUpd, FEC=10.1.1.1 / ------------- | Label Map
| | | 10.1.1.2 | update
| | | Label=A |
| | | |
| |<----- PCLabelUpd, FEC=10.1.1.2--------- | Label Map
| | | 10.1.1.1 | update
| | | Label=B |
| | | |
The forwarding behavior and the end result is similar to IGP based
"Adj-SID" in SR.
The Path Setup Type MUST be set for PCECC SR-TE (see Section 7.3).
The rest of the PCEP procedures and mechanism are similar to
[I-D.ietf-pce-segment-routing].
PCE rely on the Adj label cleanup using the same PCLabelUpd message.
6. PCEP messages
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.
6.1. The PCLRResv message
A Label Range Reservation message (also referred to as PCLRResv
message) is a PCEP message sent by a PCC to a PCE for the reservation
of label range or by PCE to PCC to send reserved label range for the
network. The Message-Type field of the PCEP common header for the
PCLRResv message is set to [TBD].
Zhao, et al. Expires April 9, 2016 [Page 17]
Internet-Draft PCECC October 2015
The format of a PCLRResv message is as follows:
PCLRResv Message>::= <Common Header>
<label-range>
Where:
<label-range> ::= <SRP>
<labelrange-list>
Where
<labelrange-list>::=<LABEL-RANGE>[<labelrange-list>]
There are two mandatory objects that MUST be included within each
<label-range> in the PCLRResv message: the SRP Object and LABEL-RANGE
object.
SRP object is defined in [I-D.ietf-pce-stateful-pce] and this
document extends the use of SRP object in PCLRResv message. If the
SRP object is missing, the receiving PCE MUST send a PCErr message
with Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP
object missing).
PCC generates the value of SRP-ID-number in SRP object of PCLRResv
message send to a PCE. The PCE MUST include the same SRP-ID-number
in SRP object of PCLRResv message sent to the PCC in response to
PCLRResv message.
LABEL-RANGE object is defined in Section 7.2. If the LABEL-RANGE
object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (Label
object missing).
[Editor's Note: This section of the document would be updated with
more details about Label Block Negotiation, Reservation, Adjustment
etc in a future revision of the document.]
6.2. The PCLabelUpd message
The Label Update Message (also referred to as PCLabelUpd) is a PCEP
message sent by a PCE to a PCC to download label or update the label
map. The same message is also used to cleanup the Label entry. The
Message-Type field of the PCEP common header for the PCLabelUpd
message is set to [TBD].
The format of the PCLabelUpd message is as follows:
Zhao, et al. Expires April 9, 2016 [Page 18]
Internet-Draft PCECC October 2015
<PCLabelUpd Message> ::= <Common Header>
<pce-label-update-list>
Where:
<pce-label-update-list> ::= <pce-label-update>
[<pce-label-update-list>]
<pce-label-update> ::= (<pce-label-download>|<pce-label-map>)
Where:
<pce-label-download> ::= <SRP>
<LSP>
<label-list>
<pce-label-map> ::= <SRP>
<LABEL>
<FEC>
<label-list > ::= <LABEL>
[<label-list>]
The PCLabelUpd message is used to download label along the path of
the LSP for the basic PCECC mode, as well as to update the label map
for the Node and Adjacency Label in case of SR.
The SRP object is defined in [I-D.ietf-pce-stateful-pce] and this
document extends the use of SRP object in PCLabelUpd message. The
SRP object is mandatory and MUST be included in PCLabelUpd message.
If the SRP object is missing, the receiving PCC MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error-
value=10 (SRP object missing).
The LSP object is defined in [I-D.ietf-pce-stateful-pce] and this
document extends the use of LSP object in PCLabelUpd message. The
LSP is an optional object and used in the basic PCECC mode in
PCLabelUpd message. LSP Identifiers TLV is defined in
[I-D.ietf-pce-stateful-pce], it MUST be included in the LSP object in
PCLabelUpd message. If the TLV is missing, the PCC will generate a
PCErr message with Error-Type=6 (mandatory object missing) and Error-
Value=11 (LSP-IDENTIFIERS TLV missing) and close the session.
The LABEL object is defined in Section 7.4. The LABEL is the
mandatory object and MUST be included in PCLabelUpd message. If the
LABEL object is missing, the receiving PCC MUST send a PCErr message
with Error-type=6 (Mandatory Object missing) and Error-value=[TBD]
(LABEL object missing). More than one LABEL object MAY be included
in the PCLabelUpd message for the transit LSR.
Zhao, et al. Expires April 9, 2016 [Page 19]
Internet-Draft PCECC October 2015
The FEC object is defined in Section 7.5. The FEC is an optional
object and used in PCECC SR mode in PCLabelUpd message. The FEC
object encodes the Node and Adjacency information of the Label Map.
To cleanup the SRP object must set the R (remove) bit.
7. PCEP Objects
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.
7.1. OPEN Object
This document defines a new optional TLVs for use in the OPEN Object.
7.1.1. PCECC Capability TLV
The PCECC-CAPABILITY TLV is an optional TLV for use in the OPEN
Object for PCECC capability advertisement. Advertisement of the
PCECC capability implies support of LSPs that are setup through PCECC
as per PCEP extensions defined in this document.
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 |G|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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):
L (LOCAL-LABEL-RANGE-CAPABILITY - 1 bit): If set to 1 by a PCEP
speaker, it indicates that the PCEP speaker is capable for local
label range reservation.
G (GLOBAL-LABEL-RANGE-CAPABILITY - 1 bit): If set to 1 by a PCEP
speaker, it indicates that the PCEP speaker capable for global
label range reservation.
Zhao, et al. Expires April 9, 2016 [Page 20]
Internet-Draft PCECC October 2015
Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt.
7.2. LABEL-RANGE Object
The LABEL-RANGE object MUST be carried within PCLRResv message. The
LABEL-RANGE object is used to carry the label range information based
on the label type.
LABEL-RANGE Object-Class is TBD.
LABEL-RANGE Object-Type is 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| label type | range size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| label base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
label type (8 bit): The values defined for label type are label type
1 specifies the local label. It means the label range is non
negotiable. label type 2 specifies the global label. It means
the label range is negotiable. Refer
[I-D.li-mpls-global-label-framework] for global label.
Range size (24 bit): It specifies the size of label range.
Label base (32 bit): It specifies the minimum label of label range.
7.3. PATH-SETUP-TYPE TLV
The PATH-SETUP-TYPE TLV is defined in
[I-D.sivabalan-pce-lsp-setup-type]; this document defines following
new PST value:
o PST = 2: Path is setup via Basic PCECC mode.
o PST = 3: Path is setup via PCECC SR-TE mode.
Zhao, et al. Expires April 9, 2016 [Page 21]
Internet-Draft PCECC October 2015
On a PCRpt or PCInitiate message, the PST=2 in PATH-SETUP-TYPE TLV in
SRP object indicates that this LSP was setup via a basic PCECC based
mechanism; the PST=3 indicates that this LSP was setup via a PCECC
SR-TE based mechanism.
7.4. Label Object
The LABEL Object is used to specify the Label information and MUST be
carried within PCLabelUpd message.
LABEL Object-Class is TBD.
LABEL Object-Type is 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the LABEL object are as follows:
Flags: is used to carry any additional information pertaining to the
label. Currently, the following flag bit is defined:
* O bit(Out-label) : If the bit is set, it specifies the label is
the OUT label and it is mandatory to encode the nexthop
information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or
UNNUMBERED-IPV4-ID-ADDRESS TLV in LABEL object). If the bit is
not set, it specifies the label is the IN label and it is
optional to encode the local interface information (via
IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID-
ADDRESS TLV in LABEL object).
Label (32-bit): The Label information encoded such that the 20
rightmost bits represent a label.
Zhao, et al. Expires April 9, 2016 [Page 22]
Internet-Draft PCECC October 2015
7.4.1. Address TLV
This document defines the following TLV for the LABEL object to
associate the nexthop information incase of an outgoing label and
local interface information incase of an incoming label.
IPV4-ADDRESS TLV:
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 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPV6-ADDRESS TLV:
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 = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv6 address (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UNNUMBERED-IPV4-ID-ADDRESS TLV:
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 = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The address TLVs are as follows:
IPV4-ADDRESS TLV: an IPv4 address.
IPV6-ADDRESS TLV: an IPv6 address.
Zhao, et al. Expires April 9, 2016 [Page 23]
Internet-Draft PCECC October 2015
UNNUMBERED-IPV4-ID-ADDRESS TLV: a pair of Node ID / Interface ID
tuples.
7.5. FEC Object
The FEC Object is used to specify the FEC information and MAY be
carried within PCLabelUpd message.
FEC Object-Class is TBD.
FEC Object-Type is 1 'IPv4 Node ID'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 2 'IPv6 Node ID'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv6 Node ID (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 3 'IPv4 Adjacency'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 4 'IPv6 Adjacency'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Local IPv6 address (16 bytes) //
| |
Zhao, et al. Expires April 9, 2016 [Page 24]
Internet-Draft PCECC October 2015
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Remote IPv6 address (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 5 'Unnumbered Adjacency with IPv4 NodeIDs'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FEC objects are as follows:
IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of
the Node. FEC Object-type is 1, and the Object-Length is 4 in
this case.
IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of
the Node. FEC Object-type is 2, and the Object-Length is 16 in
this case.
IPv4 Adjacency: where Local and Remote IPv4 address is specified as
pair of IPv4 address of the adjacency. FEC Object-type is 3, and
the Object-Length is 8 in this case.
IPv6 Adjacency: where Local and Remote IPv6 address is specified as
pair of IPv6 address of the adjacency. FEC Object-type is 4, and
the Object-Length is 32 in this case.
Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID /
Interface ID tuples is used. FEC Object-type is 5, and the
Object-Length is 16 in this case.
8. Security Considerations
TBD
Zhao, et al. Expires April 9, 2016 [Page 25]
Internet-Draft PCECC October 2015
9. Manageability Considerations
9.1. Control of Function and Policy
TBD.
9.2. Information and Data Models
TBD.
9.3. Liveness Detection and Monitoring
TBD.
9.4. Verify Correct Operations
TBD.
9.5. Requirements On Other Protocols
TBD.
9.6. Impact On Network Operations
TBD.
10. IANA Considerations
TBD
11. Acknowledgments
We would like to thank Robert Tao, Changjing Yan, Tieying Huang for
their useful comments and suggestions.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
Zhao, et al. Expires April 9, 2016 [Page 26]
Internet-Draft PCECC October 2015
[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-11 (work in progress), April 2015.
[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-04 (work in
progress), April 2015.
[I-D.dhodylee-pce-pcep-ls]
Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for
Distribution of Link-State and TE Information.", draft-
dhodylee-pce-pcep-ls-00 (work in progress), September
2015.
[I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-12
(work in progress), October 2015.
12.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>.
[I-D.li-mpls-global-label-framework]
Li, Z., Zhao, Q., Chen, X., Yang, T., and R. Raszuk, "A
Framework of MPLS Global Label", draft-li-mpls-global-
label-framework-02 (work in progress), July 2014.
Zhao, et al. Expires April 9, 2016 [Page 27]
Internet-Draft PCECC October 2015
[I-D.zhao-pce-central-controller-user-cases]
Zhao, Q., Li, Z., Ke, Z., Fang, L., Zhou, C., and T.
Communications, "The Use Cases for Using PCE as the
Central Controller(PCECC) of LSPs", draft-zhao-pce-
central-controller-user-cases-02 (work in progress), July
2015.
[I-D.ietf-pce-remote-initiated-gmpls-lsp]
Ali, Z., Sivabalan, S., Filsfils, C., Varga, R., Lopez,
V., Dios, O., and X. Zhang, "Path Computation Element
Communication Protocol (PCEP) Extensions for remote-
initiated GMPLS LSP Setup", draft-ietf-pce-remote-
initiated-gmpls-lsp-01 (work in progress), July 2015.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-05 (work in progress),
September 2015.
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-05 (work in progress), June 2015.
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-05 (work in progress), June 2015.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
"PCEP Extensions for Segment Routing", draft-ietf-pce-
segment-routing-06 (work in progress), August 2015.
[I-D.sivabalan-pce-lsp-setup-type]
Sivabalan, S., Medved, J., Minei, I., Crabbe, E., and R.
Varga, "Conveying path setup type in PCEP messages",
draft-sivabalan-pce-lsp-setup-type-02 (work in progress),
June 2014.
Zhao, et al. Expires April 9, 2016 [Page 28]
Internet-Draft PCECC October 2015
Authors' Addresses
Quintin Zhao
Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
USA
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
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
EMail: dhruv.ietf@gmail.com
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
EMail: udayasree.palle@huawei.com
Zhao, et al. Expires April 9, 2016 [Page 29]
Internet-Draft PCECC October 2015
Boris Zhang
Telus Ltd.
Toronto
Canada
EMail: boris.zhang@telus.com
Zhao, et al. Expires April 9, 2016 [Page 30]