Internet DRAFT - draft-choi-pce-p2mp-framework
draft-choi-pce-p2mp-framework
Network Working Group Jun Kyun Choi (BcN ERC)
Internet Draft Dipnarayan Guha (NTU)
Category: Informational
Expiration Date: January 2007 August 2006
Considerations of point-to-multipoint route optimization using PCEMP
draft-choi-pce-p2mp-framework-04.txt
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Copyright (C) The Internet Society (2006).
Abstract
This draft describes the basic concepts of point-to-multipoint
(p2mp) path computation on the basis of the Path Computation Element
Metric Protocol (PCEMP). PCEMP, being soft-memory based, has the
capability of dynamic configuration of its finite state machines
(FSMs) in the participating PCEMP peers, and thus can support a
wide variety of traffic engineering techniques that are needed to
guarantee bandwidth demand and scalable fast protection and
restoration in PCE based p2mp frameworks. To take advantage of
bandwidth considerations and fast restoration mechanisms, the
centralized Controller, which is the key element in a PCE node,
is used for path computation in case of p2mp paths and can be used
in a scenario where reliable multicasting of bandwidth-on-demand
services becomes an important criteria for multiple-domain and/or
inter-domain PCE based architectures.
Choi, Guha Informational [Page 1]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
Table of Contents
1 Terminology ................................................. 3
2 Introduction ................................................ 4
3 p2mp Support Requirements in PCE architectures .............. 4
3.1 High-level requirements for PCE-based p2mp TE path
computation and PCEMP ....................................... 5
3.2 Features of PCEMP as outlined for p2mp realizations ..... 6
3.2.1 PCEMP as a metric protocol ........................ 6
3.2.2 Protection and Restoration considerations in p2mp
TE LSP computation using PCEMP .................... 7
3.2.3 p2mp Peer Discovery during Path Computation ....... 7
4 Implementation considerations of the PCEMP protocol
architecture in p2mp LSP TE computations .................... 7
4.1 PCEMP State Machines Design ............................. 8
4.2 Functional Parameters for PCEMP DS processing for
p2mp TE LSP computation ..................................... 8
4.3 Realization of fast path computing unit architecture
using PCEMP ................................................. 9
4.4 Fundamentals of the PCEMP Algorithm as a function of CPCA 9
4.5 Protocol implementation considerations using PCEMP ...... 12
5 Considerations of operationing of p2mp in PCE ............... 14
5.1 QoS oriented p2mp path computation provisioning in PCE .. 15
6 Conclusion .................................................. 15
7 Security Considerations ..................................... 16
8 IANA Considerations ......................................... 16
9 Acknowledgements ............................................ 16
10 Intellectual Property Considerations ........................ 16
11 Normative References ........................................ 17
12 Informational References .................................... 17
13 Authors' Addresses .......................................... 18
14 Full Copyright Statement .................................... 19
Choi, Guha Informational [Page 2]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
1. Terminology
This memo makes use of the following terms:
1. Path Computation Element (PCE): an entity that is responsible
for computing/finding inter/intra domain LSPs. This entity can
simultaneously act as a client and a server. Several PCEs can
be deployed in a given Autonomous System (AS).
2. Path Computation Element node (PCE Node): a network processing
unit comprising of a PCE unit. This can be embedded in a router
or a switch.
3. Domain: Denotes an Autonomous system (AS) within the scope of
this draft.
4. PCE Domain Area (PCEDA): A specific domain area within an AS
that consists of PCE peers managed by a PCE node running PCEMP
5. PCE descriptor ID: a 32 bit number generated by the PCEMP
FSM execution upon successful path computation and partition
of the AS into PCEDAs
6. PCE p2mp ID (pp2mp ID): A set consisting of one or more PCE
descriptor IDs. The scope of this ID is determined by the
LSP setup and teardown dynamically, it can be within two
adjacent nodes, or between different PCE peers under a
common PCEDA, or just a unique one for the entire LSP.
Choi, Guha Informational [Page 3]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
2. Introduction
One of the key work items involving the functional specification of
MPLS and GMPLS Traffic Engineering LSP path computation techniques
in the proposed PCE WG charter is the case for TE LSP path
computation for inter-domain areas applying to both point-to-point
(p2p) and point-to-multipoint (p2mp) TE LSPs. Such path computation
techniques include primary, protection and recovery paths and well
as load balancing and reoptimization techniques.
Most of the existing MPLS TE allows for strict QoS guarantee,
resource optimization and fast failure recovery, but the scope is
mostly limited to p2p applications. In the context of path
computation, one of the important application areas is the
reliable support of bandwidth-on-demand applications, where the
QoS provisioning needs to be dynamic and robust. A scenario where
a PCE node acts a server which are connected to several clients,
which may or may not be PCE peers, needs a clear requirement
addressal so far as p2mp TE tunneling is considered. In this draft,
we consider that such p2mp TE LSP path computation is QoS triggered,
and we show how PCEMP finite state machines (FSMs) might help in
achieving a scalable architecture involving PCEDAs where p2mp path
computation metrics are independent of the number of clients to which
the PCE server is attached to.
The Path Computing Element Metric Protocol (PCEMP) acts as a generic
computational model for path based metrics in large multi-domain and/or
multi-layer networks. This draft goes on to show some of the features
of the PCEMP protocol in realizing a protocol-driven architecture,
which essentially means that the topology for load balancing and
reoptimization in path computation is performed on the fly with the
PCEMP FSM execution on the participating PCE peers. This feature of
PCEMP helps in degenerating the setup and teardown of p2mp TE LSP
computation to the PCEMP protocol processing itself, thus enabling
support of an arbitrary number of clients as well provisioning of
guaranteed robust path protection and restoration and dynamic QoS
provisioning for bandwidth-on-demand services.
3. p2mp Support Requirements in PCE architectures
For the scenario involving robust and dynamic provisioning of
bandwidth-on-demand services, the p2mp applications request p2mp
forwarding paths in case of different topology deployments. The
robustness must be thought in the context of path reoptimization,
so a quick change in the topology must be accomodated with every
PCEDA level optimization. The p2mp path will have several observed
metrics as constraints, such as cost of path establishment and
teardown, delay boundedness of the p2mp path, both delay bounded
and cost optimized constraints in tandem for path computation, etc.
One of the features as brought out in the PCE WG charter is the
co-existence of different path computation algorithms on the PCE
node, so that depending upon the data that is processed, a
particular algorithm is invoked. It is also evident that for p2mp
Choi, Guha Informational [Page 4]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
applications, a CPU intensive path computation is necessary,
primarily because most of the bandwidth-on-demand applications tend
to be resource-intensive applications like streaming multimedia,
real-time videoconferencing, etc. The ideal thing would be to let the
data that is under processing in the PCE node determine the path
computation algorithm directly, which would mean that the constraints
imposed by the QoS provisioning requirements would directly determine
the path computation algorithm and path reoptimization, which in
turns drives the resulting topology architecture. Thus, it is easy to
see why PCEMP is a possible solution for p2mp TE LSP computation, as
it drives a protocol driven architecture for topology changes in
path reoptimization.
The traffic engineering techniques involved with p2mp TE LSP
computation involve mainly with the case of p2mp path computation
over multiple domains. There are three main issues involved with this
feature: 1. load sharing among paths, 2. ability to modify the p2mp
paths in different PCEDAs even when the PCEDA entities lie in
different multiple domains, 3. p2mp path computation for corresponding
clients in muliple domains must be able to support scalability, i.e.
the number of clients entering/leaving the p2mp tree at a given time.
3.1 High-level requirements for PCE-based p2mp TE path computation and
PCEMP
Some of the high level requirements for PCE-based p2mp TE path
computation [1] are:
1. Capability to implement multiple p2mp path calculation
algorithms/mechanisms and to select the appropriate algorithm/
mechanism based on computation demands. We have mentioned this
independently earlier about PCEMP FSM driven architectures.
2. Reliability in LSR-PCE signaling. A good thing about PCEMP is
that as the FSMs are soft-configured on the participating peers,
the same protocol can be used for communicating between a LSR and
a PCE, as well do the data processing and path computation on a
PCE peer entity, i.e. a node.
3. Support of PCE in a centralized and distributed manner. This is
automatically derived from the PCEDA partitions once the PCE peers
are known.
4. Capability to calculate a p2mp path by co-ordinating multiple
PCEs. PCEMP does this by assigning an IDT (input data type)
associated with each TE-LSP that is set up through the corresponding
PCE node entity. For path computation using PCEMP FSMs, the PCE
descriptor ID is returned after every computation is complete. If
the computation is successful, a random 32 bit number is generated
Choi, Guha Informational [Page 5]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
which holds the path computation status at that PCE node. If the
path computation fails, a value of -1 is generated in the PCE
descriptor ID field which is communicated to the immediate PCE peer
and automatic protection of the TE LSP begins and a reoptimization
is calculated by the last stored random number for this node by the
neighboring PCE peer. A pp2mp ID is a set of the corresponding PCE
descriptor IDs (a -1 has a local scope to the node where the fault
occurred)
5. Detection of p2mp capability (p2mp signaling/forwarding support)
of LSRs. This is done using the soft-memory feature aspect of PCEMP
FSMs. If the LSR does not support p2mp capability, it will just
transparently pass through the PCEMP protocol messages. The
soft-memory will provide a temporary "make-and-break" FSM support
on the LSR before actual communications take place.
6. Support of load balancing between multiple PCEs. This is done
with the help of the corresponding IDTs derived from the QoS classes
in the PCEMP FSMs.
7. Capability to hold calculated p2mp path information. This is
done dynamically for TE LSPs passing through a PCE peer entity
through the PCE descriptor IDs. Besides, the centralized Controller
of the PCE server also maintains a table containing these
descriptor IDs corresponding to the PCE peers within the PCEDA for
which it is responsible.
8. Capability to synchronize TEDB/LSDB between the PCE and LSR.
This has been discussed using the different parts of the centralized
Controller. The authors have brought out a draft on this for SRLG
based end-to-end fast protection and recovery, where this
synchronization aspect is mentioned in [3].
3.2 Features of PCEMP as outlined for p2mp realizations
3.2.1 PCEMP as a metric protocol
1. PCEMP acts as a generic computational model for path based metrics
in large multi-domain and/or multi-layer networks.
2. The protocol mechanism can serve as an application path
computation framework for any PCE
3. Analysis of PCEMP metrics in terms of protocol cost shows the
implementation considerations of PCEMP protocol state machines in
p2mp TE LSP path computations.
Choi, Guha Informational [Page 6]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
4. The underlying key point is that PCEMP addresses inter-domain
partitioning and management issues through the concept of PCE peers
drafted by PCEMP. Partitioning into PCEDAs help automatically in
p2mp path computation, reoptimization and multiple PCE co-ordination.
3.2.2 Protection and Restoration considerations in p2mp TE LSP computation
using PCEMP
1. PCE based backup path computation can be done using SRLGs, as in
[3]. There can be any other mechanism associated with the real-time
protection, restoration and recovery for p2mp TE LSP path
computation, as we have mentioned earlier, using the PCE descriptor
ID. Processing the PCE descriptor ID for protection and recovery is
outside the scope of this draft.
2. PCEMP FSMs partition the corresponding AS into PCEDAs, which
means there is an obvious segmentation of any logical topology
during path computation. The network and control structure
frameworks in the scenario of PCEMP guarantees a fast establishment
of a disjoint backup path. This also means that there is a
mechanism possible for integrated provisioning and protection for
the purpose of fast backup path computation, which is an important
standpoint for bandwidth-on-demand QoS provisioning in p2mp
scenarios.
3.2.3 p2mp Peer Discovery during Path Computation
1. The PCE peer architecture as "seen" by the PCEMP FSM [2] helps
in fast PCE peer advertisement and fast processing of PCE peer
solicitations, thus improving router handling procedures on
individual PCE nodes and peers.
2. The configuration of PCE peers for fast processing of
solicitations is one of the key aspects of p2mp TE LSP path
computation and reoptimization. This is also an important requirement
for bandwidth-on-demand services involving a PCE server and the
corresponding clients.
3. [4] has shown a guideline to specifications of modifying existing
protocols to facilitate communication between LSRs, PCEs and PCE
peers. The concept of synchronization of information between PCE
nodes in case of a change in the PCEDA helps in fast default PCE peer
acquisition [4]. This results from the fact that PCE peers are capable
of being "soft-configured" in inter-domain PCE issues.
4. Implementation considerations of the PCEMP protocol architecture in
p2mp LSP TE computations
We extend the definition from [2], which contains the basic
definition of PCEMP Data Structure (PCEMP DS). The PCE node
essentially has three distinct functional entities:
Choi, Guha Informational [Page 7]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
1. Protocol System Architecture: PCEMP DS decoder architecture and
path computing core that interfaces with the network processing
engines in the PCE nodes.
2. Protocol System Specifications: An efficient algorithm for running
in the computing core of the PCE units, called the Combinatorial Path
Computing Algorithm (CPCA). This algorithm is the fundamental block
that co-ordinates the PCEMP state machines and describes the decoder
that processes arbitrarily large input data sequences using SCM [2].
The memory structure of the protocol processing engine is implemented
in terms of these soft decoder algorithms and the data that is being
processed for p2mp applications. The method reduces hardware and path
computing complexity considerably.
3. Protocol System Requirements: High Level Path Computing Transform
Library
4.1 PCEMP State Machines Design
Definition: A unifying concept that ties together the CPCA and
protocol level processing. These mathematical programs are selected
on the PCE node block structure by the PCEMP DS based on the input
data sequence real-time and implemented as a dynamic data driven
tree partitioning. For p2mp TE LSP computation, this tree is
additionally given respective IDs for different LSPs (differentiated
by LSP IDs during LSP setup)
Concept: A function that is mapped onto the CPCA and PCE computation
(PCEC) classes and outputs the path computation unit length. This
parameter is benchmarked for performance in processing time and
computational complexity of the PCE unit and invoked CC and SPC
metrics. For p2mp, these individual functions might be mapped to a
single centralized function in the PCE server (centralized path
computation), or might co-exist with one another in terms of local
function descriptors(distributed path computation)
Iterator Self-Reflection of Types Design: The PCEMP DS is a general
framework supporting CPCA and PCEC modes of computation in the PCE
unit. Self-reflection of type instantiates two iterators that share
a common constructor class. The iterator types are of type CPCA and
PCEC, and called during compile-time to generate the necessary
control structure output. This helps in implementing the data-driven
strategy for path computing real-time and forms the basis of PCEMP
State Machines design.
4.2 Functional Parameters for PCEMP DS processing for p2mp TE LSP
computation
The input data sequence is arranged into an ordered set called the
Input Data Type (IDT) which is a subset of the input vector S and
a function of the control transform to be computed T. A State Subset
Choi, Guha Informational [Page 8]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
is a member of the cardinal product of S and T. It is shown to be
isomorphic with the logical decoder outputs [2]. The IDTs invoke
the hardware for computing across the partitioned kernel in the PCE
nodes.
Input: IDT Tj, State Subsets Sl and Sm, Integers l and m, Label Lb,
Semi-Ring R. For p2mp support, there will be multiple state subsets,
and we will pairwise consider all such states. In case where the
total number of states is odd, one state will be paired with the
identity state.
Output: Flow metric/measure p(A,B), which maps to the PCE descriptor
ID. For p2mp cases, the PCE descriptor IDs are setwise collected to
form the pp2mp ID. This is again implementation dependent.
4.3 Realization of fast path computing unit architecture using PCEMP
Concept: Iterative applications of the PCEMP DS. Two or more IDT
encoders separated by an interleaver (respectively CC and SPC).
This structure suggests a decoding strategy based on the iterative
passing of soft-computing information between two decoding
algorithms. This is equivalent to dynamically partitioning the path
computing engine core into sub-units that are linked together
real-time based on the input data and the protocol handler. This is
what makes PCEMP a protocol driving architecture, and is one of the
key features of realizing a NP-hard path computation for p2mp TE LSPs.
Basic Computation: Configure PCEMP DS to compute soft-decisions in
terms of measures. An assigned measure is given to each branch of
the IDT. This algorithm makes the data intensive path computing much
easier and reduces overhead and complexity and is incorporated in
the computing core. It also guarantees disjoint path computation
that enables fast end-to-end backup and protections. The configuration
is totally dependent on the processed data and in a PCE server based
bandwidth-on-demand scenario, can be triggered by the QoS service
classes. The QoS classes are directly mapped onto the IDT, and thus
can realize the p2mp based TE LSP path computation and reoptimization
all the time based on the demanded bandwidth ensuring robustness and
reliability of services.
4.4 Fundamentals of the PCEMP Algorithm as a function of CPCA
for {
any TE LSP passing through a PCE node P
{
Let A belong to Sm and B belong to Sl.
A and B are thus sets of states with m and l.
Initialization: For each s in Sm, r(Sj,s) = 1 when s is
in A else 0
xt(0) =1, xt(m) = 0, m is not zero
Loop:
Choi, Guha Informational [Page 9]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
/* For Decoder i to Decoder k, CC and SPC */
/* For j = m+1, m+2,...,l, for each s2 in Si, */
/* Label branch bout with input m and three outputs
(c0,c1,x1); */
// p2mp TE LSP path computation support //
do
{
repeat for all Si's ;
assign bouts for each si in Si for P ;
}
// p2mp TE LSP path computation support //
/* c0 = common symbols between the two encoders, CC
and SPC */
/* c1,x1 = PCE unit inputs */
call decoder_private; /* populates decoder specific
private data*/
/* This is populated by data driven mapping of
external routing information. In PCEMP, each
external route is imported into the PCE domain area
in separate data driven computation strategies */
u(y|c0) = load file_channel; /* populates PCE
unit kernel specific data */
/* This is populated by the peer-to-peer information
exchange by the functional blocks involved in the
PCE node. i.e. the network processor, the domain
processor and the node processor */
u(y|m) = rel (u(y|c0), u(c1,x1|c0,y);
/* This is SCM specific kernel computation that
involves a data-driven partitioning of the ordered
graph based on iterator instantiates */
assign p = probability(c0);
// p2mp TE LSP path computation support //
do
{
repeat for all Si's;
assign p for all c0's for all Si's;
take the weighted arithmetic mean of the
probabilities along with the branch labels;
assign p1 = probability weighted (mean(c0));
}
// p2mp TE LSP path computation support //
/* This is the probability that the PCE computing is
actually invoked for computing upon data vectors
that show a significant change in the data profile
sequence, else it is just buffered and tagged for
decision making. This reduces computational overhead
and unnecessary kernel calls for data intensive path
computing */
Choi, Guha Informational [Page 10]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
// This is precisely what we use for the p2mp
support in PCEMP based architectures. The path
computation and reoptimization is driven by QoS
demands. The algorithm processing completely
depends on the data that is under processing,
and the PCEMP FSM executes accordingly. Besides,
this also shows that there can be other algorithms
that can co-exist with PCEMP, in which case the
corresponding iterators to the other protocol FSMs
would just be needed to be included as a child of
the PCEMP iterator //
assign y = u(c0).u(y|c0).decoder_private;
log p(Si, xj) = log sum (si, xj-1) + log sum (zj) over
all b in Bi,
y(b) = u(m).u(y|m).decoder_private;
invoke Fast_Decoding_Procedure;
/* This procedure has been described in the context of
iterator self-reflection types in Section 4.1 */
/* This essentially means this: */
/* for m to l all the state indices, */
/* for all the branches on the corresponding graph of
the PCEMP DS IDT, obtain the sum of the logarithms of
the corresponding weights and optimize it for
choosing the correct points on the graph. This is a
continuous, cumulative and dynamic process which
involves minimum computation overhead and provides a
guaranteed fast crossover for path computation and
backup protection */
// This is thus invoked for all the p2mp TE LSP
path computations, as we see above in the algorithm//
// besides, the path computation for p2mp support
is independent of the number of nodes, as that
parameter does not appear in our algorithm. This
helps in scalability issues for p2mp TE LSP
computation in PCE architectures //
Stop:
p(si,xj) = min log (sum (si, xj -1)
/* Store the sums obtained in the Loop and then equate
to the final sum */
Choi, Guha Informational [Page 11]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
/* Fast path computing procedure for large sequence input
data: */
/* 1. Setup: Use the received kernel data to compute the
common and private soft channel information */
/* 2. Iterate: Repeatedly update, for the outer and inner
decoder, the iterative information by updating u(c0) and
u(m). The computation involves a forward and backward
application of the PCEMP DS with the complete branch
measure. */
/* The extracted measure for the common symbol is computed
based on (x,y1,z) using the private branch measure */
/* 3. Conclude: The extracted measure for the control
symbol m is computed based on (x,y1,z) using the complete
branch measure z */
Based on the above algorithm and analysis, we can consider two
distinct finite state machine diagrams of the PCEMP protocol
architecture, as in [2]:
1. The case where the PCE unit block is invoked for constantly
changing data profiles within the time of test of goodness of fit
(MAX_PCE_TIME_FIT)
2. The case where the PCE unit block is invoked only once for a
variable data profile and then the data is tagged (tags) within the
time of test of goodness of fit (MAX_PCE_TIME_FIT). max tags is an
important parameter to determine the computing potential within
MAX_PCE_TIME_FIT and determines the ease of p2mp path bifurcation,
route reoptimization and real-time protection and restoration.
4.5 Protocol implementation considerations using PCEMP
|----------- (1) ------------>|
| |
|<-----------(2) -------------|
| |
|------------(3) ------------>|
| |
|<-----------(4) -------------|
| |
|------------(5) ------------>|
| |
|<-----------(6) -------------|
PCE1 PCE2
Figure 1: PCEMP message exchanges between PCE elements in p2mp case
Choi, Guha Informational [Page 12]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
For considerations of point-to-multipoint route optimization using
PCEMP, we can use PCEMP messaging for implementing such a scenario.
Here is a sample sequence of messaging that helps in the PCE nodes
maintain soft PCEMP status. Details about the protocol messages can
be found in [2].
(1): Send a PCEMP Common Header with the COMPUTE_PATH enabled in the
PCEMode field and the ACK REQUESTED enabled in the PCEFlag field.
The PCEMP message MAY include a PCE SUBOBJECT to inform the
responder (PCE2) about the initiator's (PCE1)
PCEMP-LOCAL-INITIATOR-ADDRESS. In this way PCE2 is initialized
with the soft-memory based computation for PCEMP FSMs.
(2): PCE2 receives this message and is configured with the soft-memory
based path computation states. It sends back an ACK message to
PCE1 with the responder's (PCE2) PCEMP-LOCAL-RESPONDER-ADDRESS
(3): PCE1 sends a PCEMP Common Header with the COMPUTE_LSP_TYPE enabled
in the PCEMode field, the Peer-to-peer mode set to 0 in the
PCEStatus field of the Common Header. For the other values set in
the Peer-to-peer mode according to [2], this is still TBD. It
also sends a PCEMP ESTABLISH message with the following
parameters:
1. Flag field set to VARIABLE. The MAX_PCE_TIME_FIT is to be
negotiated as discussed in [2]. In case this is not able to
be negotiated, then the PCEMP ERROR message SHOULD be
generated with the ERROR CODE field set to OUT OF TIME, and
the PCE1 node MUST issue a fresh PCEMP ESTABLISH message with
the Flag field set to STATIC.
2. In case of contention in the value of the MAX_PCE_TIME_FIT
during negotiation, the node ID with the higher value wins.
The other PCE node which has won contention must send a
fresh PCEMP ESTABLISH message with the Flag field set to
STATIC and its' own MAX_PCE_TIME_FIT value. It MUST also set
the ACK requested flag in the PCEFlag of the corresponding
outgoing PCEMP Common Header. The node which has lost
contention SHOULD send out an ACK message along with a
PCE SUBOBJECT with the MAX_PCE_TIME_FIT value obtained thus.
3. A BANDWIDTH OBJECT for conveying the QoS requirements of the
initiator. An absence of this object SHOULD generate a PCEMP
ERROR MESSAGE with the ERROR CODE field set to 3 signifying
a protocol error.
(4): PCE2 sends a PCEMP RESPOND message with the corresponding PCE
Descriptor ID. This is matched and stored statically for the
lifetime of the path computation between PCE1-PCE2 so that this
ID remains static between them till the path computation is over.
If the PCE Descriptor ID changes value, a PCEMP ERROR message
MUST be generated with the ERROR CODE field set to PROTOCOL
ERROR with its own saved PCE Descriptor ID of the wronged hop
in the PCEMP NEGOTIATE OBJECT. It MUST also set the Protection
mode in the PCEStatus field of the corresponding outgoing
PCEMP Common Header and the BANDWIDTH OBJECT with the same field
value that was received in the PCEMP ESTABLISH message. If the
two values are different, a PCEMP ACK message MUST be generated
with the PCE SUBOBJECT set to the newer value of the BANDWIDTH
OBJECT. The responder MUST generate a PCEMP ACK message with
this accepted value of the BANDWIDTH OBJECT. In case these two
still do not match, a PCEMP ERROR message MUST be generated
with the ERROR CODE field set to 3, a PCEMP NEGOTIATE OBJECT
with the accepted QoS parameters and the same value in the
BANDWIDTH OBJECT.
Choi, Guha Informational [Page 13]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
(5): PCE1 issues a PCEMP TEARDOWN message with the RequestType field
set to CHANGE IN COMPUTATION STYLE for PCE2 to remain PCEMP
enabled and the path computation state active.
(6): PCE2 sends a PCEMP Common Header with the COMPUTE_LSP_TYPE
enabled in the PCEMode field. The PCEMP message MAY include a
PCE SUBOBJECT to inform the responder (PCE1) about the
initiator's (PCE2) PCEMP-LOCAL-INITIATOR-ADDRESS.
This process is repeated for multiple PCEn, and the path computation
works along the one described in Section 4.4.
5. Considerations of operationing of p2mp in PCE
As said before, it is possible to obtain a protocol driven network
architecture from a data driven protocol FSM. From the operationing
point of view, there are two equally likely possibilities for p2mp
support in PCEs:
1. The PCE descriptor ID that is obtained from the FSM execution can
be carried as a separate optional object in standard OSPF/RSVP-TE
extensions, irrespective of whether a routing or a signaling based
solution is deployed for TE LSP path computation in p2mp scenarios.
Traditionally, if an explicit-route object is used, the PCE descriptor
ID can be used in conjuction with it as a sub-object. It is easy to
understand that a path change will essentially mean changing the
contents of the explicit-route object and/or inserting/deleting a new
one for the purpose of p2mp support. The pp2mp ID, which is added on
once the PCE descriptor IDs are added with the explicit route object
being processed by every next hop, will be thus spanned over the
entire PCEDA. At the egress side, the total pp2mp ID is recognized
and the LSP contents mapped onto the corresponding client paths.
2. The other option is to have a separate messaging system for PCEMP
that only has the PCEMP header and the PCE descriptor ID as the
payload. The PCE nodes can maintain a local counter for these IDs,
which are generated randomly but become fixed for any set of adjacent
path computation. The scope of this deployment is again implementation
specific. It might act as an encapsulated packet within standard
routing or signaling protocols, or may be run independently before
control and management information is exchanged, or may be periodically
run to maintain the "soft-state" like conditions.
In either case, the p2mp TE LSP path computation is independent of the
number of clients (or end points) that are attached to the PCE node,
resulting in clear scalability enhancements. It is also evident that
the make-before-break conditions in modifying p2mp TE LSPs can be
easily done without much overhead and computation intensive operations.
Choi, Guha Informational [Page 14]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
5.1 QoS oriented p2mp path computation provisioning in PCE
For bandwidth-on-demand services, the QoS flow classes are mapped
onto individual PCE descriptor IDs using soft-memory concepts, as
shown in Section 4.4, so that route optimization is guaranteed for
reliable bandwidth provisioning in case of protection and restoration
using the central Controller in PCE nodes [3]. The central Controller
acts analogous to a bandwidth controller in this case. The algorithm
tree helps in guaranteeing an optimal route path all the time, thus
provisioning (as well as tree generation/bifurcation/extensions is
optimal globally all the time) is guaranteed for bandwidth-on-demand
applications. This is possible to do while extracting the QoS field
or indicative object/TLV in the corresponding control packet and
then generating the PCE FSM based on this. This also has the feature
that one single PCE node that is part of multiple LSPs requesting
different levels of bandwidth may support them by the corresponding
FSM execution and optimized routes, ensuring real-time provisioning
and path protection for multiple LSPs that may pass through it. It
also has the compatibility of supporting both P2P and P2MP scenarios
in either case based on what the LSP setup and teardown demands.
Also, in the trivial case the p2mp support using PCEMP degenerates
to what the single p2p case is so far as performance and scalability
is concerned.
6. Conclusion
One of the important things is that the soft-nature of the PCEMP FSM
helps in supporting an arbitrary number of client nodes so far as
p2mp applications are concerned. The nominal value of such nodes is a
function of the deployment scenario, based on the domain that is being
controlled by the service provider, or in the case where different
service providers have an agreement about providing inter-domain
end-to-end QoS services. The algorithm's performance is independent of
the number of leaf nodes, which makes PCEMP scalable to large
inter-domain and multi-domain networks considerably. Apart from this,
PCEMP also helps the p2mp participating nodes to advertise their
capabilities based on the set of constraints that it can support. Using
PCEMP for p2mp TE LSP path computation and global reoptimization also
serves the dual purpose of topology reconfiguration. The main metrics
for evaluating PCEMP as a facilitator for p2mp support in PCE are
1. scalability, 2. cost of setup/teardown of the tree and/or its subtrees
and branches, and 3. reliability and robustness. The intent of this draft
is to provide a general framework for p2mp support in PCE architectures,
and is based on a scenario where the p2mp path computation is triggered
by a QoS requirement. However, the algorithm is very general for path
computation and the p2mp support can be invoked by any general criterion.
The PCEMP framework also supports the co-existence of other path
computing algorithms, as seen in Section 4.4, and can invoke them
based solely on the data (here the bandwidth-on-demand) that is being
processed. This draft shows a complete bandwidth sharing scheme which
might help in significant bandwidth savings for bandwidth-on-demand
scenarios in PCE architectures.
Choi, Guha Informational [Page 15]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
7. Security Considerations
As outlined in the scope of the PCE WG charter, one of the main area
for standardization is the specification of a communication protocol
for use between LSRs(termed Path Computation Clients - PCCs) and
PCEs, and between cooperating PCEs. This protocol must be capable
of representing requests for path computation including a full set
of constraints, must be able to return multiple paths with
consideration of confidentiality and security, and must itself be
secure. The impact of the use of the PCEMP architecture is relatively
much secure as the PCEDA are computed and distributed internal to the
PCE unit. An increase in inter-domain information flows and the
facilitation of inter-domain path establishment through PCEMP does not
increase the existing vulnerability to security attacks. It should
be remembered that PCEMP works by an invoked logic scheme local to
each participating PCE unit, and the protocol invoke is brought into
play only when there is a significant change in the data profile
within the time of goodness of fit. However, it is expected that the
PCE solutions will address security issues mentioned in [Ash] in
details using authentication and security techniques.
8. IANA Considerations
This document makes no requests for IANA action.
9. Acknowledgements
This work was supported by the BcN ITRC, Ministry of Information and
Communications (MIC), Republic of Korea
10. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
Choi, Guha Informational [Page 16]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
12. Informational References
[1] Yasukawa, S. ed., "Signaling Requirements for Point to Multipoint
Traffic Engineered MPLS LSPs", Internet Draft,
draft-ietf-mpls-p2mp-sig-requirement-05.txt, May 2006
[2] Choi, J.K., and Guha, D., "Path Computation Element Metric
Protocol (PCEMP)", Internet Draft,
draft-choi-pce-metric-protocol-05.txt, August 2006
[3] Choi, J.K., Guha, D. et al., "Fast End-to-End Restoration
Mechanism with SRLG using Centralized Control", Internet Draft,
draft-choi-pce-e2e-centralized-restoration-srlg-06.txt, August 2006
[4] Choi, J.K. and Guha, D., "Fast IPv6 PCE peer Advertisement
using PCEMP", Internet Draft, draft-choi-pcemp-ipv6-05.txt,
August 2006
[5] Mannie, E. et al., "Generalized Multi-Protocol Label Switching
Architecture", Internet Draft,
draft-ietf-ccamp-gmpls-architecture-07.txt, November 2003.
[6] Papadimitriou, D. and Mannie, E. (Editors), "Analysis of
Generalized Multi-Protocol Label Switching (GMPLS) based Recovery
Mechanisms (Including Protection and Restoration)", Internet Draft,
draft-ietf-ccamp-gmpls-recovery-analysis-03.txt, October 2004.
Choi, Guha Informational [Page 17]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
[7] Mannie, E. and Papadimitriou, D. (Editors), "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", Internet Draft,
draft-ietf-ccamp-gmpls-recovery-terminology-04.txt, October 2004.
[8] Lang, P. and Rajagopalan, B. (Editors), "Generalized
Multi-Protocol Label Switching (GMPLS) Recovery Functional
Specification", Internet Draft,
draft-ietf-ccamp-gmpls-recovery-functional-02.txt, October 2004.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J.
McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999.
[RFC3209] Awduche, D., et. al., "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg-interarea-mpls-te-req-00.txt, March 2004 (WIP).
[INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-06.txt,
January 2004 (work in progress).
[MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture
for Multi-Region Networks",
draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, February 2004 (WIP).
Le Roux, J.L., Ed., "Requirements for Path Computation Element (PCE)
Discovery", draft-ietf-pce-discovery-reqs-05.txt, June 2006
Ash, J., and Le Roux, J.L., Ed., "PCE Communication Protocol Generic
Requirements", draft-ietf-pce-comm-protocol-gen-reqs-07.txt,
June 2006
13. Authors' Addresses
Jun Kyun Choi
BcN Engineering Research Center
103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
Dipnarayan Guha
Nanyang Technological University, Singapore
Email: dg236@cornell.edu
Choi, Guha Informational [Page 18]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
14. Full Copyright Statement
Copyright (C) The Internet Society (2006). All Rights Reserved.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Choi, Guha Informational [Page 19]
Internet Draft draft-choi-pce-p2mp-framework-04.txt August 2006
