Network Working Group Jun Kyun Choi (ICU) Internet Draft Dipnarayan Guha (ICU) Category: Informational Seng Kyoun Jo (ICU) Expires: December 2005 July 2005 Framework of PCEMP based Layer 1 Virtual Private Network draft-choi-pce-l1vpn-framework-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 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 shows how PCEMP messages might help preserving the path computational entities in the L1 VPN peer nodes. 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-02.txt July 2005 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 ............................................. 9 5.2 Network structure considerations ........................ 10 5.3 Control structure considerations ........................ 10 5.4 Segment wise partitioning using the PCE nodes ........... 11 5.5 Complete Network Topology for L1 VPN networks: A PCE perspective ................................................. 11 5.6 Protocol implementation considerations using PCEMP ...... 13 5.6.1 PE-P L1 connection ................................ 13 5.6.2 PE-P-PE L1 connection (teardown invoked from any PE) ............................................... 14 5.6.3 PE-P-PE L1 connection (teardown invoked from any P) ................................................ 15 5.6.4 Inter-domain point-to-multipoint considerations ... 15 6 Overview of PCE node requirements for dynamic L1 VPN provisioning ................................................ 16 6.1 Protocol level hierarchy architecture on the L1 control plane ............................................... 16 6.2 PCEMP peer architecture as seen by the PCEMP protocol ... 18 7 Conclusion .................................................. 18 8 Security Considerations ..................................... 18 9 IANA Considerations ......................................... 19 10 Acknowledgements ............................................ 19 11 Intellectual Property Considerations ........................ 19 12 Normative References ........................................ 20 13 Informational References .................................... 20 14 Authors' Addresses .......................................... 22 15 Full Copyright Statement .................................... 22 Choi, Guha et al. Informational [Page 2] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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-02.txt July 2005 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-02.txt July 2005 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-02.txt July 2005 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]. 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 Choi, Guha et al. Informational [Page 6] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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. 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. Choi, Guha et al. Informational [Page 7] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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. 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. Choi, Guha et al. Informational [Page 8] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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. 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. Choi, Guha et al. Informational [Page 9] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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. 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. Choi, Guha et al. Informational [Page 10] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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. 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. Choi, Guha et al. Informational [Page 11] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 +--------------------------------+ | | | | : +------+ | +------------+ | : | 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 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. Choi, Guha et al. Informational [Page 12] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 5.6 Protocol implementation considerations using PCEMP 5.6.1 PE-P L1 connection |----------- (1) ------------>| | | |<-----------(2) -------------| | | |------------(3) ------------>| | | |<-----------(4) -------------| | | |------------(5) ------------>| | | |<-----------(6) -------------| PE P Figure 6: PCEMP message exchanges between L1 VPN peers (PE/P) For a single PE-P per VPN connection, we can use PCEMP messaging for implementing the L1 VPN framework using PCE techniques. Here is a sample sequence of messaging that helps in the L1 VPN PE/P nodes maintain soft PCEMP status. Details about the protocol messages can be found in [2]. (1): Send a PCEMP Common Header with the COMPUTE_PATH enabled in the PCEMode field and the ACK REQUESTED enabled in the PCEFlag field. The PCEMP message MAY include a PCE SUBOBJECT to inform the responder (P) about the initiator's (PE) PCEMP-LOCAL-INITIATOR-ADDRESS. In this way the PE is initialized with the soft-memory based computation for PCEMP FSMs. (2): P receives this message and is configured with the soft-memory based path computation states. (If P does not support this, it may be needed to be configured administratively). It sends back an ACK message to the PE with the responder's (P) PCEMP-LOCAL-RESPONDER-ADDRESS (3): PE sends a PCEMP Common Header with the ESTABLISH_PATH enabled in the PCEMode field and the Peer-to-peer mode set in the PCEStatus field of the Common Header. It also sends a PCEMP ESTABLISH message with the following parameters: 1. Flag field set to VARIABLE. The MAX_PCE_TIME_FIT is to be negotiated as discussed in [2]. In case this is not able to be negotiated, then the PCEMP ERROR message SHOULD be generated with the ERROR CODE field set to OUT OF TIME, and the PE node MUST issue a fresh PCEMP ESTABLISH message with the Flag field set to STATIC. Choi, Guha et al. Informational [Page 13] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 2. The BANDWIDTH OBJECT is mandatory for the PCEMP Common Header with the Peer-to-peer mode set in the PCEStatus field. If this object is absent, a PCEMP ERROR message MUST be generated with the ERROR CODE field set to PROTOCOL ERROR along with its' supported bandwidth in the PCEMP NEGOTIATE OBJECT, following which the initiator requests a fresh PCEMP ESTABLISH message with the BANDWIDTH OBJECT equal to the PCEMP NEGOTIATE OBJECT. (4): P sends a PCEMP RESPOND message with the corresponding PCE Descriptor ID. This is matched and stored statically for the lifetime of the path computation between P-PE so that this ID remains static between them till the path computation is over. If the PCE Descriptor ID changes value, a PCEMP ERROR message MUST be generated with the ERROR CODE field set to PROTOCOL ERROR with its own saved PCE Descriptor ID of the wronged hop in the PCEMP NEGOTIATE OBJECT. It MUST also set the Protection mode in the PCEStatus field of the corresponding outgoing PCEMP Common Header. (5): PE issues a PCEMP TEARDOWN message with the RequestType field set to CHANGE IN COMPUTATION STYLE for PE to remain PCEMP enabled and the path computation state active. The L1 VPN peers thus maintain their path computation enable for the architecture framework as discussed earlier in this draft. (6): P sends a PCEMP Common Header with the COMPUTE_PATH enabled in the PCEMode field. The PCEMP message MAY include a PCE SUBOBJECT to inform the responder (PE) about the initiator's (P) PCEMP-LOCAL-INITIATOR-ADDRESS. 5.6.2 PE-P-PE L1 connection (teardown invoked from any PE) |----------- (1) ------------>| | | |-----------(1A) ----------->| |<-----------(2) -------------| | | |<----------(2A) ------------| |------------(3) ------------>| | | |-----------(3A) ----------->| |<-----------(4) -------------| | | |<----------(4A) ------------| |------------(5) ------------>| | | | | |<-----------(6) -------------| | PE1 P PE2 Figure 7: PCEMP message exchanges between L1 VPN peers (PE-P-PE) Teardown invoke from any PE Choi, Guha et al. Informational [Page 14] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 This follows from Section 5.6.1, with (1A), (2A), (3A), (4A) being identical to (1), (2), (3) and (4). (5) and (6) are also identical as in the previous section. The only point of study is the path computation state of PE2. The Teardown message may be propagated to PE2, like the Establish and the Respond messages, in which case it is trivial to the PE-P case. In Figure 7, PE2 still remains in the active state, i.e. it is capable of generating PCEMP messages on its own. The Path Computation state of PE2 is local to it, and is completely independent of what happens at PE1. This is a very big advantage in realizing PCE based L1 per VPNs. PE2 can alternately serve the next PCEDA using the path computation state information of PE1 learnt through processes (1), (2), (3) and (4). This means that there is always a guaranteed virtual topology link from PE1 to the other PEs, which means that L1 VPN provisioning is also guaranteed. 5.6.3. PE-P-PE L1 connection (teardown invoked from any P) |----------- (1) ------------>| | | |-----------(1A) ----------->| |<-----------(2) -------------| | | |<----------(2A) ------------| |------------(3) ------------>| | | |-----------(3A) ----------->| |<-----------(4) -------------| | | |<----------(4A) ------------| |<------------(5) ------------| | | |-----------(5) ------------>| |-----------(6) ------------->| | | |<----------(6)--------------| PE1 P PE2 Figure 8: PCEMP message exchanges between L1 VPN peers (PE-P-PE) Teardown invoke from P In this case, path computation states are preserved among all the participating entities. P here would ideally act as the PCE node initiator for multiple PCEDAs (multi-layer networks in particular) and multiple TE-LSPs shared by different paths between different L1 VPN peers. The advantage of this is superior path protection and bandwidth utilization. 5.6.4 Inter-domain point-to-multipoint considerations The protocol implementations are followed as in the previous section, except for a few modifications. Before Step (3) as in 5.6.1, the PE node needs to send a PCEMP Common Header with the COMPUTE_LSP_TYPE set in the PCEMode and the Peer-to-peer mode set in the PCEStatus. This precedes Step (3) in 5.6.1. The participating PCE peers thus get information that the path computation session is a point-to-multipoint one. The paths may even be aggregated for multipoint-to-multipoint TE LSP path computation in inter-domains. In this mode of operation, Step (6) in 5.6.1 is replaced with the P (or Pn, in the more general case) sending a PCEMP Common Header with the COMPUTE_LSP_TYPE enabled in the PCEMode field. Details of inter-domain operations TBD. Choi, Guha et al. Informational [Page 15] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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 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 Choi, Guha et al. Informational [Page 16] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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. All this is used for dynamic L1 VPN provisioning. Choi, Guha et al. Informational [Page 17] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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 Choi, Guha et al. Informational [Page 18] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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. 9. IANA Considerations This document makes no requests for IANA action. 10. Acknowledgements This work was supported by 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 19] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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-04.txt, June 2005. [2] Choi, J.K., and Guha, D., "Path Computation Element Metric Protocol (PCEMP)", draft-choi-pce-metric-protocol-02.txt, July 2005 (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-03.txt, July 2005 (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. Choi, Guha et al. Informational [Page 20] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 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). 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 [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. Choi, Guha et al. Informational [Page 21] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 [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. 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 15. 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. Choi, Guha et al. Informational [Page 22] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005 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 et al. Informational [Page 23] Internet Draft draft-choi-pce-l1vpn-framework-02.txt July 2005