PCE Evolutionary SDN

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

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.

© 2012 METASWITCH NETWORKS. ALL RIGHTS RESERVED. | Page 2

Contents

Executive Summary ........................................................................................................................ 3

1. Introduction .......................................................................................................................... 4

2. What is a PCE? ...................................................................................................................... 6

2.1 Where Does the PCE Server Sit in the Network? ................................................................ 6

2.2 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 Layered Networks ........................................................................................................ 10

2.5 Multiple PCE Servers .................................................................................................... 10

3. 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 Evolutionary Path to SDN .............................................................................................. 16

4.2 Inter-Domain Networking – PCE’s Killer App for Telco/WAN ............................................. 17

5. Conclusions ........................................................................................................................ 18

6. Further Information ............................................................................................................. 19

6.1 Reference Material ....................................................................................................... 19 6.1.1 PCE .......................................................................................................................... 19 6.1.2 OpenFlow ............................................................................................................. 20

6.2 Metaswitch PCE Solutions ............................................................................................ 20

6.3 About Network Technologies ........................................................................................ 21

6.4 Contact Us ................................................................................................................... 21


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.


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.


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.


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.


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


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.


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.


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.


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.


• 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 today’s applications and traffic flows.


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.


• 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.


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 / field-

trial / 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.


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.


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 – PCE’s 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.


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.


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 A Path Computation Element (PCE)-Based Architecture

RFC 4657 Path Computation Element (PCE) Communication Protocol Generic

Requirements

RFC 4674 Requirements for Path Computation Element (PCE) Discovery

RFC 4927 Path Computation Element Communication Protocol (PCECP) Specific

Requirements for Inter-Area MPLS and GMPLS Traffic Engineering

RFC 5088 OSPF Protocol Extensions for Path Computation Element (PCE)

Discovery

RFC 5089 IS-IS Protocol Extensions for Path Computation Element (PCE)

Discovery

RFC 5376 Inter-AS Requirements for the Path Computation Element

Communication Protocol (PCECP)

RFC 5394 Policy-Enabled Path Computation Framework

RFC 5440 Path Computation Element (PCE) Communication Protocol (PCEP)

RFC 5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to

Compute Shortest Constrained Inter-Domain Traffic Engineering

Label Switched Paths

RFC 5455 Diffserv-Aware Class-Type Object for the Path Computation Element

Communication Protocol

RFC 5520 Preserving Topology Confidentiality in Inter-Domain Path

Computation Using a Path-Key-Based Mechanism

RFC 5521 Extensions to the Path Computation Element Communication

Protocol (PCEP) for Route Exclusions

http://www.ietf.org/�


RFC 5541 Encoding of Objective Functions in the Path Computation Element

Communication Protocol (PCEP)

RFC 5557 Path Computation Element Communication Protocol (PCEP)

Requirements and Protocol Extensions in Support of Global

Concurrent Optimization

RFC 5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic

Engineering

RFC 5671 Applicability of the Path Computation Element (PCE) to Point-to-

Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)

RFC 5862 Path Computation Clients (PCC) - Path Computation Element (PCE)

Requirements for Point-to-Multipoint MPLS-TE

RFC 5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based

Architecture

RFC 6006 Extensions to the Path Computation Element Communication

Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label

Switched Paths

RFC 6007 Use of the Synchronization VECtor (SVEC) List for Synchronized

Dependent Path Computations

RFC 6163 Framework for GMPLS and Path Computation Element (PCE) Control

of Wavelength Switched Optical Networks (WSONs)

RFC 6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-

Layer 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

[email protected].

http://www.opennetworking.org/�

http://network-technologies.metaswitch.com/pce/pce.aspx�

mailto:[email protected]�


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 [email protected]

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

mailto:[email protected]�

Documents

PCE Evolutionary SDN