Network Working Group Jun Kyun Choi (ICU) Internet Draft Dipnarayan Guha (ICU) Category: Informational Expires: December 2005 July 2005 Path Computation Element Metric Protocol (PCEMP) draft-choi-pce-metric-protocol-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 (2005). Abstract In this draft, we propose an analysis of a Path Computation Element Metric Protocol (PCEMP) that acts as a generic computation model for path based metrics in large multi-domain or multi-layer networks. The mechanism that is described in this draft is generic and can serve as an application path computation framework for any Path Computation Element (PCE). We describe a protocol message format for PCE-PCC and PCE-PCE communications derived from this computation model. This draft proposes to elucidate protocol independent metrics defining path quality measurement criteria, algorithm complexity and scalability criteria related to path computation techniques through the PCEMP along with a PCE peer communication protocol and is in line with the PCE WG Charter. Choi, Guha Informational [Page 1] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 Table of Contents 1 Terminology ................................................. 3 2 Introduction ................................................ 4 3 Key features of PCEMP ....................................... 4 3.1 Other features of PCEMP ................................. 4 3.2 Cost of the protocol metrics ............................ 6 4 Overview of Soft Memory and Path Computing Unit requirements................................................. 7 4.1 Protocol level hierarchy architecture on the control plane......................................................... 7 4.2 PCE unit architecture as seen by the PCEMP protocol...... 9 5 The Path Computing Element Metric Protocol Data Structure (PCEMP DS)................................................... 9 6 Implementation considerations of the PCEMP protocol architecture................................................. 10 6.1 PCEMP State Machines Design.............................. 10 6.2 Functional Parameters for PCEMP DS processing of long sequence data................................................ 11 6.3 Realization of fast path computing unit architecture using PCEMP.................................................. 11 6.4 Fundamentals of the PCEMP Algorithm as a function of CPCA ........................................................ 12 6.5 PCEMP FSM Diagrams ...................................... 13 6.5.1 PCEMP Events ..................................... 14 6.5.2 Changing data vector profile PCEMP FSM ........... 15 6.5.3 Static data vector profile PCEMP FSM ............. 16 6.6 Flow Logic of the PCEMP FSM and design considerations ... 17 7 PCEMP message formats ....................................... 17 7.1 PCEMP Common Header ..................................... 18 7.2 PCEMP ESTABLISH message ................................. 19 7.3 PCEMP RESPONSE message .................................. 21 7.4 PCEMP ERROR message ..................................... 22 7.5 PCEMP TEARDOWN message .................................. 23 7.6 PCEMP ACK message ....................................... 24 8 Analysis of the PCEMP metrics in terms of protocol cost ..... 24 8.1 Link Bandwidth .......................................... 24 8.2 Router memory ........................................... 24 8.3 Router CPU usage ........................................ 25 8.4 Role of CC and SPC ...................................... 26 9 Conclusion .................................................. 26 10 Security Considerations ..................................... 27 11 IANA Considerations ......................................... 27 12 Acknowledgements ............................................ 27 13 Intellectual Property Considerations ........................ 27 14 Normative References ........................................ 28 15 Informational References .................................... 28 16 Authors' Addresses .......................................... 29 17 Full Copyright Statement .................................... 29 Choi, Guha Informational [Page 2] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 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. Choi, Guha Informational [Page 3] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 2. Introduction This draft addresses the metric definition and analysis requirements of PCE models set forth by the PCE WG Charter for an internet routing protocol. Some of these requirements are stated as follows. The next sections of this draft go on to show how PCEMP can be a satisfactory answer to efficient intra and inter domain path computation and routing. -> Key algorithm feature of the proposed protocol mechanism -> PCE controller memory and controller CPU cycle costs of protocol -> Scalability of the algorithm and protocol metrics in large multi domain and multi-layer networks. -> Limits of protocol metrics -> Adaptibility of algorithm for different centralized and distributed path computation scenarios -> Genericness of the mechanism and easy integrability with current PCEs and router hardwares 3. Key features of PCEMP This section summarizes the key features of the PCEMP protocol. PCEMP is a generic domain routing and path computation protocol that runs on any PCE unit that is capable of computing a path based on an ordered graph. PCEMP uses data vector techniques for path computation. Individual link state advertisements (LSAs) are mapped onto the computation units directly at TE-LSP setup time. Each PCE unit maintains this mapping information through the controller unit [1] and the mapping synchronization of the Link State Databases (LSDBs) are performed using PCEMP finite state machines. From this central controller sub-units, each PCE constructs a routing table by calculating a shortest data vector tree, the root being the calculating PCE node itself. 3.1 Other features of PCEMP The other features of the PCEMP protocol are: 1. Central Controller (CC). The central controller acts as the Choi, Guha Informational [Page 4] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 originator of the network's local information environment. The controller also acts in the global scenario of inter domain PCEs and inter layer networks. It serves as the key functional point of the data vector driven algorithm for all PCE information and link state synchronizations by co-ordinating LSP advertisements from other PCEs and LSRs (All PCE peers). 2. Soft PCE Controller (SPC). A Soft PCE Controller is an entity designed primarily for protection and fast route establishment in conjunction with the Central Controller. The SPC's primary functionality is to provide a robust and real-time path computation adjacency without crossover delays for the data driven algorithm mechanism. Also, this enables the LSP state and path computation state retention in case of nodal faults and hardware failures. 3. Support for peer adjacency through non-participating interior nodes. PCEMP treats these nodes opaquely and is able to maintain the PCE adjacencies over inter-domains and inter-layer networks. The protocol is generic and can be easily carried over existing routing mechanisms over non-supporting network clouds. There is no necessity for any additional configuration updates for PCEs attached to such networks for initial discovery as the data driven mechanism is flow based. 4. PCE domain areas (PCEDA). PCEMP allows the formation of distinct PCE domain areas in a specific domain for end-to-end peer participations. This is useful for several reasons. This is in line with the protocol architecture that provides a granularity of data protection within an autonomous system and isolation of data to local branches of the tree. This is also helpful for the design of the PCE units using soft memory techniques and reduces the algorithm operation costs. 5. 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. This reduces the amount of instantaneous re-computation of routing traffic data. It also enables partial controller database updates when there is a partial external route change. 6. Three level functional control hierarchy. PCEMP has a three level controller hierarchy, intra-PCE-domain, inter-PCE-domain and external-PCE-domain. This is discussed in the context of the Centralized Controller [1]. Choi, Guha Informational [Page 5] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 7. Virtual link mapping. This is done via the real-time configuration of logical local links based on the data-driven strategy of the algorithm. The mechanism is thus made topology independent and generic. 8. Soft Computation Memory (SCM). This is a novel feature in terms of path computation in the CC and SPC. It helps split the tree into a combination of sparse subtrees for fast computation. SCM can be used to assign metrics of path computation as well as compute data-driven flow based mappings in the PCE. 9. Data-driven routing metric. In PCEMP, the computation metrics are assigned to the outbound router interfaces and the soft memory cycles in the PCE controller unit. The cost of a path is then the weighted sum of the path's component interfaces and the soft memory cycles. The routing and external path metrics can be assigned externally. 10. Flow-based routing. Separate sets of paths can be computed for each type of service. This is done by assigning flow-based metrics to each outgoing router interface. 3.2 Cost of the protocol metrics This section analyzes the metrics that build up the PCEMP protocol metrics 1. Link Bandwidth. In PCEMP, the link state synchronizations are done using a data-driven strategy scheduling mechanism as will be shown later on in this draft. There is still backward compatibility with existing mechanisms like OSPF that physically advertise using reliable flooding schemes. Synchronization of link state databases reduces to a degeneration of individual link state machines' management in the CCs. This fits in well to the case where size of the TE-LSDB (Traffic Engineering Link State Database) increases and there is practically no change in the amount of link bandwidth used. 2. Router hardware memory and CPU usage. To consider the constraints of router hardware memory, PCEMP uses finite state machines in the SCM model for path computation. Still, this can be an imposing constraint even in the presence of many external LSAs. Dividing the path computation domain into multiple PCEDA can reduce this to a large extent. The length of time it takes to run PCEMP is a function of the finite state machine tree alignment on a given CC and SPC. Choi, Guha Informational [Page 6] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 Once the end-to-end peer PCE systems are determined, this becomes independent of the number of participating entities. 3. Role of the CC and SPC. The CC is responsible for handling data vectors and synchronization of different link states. The SPC acts a fast path computation mechanism in case of crossover and faults. This conjunction makes the PCE's functioning much more efficient. 4. Overview of Soft Memory and Path Computing Unit requirements This draft describes the architecture of the PCEMP protocol using soft memory concepts in the context of path computing block requirements. The network graph is constructed and analyzed real time inside the core of the PCE node with the aid of soft decision algebraic polynomial algorithms. The system is robust and guarantees efficient path computation for large scale data vectors and handles efficient segmentation of inter-domains and inter-layer networks into PCEDAs during path computation. It also reduces computational complexity of data intensive processing. We define a structure called the Path Computing Element Metric Protocol Data Structure (PCEMP DS) that makes up the system map for PCEMP state machines. The CC and SPC executes transforms as core computational units where the path computing algorithms for handling the entire data vector is processed, thereby reducing the computational complexity to a large extent. This draft addresses the requirements of a PCE unit block that helps to ease computationally intensive data processing for integrated provisioning in inter-domain and inter-layer networks. The PCEMP along with the CC and SPC as part of the PCE unit enables an integrated network architecture where each network layer can freely exchange topology and resource information. This allows network performance to be globally optimized across all layers. In addition, a single control plane and the central controller that manages all network layers greatly simplifies network management tasks. 4.1 Protocol level hierarchy architecture on the control plane In an integrated control plane, three levels of functional control hierarchy are mapped into one PCE node in the core of the Network Processing engine and implemented as a single unit. PCEMP thus has a three level controller hierarchy, intra-PCE-domain, inter-PCE-domain and external-PCE-domain. Choi, Guha Informational [Page 7] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 The functional blocks involved in the PCE node are: the network processor (the network management system with extended functionalities), the domain processor (the network element management system with extended functionalities), and the node processor. These are invoked by the PCEMP state machines and comprise the fundamental protocol level hierarchies on the control plane. In the first level, the network processor acts as an interface between users and all sub-network domains. Its' main functionality is to oversee the provisioning of new connections across multiple sub-networks and to maintain the network-wide topological view by reducing the computational domains to PCEDAs. The domain processor supervises tasks within a sub-network domain, such as service provisioning and network status monitoring. It handles requests for connection setup and teardown, and computes explicit paths that meet the SLA of each request. The network monitor observes the overall network health and detects failure and repair events. The databases maintained by the domain processor include the domain topology, the domain link state database gathered via the LSA protocol within its domain, and the domain connection database which keeps track of all established connections in the domain. The node processor manages specific functionalities that can be done in a distributed manner at each node, such as overload handling, failure recovery, and status monitoring. It also detects sudden link overloads, conducts a countermeasure and provides rapid protection and restoration capability in times of failure. The databases maintained by the node processor are the local link state and the local connection databases. The local link state is obtained automatically via the neighbor discovery protocol, while the list of local connections is obtained from all connections that traverse the node. These are implemented using soft memory concepts and synchronized using PCEMP. For the purpose of establishing a guaranteed a disjoint backup path and fast restoration techniques in the participating PCEDAs, it is essential that the large scale data processing in the CC and SPC have minimum overhead and processing delay. The CC manages the entire domain network, as discussed before. In this architecture, backup paths can be easily established end-to-end using the logical configuration in the SPCs using PCEMP. Based on the data driven routing metric table, which is configured at each PCE node by the CC, one can make a robust real-time path between a source node and a destination node and many intermediate nodes between the two. This is done using soft decision PCEMP algorithms. Choi, Guha Informational [Page 8] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 4.2 PCE unit architecture as seen by the PCEMP protocol These are the PCE unit architectures as seen by the PCEMP protocol state machines during path computation: 1. A matrix and parallel vector arithmetic unit that provides parallel data processing capabilities on the commonly used matrix and vector mathematical data types. Performance of this unit is independent of the size of the data vector under computation. This is implemented in the CC and SPC. 2. The processing core that provides the ease of programming and flexibility to address changing algorithms and standards. There exists a one-to-one map from the transform computed by the core to the high-level code generated by the PCE application. This is implemented using soft memory techniques in the CC, SPC and SCM. 3. A high-speed I/O system that allows complex, adaptive algorithms to be partitioned cost-effectively across multiple sub PCE unit blocks by providing dual ports. These ports are logically indistinguishable across the ordered pair of a data vector and the corresponding transform that is executed. These units are images of the PCE computing unit that are mapped onto the PCEMP state machines. 5. The Path Computing Element Metric Protocol Data Structure (PCEMP DS) This data structure is ideally a multidimensional array of ordered pairs of a data vector S, a transform T, and a mapping * to the system computing code. The description of the PCE unit block and memory architecture is in terms of this fundamental unit of computation. There are unique maps that exist between the PCEMP DS and the transform library that forms part of the PCE unit core. The elements of the vector S is again thought of as a key-record pair R (k,t) where k is the pointer of the components of the data vector S and t is the associated structure or a pointer to the structure to the corresponding executable transform T. Investigations into the methods to achieve parallelism of operations in different protocol engine architectures comprise solutions in form of machine architectures designed to execute transforms effectively; and of algorithms that allow concurrent accesses to search PCEMP DS'. If a complex transform is executed by a number of multiprocessors in the engine in parallel, then the best speed-up possible is logarithmic in the number of processors. The suggestion is therefore to increase the total throughput in the executing Choi, Guha Informational [Page 9] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 transforms and operations by increasing the number of instructions that can be handled by the protocol state machine at the same time rather than the speed-up of individual instructions. This is what makes the processing of large sequence data vectors so effective with a high degree of parallelism in the context of Path Computing. 6. Implementation considerations of the PCEMP protocol architecture This section discusses about the architecture of the PCEMP DS, outlay and mapping of protocol iterator instantiates to PCE unit blocks. -> Protocol System Architecture: PCEMP DS decoder architecture and path computing core that interfaces with the network processing engines in the PCE nodes. -> 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. The memory structure of the protocol processing engine is implemented in terms of these soft decoder algorithms. The method reduces hardware and path computing complexity considerably. -> Protocol System Requirements: High Level Path Computing Transform Library 6.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. 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. 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. Choi, Guha Informational [Page 10] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 6.2 Functional Parameters for PCEMP DS processing of long sequence data 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 is a member of the cardinal product of S and T. It is shown to be isomorphic with the logical decoder outputs. The IDS invokes 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; Output: Flow metric/measure p(A,B) 6.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. 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. Choi, Guha Informational [Page 11] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 6.4 Fundamentals of the PCEMP Algorithm as a function of CPCA 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: /* 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); */ /* 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); /* 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 */ 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 5.1 */ Choi, Guha Informational [Page 12] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 /* 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 a continuous, cumulative and dynamic process */ /* which involves minimum computation overhead and provides a */ /* guaranteed fast crossover for path computation and backup */ /* protection */ Stop: p(si,xj) = min log (sum (si, xj -1) /* Store the sums obtained in the Loop and then equate to the */ /* final sum */ /* 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 */ 6.5 PCEMP FSM Diagrams Based on the above algorithm and analysis, we can consider two distinct finite state machine diagrams of the PCEMP protocol architecture: 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 Choi, Guha Informational [Page 13] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 6.5.1 PCEMP Events PCEMP events are generated by the protocol processing routine iterators and by the state machines of the associated TE-LSP links. Every event has its number and a symbolic name. Here is a possible description of PCEMP events: 1 :PCEStart: This is when the PCE node receives a request from an adjacent peer 2 :PCEEnd: This is when the PCE node receives a request from its adjacent peer that the path computation has ended and the exchanged metrics acknowledged 3 :PCETest: This is an event that signifies the formation of PCEDAs and invokes the exchange of data vectors over the link. 4 :PCEResponse: This is an internal PCE unit kernel event that listens for the received data vectors. 5 :PCETestACK: The initial information exchange between a pair of adjacent PCE peers has been successful and acknowledged. (a) This event indicates the CPCA and PCEC classes have been instantiated by the initial exchange of information and the data driven mapping of external routing information is complete. (b) This event indicates the PCE unit is ready for path computation, but the ACK has not been explicitly taken into account. This is done to minimize unnecessary packet overhead during path computation information exchange. Tags are sufficient to convey this information. 6 :PCEMPTest: Data vector was successfully received over the designated port and a PCEMP Fast_Decoding_Procedure has been invoked and the message sent to the peer. 7 :PCEMPFail: This is when there is a protocol error in processing the PCEMP fast decode output messages or when there is a failure message received from the PCE peer. Choi, Guha Informational [Page 14] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 8 :PCEMPDetectFail: This indicates that a PCEMP fast decode output failed to compute within the specified alive timer. 9 :PCECompute: The CC and SPC have been invoked in the PCE node. 10:PCEDeCompute: The CC and SPC have been released in the PCE node. 11:PCEMPRetransmit: The peer sends another refresh message to the PCE node 12:PCELocalFail: Port and/or interface mismatches with the data vectors and output written metrics 13:PCEDataFail: There is a local fault related to the receiving of the data vectors and this is taken into consideration while assigning the measures to the output graph. 14:PCEDataDown: The data vector stream has terminated 6.5.2. Changing data vector profile PCEMP FSM Figure 1 illustrates the FSM transition diagram in this case. +------+ | |<-------+ +--------->| Down | | | +----| End |<-----+ | | | +------+ | | | |5b 3| ^ | | | | | |7 | | | | v | | | | | +------+ | | | | |PCEMP |<-+ | | | | |Test | |11 | | | | |Resp. |--+ | | | | +------+ | | | | 5a| 3^ | | | | | | | | | | v | | | |12 | +---------+ | | | +-->| |14 | | | | Start/ |----+ | +---------| Compute | | +---------+ | 9| ^ | | | | v |10 | +---------+ | | |13 | |Compute/ |------+ |DeCompute| +---------+ Figure 1: Changing data vector profile PCEMP FSM Choi, Guha Informational [Page 15] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 6.5.3 Static data vector profile PCEMP FSM Figure 2 illustrates the FSM transition diagram in this case. +------+ | |<------+ +---------->| Down | | | +-----| End |<----+ | | | +------+ | | | |5b 4| ^ | | | | | |8 | | | | v | | | | | +----------+ | | | | | PCEMPTest| | | | | | Resp. | | | | | +----------+ | | | | 6| 4^ | | | | | | | | | | v | | | |12 | +---------+ | | | +--->| Start/ |14 | | | | Compute |---+ | +----------| | | +---------+ | 9| ^ | | | | v |10 | +---------+ | | |13 | |Compute/ |-----+ |DeCompute| +---------+ Figure 2: Static data vector profile PCEMP FSM Choi, Guha Informational [Page 16] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 6.6 Flow Logic of the PCEMP FSM and design considerations This shows the flow logic of the PCEMP FSM and the design considerations on the PCE node Data --> CC and SPC ---> (Network Processor, dynamic data (PCE Domain Processor,:: fitness peer1) Node Processor) function | | v < Test goodness of fit ---> Execute : compare data profile FSM for | static data | > profile ** | v Instantiate PCE unit kernel threads with data driven strategy | | | v Send PCE descriptor ID | | v optimize data driven strategy for path computation | (PCE | peer2) v Data <-- CC and SPC** <--Execute FSM for changing data profile Figure 3: PCEMP FSM implementations on the PCE nodes 7. PCEMP message formats Based on the PCEMP FSM and the path computation metric protocol handling considerations, there are 5 primary message formats in the PCEMP protocol, the Common Header, the Establish, the Respond, the PCEMP Teardown, Error and the ACK. It is important to keep the protocol messaging light-weight primarily to consider one protocol for both PCC-PCE and PCE-PCE, and to keep the protocol metric costs to a minimum and facilitate greater reuse of existing objects in other signaling and routing messages. The PCEMP messages can also be encapsulated generically and carried as a sub-object/TLV in existing routing/signaling protocols like RSVP-TE, LDP and BGP. Choi, Guha Informational [Page 17] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 7.1 PCEMP Common Header 0 1 2 3 4 +--------------+--------------+--------------+--------------+ | Version | PCEMode | PCEFlag | PCEStatus | +--------------+--------------+--------------+--------------+ | PCEObject | PCEMP Message Length | +--------------+--------------+--------------+--------------+ The Header fields in the PCEMP message are as follows: 1. Version : 8 bits. The current version is 1 2. PCEMode : 8 bits. Currently this supports the following codes: 1: COMPUTE_PATH: This means to perform the TE LSP path computation only. The result is passed onto the corresponding routing/signaling protocol that is used for LSP setup in the participating PCE node. There is no explicit PCEMP message exchanges 2: ESTABLISH_PATH: This means to perform the TE LSP path computation and invoke the PCEMP message exchanges from the protocol finite state-machine executions 3: TRANSPARENT: This means enable the PCEMP message to be passed through transparently through a non-supporting node in the establishment of inter-domain PCEDAs 4: COMPUTE_LSP_TYPE: This is currently an optional feature. When set, this means the path computation is performed for p2mp TE LSPs and for QoS-enabled path computation. Details TBD. 3. PCEFlag : 8 bits. Currently this supports the following codes: 1: ACK requested: This means that the immediate next PCEMP adjacent peer is requested to send an ACK about the PCEMP message 2. ACK not requested: This means that the immediate next PCEMP adjacent peer does not need to inform the initiator about the status of path computation 4. PCEStatus: 8 bits. Currently this supports the following codes: 1: Protocol mode: PCEMP used as a soft-state protocol and path computation mode, in the usual format 2: Peer-to-peer mode: PCEMP used in conjunction with QoS related metrics. Set if COMPUTE_LSP_TYPE in PCEMode set. Details TBD. 3: Discovery mode: PCEMP is used as a PCE peer discovery mode for mobile nodes across different PCEDAs. Choi, Guha Informational [Page 18] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 4. Protection mode: PCEMP is used for explicit protection and restoration of paths across the PCEDAs. The ACK is suggested in this mode of operations. 5. PCEObject: 16 bits. This contains any specific requested support for the next PCEMP peer node. Requests could be suggested values of data driven maps of external routing information, suggested values of the MAX_PCE_TIME_FIT (in case of protection mode), etc. 6. PCE Message Length: 16 bits. This contains the length of the PCEMP message. 7.2 PCEMP ESTABLISH message 0 1 2 3 4 +-------------------------------------------------------+ | MAX_PCE_TIME_FIT | Flag | Suggest Time| +-------------+-------------+-------------+-------------+ | PCEDA-NUMBER | +-------------+-------------+-------------+-------------+ | OTHER AS-NUMBER | +-------------+-------------+-------------+-------------+ | PCEDA_COUNT | AS_COUNT | +-------------+-------------+-------------+-------------+ | PCE DESCRIPTOR ID | +-------------------------------------------------------+ | GLOBAL-PCE-TAG-ID | +-------------+-------------+-------------+-------------+ | PCEMP-LOCAL-INITIATOR-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-LOCAL-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-EXTERNAL-ROUTE-INITIATOR-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-EXTERNAL-ROUTE-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ | BANDWIDTH OBJECT | +-------------------------------------------------------+ | PCE SUBOBJECT 1 | +-------------------------------------------//----------+ | PCE SUBOBJECT n | +-------------------------------------------------------+ The fields in the PCEMP ESTABLISH message are as follows: 1. MAX_PCE_TIME_FIT: 16 bits. This is to advertise the path computation timer of the instantaneous (initiator) node and to inform the peer node that it sets the keep-alive time within which it calculates the path computation on its own side and expects an ACK from the adjacent peer within this time. Choi, Guha Informational [Page 19] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 2. Flag: 8 bits. This shows whether the MAX_PCE_TIME_FIT is static or variable for PCEMP FSM synchronization on the two adjacent PCE peers. Currently this supports the following codes: 1. STATIC 2. VARIABLE (in which case the first ACK from the PCE peer will need to suggest a different value of the MAX_PCE_TIME_FIT. This value if agreed upon by the initiator will be used for its own path computation, else there would be an error message generated) 3. Suggest Time: 8 bits. This value indicates the suggested value of the MAX_PCE_TIME_FIT when the Flag is set to Variable. 4. PCEDA-NUMBER: 32 bits. This value indicates the number of PCEDAs that are traversed by the TE-LSP once the path computation takes place in the corresponding PCE peers. This has local significance to every participating PCE node. Non-supporting nodes just pass this field transparently. 5. OTHER AS-NUMBER: 32 bits. This value indicates the number of other Autonomous Systems that are traversed by the TE-LSP during path computation in the corresponding PCE peers. This basically indicates the strict or loose hop routes that comprise different AS-s which do not comprise the PCEDAs as determined by a single PCE node. 6. PCEDA_COUNT: 16 bits. Keeps a total count of the PCEDAs traversed by a TE-LSP at any one PCE node. This has local significance to the CC and the SPC and the total count takes into consideration all the different multiple TE-LSPs that pass through a single PCE node. 7. AS_COUNT: 16 bits. Keeps a total count of the ASs traversed by a TE-LSP at any one PCE node. This has local significance to the CC and the SPC and the total count takes into consideration all the different multiple TE-LSPs that pass through a single PCE node. 8. PCE DESCRIPTOR ID: 32 bits. PCEMP assigns an IDT (input data type) 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 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. 9. GLOBAL-PCE-TAG-ID: 32 bits. This is a global ID w.r.t. to a fixed TE LSP that is assigned by external routing information and 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. This, along with the PCE DESCRIPTOR ID, provides a unique identification of the Choi, Guha Informational [Page 20] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 TE-LSP and also helps in granularity protection of the main LSP. 10. PCE-LOCAL-INITIATOR-ADDRESS: 32 bits. This is the local TE-LSP specific head-end address of the participating node. It is local to each CC and SPC and is specific to the PCEDA which is assigned to that PCE node. This address is PCEDA specific to the initiator 11. PCE-LOCAL-RESPONDER-ADDRESS: 32 bits. This is the local TE-LSP specific tail-end address of the corresponding participating PCE node. It is also local to each CC and SPC and is specific to the PCEDA which is assigned to the immediate PCE hop node of the initiator. 12. PCEMP-EXTERNAL-ROUTE-INITIATOR-ADDRESS: 32 bits. This is the global TE-LSP head-end address (consisting of different AS-s) which are used for tunneling. This address is the TE-LSP tunnel address that is assigned to the initiator. 13. PCEMP-EXTERNAL-ROUTE-RESPONDER-ADDRESS: 32 bits. This is the global TE-LSP tail-end address (consisting of different AS-s) which are used for tunneling. This address is the TE-LSP tunnel address that is assigned to the responder. 14. BANDWIDTH OBJECT: 32 bits. This is used for conveying bandwidth support and QoS requirements imposed by the initiator as well as the global TE-LSP tunneling. Used in conjunction with the COMPUTE_LSP_TYPE set in the PCE Header if used. Details TBD. 15. PCE SUBOBJECT 1: 32 bits. Used to insert any local information like protection requirements, diversities, etc. This is an optional component of the PCEMP ESTABLISH Message. 7.3 PCEMP RESPOND message 0 1 2 3 4 +-------------------------------------------------------+ | MAX_PCE_TIME_FIT | Flag | Suggest Time| +-------------------------------------------------------+ | PCEDAType | PathType | +-------------+-------------+-------------+-------------+ | PCE DESCRIPTOR ID | +-------------------------------------------------------+ | GLOBAL-PCE-TAG-ID | +-------------------------------------------------------+ | PCEMP-LOCAL-INITIATOR-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-LOCAL-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-EXTERNAL-ROUTE-INITIATOR-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-EXTERNAL-ROUTE-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ | BANDWIDTH OBJECT | +-------------------------------------------------------+ | PCE SUBOBJECT 1 | +-------------------------------------------//----------+ | PCE SUBOBJECT n | +-------------------------------------------------------+ Choi, Guha Informational [Page 21] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 The fields in the PCEMP RESPOND message are as follows: 1. PCEDAType: 16 bits. This basically indicates the nature of the TE-LSP within the specific PCEDA, i.e. whether it is composed of AS-s, or a non-supporting entity, etc. 2. PathType: 16 bits. This indicates the nature of the path that is returned after computation. Also indicates the presence of loose and strict route paths, or if an explicit route is requested, or if an explicit re-computation is necessary by the initiator. All the other fields are derived similarly from the ESTABLISH message. The RESPOND message may also contain information about backup path suggestions, alternative route computation and support of the bandwidth/path computation etc. It is important that the PCEMP protocol FSMs are synchronized at the beginning of mutual path computation, so it might be necessary to send a couple of ESTABLISH-RESPOND messages to negotiate about the MAX_PCE_TIME_FIT field. This is particularly true when the PCEStatus Flag of the PCEMP Common Header is either 2 (Peer-to-peer mode), 3 (Discovery mode) or 4 (Protection mode). Alternatively, the timing info MAY be carried by a PCE SUBOBJECT directly with a PCEMP header and the ACKs may be requested by setting the PCEFlag field to ACK requested = true in the PCEMP Common Header. The state machines follow from Sections 6.5.2 and 6.5.3. 7.4 PCEMP ERROR message 0 1 2 3 4 +-------------------------------------------------------+ | ERROR TYPE | ERROR CODE | +-------------+-------------+-------------+-------------+ | PCEMP NEGOTIATE OBJECT | +-------------------------------------------------------+ | PCE DESCRIPTOR ID | +-------------------------------------------------------+ | GLOBAL-PCE-TAG-ID | +-------------------------------------------------------+ | PCEMP-LOCAL-INITIATOR-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-LOCAL-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-EXTERNAL-ROUTE-INITIATOR-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-EXTERNAL-ROUTE-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ | BANDWIDTH OBJECT | +-------------------------------------------------------+ | PCE SUBOBJECT 1 | +-------------------------------------------//----------+ | PCE SUBOBJECT n | +-------------------------------------------------------+ Choi, Guha Informational [Page 22] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 The fields in the PCEMP ERROR message are as follows: 1. ERROR TYPE: 16 bits. This denotes the type of Path Computation Error that has happened, e.g. lack of bandwidth, allocation not possible etc. A full list is TBD. 2. ERROR CODE: 16 bits. This denotes the corresponding error descriptor generated. Currently, the ERROR CODE supports the following codes: 1. FAILED PATH COMPUTATION: Only if the PCE DESCRIPTOR ID has the value -1, as explained in Section 7.2 2. OUT OF TIME: If the MAX_PCE_TIME_FIT timer operated in the variable mode expires before a RESPOND or an ACK message arrives. 3. PROTOCOL ERROR: If the requested path computation cannot be supported. 3. PCEMP NEGOTIATE OBJECT: 32 bits. This denotes the suggested object (in terms of bandwidth support, path computation support etc.) that are supported by the responder for the corresponding Error Code generated. 7.5 PCEMP TEARDOWN message 0 1 2 3 4 +-------------------------------------------------------+ | RequestType | REQUEST ID | +-------------+-------------+-------------+-------------+ | PCE DESCRIPTOR ID | +-------------------------------------------------------+ | GLOBAL-PCE-TAG-ID | +-------------------------------------------------------+ | PCEMP-LOCAL-INITIATOR-ADDRESS | +-------------+-------------+-------------+-------------+ | PCEMP-LOCAL-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ The fields in the PCEMP TEARDOWN message are as follows: 1. RequestType: 16 bits. This denotes the type of request associated with the path computation termination and bringing back the PCEMP event state to PCEDataDown. Normally, this is done when the processing data stream has terminated. However there might be an administrative requirement to do this, in which case either the initiator or the responder might issue this message. Currently there are two codes supported here: 1. DELETE PATH STATE: The complete PCEMP FSM is brought back to the initial state and PCEMP messages stop. Choi, Guha Informational [Page 23] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 2. CHANGE IN COMPUTATION STYLE: This means that though the PCEMP messages stop, the state of the participating PCE peers go to the COMPUTE_PATH state. Ideally, then the PCEMode field in the PCEMP Common Header SHOULD be set to the COMPUTE_PATH code. 7.6 PCEMP ACK message 0 1 2 3 4 +-------------+-------------+-------------+-------------+ | PCEMP-LOCAL-RESPONDER-ADDRESS | +-------------+-------------+-------------+-------------+ | PCE SUBOBJECT 1 | +-------------------------------------------//----------+ | PCE SUBOBJECT n | +-------------------------------------------------------+ The PCEMP ACK message is local between two PCEDA peers and contains the local responder address without any argument. There may be optional PCE subobjects with the ACK message, as discussed earlier. 8. Analysis of the PCEMP metrics in terms of protocol cost: 8.1 Link Bandwidth In PCEMP, we have shown that the link state synchronizations are done using a data-driven strategy scheduling mechanism which minimizes kernel calls and invokes the computation unit only when there is a significant change in the data profile within the time of goodness of fit. Wastage of link bandwidth by ACKs and soft-state preservation messages are minimized. Synchronization of link state databases reduces to a degeneration of individual link state machines' management in the CCs and SPCs. This fits in well to the case where size of the TE-LSDB increases and there is practically no change in the amount of link bandwidth used. 8.2 Router memory Memory requirements in PCEMP are a function of the SCM realizations of the CC and SPC. External LSAs comprise the majority of peer advertisements. The PCEMP DS processing application benefits from an architecture consisting of multiple register files in the PCE unit, each conforming to the following properties: Choi, Guha Informational [Page 24] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 1. Each register file supports a number of multiple read/write ports that is at least equal to the number of states in the IDT sequence. Typical numbers range from 4096 to 65536. 2. The memory access pattern of the register file highly structured. Data is alternatively written in the forward and backward directions. The same applies to the read pattern. There will be 128 read accesses for every written data. 3. In-place storage and single cycle read/write, where data is read during the first half cycle, followed by a write during the second half. The structured access pattern makes it redundant to implement an address decoder that is commonly found in register file and general purpose embedded memory designs of routers. Our architecture that implements the address decode utilizes this functionality in the PCE node. The CPCA algorithm indicates that the size of memory is of order ~ O (N x D x B), where N = Number of states in the IDT, D = Depth of the trace forward/backward path, B = Number of bits in the fixed-point algorithm. The states of the IDT can be drawn from any arbitrary number of permutations of the input data sequence. Typical values of N range from 1024 to 4096 .Values of D are expected to be between 512 and 1024. Bit resolution B is set at 4 or less. CPCA time execution = 0.5 s for N 1024 and D 512 with B 4 A database can thus support 100,000 external LSAs with a router memory block of 512K bytes. This can be extended in the hardware architecture of the PCE unit as per configuration. 8.3 Router CPU usage As the size of the PCEDA grows, the number of interfaces per router stays bounded. Thus the order of computation is order (n * log (n)), where n is the number of routers in the routing domain. The approach in PCEMP is to achieve parallelism of operations in different protocol engine architectures comprising of solutions in form of machine architectures designed to execute transforms effectively. If a complex transform is executed by a number of multiprocessors in the engine in parallel, then the best speed-up possible is logarithmic in the number of processors. The suggestion is therefore to increase the total throughput in the executing transforms and operations by increasing the number of instructions that can be handled by the protocol state machine at the same time rather than the speed-up of individual instructions. This is what makes the processing of large sequence data vectors so effective with a high degree of parallelism in the context of Path Computing. Choi, Guha Informational [Page 25] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 8.4 Role of CC and SPC The CC is responsible for handling data vectors and synchronization of different link states. The SPC acts a fast path computation mechanism in case of crossover and faults. This conjunction makes the PCE unit's functioning much more efficient. This has the same implications as the LSA protocol used for peer advertisement and topology discovery. A significant improvement by using PCEMP is that the number of routers that can be attached to a single PCEDA is quite arbitrary. As traffic increases, the SPC eases the stringency of backup path computation and the CC-SPC combination guarantees a disjoint alternate path calculation with the minimum crossover time. This follows from Section 4.1 9. Conclusion In summary, we have proposed an algorithm and protocol metrics for an efficient Path Computation model that does away the obvious limitation about the size of the computing hardware system with respect to physical memory requirements. This method utilizes pipelined access by the PCE units to the PCEMP DS by distributing the levels among the multiprocessors in the array of invoked computing logic in the CC and SPC. The objectives achieved in this method, are, firstly, achieving a coarse grained transform engine with a small number of multiprocessors connected in a simple topology of a linear array. The accesses are highly localized within the structure topology. Secondly, performing load balancing among the computing units along with the execution of transforms increases the pipeline interval only by a constant. This helps in automatic buffering and synchronization of individual scalar elements of the input data vector across adjacent PCE peers, which is a big plus for reducing computational complexity and overhead. A number of issues related to the PCEMP DS tree restructuring operations and data redistribution for load balancing thus get resolved in a much simpler and more efficient manner in this architecture, which effectively means that there is greater possibility of increasing the number of scalar points in the input data vector for path computation. The algorithm is generic and can easily be integrated onto existing network processing engines and routers. There might not be physical hardware requirement for PCEMP support, it can be soft configured on the participating PCE peers. Choi, Guha Informational [Page 26] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 10. Security Considerations 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. 11. IANA Considerations The different PCEMP message field values might be needed to be a assigned specific numbers. 12. Acknowledgements This work was supported by the Institute of Information Technology Assessment (IITA) through the Ministry of Information and Communications (MIC), Republic of Korea. 13. 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. 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. Choi, Guha Informational [Page 27] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 14. 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. 15. Informational References [1] Choi, J.K., et al., "Fast End-to-End Restoration Mechanism with SRLG using Centralized Control", draft-choi-pce-e2e-centralized- -restoration-srlg-03.txt, July 2005 (work in progress) Le Roux, J.L., Ed., "Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-00.txt, July 2005 Ash, J., and Le Roux, J.L., Ed., "PCE Communication Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-00.txt, May 2005 [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 (work in progress). [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 (work in progress). Choi, Guha Informational [Page 28] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005 [Ash] Farrel, A., Vasseur, JP., and Ash, J., "Path Computation Element (PCE) Architecture", draft-ash-pce-architecture-01.txt, February 2005 (work in progress) 16. Authors' Addresses Jun Kyun Choi Information and Communications University (ICU) 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Dipnarayan Guha Information and Communications University (ICU) 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea Phone: +82-42-866-6282 Email: dip@icu.ac.kr 17. Full Copyright Statement Copyright (C) The Internet Society (2005). 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 translations of it MAY be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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 29] Internet Draft draft-choi-pce-metric-protocol-02.txt July 2005