PCE - An Evolutionary Approach To SDN

An introduction to PCE-based control plane architecture, its operational advantages, including full traffic engineering of inter-domain paths, and how it delivers SDN.

Metaswitch Networks, 100 Church Street, Enfield, EN2 6BQ, UK http://network-technologies.metaswitch.com

Contents
Executive Summary........................................................................................................................ 3 1. 2. Introduction.......................................................................................................................... 4 What is a PCE? ......................................................................................................................6 2.1 2.2 Where Does the PCE Server Sit in the Network? ................................................................6 Communicating With the PCE Server ............................................................................... 7

2.3 Access to Topology Information ...................................................................................... 7 2.3.1 Calculating Routes Within a Single Domain ..............................................................8 2.3.2 Calculating Routes Across Multiple Domains ............................................................ 9 2.4 2.5 3. Layered Networks ........................................................................................................ 10 Multiple PCE Servers .................................................................................................... 10

The Key Reasons to Deploy PCEs ...........................................................................................11 3.1 Inter-Domain Routing ....................................................................................................11 3.1.1 Dynamic and Optimal End-to-End Path Computation....................................................11 3.1.2 Secure and Private Information Sharing ..................................................................11 3.2 Customizable Path Computation ................................................................................... 12 3.3 Improved Price / Performance Ratio .............................................................................. 13 3.3.1 Increased Performance with Lower CAPEX and OPEX ............................................... 13 3.3.2 Optimizing Existing Equipment .............................................................................. 14 3.4 Simplified Operations for Upgrading Path Computation ................................................. 15

4.

The Preferred Approach to SDN for Telco/WAN ...................................................................... 16 4.1 4.2 Evolutionary Path to SDN .............................................................................................. 16 Inter-Domain Networking PCEs Killer App for Telco/WAN............................................. 17

5. 6.

Conclusions........................................................................................................................ 18 Further Information ............................................................................................................. 19 6.1 Reference Material ....................................................................................................... 19 6.1.1 PCE.......................................................................................................................... 19 6.1.2 OpenFlow ............................................................................................................. 20 6.2 6.3 6.4 Metaswitch PCE Solutions ............................................................................................ 20 About Network Technologies ........................................................................................ 21 Contact Us ................................................................................................................... 21

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 2

Executive Summary
The Software Defined Networking (SDN) movement aims to make networks more customizable and efficient by separating and opening up the control plane of the network. This white paper describes how deploying Path Computation Elements (PCEs) can provide operators with the benefits of SDN, while at the same time leaving the existing network equipment to run the mature and sophisticated signaling and topology dissemination algorithms that have been the cornerstone of the Internet for well over a decade. The migration path to PCE-based SDN is evolutionary, with lower CAPEX and OPEX than alternative approaches. It allows a gradual migration without network disruption and maintains existing interoperability, crucial for the WAN/telco environment. This white paper focuses on the operational advantages and extra capabilities that PCEs bring to MPLS and GMPLS networking. These include enabling secure, dynamic, optimal, and private inter-area and inter-domain traffic engineered path setup.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 3

1. Introduction
A PCE (Path Computation Element) is an entity that computes paths complying with supplied constraints, on behalf of routers, an OSS or another PCE in a network. This architecture provides an evolutionary approach to SDN that is especially suitable for WANs and telco networks. SDN opens up the control of data flows through the network to customizable software that is independent of the hardware that forwards the flows. The SDN movement explains that development of networks, in particular, the Internet, has been slow because control of those networks is localized to closed hardware. Among other constraints, this tight coupling of network control and hardware limits access to the software and hinders operator-specific developments. With SDN, network control is more centralized and abstracted. The control plane function is made open to network operators, enabling them to define the network through software hence the term: Software Defined Networking. There are multiple ways that SDN can be achieved, and research groups and development teams in academia and industry are working on various strategies. Two approaches have reached the mainstream in OpenFlow and PCE. The former is considered a more revolutionary approach in that it removes and replaces the legacy control plane function that has been deployed for decades. PCE-based SDN is more evolutionary as it retains much of the widely deployed technology that has been invested in over the years and migrates only the key closed control function of the control plane to a centralized and open role. Path computation is the key control feature that needs to be centralized and opened up by SDN. For full control of the network, the network operator must control traffic engineering policy and that is executed by the path computation function. The PCE architecture delivers access to this crucial function in an open and centralized format whilst the existing configurable functions remain on the NEs. Adding PCEs to a network can be carried out via a gradual migration path in which existing NEs only require a software upgrade in order to communicate with the PCE. Accordingly, a network can comprise a mixture of legacy routers and PCE-upgraded routers, although the full benefits of the PCE architecture will not be achieved until all ingress nodes are upgraded. This gradual migration and evolutionary approach is especially advantageous for WANs and telco networks.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 4

This white paper describes PCE function and communication (section 2) and explains the key reasons for deploying PCEs (section 3). It then looks at why PCE-based SDN should be the approach of choice for WANs and telco networks (section 4). The paper ends with our conclusions on PCE-based SDN and then includes references and contact details for you to follow up, should you want to learn more. The focus of this white paper is on deploying PCEs in MPLS-based networks as this is the most obvious use case. However, the PCE-based model can be advantageously applied to other network types.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 5

2. What is a PCE?
A PCE is an entity that computes paths on behalf of the nodes in the network. It can be a router, a COTS server, part of the OSS, or a virtualized entity running in a cloud. When a network node needs a path for an LSP, it makes a request to the PCE using the PCE protocol (PCEP). The PCE has access to topology information for the entire network and uses this in path computations. The PCE architecture and PCE protocol are defined by the IETF in RFCs 4655 and RFC 5440, respectively. Other RFCs defining PCE function and communication are listed at the end of this white paper. This section explains where a PCE sits in the network, how nodes and PCEs communicate, and how a PCE has access to the full topology of the network in order to calculate secure, private, optimal, end-to-end paths. This section refers to a PCE Server, that is a standalone PCE device, but the PCE may equally be some other entity such as a virtualized entity running in a cloud or function integrated with the OSS.

2.1 Where Does the PCE Server Sit in the Network?

A PCE Server provides a centralized path computation function. It sits between the OSS/NMS and NEs, as shown in Figure 1.

Figure 1: Replacing distributed path computation function by a PCE Server.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 6

The current MPLS-TE distributed control plane comprises the four building blocks of local topology discovery, topology database distribution, path computation, and path setup, shown on the left of Figure 1. The PCE architecture leaves three of these functions on the NE, abstracting the path computation function in a separate entity. The centralization of path computation and provision of an open interface enables operators to customize, control and update policies from a single location and delivers many benefits which are addressed in section 3. The successful and mature part of the architecture remains in the NEs.

2.2 Communicating With the PCE Server

Each network node runs a Path Computation Client (PCC), which allows it to send path computation requests to a PCE Server. The PCCs and PCE Servers communicate using the PCE protocol, a standard protocol defined by the IETF in RFC 5440. The communication is therefore non-proprietary and the PCE Server can communicate with any type of NE that can use the PCE protocol. On request by a PCC, the PCE Server computes an optimal path and returns it in the form of an Explicit Route Object, suitable for the client to insert directly into their RSVP signaling messages. The PCE model is thus optimized for use with MPLS-TE (although there is no reason that it could not be used by other traffic engineering clients, such as network management applications.) As shown in Figure 2, the network operator communicates with the PCE Server to modify path computation function, rather than with individual NEs. The interface between the OSS/NMS and the PCE Server is an open interface. This interface is currently not defined by standards but could be, if the industry requires it. PCE manufacturers will provide the interfaces that operators require.

2.3 Access to Topology Information

A PCE Server has access to sufficient topology information to calculate complete end-to-end paths that fulfill traffic engineering requirements. The Server gains access to topology information in two different ways. A PCE Server has a topology database comprising topology information for an entire domain. (NEs typically hold information for only an area within a domain.) PCE Servers in different domains work together to compute inter-domain paths.

This provides improved function to the MPLS-TE architecture, where currently nodes within the network have access to topology information for only their own area. If a path crosses an area, or domain, boundary then the node specifies the path as far as that boundary; the border node must

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 7

compute the rest of the path. The source node must choose a border node based on an incomplete vision of the network topology.

2.3.1

Calculating Routes Within a Single Domain

A PCE Server gains knowledge of the topology of its own network domain by participating in the OSPF or IS-IS routing protocols in all routing areas within the domain. If the domain is split into several areas, as shown in Figure 2, a single PCE Server will build up a topology database for the entire domain. (The topology information could also be obtained in some other way, for example, it could be provided by the management system.) The PCE Server has the computing power and scalability to store and manipulate this large volume of information. The PCE has all the information it needs to compute a path between any two nodes in its domain, whether or not they are in the same area. This avoids the problems inherent in inter-area path computations by fully distributed control planes.

Figure 2: A PCE Server has knowledge of the entire topology of its network domain.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 8

2.3.2

Calculating Routes Across Multiple Domains

A PCE Server gains access to information about another domain by PCE protocol communications with the PCE designated for that domain. As illustrated in Figure 3, an interrogated PCE Server provides path information and the relative costs of the possible paths. Although each PCE Server sees only part of the total topology, they use an algorithm called Backwards Recursive Path Computation (BRPC), defined in RFC 5441, to ensure that the calculated path is fully optimized end-to-end. In the diagram, node C, in domain A, sends a path request to PCE Server A for a path to a node Q, in domain B. PCE Server A sends a request for information to PCE Server B in domain B. PCE Server B sends back path options with relative costs. PCE Server A then computes a full path through domains A and B, taking into account the cost of paths in domain A which it knows from its own topology database, and the additional cost of the path from X to Q and from Y to Q. PCE Server A provides node C with the optimal path.

Figure 3: PCE Servers communicate information to allow path computation across multiple network domains.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 9

Mechanisms are provided in the PCE model to deal with security and privacy of network details when paths cross multiple domains. PCE Servers can communicate over secure channels, and when a PCE Server receives a path request from a PCE Server in a separate administrative domain it can provide path details without providing details of the topology of its domain. A PCE server can answer a request using Path Key Encryption, see RFC 5520. For each path option the Server provides a border router address and an encryption key that represents the remainder of the path to the destination node. At path setup, when the signaling message enters the domain at the border router, the router queries its PCE Server to decode the key into an unencrypted path.

2.4 Layered Networks

If a network has multiple layers, for example, if Ethernet is being run over G.709 OTN on an optical network, then a PCE Server can include in its database topology information for all layers and can use this to compute optimal paths for each layer. In a complex network such as this, the PCE Server can be tightly integrated with the OSS to allow the PCE Server to automatically provision changes in the lower layers to provide the links necessary to create optimal paths in the upper layers.

2.5 Multiple PCE Servers

The examples and diagrams in this white paper show a single PCE Server per domain. However, each network domain may contain multiple PCE Servers. This serves two key purposes. It provides redundancy to the PCCs in the event of a server failure. It enables load sharing across the PCE Servers.

PCE auto-configures itself; the server disseminates its address in the network using OSPF or IS-IS, and the PCCs connect to it automatically. Multiple servers can be present in a single network for redundancy in which case each PCE Server is allocated a priority. The PCCs can be configured to use the highest priority PCE Server that is available. Alternatively, PCCs may be configured with specific server addresses as well as, or instead of, this mechanism.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 10

3. The Key Reasons to Deploy PCEs

This section summarizes the key operating gains that are achieved by deploying PCEs. Inter-domain routing Customizable path computation Improved price / performance ratio Simplified operations for path computation

3.1 Inter-Domain Routing

PCE is the only technology that allows secure, dynamic, optimal, and private inter-area and inter-domain TE path setup. Inter-domain routing is a killer app for PCEs and may alone be sufficient justification for deploying the PCE model in WANs/telco networks.

3.1.1

Dynamic and Optimal End-to-End Path Computation

For true traffic engineered inter-domain data flow, it must be possible for the control plane to calculate an optimal end-to-end path. That is not possible with the current distributed control plane architecture as no node has access to the full network topology. If a node needs an inter-area or inter-domain path, the node computes the path as far as a border router on the boundary and the border router computes the rest of the path. The source node must select a border node based on the TE cost of paths within its area but the border router it chooses may not be able to deliver the optimal end-to-end path. It may be that a better overall path is available by taking a higher cost route to the boundary. A network node does not have the information to make this calculation so may choose a less than optimal path. PCE Servers do have access, via interrogation of other PCE Servers, to the path and traffic engineering information for the entire network so compute optimal end-to-end paths.

3.1.2

Secure and Private Information Sharing

Historically, there have been issues of security, privacy and trust when creating paths across administratively separate domains. Using PCE Servers to share the necessary topology information allows operators to choose secure communication methods and to keep private the detailed topology of their networks.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 11

The PCE protocol communications between PCE Servers may use a secured channel. It is not acceptable for all NEs in one domain to interrogate the topology of the other domain because the source domain does not want to expose these NEs to the destination domain the destination domain does not want to manage that number of secure connections. Communication between a pair of well-known public servers, the PCE Servers, is the only way to achieve secure communication.

The PCE Servers can provide path details in the form of an encrypted key, thereby keeping internal domain topology private. When a source domain PCE Server interrogates a destination domain PCE Server, the PCE protocol allows the interrogated PCE Server to respond with route options comprising traffic engineering costs and path details in the form of encryption keys instead of detailed node addresses/identifiers. The source PCE Server includes one of the keys in the optimal path supplied to the client and that key is only expanded when the signaling messages enter the destination domain. Thus, operators avoid exposing internal details of their domain topology to other operators.

3.2 Customizable Path Computation

The PCE model enables network operators to customize the very path computation algorithms that are currently baked into router operating systems. The traditional path computation architecture gives operators little, or no, scope to radically change or to routinely increment, path computation. PCE Server products provide open software APIs, to allow operators to customize or replace routing algorithms. Providers of PCE Server products provide policy and provisioning interfaces to the OSS. Those interfaces allow the OSS to influence network behavior via the PCE Server, in place of direct communications with every NE in the network. This is a much more reliable way to manage a network, and is cheaper for OSS vendors to develop and for OSS users to run. The increased flexibility and openness for customization enables operators to address the rapid change of pace set by todays applications and traffic flows.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 12

3.3 Improved Price / Performance Ratio

Price and performance ratio is a key consideration in any network, especially when path setup performance is a bottleneck. For example, in large-scale WDM / DWDM networks path computation requires a lot of computing power which is expensive and difficult to upgrade on NEs that utilize proprietary hardware. Deploying PCEs is a much lower cost alternative way, in terms of both CAPEX and OPEX, to upgrade network performance and it delivers improved performance from existing, expensive equipment.

3.3.1

Increased Performance with Lower CAPEX and OPEX

Deploying PCE requires the purchase of a small number of inexpensive PCE Servers and a one-time software upgrade of existing equipment to support PCE (if it is not already supported). PCE Servers are not required to run on the data plane, therefore do not require expensive, proprietary hardware. Increasing path setup performance by adding and upgrading PCE Servers is much lower cost than adding or replacing data-plane network equipment. Hosting a PCE on a cluster of virtual servers in a cloud could provide even more flexibility, allowing for elastic use of resources (adding new virtual servers to the cloud at busy times) which reduces OPEX at less busy times. CAPEX A COTS server with a very powerful CPU is available for a few thousand dollars and the NE upgrade required to support PCE is a software upgrade. (There is no need to replace NEs.) The cost of a COTS server with a top-line CPU is much less than the cost of a router and it is easy and cheap to keep upgrading the CPU in a COTS server. Software-upgrading existing NEs to support PCE increases the life span of the NE by offloading CPU to another device. Rather than continually needing to buy new NEs with more and more powerful CPUs in order to do increasingly complex path computation more quickly, the network operator need only upgrade CPU in the PCE Server(s). Further, new NEs do not need the top of the range, fastest CPUs, so deploying PCE also pushes down the cost of any new NEs added to the network.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 13

OPEX The cost of ongoing upgrade of path computation software is reduced; only a small number of PCEs are upgraded rather than all the NEs in the network. Network administration costs are reduced: networks are obviously easier to plan and manage when controlling path computation from a single point, the PCE Server or PCE Server cloud, rather than interacting with thousands of different NEs. Running a hosted virtualized cluster of PCE Servers could make further OPEX savings because computing resources are paid for when needed. Flexible cloud computing resources are available from many big, reliable providers.

3.3.2

Optimizing Existing Equipment

Deploying PCEs optimizes the use of existing equipment in two ways. The PCE architecture is an evolution of the current architecture and the migration to PCE-based SDN requires a software upgrade of existing equipment, not total replacement of that equipment. The PCE architecture retains the tried and tested signaling and topology database distribution function provided by existing equipment and adds on improved and more accessible path computation function. Local topology discovery, topology database distribution and path setup are provided by LMP, IGPs, in particular OSPF and IS-IS, and RSVP-TE respectively. The underlying protocols were developed by standards bodies with extensive input from industry. Implementations of the protocols have been developed, extensively tested and used in real live networks for well over a decade. They are mature technologies and are fundamentally well-placed and well-suited to their tasks. This strong existing function that is already in place is enhanced by the addition of path computation by the PCE. Traditional path computation architectures do not guarantee the best use of network resources when paths need to cross multiple areas and/or domains. Routers base their path computations on partial information. A PCE Server has a complete topology database for the entire domain and interrogates other PCE Servers for topology information for other domains. A PCE Server can therefore compute the best end-to-end paths, thereby ensuring optimal use of all network resources.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 14

3.4 Simplified Operations for Upgrading Path Computation

Modifying or upgrading path computation policy no longer requires a change to all NEs in the network with the cost, time lag and instability that is involved in such a process. Instead, a modification to a single PCE Server or small number of PCE Servers is all that is required. For example, to upgrade the routing algorithm, the following steps could be taken: (i) introduce a new PCE Server with the new algorithm, (ii) configure a few PCCs to talk to it and do some tests, (iii) once it is stable, cut over all the PCCs in the network to talk to the new PCE Server. This simple process replaces the upgrade of possibly thousands of NEs. The specification / development / test / fieldtrial / deploy cycle for deploying new features in the network is much cheaper. This operational ease of upgrade supports the ability of the operator to customize the path computation function.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 15

4. The Preferred Approach to SDN for Telco/WAN

SDN defines broad goals, not a set of implementation details. Therefore multiple approaches have formed all of which serve the common SDN agenda but do so in distinct fashions. Two approaches have risen to prominence, with differences in pedigree and implementation making each applicable to different markets. OpenFlow Born in university research labs, OpenFlow standards are defined in the recently formed Open Networking Foundation. OpenFlow removes the entire control plane from the network equipment, relegating it to a data-plane only role. New mechanisms of network control (discovery, path computation, path setup etc...) will be created and hosted on a server/cloud. Although applicable to telco/WAN, early work has focused on data center and campus applications. PCE Standardized in the IETF, PCE takes an evolutionary approach and migrates only the path computation component of traditional networking devices to a centralized role. Much of the well established and proven software functions of the control plane are left untouched and remain integrated within the NEs, enabling a gradual migration to SDN. PCE has the added benefit of providing inter-domain networking which is a key application for carrier networks. These attributes make PCE the preferred approach to SDN for telco/WAN environments.

4.1 Evolutionary Path to SDN

MPLS-based networks are common throughout the Internet and telco/WAN networks. The MPLS-TE control plane and its four building blocks (discussed in section 2.1) are well established and entrenched in these environments. The telco/WAN MPLS networks of today drive billions of dollars in service revenue and are commonly depreciated (expensed) over multiple decades. The bottom line is that any approach that requires a wholesale change (i.e. forklift upgrade) will not be well received and will face strong internal opposition. PCE leverages the installed base of MPLS equipment and technology by migrating only the path computation component to a centralized role (see section 2.1). In this way, the remaining components (discovery, database distribution and path setup) remain in place on the NEs, preserving the massive investment made by the carriers.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 16

Moreover, PCE provides a smooth migration plan for SDN. Maintaining tried and tested function on NEs minimizes network disruption during migration, and gradual or partial migration is possible because the PCE model does not require all the nodes in the network to adopt PCE functionality. Only the ingress node of a PCE flow needs to be upgraded. Nodes that are not yet upgraded may be used in paths and may also continue to function as ingress nodes using their existing path computation function. This allows carriers to be selective (and cost effective) in partially upgrading their network to enable SDN.

4.2 Inter-Domain Networking PCEs Killer App for Telco/WAN

PCE is the only technology allowing secure, dynamic, optimal, and private inter-area and inter-domain TE path setup. Inter-domain routing is a killer application for PCEs and may alone be sufficient justification for deploying the PCE model in telco/WAN networks. Other approaches to SDN do not yet address this important requirement.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 17

5. Conclusions
Network operators looking to realize a move to SDN need look no further than PCE. SDN's broad goal is to provide centralized control over paths taken by flows. PCEs provide centralized control of the paths that are set up for flows in MPLS networks. Deploying a PCE, with an appropriate policy interface to the OSS, is the quickest and easiest way to achieve SDN in a traditional telco / transport network. By deploying PCEs, operators of MPLS-based networks can gain the substantial benefits of inter-domain routing, customizable path computation, improved price/ performance ratio and simplified operations for path computation, with minimal disruption to existing networks. The PCE model maintains the majority of existing mature, field-hardened, trusted control-plane function while moving CPU-hungry path computation to a centralized provider, the PCE. PCE technology can be deployed with lower CAPEX and OPEX than alternative approaches. PCE is a defined in long-established IETF standards that are respected, mature and stable. It is the natural, cost-effective migration path to SDN for WANs/telco networks.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 18

6. Further Information
6.1 Reference Material
6.1.1 PCE

The following RFCs are issued by the IETF and are available from www.ietf.org.

RFC 4655 RFC 4657 RFC 4674 RFC 4927 RFC 5088 RFC 5089 RFC 5376 RFC 5394 RFC 5440 RFC 5441

A Path Computation Element (PCE)-Based Architecture Path Computation Element (PCE) Communication Protocol Generic Requirements Requirements for Path Computation Element (PCE) Discovery Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering OSPF Protocol Extensions for Path Computation Element (PCE) Discovery IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) Policy-Enabled Path Computation Framework Path Computation Element (PCE) Communication Protocol (PCEP) A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths

RFC 5455 RFC 5520 RFC 5521

Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 19

RFC 5541 RFC 5557

Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization

RFC 5623 RFC 5671 RFC 5862 RFC 5886 RFC 6006

Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Applicability of the Path Computation Element (PCE) to Point-toMultipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths

RFC 6007 RFC 6163 RFC 6457

Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) PCC-PCE Communication and PCE Discovery Requirements for InterLayer Traffic Engineering

6.1.2

OpenFlow
Open Networking Foundation www.opennetworking.org

6.2 Metaswitch PCE Solutions

Along with a full suite of integrated control plane solutions, Network Technologies of Metaswitch provides portable, software-based implementations of PCE Servers and Clients. For more information see http://network-technologies.metaswitch.com/pce/pce.aspx or contact us at dcpce@metaswitch.com.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 20

6.3 About Network Technologies

Metaswitch Network Technologies provides networking software stacks and solutions to OEMs and system vendors worldwide. Formerly known as Data Connection, Network Technologies is the genesis of Metaswitch Networks from which our core values of reliability, quality, exceptional support and innovation were born. We take a long-term approach at Network Technologies which is exemplified by our 25-plus years of service to the industry. Network Technologies builds strategic, lasting customer relationships, designs future-proof product architectures, and believes that a sustainable, successful business is in the best interests of our people and our customers

6.4 Contact Us
METASWITCH NETWORKS 100 Church Street, Enfield EN2 6BQ, UK Phone +1 888 755 1793 or +44 (0)20 8366 1177 Email dcpce@metaswitch.com

Copyright 2012 Metaswitch Networks. Metaswitch is a registered trademark. Brands and products referenced herein are the trademarks or registered trademarks of their respective holders.

2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 21