Network Working Group Jun Kyun Choi (ICU) Internet Draft Dipnarayan Guha (ICU) Category: Informational Seng Kyoun Jo (ICU) Young Hwa Kim (ETRI) Byung Ho Yae (ETRI) Expires: April 2005 October 2004 Framework of PCEMP based Layer 1 Virtual Private Network draft-choi-pce-l1vpn-framework-00.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, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. Abstract When path computation is done in the management systems for Layer 1 Virtual Private Networks (L1 VPNs), it would be important that resource information is synchronized between the management systems and the Provider Edge /Provider (PE/P). This draft looks at such a scenario from the viewpoint of the Path Computation Element Metric Protocol (PCEMP) that acts a generic computation model for path based metrics in large multi-domain or multi-layer networks. This draft proposes to show how a L1 VPN framework may be included within the scope of Path Computation Element architectures and is derived primarily from the motivation of per VPN peer service solutions using PCE techniques. PCEMP metrics defining path quality measurement criteria, algorithm complexity and scalability criteria for L1 VPNs is in line with the functional specifications of Generalized Traffic Engineered LSP path computation techniques involving Path Computation Element(s) of the PCE WG Charter. Choi, Guha et al. Informational [Page 1] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 Table of Contents 1 Terminology ................................................. 3 2 Introduction ................................................ 4 3 L1 VPN service models and architecture frameworks ........... 4 3.1 L1 VPN Network Topology ................................. 4 3.2 Current technologies for dynamic L1 provisioning and deficiencies ................................................ 5 3.3 Per VPN Peer Service Model .............................. 5 3.4 Resource management per VPN ............................. 6 4 Key features of PCEMP ....................................... 7 4.1 Other features of PCEMP for L1 VPN dynamic provisioning . 7 5 Path Computation fundamentals applicable to dynamic L1 provisioning ................................................ 9 5.1 Introduction to PCE nodes and PCEMP peers over the control network ............................................. 10 5.2 Network structure considerations ........................ 11 5.3 Control structure considerations ........................ 11 5.4 Segment wise partitioning using the PCE nodes ........... 11 5.5 Complete Network Topology for L1 VPN networks: A PCE perspective ................................................. 12 6 Overview of PCE node requirements for dynamic L1 VPN provisioning ................................................ 13 6.1 Protocol level hierarchy architecture on the L1 control plane ............................................... 13 6.2 PCEMP peer architecture as seen by the PCEMP protocol ... 15 7 Conclusion .................................................. 15 8 Security Considerations ..................................... 15 9 IANA Considerations ......................................... 16 10 Acknowledgements ............................................ 16 11 Intellectual Property Considerations ........................ 16 12 Normative References ........................................ 17 13 Informational References .................................... 17 14 Authors' Addresses .......................................... 19 15 Full Copyright Statement .................................... 19 Choi, Guha et al. Informational [Page 2] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-ROUTING] and [PPVPN-TERM]. This memo makes use of the following terms: 1. Virtual link: A provider network TE link provided to customers in routing information for purposes which include path computation. A physical link may or may not exist between two end points of a virtual link [1]. 2. Virtual node: A provider network logical node provided to customers in routing information. A virtual node may represent a single physical node or multiple physical nodes and links [1]. 3. VPN end point: CE's port, connected to a PE device, which is part of the VPN membership [1]. 4. VPN connection (or connection in L1 VPN context): A connection between a pair of VPN end points. In some scenarios, A VPN connection may be established between a pair of Cs (customer devices) [1]. 5. Path Computation Element (PCE): an entity that is responsible for computing/finding inter/intra domain LSPs. This entity can simultaneously act as client and a server. Several PCEs can be deployed in a given AS. 6. 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. 7. Domain: Denotes an Autonomous system (AS) within the scope of this draft. Choi, Guha et al. Informational [Page 3] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 2. Introduction This draft addresses L1 VPN frameworks from the PCE perspective with the motivation of per VPN peer service model architecture realizations. L1 VPNs provide services over layer 1 networks. This draft provides a framework by those networks controlled by GMPLS protocols. In this context, we show how PCEMP [2], set out by the metric definition and analysis requirements of PCE models set forth by the PCE WG Charter for an internet routing protocol, may help realize this motivation of the peer service model. The next sections of this draft go on to show how PCEMP can be a satisfactory solution to L1 VPN resource management using path computation techniques. The purpose of this draft is informational and is in line with the requirements and architecture work in this field that has been undertaken and is currently going on within the ITU-T. 3. L1 VPN service models and architecture frameworks 3.1 L1 VPN Network Topology The L1 network, made of Optical Cross-Connects (OXCs) or Time Division Multiplex (TDM) capable switches (we address them as L1 nodes), may be seen as consisting of provider edge (PE) devices that give access from outside of the network, and provider (P) devices that operate only within the core of the network. Similarly, outside the layer 1 network is the customer network consisting of customer (C) devices with access to the layer 1 network made through customer edge (CE) devices [1]. A CE and PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it [1]. Figure 1 shows such a diagram derived from [1] +--------------------------------+ | | | | : +------+ | +------------+ | : | CE | | | Management | | : |device| | | system(s) | +------+ : | of | | +------------+ | |==:=|VPN A| | | | : +------+ +------+ : | L1 | PE | : +------+ | CE | : | connection |device| : | CE | |device| : +------+ +------+ | | : |device| | of |=:==| |==========| |==========| |--:-| of | |VPN A| : | | | | +------+ : |VPN B| +------+ : | PE | | P | | : +------+ +------+ : |device| |device| | : +------+ | CE | : | | | | +------+ : | CE | |device|=:==| |==========| |==========| |--:-|device| | of | : +------+ +------+ | | : | of | |VPN B| : | | PE | : |VPN A| +------+ : | |device| : +------+ : | | | : +------+ : | | |==:=| CE | : | +------+ : |device| : | | : | of | : | | : |VPN B| : | | : +------+ Customer | | Customer interface | | interface +--------------------------------+ |<------ Provider network ------>| | | Figure 1: L1 VPN reference model [1] Choi, Guha et al. Informational [Page 4] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 In L1VPN, L1 connections are provided between CE's physical interfaces within the same VPN. In Figure 5.1, a connection is provided between the lefthand CE of VPN A and the upper righthand CE of VPN A, and another connection is provided between the lefthand CE of VPN B and lower righthand CE of VPN B (shown as "=" mark) [1]. 3.2 Current technologies for dynamic L1 provisioning and deficiencies Current UNIs (User Network Interfaces) include features to facilitate requests for end-to-end (i.e. CE-CE) service requests that include the specification of constraints such as explicit paths, bandwidth requirements, protection needs, and destinations. The UNIs, however, do not provide a sufficiently high level of service to support VPNs without some additions. For example, there is no way to distinguish between control messages received over a shared control link (i.e., a control link shared by multiple VPNs) at a UNI, and these messages must be disambiguated with respect to the L1VPN to which they apply [1]. Further, there is currently no leakage of routing information across the PE to CE boundary. While this restriction may be considered desirable from the perspective of network separation, VPN operation may benefit from the dynamic exchange of routing information between CEs that provide access to the VPNs. In order that L1 VPNs can be supported in a fully functional manner, these deficiencies and other requirements must be addressed. The Path Computation technique may be a useful solution to overcoming these deficiencies in current technologies for dynamic L1 provisioning. We will show how PCEMP and the associated protocol and PCE unit architecture is beneficial for the support of L1 VPNs. 3.3 Per VPN Peer Service Model Figure 2 describes the per VPN peer service model. +--------------------+ | | +----+ : +----+ +----+ +----+ : +----+ | CE |-------:---| PE |----| P |----| PE |---:-------| CE | +----+ : +----+ +----+ +----+ : +----+ : | | : : +--------------------+ : : |<-Provider network->| : Customer Customer interface interface Figure 2: Per VPN peer service model [1] Choi, Guha et al. Informational [Page 5] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 In this service model, the provider partitions the TE links within the provider network per VPN, and discloses per VPN TE link information to corresponding CEs. As such, a CE receives routing information of PE-CE links, remote CE sites, as well as partitioned portions of the provider network. This is a good scope of work for PCE techniques, with the partitioning of PCEDAs (PCE Domain Areas) as shown later on in this draft. Virtual links may be constructed between two nodes where direct physical links do not exist, or virtual nodes may be constructed to represent multiple physical nodes and links. This is in line with the PCEMP model and a direct consequence of the protocol architecture. 3.4 Resource management per VPN In this type of service model, one optional requirement is resource management for a dedicated Data-Plane (the provider network partitions link resources per VPN for exclusive use by a particular VPN), and resource management for sharing the Data-Plane among a specific set of VPNs (the provider network assigns link resources to a specific set of VPNs). A simple way to meet this requirement is to implement resource management functionalities in the management systems. However, if the PE/P need path computation locally, not relying on the management systems, then support of resource management in PE/P (e.g., routing protocol extension) is necessary. This is especially beneficial in the case of dynamic restoration (restoration that does not reserve backup resources in advance). When path computation is done in the management systems, it would be important that resource information is synchronized between the management systems and PE/P. This is a good scope for the PCEMP architecture where resource management support can take place through the SCMs and Fast decoding outputs [2]. Currently, there is no solution document for this type of service model [1]. This draft using PCEMP could be a suitable answer apart from the suggestions suggested in [GVPN] or the virtual router approach [VR]. Choi, Guha et al. Informational [Page 6] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 4. 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 [3] and the mapping synchronization of the 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. 4.1 Other features of PCEMP for L1 VPN dynamic provisioning The other features of the PCEMP protocol that are helpful for dynamic L1 provisioning are: 1. Central Controller (CC). The central controller acts as the 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. This is the key element in the L1 VPN peer entities. 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. This is necessary to support peer L1 provisioning over different domains. Choi, Guha et al. Informational [Page 7] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 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. In the per VPN peer service model, the provider partitions the TE links within the provider network per VPN, and discloses per VPN TE link information to corresponding CEs. The partitioning of PCEDAs using PCEMP is a direct driver to this mechanism. 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. This helps in setting up the L1 VPN paths with minimal provisioning turnaround time. 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 [3] and the L1 VPN provisioning blocks in the PCE nodes. 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 and can be applied to the Network Topology structure of a L1 VPN as shown in Figure 1. Choi, Guha et al. Informational [Page 8] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 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. We now address some of the Path computation fundamentals applicable to dynamic L1 provisioning and define the architecture on which the PCEMP may be applicable. 5. Path Computation fundamentals applicable to dynamic L1 provisioning __________________Control/Management Network_________ / \ / +--+ PCEMP peer +--+ PCEMP peer \ / | |-------------------| |------------------------\ / +--+PCE node +--+PCE node ........ \ \ /|| /|| ........ / \ / | \ / | \ / \___|_|__\_________________|_|__\______________________/ | | | | | \ / | \<-------------> / | |<--------------------...> Control / | \ PCEMP / | \ PCEMP ........ PCEMP Channel / | \ / | \ ........ peers _______/____|_____ \___ _____/____|______\_____ \ +--+ | +--+ | \ +--+ | +--+ | \ | |L1 | | | | \ | | | L1 | | | \ +--+Node | +--+ / \ +--+ |Node +--+ / \ \ | / / \ \ | / / \ \ | / / \ \ | / / ........ \ \ | / / \ \ \ / / ........ \ +--+ / \ +--+ / \ | | / GMPLS \ | | / \ +--+ / \ +--+ / Layer 1 \ / \ / Network \____/ \_____/ Figure 3. PCE-L1 node based L1 VPN framework using PCEMP Figure 3 shows the layered architecture of a PCE based L1 VPN framework for per VPN peer service model. The model is facilitated by the use of GMPLS, which supports a concept of common control of packet, TDM, wavelength and fiber services, part of the Layer 1 network, and is a key enabler of this new network architecture model using PCE techniques. Choi, Guha et al. Informational [Page 9] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 5.1 Introduction to PCE nodes and PCEMP peers over the control network This draft addresses the coordination of the IP and optical network provisioning in the L1 VPN scenario based on a consolidated PCE node and a truly integrated control plane. This PCE node, which comprises the path computing unit that supports PCEMP, 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 PCEMP peers that manage all network layers simplify network management tasks and facilitate dynamic L1 provisioning. As far as control and management types for L1 networks are concerned, they can be classified into three categories: centralized, distributed and hybrid control/management. Each control and management type has its' own advantages and disadvantages, but typical telecommunication networks and automatic switched optical networks (ASON) defined in ITU-T follows a centralized control/ management architecture in which the control plane is separate from the data plane. In this draft, for path computation purposes, we consider the control plane to be separated logically from the data plane. Separate PCE nodes or control/management networks comprising a series of PCEMP peers could be connected to each other by through signaling channels and appropriate PCEMP message exchanges. If the domains of the control/management networks increase, a hierarchical control/management structure could be applied. This can be fully realized in the PCE node through functional blocks defined by the SCM [2]. There is a channel interface between the PCE node and any L1 node in the Layer 1 network, and this can be realized using PCEMP. In this architecture, the PCE node is responsible for path calculation, recovery and provisioning. Some of the recovery functions are also assigned to nodes in the Layer 1 network for the purpose of control and load balancing. Choi, Guha et al. Informational [Page 10] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 5.2 Network structure considerations Each PCE node is assumed to have L1 and L2/L3 router capabilities in the same hardware setup, which results in the support of multiple traffic types at the same location. The traffic manager in each L1 node also manages multiple traffic types. Each L1 node can communicate directly with the corresponding PCE node to report its status. As mentioned in Section 5.1, this is achieved via PCEMP. The PCE nodes takes care of L1 nodes within the same PCEDA. They also have the responsibility of centralizing domain network management service and integrating the management of the L1 network in their respective domain. This structure permits scalability as well as internetworking of different administrative domains. 5.3 Control structure considerations Network elements within each domain communicate with one another via a common control plane. We assume a dedicated out-of-band control channel between two adjacent nodes, and between each L1 node and the PCE node. The common control plane can be implemented based on GMPLS. Apart from RSVP and CR-LDP extensions to GMPLS, PCEMP can provide traffic engineering in this unified network architecture for dynamic L1 VPN provisioning. Metrics of PCEMP in this regard remains an issue for future study. Moreover, neighbor discovery and link state update can employ routing LSA protocols like ISIS and OSPF extensions to GMPLS. 5.4 Segment wise partitioning using the PCE nodes As a network becomes large, the size of the sub networks also become large. Segment wise partitioning into PCEDAs are effected by the PCE nodes in the integrated network architecture as mentioned in Section 3.1. Additionally, this can support fast recovery and can take care for partially multiple simultaneous failures using the SPCs in the PCE nodes and thus effect fast dynamic provisioning with the minimal crossover time. The main concept is to partition a large network into several small networks to configure the path computing information to each small network. This is one of the major functionalities of the PCE nodes, which effectively partitions the addressed domain into respective PCEDAs using the three functional blocks, the Network Processor, Domain Processor and Node Processor [2]. PCEDAs are chosen according to network provisioning such as physical layer conditioning, call demands or QoS demands, which may arise from the user. The following shows a segment wise PCEDA architecture, with the PCE nodes managing the different domain areas. Choi, Guha et al. Informational [Page 11] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 PCEDA 1 PCEDA 2 PCEDA 3 +-----------------+--------------+------------------+ | +--+ | +--+ | +--+ | | |PCE| | |PCE| | |PCE| | | //+--+\\ | /+--+\ | //+--+\\ | | // \\ | / \ | // \\ | | // \\ | / \ | // \\ | | +--+ +---+ +---+ +--+ | | |L1| |L1 | |L1 | |L1| | | +--+ +---+ +---+ +--+ | | \ / | \\ // | \ / | | \ / | \\ // | \ / | | \ / | \\ // | \ / | | +--+ | +--+ | +--+ | | |L1| | |L1| | |L1| | | +--+ | +--+ | +--+ | +-----------------+--------------+------------------+ // : Working path/ : backup path Figure 4. Segment-wise partitioning into PCEDAs for L1 networks 5.5 Complete Network Topology for L1 VPN networks: A PCE perspective Based on the above discussions, we can redraw Figure 1 showing the complete network topology for L1 VPN networks from the PCE perspective. This is shown in Figure 5. +--------------------------------+ | | | | : +------+ | +------------+ | : | CE | | | PCE node | | : |device| | | PCEMP peer | +------+ : | of | | +------------+ | |==:=|VPN A| | | | : +------+ +------+ : | L1 | PE | : +------+ | CE | : | connection |device| : | CE | |device| : +------+ PCEMP +------+ PCEMP |PCEMP | : |device| | of |=:==| |==========| |==========|peer |--:-| of | |VPN A| : | | | | +------+ : |VPN B| +------+ : | PE | | P | | : +------+ +------+ : |device| |device| | : +------+ | CE | : |PCEMP | PCEMP |PCEMP | PCEMP +------+ : | CE | |device|=:==|peer |==========|peer |==========| |--:-|device| | of | : +------+ +------+ | | : | of | |VPN B| : | | PE | : |VPN A| +------+ : | |device| : +------+ : | |PCEMP | : +------+ : | |peer |==:=| CE | : | +------+ : |device| : | | : | of | : | | : |VPN B| : | | : +------+ Customer | | Customer interface | | interface +--------------------------------+ |<------ Provider network ------>| | | Figure 5: L1 VPN Network Topology from a PCE perspective Choi, Guha et al. Informational [Page 12] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 Based on this, we discuss about the aspects of PCEMP and the computing unit requirements for L1 VPN provisioning for a per VPN peer service model. Readers can refer to [2] for a detailed description of the PCEMP protocol. 6. Overview of PCE node requirements for dynamic L1 VPN provisioning The architecture of the PCEMP protocol using soft memory concepts in the context of path computing block requirements is the key factor for dynamic provisioning in Layer 1 VPNs. 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 handle efficient segmentation of inter-domains and inter-layer networks into PCEDAs during path computation, thus effectively realizing the per VPN peer model. It also reduces computational complexity of data intensive processing. The requirements of a PCE node that helps to ease computationally intensive data processing for integrated provisioning in inter-domain and inter-layer networks have been discussed in Section 5. The PCEMP along with the CC and SPC as part of the PCE node 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. 6.1 Protocol level hierarchy architecture on the L1 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 control hierarchy, intra-PCE-domain, inter-PCE-domain and external-PCE-domain. This is used to manage the PCEMP peers Choi, Guha et al. Informational [Page 13] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 on the integrated network architecture as shown in Figure 3. 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 in [2]. 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 et al. Informational [Page 14] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 All this is used for dynamic L1 VPN provisioning. 6.2 PCEMP peer architecture as seen by the PCEMP protocol These are the PCEMP peer architectures as seen by the PCEMP protocol state machines during path computation. From Figure 5, we see that the participating nodes in the integrated network for L1 VPN topology become corresponding PCEMP peers. 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 and thus make all the participating entities PCEMP supportive. 7. Conclusion We have shown that a path computation technique based architecture might be a good solution towards dynamic L1 provisioning in per VPN peer based service models. There is perfect synchronization of resource information between PCEMP peers using the PCEMP DS [2]. This draft addresses L1 VPN frameworks from the PCE perspective which is a relatively new way of describing such an architecture. In this context, PCEMP helps to realize this motivation of the peer service model. Resource management level granularity is mapped onto using PCEMP DS [2]. Traffic Engineering and protocol performance under stress remain topics of future study. 8. 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 scheme 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. Choi, Guha et al. Informational [Page 15] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 9. IANA Considerations This document makes no requests for IANA action. 10. Acknowledgements This work was supported in part by the Korea Science and Engineering Foundation (KOSEF) through the Ministry of Science and Technology (MOST) and the Institute of Information Technology Assessment (IITA) through the Ministry of Information and Communications (MIC), Republic of Korea. 11. 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 et al. Informational [Page 16] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 12. 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. 13. Informational References [1] [L1VPN-FW] Takeda, T., Editor "Framework for Layer 1 Virtual Private Networks", draft-takeda-l1vpn-framework, work in progress. [2] Choi, J.K., and Guha, D., "Path Computation Element Metric Protocol (PCEMP)", draft-choi-pce-metric-protocol-00.txt, October 2004 (work in progress) [3] Choi, J.K., et al., "Fast End-to-End Restoration Mechanism with SRLG using Centralized Control", draft-choi-pce-e2e-centralized- -restoration-srlg-00.txt, August 2004 (work in progress) [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic requirements and architecture elements, ITU-T Recommendation, September 2003. [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and network architectures, ITU-T draft Recommendation. [Y.l1vpnsdr] ITU-T SG 13 work in progress [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001. [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. Choi, Guha et al. Informational [Page 17] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 [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). [Ash] Farrel, A., Vasseur, JP., and Ash, J., "Path Computation Element (PCE) Architecture", draft-ash-pce-architecture-00.txt, September 2004 (work in progress) [GMPLS-UNI] Swallow, G., et al., "GMPLS UNI: RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay, work in progress. [GMPLS-ROUTING] Kompella, K., and Rekhter, Y. (editors), "Routing Extensions in Support of Generalized MPLS", draft-ietf-ccamp-gmpls-routing, work in progress. [L2VPN-FRAME] Andersson, L., and Rosen, E. (editors), "Framework for Layer 2 Virtual Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework, work in progress. [L3VPN-FRAME] Callon, R., and Suzuki, M. (editors), "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework, work in progress. [PPVPN-TERM] Andersson, L., and Madsen, T., "PPVPN terminology", draft-ietf-l3vpn-ppvpn-terminology, work in progress. [GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN Services: Generalized VPN Services using BGP and GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls, work in progress. [VR] Knight, P., Editor, "Network based IP VPN Architecture using Virtual Routers", draft-ietf-l3vpn-vpn-vr, work in progress. Choi, Guha et al. Informational [Page 18] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004 14. 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 Seng Kyoun Jo Information and Communications University (ICU) 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea Phone: +82-42-866-6282 E-mail: skjo@icu.ac.kr Young Hwa Kim Electronics and Telecommunications Research Institute (ETRI) 161 Gajeong-Dong, Yuseong-gu, Daejeon, 305-350, Republic of Korea Phone: +82-42-860-5819 E-mail: yhwkim@etri.re.kr Byung Ho Yae Electronics and Telecommunications Research Institute (ETRI) 161 Gajeong-Dong, Yuseong-gu, Daejeon, 305-350, Republic of Korea Phone: +82-42-860-5819 E-mail: bhyae@etri.re.kr 15. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 et al. Informational [Page 19] Internet Draft draft-choi-pce-l1vpn-framework-00.txt October 2004me