One document matched: draft-tanaka-pce-stateful-pce-data-ctrl-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3209 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml'>
<!ENTITY rfc4872 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4872.xml'>
<!ENTITY rfc5440 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml'>
<!ENTITY I-D.ietf-pce-stateful-pce PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-stateful-pce-05.xml'>
<!ENTITY I-D.crabbe-pce-pce-initiated-lsp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.crabbe-pce-pce-initiated-lsp.xml'>
<!ENTITY I-D.tanaka-pce-stateful-pce-mbb PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tanaka-pce-stateful-pce-mbb.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-tanaka-pce-stateful-pce-data-ctrl-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='yes'?>
<front>
<title abbrev="Data Control using Stateful PCE">
Stateful PCE Extensions for Data Plane Switchover and Balancing
</title>
<author initials='Y.T' surname="Tanaka" fullname='Yosuke Tanaka'>
<organization abbrev="NTT Communications">
NTT Communications Corporation
</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>yosuke.tanaka@ntt.com</email>
</address>
</author>
<author initials='Y.K' surname="Kamite" fullname='Yuji Kamite'>
<organization abbrev="NTT Communications">
NTT Communications Corporation
</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>y.kamite@ntt.com</email>
</address>
</author>
<author initials='I.M' surname="Minei" fullname='Ina Minei'>
<organization abbrev="Juniper Networks, Inc.">
Juniper Networks, Inc.
</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<region>Sunnyvale, CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>ina@juniper.net</email>
</address>
</author>
<date day="15" month="Jul" year="2013"/>
<abstract>
<t>
Stateful PCE (Path Computation Element) and its corresponding protocol extensions
provide a mechanism that enables PCE to do stateful control of MPLS Traffic
Engineering Label Switched Paths (TE LSP). One application that stateful PCE can
realize is data traffic reoptimization. Data traffic traversed in a LSP can be
switched to another PCE-initiated LSP. Moreover, data traffic can also be balanced
to multiple PCE-initiated LSPs using stateful PCE.
</t>
<t>
This document specifies the extensions to Path Computation Element Protocol
(PCEP) that allow a stateful PCE to do switchover and balancing of data traffic
with PCE-initiated LSPs. This document also specifies the usage and handling
of stateful PCEP (PCE Communication Protocol) messages and the expected behavior
of PCC as the RSVP-TE headend.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
<xref target="I-D.ietf-pce-stateful-pce"/> describes the stateful Path
Computation Elements(PCE). Stateful PCE defines the extensions to PCEP to
enable stateful control of LSPs between and across PCEP sessions, and it
also describes mechanisms to effect LSP state synchronization between
PCCs and PCEs, and PCE control of timing and sequence of path computations
within and across PCEP sessions. A PCE can update LSP settings (such as bandwidth,
priority) using update messages calle PCUpd.
</t>
<t>
<xref target="I-D.crabbe-pce-pce-initiated-lsp"/> defines the exensions to
PCEP to allow a PCE to create new LSPs (PCE-Initiated LSP). Before these extensions,
the LSP egress point had to be preconfigured at the head end Label Edge Router (LER),
the LSP would be set up with default parameters and then
its settings (e.g., initial bandwidth, priority) could be modified via PCUpd
messages. The extensions for PCE-initated LSPs eliminate the need for preconfiguration,
and allow more flexible operation. Stateful-PCE with LSP instantiation is attracting attention as
an enabler for Software Defined Networking (SDN) operation of MPLS networks.
</t>
<t>
In SDN, it is highly expected to support intelligent and interactive control of
the traffic amount of the network by means of a logically-centralized controller.
Optimizing the path and bandwidth of MPLS-TE LSP by using stateful PCE is a
leading use case of SDN applications. A PCE is able to calculate an optimized route
from the topology and bandwidth information in the TED and the LSP state database
and it can integrate with a controller that takes into account additional information
such as historical trending and service orders in order to trigger PCE action.
For example, when data traffic on a LSP counts plenty of bandwidth utilization and
if there is no capacity left in the currently signaled path (i.e., no remaining
bandwidth of links), a PCE is able to update the existing LSP's parameters
(PCE-updated LSP) or create a totally new LSP (PCE-initiated LSP).
</t>
<t>
The former method is oriented for keeping the existing instance of LSP tunnel,
so it does not change a pair of source and destination. Meanwhile, the latter method
is oriented for adding a new instance of LSP tunnel.
</t>
<t>
Specifically regarding the latter method, PCE-initiated LSP, there are some
operational scenarios in the network: one is that PCE creates a new LSP that have
alternate route with increased-bandwidth LSP and performs switchover from old LSP.
Another is that PCE creates one or more additional LSPs and performs load balancing
of data traffic.
Today, however, there is no detailed procedure specified as to how to control data
traffic switching from an old LSP to new PCE-Initiated LSP(s).
</t>
<t>
This document specifies the procedures that stateful PCE controls data
traffic switchover and load balancing with multiple PCE-Initiated LSPs.
This document also specifies the usage and handling of stateful PCEP (
PCE Communication Protocol) messages and the expected behavior of PCC as an
RSVP-TE headend.
</t>
</section>
<section title="Conventions used in this document">
<t>
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<xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>
This document uses the following terms defined in <xref target="RFC5440"/>: PCC, PCE, PCEP Peer.
</t>
<!-- <t>
This document uses the following terms defined in <xref target="RFC4426"/> and
<xref target="RFC4427"/>: recovery, protection, restoration.
</t>
<t>
According to their definition the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are used only when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery period. Hence the protection allocates LSP resource in advance of a failure, while the restoration allocates LSP after a failure occur.
</t>
-->
<t>
This document uses the following terms defined in <xref target="I-D.ietf-pce-stateful-pce"/>: Stateful PCE, LSP State Request, LSP Update Request.
</t>
<!-- <t>
This document uses the following terms defined in <xref target="I-D.crabbe-pce-stateful-pce-mpls-te"/>: LSP Identifiers TLV.
</t>
-->
<t>
This document uses the following terms defined in <xref target="I-D.crabbe-pce-pce-initiated-lsp"/>: LSP Create Request message.
</t>
<t>
The message formats in this document are specified using Backus-Naur Format (BNF) encoding as specified in [RBNF].
</t>
</section>
<section title="PCEP Operation for Data Switchover and Balancing">
<t>
There are two typical operations for explaining the functionality of data
switchover and balancing. One is whole data switchover, where a PCC switches
all data traffic from one LSP tunnel to another. The other is load balancing
of multi-pathing LSP tunnels, where a PCC (headend) balances data traffic among
two tunnels equally (fifty percent each, for instance). Both operational cases
are completed by the messaging over a single protocol, PCEP, so this is a simple
and straightforward solution for MPLS networks.
</t>
<!-- Negotiation (Capability bit ) is out of scope at this moment. -->
<t>
Support of the procedures listed in this document is negotiated at session init time.
The capability negotiation will be speleld out in a future version of this document.
</t>
<t>
Data switchover and balancing for an MPLS-TE LSP is available once a PCEP session
is established and then a PCC delegates its LSPs to a PCE. <!--Delegated LSPs MUST be ready for data switchover and balancing.-->
</t>
<t>
First step is LSP creation. In this step, a PCE sends as many PCInitiate messages as
PCE-Initiated LSP as it demands. Once the PCC receives them and successfully establishes
PCE-Initiated LSPs, it sends PCRpt messages in reply to the PCInitiate messages and
delegates the newly established LSP to the PCE. Message formats and behaviors of the
PCC and the PCE are described in detail in <xref target="I-D.crabbe-pce-pce-initiated-lsp"/>.
</t>
<t>
Second step is LSP association. After the PCE-Initiated LSP sucessfully established
and delegated the PCE sends a PCUpd message that
contains the ASSOCIATION-GROUP TLV in the LSP Object in order to assemble
the members of an association group of LSPs to take over the traffic.
Once a PCC receives the PCUpd message with ASSOCIATION-GROUP TLV, the PCC sends back
a PCRpt message that contains the ASSOCIATION-GROUP TLV with current operational status.
</t>
<t>
The option of specifying the association at LSP instantiation time (as part of the
PCInitiate message) will be evaluated in a future version of this document.
</t>
<t>
Third step is executing the data switchover and/or load balancing. In this step,
the PCE sends a single PCUpd message which updates the operational status of the
LSP from "up and carrying traffic" to just "up".
This Update request message for data plane switchover/balancing execution MUST
contain DATA-CONTROL TLV in LSP Object. The associated group of traffic origin
and that of target to take over the traffic are listed in the DATA-CONTROL TLV.
The PCC (LSP headend) load-balances between LSPs in the same association group
based on their respective bandwidths.
If one of the LSPs does not come up, the traffic would load balance correctly
over the others. The switchover case is supported since there will be an
association of a single LSP, so that LSP will get hundred percent of data traffic.
<!--The PCUpd message MUST contain at least two LSP objects: one represents the LSP
of traffic origin, which carries current data traffic, and the other represents
the LSPs on which whole or a part of data traffic will be carried. Each LSP
Object in the PCUpd message MUST contain DATA-CONTROL TLV in order to specify
which LSP is traffic origin or target(s) of switchover/balancing. -->
</t>
<t>
The PCC MUST send a PCRpt message to the PCE in order to notify of the result of the
data switchover/balancing. The PCRpt message MUST have the DATA-CONTROL TLV that
indicates the actual assigned percentages of each member of association group after
the execution of the data switchover/balancing operation. The LSP object in the PCRpt
will have the reserved PLSP-ID of 0.
</t>
<t>
The final step is the deletion of old LSP. It is OPTIONAL to carry out this step.
The PCE sends PCInitiate message requesting deletion of the LSP that does not carry
data traffic anymore after data switchover/balancing execution. Once the PCC tears
down the LSP, a PCRpt message MUST be sent from the PCC to the PCE in order to
notify that the LSP is no longer used and return delegation.
</t>
<t>
Note that, both RSVP-TE <xref target="RFC3209"/> Tunnel-ID and LSP-ID for
PCE-Initiated LSP signaling is not allocated by a PCE. A PCC locally assigns
those IDs that are related to RSVP-TE parameters. Therefore, the operations of
data switchover and balancing specified in this document is the traffic control
procedure across multiple RSVP-te Tunnels (i.e., different Tunnel instances).
Data switchover method across LSPs within a single RSVP-TE Tunnel, which is the
switchover in the middle of make-before-break reoptimization, is covered by
<xref target="I-D.tanaka-pce-stateful-pce-mbb"/>.
</t>
</section>
<section title="TLVs in LSP Objects">
<section anchor="ASSOCIATION-GROUP-TLV" title="ASSOCIATION-GROUP TLV in LSP Objects">
<t>
This section defines ASSOCIATION-GROUP TLV in LSP Objects.
ASSOCIATION-GROUP TLV is used in the LSP Object in PCUpd messages when a
PCE creates association group of LSPs on a PCC.
</t>
<figure title="ASSOCIATION-GROUP TLV format" anchor="format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Association Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
Flags and fields
<list style="empty">
<t>
<list style="hanging">
<t hangText="Association Group ID - 8 bit: ">
This field specifies a identifier of association group of LSPs. The IDs are assigned by a PCE, however a PCC (RSVP headend) owns the association group.
0x0000 and 0xFFFF is reserved for special use.
</t>
<t hangText="Flags - 8 bit: ">
None defined. MUST be set to zero.
</t>
<!--
<t hangText="Add(A) bit - 1 bit: ">
This bit is used when a PCE request to add PLSP-ID of the LSP Object to the Association Group ID.
</t>
<t hangText="Remove(R) bit - 1 bit: ">
This bit is used when a PCE request to remove PLSP-ID of the LSP Object from the Association Group ID.
</t>-->
</list>
</t>
</list>
</t>
<t>
An association group is a group of LSPs that is referenced by a single identifier,
by both the PCE and PCC. This number is significant in the context of a single PCEP
session. An association group may have one or more LSPs. Association
groups with zero members are removed and the id can be reused. The PCE is the entity
managing association, and this is considered PCE state that will be cleaned up
when the State Timeout Interval expires.
An LSP can be associated with a single association group. Extensions for support of
multiple association groups are left for a future version of this document.
</t>
<t>
To create a new association group on a PCC, a PCE sends a PCUpd message which
contains the LSP Object(e.g. PLSP-ID=100) and ASSOCIATION-GROUP TLV (Association
Group ID=10) in the LSP object. Next, a PCE sends the another PCUpd message
with another LSP Object(e.g. PLSP-ID=200) and ASSOIATION-GROUP TLV(Association Group ID=10).
As a result, the PCC and PCE both recognize that Association Group ID 10 represents
PLSP-ID=100 and 200.
</t>
<t>
To remove a specific PLSP-ID from the association group, a PCE sends PCUpd
message which contains the LSP Object(PLSP-ID=100) and ASSOCIATION-GROUP TLV
(Association Group ID=0x0000). Then a PCC removes the PLSP-ID 100 from any
association groups on the PCC.
</t>
<t>
To flush all association groups on a PCC, a PCE sends a PCUpd message which
contains the LSP Object(PLSP-ID=0x0000) and ASSOCIATION-GROUP TLV(Association
Group ID=0x0000). Then a PCC flushes all association groups.
</t>
<!-- This section is problematic, I am commenting out, it will otherwise create unnecessary discusison
<t>
When a PCC successfully created/removed/flushed association group, the PCC
sends a PCRpt message that contains LSP Object with ASSOCIATION-GROUP TLV.
Association Group ID field fills the ID that the PCC has just created.
It fills 0x0000 if a PCC remove the member, and in addition, PLSP-ID set to
0x0000 if a PCC flush
</t> -->
</section>
<section anchor="DATA-CONTROL-TLV" title="DATA-CONTROL TLV in LSP Objects">
<t>
This document defines DATA-CONTROL TLV in LSP Objects.
</t>
<figure title="DATA-CONTROL TLV format" anchor="D-CTRL-format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Association Group ID | Flags | O |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Association Group ID | Flags | O |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (OPTIONAL) DATA-REPORT TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<figure title="DATA-REPORT TLV format" anchor="D-REPORT-format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Member 1 (PLSP-ID ) | MUST Zero | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member 2 (PLSP-ID ) | MUST Zero | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member N (PLSP-ID ) | MUST Zero | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>Flags and fields
<list style="empty">
<t>
<list style="hanging">
<t hangText="Origin Association Group ID: ">
data traffic origin
</t>
<t hangText="Target Association Group ID: ">
for taking over whole data traffic from origin.
</t>
<t hangText="O (Operational – 3 bit): ">
This bit represents the requested operational status by a PCE.
The meanings of the values are defined in <xref target="I-D.ietf-pce-stateful-pce"/>.
</t>
<t hangText="Member in DATA-REPORT TLV:">
This TLV is used in a PCRpt message and represents actual percentages of load balancing per respective PLSP-ID after load balancing execution. Member field fills PLSP-ID that is member of target association group.
</t>
<!--
<t hangText="O (traffic Origin – 1 bit): "> “traffic Origin(O) = 1” indicates this is an active LSP (i.e., carring traffic now) whose traffic is to be switched over or to be load-balanced. A PCE uses this bit to specify traffic origin that it wants to manipulate. On the other hand, A PCC uses this bit in PCRpt message to notify a PCE that switching traffic succeeded and carrying data traffic.
</t>
<t hangText="C (Continue - 1 bit): "> If this flag set to 1, it indicates the next LSP Object encoded in the PCUpd has also DATA-CONTROL TLV. If this flag set to 0, it indicates no more LSP Object continues and load balancing calculation is completed, and then the PCC MUST perform switching traffic or load-balancing.
</t>-->
<t hangText="Percentage in DATA-REPORT TLV - 8 bit: ">This field specifies actual percentage of load balancing as an unsigned char. <!--The sum of this field across subsequent LSP Object has to be hundred percent. The value must be less than or equal to 100%(0B01100100) (e.g., If you want to set 50%, this field should be set to 0B00110010). If no traffic goes through the corresponding LSP, this field should be set to 0%. 0% LSP MUST be deleted immediately after switchover. The special value 0B11111111 indicates traffic 0%, but the LSP MUST remain after switchover.-->
</t>
</list>
</t>
</list>
</t>
<t>
An LSP Object in PCCUpd message MUST have DATA-CONTROL TLV when a PCE operates
data switchover and balancing on a PCC. DATA-CONTROL TLV is sub-TLV of an LSP
Object and is used in both PCUpd and PCRpt message.
</t>
<t>
An operation of data switchover/balancing is the action of transferring traffic
from an origin association group to a target association group. A PCUpd message
with reserved LSP Object (PLSP-ID=0x0000) and DATA-CONTROL TLV (a set of an origin
and a target association group) MUST triggers data switchover/balancing execution.
</t>
<t>
A PCC replies to a PCE a PCRpt message as a notification of data '
switchover/balancing result. The PCRpt message MUST have reserved
LSP Object(PLSP-ID=0x0000) and DATA-CONTROL TLV with DATA-REPORT inside.
</t>
</section>
</section>
<section title="Operation Examples">
<t>
For easy understanding this section introduces typical operation examples of data switchover/balancing.
</t>
<section title="Data switchover operation (100:0 => 0:100)">
<t>
A PCE instructs a PCC to switchover 100% traffic from association group ID
1 to association group ID 2. A PCE sends single PCUpd message containing the
reserved LSP Objects with DATA-CONTROL TLV.
</t>
<t>
Expected PCUpd,PCRpt messages to create association group and to trigger data switchover follow.
</t>
<figure title="Switchover Operation Example" anchor="switchover">
<artwork><![CDATA[
PCE PCC(Ingress) Egress
[LSP Association for existing LSP]
| | |
| --PCUpd ----------------->| |
| LSP Obj: PLSP-ID=1 | |
| + ASSOC-G: Assoc-G-ID 10| |
| | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=1 | |
| + ASSOC-G: Assoc-G-ID 10| |
[LSP Creation]
| | |
| --PCInitiate ------------>| |
| | --Path ------->|
| |<------- Resv-- | Establish a new
|<--PCRpt ----------------- | | PCE-Initiated LSP
| LSP Obj: PLSP-ID=2 | |
| | |
[LSP Association for PCE-Initiated LSP]
| | |
| --PCUpd ----------------->| |
| LSP Obj: PLSP-ID=2 | |
| + ASSOC-G: Assoc-G-ID 20| |
| | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=2 | |
| + ASSOC-G: Assoc-G-ID 20| |
| | |
[Switchover Execution]
| | |
| --PCUpd ----------------->| |
| LSP Obj: PLSP-ID=0x0000 | |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) : |
| Target Assoc-G-ID 20(O=active) : |
| |))))))))))))))))| Switchover
| |}}}}}}}}}}}}}}}}| Execution
|<--PCRpt------------------ | : |
| LSP Obj: PLSP-ID=0x0000 | : |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) |
| Target Assoc-G-ID 20(O=active) |
| + D-REPORT: | |
| PLSP-ID 2, 100% | |
| | |
]]>
</artwork>
</figure>
</section>
<section title="Load balancing operation (100:0 => 50:50)">
<t>
The scenario is one where the starting state is a single LSP (of bandwidth 100 M)
is carrying the
traffic. To enable better bin-packing, the PCE may want to create two smaller
LSPs instead, each of 50M, and load balance the traffic over them.
To accomplish this, two association groups are used, the first
(say association group ID 10)
contains the LSP carrying the traffic, and the second (say association group ID 30)
contains the two new smaller LSPs.
Expected PCUpd,PCRpt messages to create association group and to trigger
load-balance follow (The instantiation of the original LSP of bandwidth 100M
and its association into group ID 10 is not shown)
</t>
<figure title="Load-Balance Operation Example" anchor="load-balancing">
<artwork><![CDATA[
PCE PCC(Ingress) Egress
[LSP Creation]
| | |
| --PCInitiate x2---------->| |
| BW: 50M | --Path x2----->|
| |<-----Resv x2-- | Establish two new
|<--PCRpt ----------------- | | PCE-Initiated LSP
| LSP Obj: PLSP-ID=3 | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=4 | |
| | |
[LSP Association for PCE-Initiated LSPs]
| | |
| --PCUpd ----------------->| | Create new
| LSP Obj: PLSP-ID=3 | | Association Group
| + ASSOC-G: Assoc-G-ID 30| | for PCE-Initiated
| | | LSP
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=3 | |
| + ASSOC-G: Assoc-G-ID 30| |
| | |
| --PCUpd ----------------->| | Add a new LSP
| LSP Obj: PLSP-ID=4 | | to Association Group
| + ASSOC-G: Assoc-G-ID 30| |
| | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=4 | |
| + ASSOC-G: Assoc-G-ID 30| |
[Load Balancing Execution]
| --PCUpd------------------>| |
| LSP Obj: PLSP-ID=0x0000 | |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) : |
| Target Assoc-G-ID 30(O=active) : |
| |))))))))))))))))| Balancing
| |)})})})})})})})}| Execution
| | : |
|<--PCRpt------------------ | : |
| LSP Obj: PLSP-ID=0x0000 | : |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) |
| Target Assoc-G-ID 30(O=active) |
| + D-REPORT: | |
| PLSP-ID 3, 50% | |
| PLSP-ID 4, 50% | |
| | |
]]>
</artwork>
</figure>
</section>
<!-- removed the text here, teh xml2rfc tool could not handle hyphens in comment -->
</section>
<section title="IANA Considerations">
<section title="PCEP TLV Indicators">
<t>
This document defines the following new PCEP TLVs:
</t>
<figure>
<artwork><![CDATA[
Value Meaning Reference
TBD DATA-CONTROL This document
TBD DATA-REPORT This document
]]>
</artwork>
</figure>
</section>
<section anchor="ERROR-CODE" title="PCEP Error Objects">
<t>
This document defines new Error-Type and Error-Value for the following new error conditions:
</t>
<figure>
<artwork><![CDATA[
Error-Type Meaning
6 Mandatory Object missing
Error-value=TBD: DATA-CONTROL TLV missing.
Error-value=TBD: DATA-REPORT TLV missing.
19 Invalid operation
Error-value=TBD: No association group existing.
Error-value=TBD: No association group specified.
]]>
</artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>
TBD
</t>
</section>
<section title="Acknowledgments">
<t>
Many thanks to Adrian Farrel for his ideas and suggestions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5440;
&I-D.ietf-pce-stateful-pce;
&I-D.crabbe-pce-pce-initiated-lsp;
&rfc4872;
</references>
<references title="Informative References">
&rfc3209;
&I-D.tanaka-pce-stateful-pce-mbb;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:37:34 |