OFC/NFOEC Technical Digest © 2012 OSA
Experimenting Hierarchical PCE Architecture in a Distributed Multi-Platform Control Plane Testbed F. Paolucci1, O. González de Dios2, R. Casellas3, S. Duhovnikov4, P. Castoldi1, R, Muñoz3, R.Martínez3 1: Scuola Superiore Sant’Anna, CNIT, Pisa, Italy, e-mail:
[email protected] 2: Telefónica I+D , Madrid, Spain 3:CTTC, Barcelona, Spain 4: Nokia Siemens Networks GmbH & Co. KG, Munich, Germany
Abstract: A distributed control plane testbed, connecting four European institutions, is developed to enable interoperability testing among independent PCE platforms and evaluate inter-domain computation algorithms based on the Hierarchical PCE. Performance results are detailed and discussed. © 2012 Optical Society of America OCIS codes: (060.4250); (060.4251).
1. Introduction The Path Computation Element (PCE) architecture [1] is widely recognized to enable Traffic Engineering (TE) solutions even in network scenarios where available resources information exchange is limited (e.g., multi-layer, multi-domain, multi-carrier). In the typical multi-domain scenario, a single PCE is responsible for path computation inside each domain, while the inter-domain path computation is the result of a coordinated communication process among different PCEs, using the PCE Protocol (PCEP) and assuming that the domain sequence is known in advance, as, for instance, in the Backward Recursive PCE-based Computation (BRPC) procedure [2]. The recently proposed Hierarchical PCE (H-PCE) architecture [2], represents an attractive solution to enable both effective domain sequence computation and optimal end-to-end path computation. This architecture comprises two types of PCE. A single parent PCE (pPCE), placed at a higher hierarchical level, is responsible for the inter-domain path computation / domain sequence selection, while in each domain a local child PCE (cPCE) is dedicated to intradomain path computation. The pPCE resorts to inter-domain connectivity information, to determine such sequence. Moreover, in order to perform a more effective path computation, the pPCE is allowed to ask cPCEs for path computation of potential LSP intra-domain segments, thus selecting the most suitable end-to-end Explicit Routing Object (ERO) path. In this work, for the first time, the H-PCE architecture is experimentally validated exploiting a distributed multidomain and multi-technology control plane testbed, made available by the STRONGEST Project [3]. The aim of the testbed development is to evaluate inter-operability of developed extensions which are needed in the case of multiplatform and/or multi-vendor network equipments, mainly focused on the common control plane functions required to handle network islands. Path computation performance obtained with two alternative inter-domain sequence algorithms on distributed Wavelength Switched Optical Networks (WSON) islands represents the current state-ofthe-art of the research in the field of optical networks control plane and aims at establishing a reference benchmark for future extensions and enhancements of the H-PCE architecture. 2. STRONGEST Distributed Control Plane Testbed The STRONGEST Distributed Control Plane Testbed interconnects four European research institutions, located in Madrid (Telefónica I+D), Barcelona (CTTC), Pisa (CNIT) and Munich (NSN). The testbed physical topology is depicted in Fig. 1a. Partners premises are connected (at the control plane level) by means of dedicated IPsec tunnels. The resulting low level connectivity layout is a hub, centered at CTTC. Static routing entries provide full connectivity between partners’ private addresses, secured and isolated from the rest of Internet traffic. On top of this distributed control plane connectivity network, logical relationships between PCEs are established, in particular between Telefónica I+D PCE, acting as pPCE, and the other PCEs, acting as cPCE, as shown in Fig. 1b. The PCEs of the testbed have been independently developed by each partner. Telefónica I+D pPCE is a multi-threaded application developed in Java 1.6. It accepts sessions from cPCEs, maintaining each session with a specific thread which handles all the messages exchange. Also, a dedicated thread used for processing the PCEP Notification (PCNtf) message that contain the OSPF-TE information sent by cPCEs and builds the multi-domain TE Database (TED), in which the nodes are domains, and the edges are the interdomain links. A request dispatcher is in charge of receiving the PCEP Request (PCReq) messages from cPCEs and distributes the individual requests in the computing threads. A computing thread chooses the specific multi-domain algorithm using a set of configurable rules, based on the values of PCEP objects. The computing thread can calculate either the sequence of domains, or the sequence of inter-domain links, completing the path with the help of
OM3G.3.pdf 1
1/23/2012 11:47:49 AM
OFC/NFOEC Technical Digest © 2012 OSA
Control Plane Link
RTT
CNIT - TID
73 ms
CNIT - CTTC
55 ms
CNIT - NSN
104 ms
NSN - CTTC
44 ms
NSN – TID
61 ms
TID - CTTC
18 ms
CPU QuadCore @2.33GHz, 4GB RAM, C++
CPU QuadCore @2.33GHz, 2GB RAM, C++
Intel Xeon E5430 @2.66GHz 8GB RAM, Java
CPU Core2 Duo @2.66GHz, 2GB RAM, C++
Fig.1. STRONGEST Distributed Control Plane Testbed: physical (a) and logical control plane (b) topology.
the cPCEs. A cPCE request Manager is used to coordinate parallel requests to several cPCEs, and maintaining an association domain ID–PCE session. CTTC PCE [4][5] is a network appliance that implements a Path Computation Element, a multi-threaded, asynchronous process, developed in C++. Dedicated thread pools are responsible for updating the TED, and for the actual path computations. Extended functionality and algorithms are implemented as shared libraries / plug-ins, using an abstracted algorithm API. It supports most current IETF PCE WG standards and has successfully been deployed in single and multi-domain scenarios, in both WSON and MPLS-TP networks. CNIT PCE [6] is developed in C++ and handles requests through the Session Handler module. This module communicates through a persistently open socket with the Path Solver module. WSON-based path computation supports multi-rate (up to 200Gb/s) requests. Intra-domain paths may be computed through impairment-valid (IV) algorithms applying the wavelength continuity constraint (WCC). Optional wavelength suggestion is performed. TED creation and updating operations are handled resorting to either proprietary UNI or topology emulation. NSN research PCE solution represents a compound PCE/PCC node. Its core is implemented in C++ and operates multiple threads responsible for processing incoming and outgoing requests and replies, and path computation. It is capable of finding paths in WSON networks by utilizing impairment aware constraint based routing and wavelength assignment algorithms. It can operate both as cPCE and as pPCE. Each cPCE is responsible of a single WSON domain, internally represented as TED and updated through independent mechanisms (e.g., OSPF-TE, NMS). The utilized WSON multi-domain topology is shown in Fig 1b. 3. Inter-domain path computation procedure, TED update, reachability and PCE identification The pPCE is responsible for inter-domain path computation and maintains a graph in which nodes are domains and edges are inter-domain links. Over this graph, there are 2 main strategies: a) algorithm A1: compute the shortest path, obtaining one single sequence of inter-domain links [2, 5]. From that set, obtain the endpoints of the different intra-domain paths, and request in parallel to the PCE of each domain the specific intra-domain path details and b) algorithm A2: compute the set of shortest paths with the same cost, obtaining several sets of inter-domain links. From these sets, obtain the set of intra-domain paths needed, excluding duplicates and request the cPCEs for these paths. Use the metric of each returned path to choose the least cost sequence of inter-domain links from the initial sequence. If no metric is returned, the ERO is processed for a hop count. Each cPCE performs a different intra-domain path computation algorithm: CTTC default algorithm. when no standard objective function (OF) code is requested, is based on Dijkstra Shortest Path algorithm, OSNR-aware with WCC and regenerator allocation [7]. CNIT PCE utilizes the WCC least congested shortest path and first fit wavelength suggestion [8]. NSN routing algorithm uses a modified branch and bound algorithm, which supports WCC and optical performance metrics per modulation format as a link cost [9]. The inter-domain TED is maintained by the pPCE by receiving, from each cPCE, updates through PCNtf messages enclosing OSPF-TE Link State Advertisements, such as OSPFv2 Inter-domain TE LSA with GMPLS extensions and Virtual Network Topology (VNT) TLV information [4]. Since the pPCE is not aware of the details of the intradomain TEDs, it needs to maintain an association between endpoints and the domain they belong to. In order to automate the process of learning such information, the list of intra-domain network prefixes is enclosed within the Reachability TLV carried by a PCNtf message, sent by each cPCE after PCEP handshake [5]. As previously explained, the pPCE needs the cooperation of the cPCEs to compute the details of the intra-domain
OM3G.3.pdf 2
1/23/2012 11:47:49 AM
OFC/NFOEC Technical Digest © 2012 OSA
PARENT PCE
Inter-domain link sequence computation (ms)
Inter-D om ain Link sequence com putation (N _d=2, A1) Inter-D om ain Link sequence com putation (N _d=2, A2)
50
ERO selection/ aggregation time (ms)
45 40 35
b
30
Algorithm
Nd=2
Nd=3 Nd=2 Nd=3
A1
0.602
0.813
0.294
0.314
A2
0.869
0.892
0.310
0.328
Counts
a
25 20 15 10 5 0 0,0
0,5
1,0
1 ,5
com putation tim e (m s)
c CHILD PCEs
Fig. 2. Packet messages exchange between pPCE (running algorithm A1) and cPCEs.
Service Delivery time (latency) (ms) Intra-domain computation (ms)
A1
A2
Nd=2
Nd=3
Nd=2
Nd=3
153.8
159.1
162.3
163.7
CNIT
0.379
CTTC
0.215
98
-
99
-
NSN
2.779
136.8
143.3
134.3
141.3
Fig 3 . Computation performances: a) pPCE, b) pPCEdistribution , c) cPCEs (in italics underlined, low traffic period tests).
paths, so it needs to be able to map a domain to a given cPCE / PCEP session, which are initiated by the cPCEs in persistent mode. Upon connection, each cPCE indicates the domain it is responsible for. To that end, each cPCE is identified by a PCE-Id and univocally associated to a Domain-id, both parameters being conveyed as TLVs within the Open message during the PCEP session handshake [5]. 4. Experimental results The testbed PCEs performance is evaluated in terms of path computation time and end-to-end overall path computation latency, or service delivery time, as a function of the adopted pPCE algorithm and the number of crossed domains Nd. The path computation time is defined as the time elapsing between the received PCReq and the transmitted PCRep message, while the service delivery time is the time, seen by the originating cPCE, elapsing between the cPCE PCReq transmission and the PCRep reception enclosing the end-to-end path. The pPCE first performs the inter-domain link sequence computation (i.e., time elapsing between received PCReq and first intermediate PCReq transmission), then collects requested ERO segments and creates the end-to-end ERO (ERO selection/aggregation time). In particular, A1 performs simple aggregation and A2 performs selection between alternative ERO candidates. To obtain average values, several sets of 100 identical requests are generated by cPCEs. Fig. 2 shows a capture screenshot of the pPCE running A1, in particular the PCNtf enclosing the cPCE VNT (a), the (unique) PCRep of the intermediate cPCE containing the ERO segment (b) and the PCRep enclosing the end-to-end ERO (c), where Label Control carries wavelength suggestion. Performance results shown in Fig. 3: pPCE averages are below 1ms and depends on Nd (A1 with Nd=2 is 30% faster than with Nd=3) and the algorithm (A2 is up to 40% slower than A1). ERO selection introduced by A2 causes additional delay with respect to ERO aggregation. Obtained values at the pPCE are fast and extremely stable (see distributions of Fig. 3b). Single cPCEs computation takes up to 2.8ms, strongly depending on the adopted algorithm. The service delivery is mainly affected by the testbed latency introduced by the IPsec tunnels (see values in Fig. 1a) and by its variance (see comparisons with low traffic period tests in Fig.3c: in this case delivery is faster, due to reduced internet traffic) and PCEs computation impact is kept low (with A2 the delivery time is slightly slower due to increased number of intermediate PcReqs). 4. Conclusion In this work, inter-domain path computation performance is evaluated in a distributed multi-platform control plane testbed based on the H-PCE. Results show that path computation inter-operability is successfully achieved with few PCEP extensions and path computation time impact is kept low and negligible with respect to the testbed latency. Acknowledgements: The research leading to these results has received funding from the European Community's Seventh Framework Programme FP7/2007-2013 under grant agreement n° 247674 (STRONGEST project).
References [1] [2] [3] [4] [5] [6] [7] [8] [9]
OM3G.3.pdf 3
A. Farrel et al. “RFC 465: A Path Computation Element (PCE) based architecture”, August 2006. D. King and A. Farrel, draft-king-pce-hierarchy-fwk-06, IETF, PCE WG, April 2011. STRONGEST Project, www.ict-strongest.eu R. Casellas et al, “Dynamic Virtual Link Mesh Topology Aggregation in Multi-Domain Translucent WSON with H-PCE”, ECOC 2011. R. Casellas et al., “Lab Trial of Multi-Domain Path Computation in GMPLS Controlled WSON Using a Hierarchical PCE”, OFC 2011. F. Paolucci et al. “Experimental Demonstration of Impairment-aware PCE for Multi-Bit-Rate WSONs”, JOCN, vol.3, n. 8, 2011. R. Martínez, et al., IEEE/OSA JLT, vol. 28, no. 8, pp. 1241-1255, 2010. A.Giorgetti, et al., “Routing and Wavelength Assignment in PCE-based Wavelength Switched Optical Networks”, ECOC 2008. F. Rambach e al., "Branch-and-Bound Algorithms for Constrained Paths and Path pairs and their application to Transparent WDM Networks," ONDM 2006.
1/23/2012 11:47:49 AM
