An Emulation Study on PCE with Survivability: Protocol Extensions and Implementation

Transcription

1 1 An Emulation Study on PCE with Survivability: Protocol Extensions and Implementation Xiaomin Chen, Yuesheng Zhong, Admela Jukan Technische Universität Carolo-Wilhelmina zu Braunschweig Abstract This report describes the first implementation of PCE to support survivable path computation which scales and performs well in networks with different size and different load. As of today, most research work related to PCE is based on simulations. Few has been done yet in terms of protocol extension and implementation based on emulation study, especially implementation of PCE supporting survivable path computation has not been reported yet. We proposed and implemented PCEP protocol extensions for survivable path computation based on an open-source PCE emulator. We emulated the extended survivable PCE with focus on measuring three time parameters, referred to as signaling delay, queuing delay and computation delay. The results show that the presented implementation of PCE with survivability extensions scales well in different networks regardless of network load and network size. I. INTRODUCTION With increasing demand for connections with Quality of Service (QoS) guarantees, Path Computation Element (PCE) has attracted attention from both academic and industrial communities. PCE was proposed as a third- party network control and management entity that computes an optimal path based on its Traffic Engineering Database (TED). The PCE architecture as well as the PCE communication protocol (PCEP) [1] have been standardized by the IETF. Extensions have also been proposed to enrich PCE architectures for various scenarios. Among many third-party control and management subsystems that have been proposed, PCE with its latest extensions has become the de-facto standard of QoS constrained path computation in circuit-switching networks. In addition, the capability of constrained path computation independent of network technologies has make PCE especially attractive to the network carriers where typically different network technologies are deployed. As of today, PCE has been extensively studied in various network scenarios, such as multi-layer, multi-domain path computation, where simulation has been commonly used. However, PCE prototyping with focus on protocols extensions and implementation has rarely been studied. Few has been reported in terms of emulation study related to PCE architectures. In particular, extending a standard PCE to support survivable path computation has not been studied yet. To this end, commercial PCE implementations are commonly vendor-specific,posing a barrier for emulation studies. To counter this issue, an open source, vendor-independent PCE emulator has been developed, which includes all basic features of a PCE [2]. It works in a server-client fashion, where a path computation client s a request to a path computation server. Based on the information stored in its TED, PCE server returns the path information in an Explicit Route Object (ERO) to the client. However, the PCE emulator does not support survivable path computation yet. Extending the PCE emulator with survivability is not without challenges. To this end, PCEP messages only allow for requesting a single path and returning a single Explicit Route Object (ERO). Extensions are required for simultaneous computation of two link-disjoint paths in support of protection. Moreover, the accompanying signaling flow also requires modification. In this report, we present the first implementation of PCE with extensions to support survivable path computation and evaluate its performance with emulation study. The extensions are implemented based on the open-source PCE emulator presented in [2]. We study the performance of the extended PCE in real-size networks and show that the extended PCE scales well in different network with different size and traffic load. We show that survivable path computation extensions in the PCEP protocol allow for requesting a connection with two link disjoint paths and returning of two Explicit Route Objects (EROs) simultaneously. This study is the first attempt to implement extended standardized PCE to support survivable path computation with focus on emulation. The results reported here show that PCE with survivability is feasible and deployable in transport networks.

2 2 PCE 2 Check TED and computes a solution. 3 Response: a connection 1 between R1 and R7 with A path computation request from R1 1+1 protection, i.e., two to R7, with 1+1 protection link-disjoint paths from R1 to R7 R1 R4 R5 Network Switch Primary ypath Protection path R7 Primary path R2 Backup path R3 R6 Fig. 1: A reference scenario of PCE with survivability extensions in a transport network The rest of the report is organized as follows: Section II presents the PCE background and the related work. The deployment example and protocol extensions are presented in Section III. Section V presents the implementation and emulation study and Section VI concludes the paper. II. BACKGROUND AND RELATED WORK The Path Computation Element (PCE) works in a server-client mode, where the PCE server performs constrained path computation based on the topology information stored in its Traffic Engineering Database (TED). The topology information stored in the TED includes link capacity, available bandwidth, link delay etc., which is typically updated via the network control plane, e.g., Generalized Multi-Protocol Label Switching (GMPLS). Path computation in a network with PCE is initiated by a Path Computation Client (PCC) by ing a request using Path Computation Element Communication Protocol (PCEP) [1]. A PCE can also act as a client which a path computation request to another PCE in order to extend the reach of the optimal path computation to the multi-layer [3] and multi-domain [4] scenarios. Seven message types have been defined in PCEP, including Open, Close, Path Computation Request message (PCReq), Path Computation Response message (PCRep), Keepalive, Notification and Error. Open and Close messages are used to initialize and close the connection between clients and PCE server; PCReq message is defined to carry a path computation request from PCC to PCE, while the information of a computed path is sent back from PCE to PCC in PCERep message. Finally, Keepalive message, Notification message and Error message are defined for conveying additional information. To date, PCE has been extensively studied in terms of path computation algorithms. Few has been reported in terms of protocol extensions and implementation. Efforts have also been paid to extend the PCE architecture and related specifications to address issues such as policy integration [5], monitoring [6] and point-to-multipoint path computation [7] as well as extensions to support Wavelength Switched Optical Networks (WSON) [8]. Applicability of stateful PCE to facilitate network protection and failure recovery has been proposed in an IETF draft specified in [9]. However, protocol extensions and implementation of PCE with survivability has not been studied yet. Especially emulation study on PCE with survivability has not been reported in the literature. our work is the first attempt to extend PCE with survivability and evaluate the implementation with emulation study. A. Reference scenario III. PROTOCOL EXTENSIONS A reference scenario of PCE with survivability extensions is shown in Figure 1, where a path computation request is sent from R1 to PCE requiring a connection to R7 with protection in a transport network. In this example, network switch R1 is the Path Computation Client (PCC), which initiates a path computation request by ing a PCReq to the PCE. QoS constraints such as bandwidth requirement and path delay are included in the PCReq

3 3 Fig. 2: PCEP request message with survivability extension Fig. 3: PCEP reply message with survivability extension message. Upon receiving the path computation request, PCE checks the traffic information stored in TED and starts computation of two link-disjoint paths. The solution is sent back to R1 within the PCRep message and R1 initiates signaling for the path setup. In case that the PCE fails to compute two link-disjoint paths with required QoS requirements, the PCE s back a nopath in the PCRep message. B. PCEP Protocol Extension The communication protocol of PCE, i.e., PCEP protocol, needs to be extended in order to support survivable path computation. Two messages need to be modified, namely, Path Computation Request message (PCReq) and Path Computation Response message (PCRep), as shown in Figure 2 and Figure 3. In the PCReq message, a new metric is added to the <Metric-list> to indicate the survivability requirements. The PCReq message shown in Figure 2 is defined for a connection requiring dedicated path protection, i.e., protection. It should be noted that the survivability metric can also be restoration, which is not shown here. In case of restoration, a connection also requires two link-disjoint paths. However, the backup path will only be established when the primary path fails. The QoS metrics include end-to-end delay and bandwidth are also included in the <Metric-list>. Upon receiving the PCReq of survivable path computation, PCE initiates survivable path computation based on the resource information in its TED. If two link-disjoint paths can be computed simultaneously and both can meet all QoS requirements, such as bandwidth and end-to-end delay, PCE returns a PCRep message with survivability extensions to the PCC. Extensions to the PCRep message including <Path-list > and a new metric in <Metric-list >. In the survivable path computation, two link-disjoint paths are computed. Hence, the <Path-list > contains two Explicit Route Objects (EROs) specifying the path information and bandwidth assigned on each path, as shown in Figure 3. The new metric in <Metric-list > in PCRep message is the same as the PCReq message. C. Signaling flow for Survivable Path Computation The signaling flow for survivable path computation is shown in Figure 4, which follows the specification standardized in RFC5440 [1] with survivability extensions. Figure 4 illustrates the signaling flow of the survivable path computation in the reference scenario (Figure 1). In the first step, the PCC (here R1) initiates a PCEP session with the PCE, which involves the exchange of Open and Keepalive messages. The client then s a Path Computation Request (PCReq) which specifies source and destination nodes (endpoints) and QoS constraints to PCE. In addition to the bandwidth requirement and end-to-end delay, survivability requirement is also specified in the PCReq message. Here, protection is required. The PCE computes two link-disjoint paths and returns the information of paths in the Path Computation Response Message (PCRep) in form of a list of Explicit Route Objects (EROs), where bandwidth allocated on each path is also specified. In the example shown in Figure 1, P1 (R1-R4-R5-R7) is computed as primary path and P2 (R1-R2-R3-R6-R7) is the backup path.

4 4 PCC (R1) PCE PCC connects to PCE PCC s Path computation request PCE returns two paths With given constraints Fig. 4: PCE signaling for survivable path computation; Note that messages such as Close and Error are not shown in this signaling flow PCE Server PCE Queuing dela ay tion elay Computat de Computation lay Signaling del Session Management Session M Network Net Client Fig. 5: Functional modules of a PCE server IV. IMPLEMENTATION We first briefly describe the open-source PCE emulator which is shown in Figure 5. Afterwards, we describe the extensions in support of survivable path computation. As shown in Figure 5, the PCE emulator presented in [2] is composed of three main function modules in the PCE emulator, referred to as Network Module, Session management module and Computation module. We hereby briefly overview the main function of each module, please refer to [2] for the detailed information. The network module is responsible for managing communication between remote peers, i.e., retrieving and ing the PCEP messages over a network connection. While the session management module is mainly responsible for managing a PCEP session between a PCE client and server. Finally the computation module is in charge of network information update and path computation. Algorithms that are used for path computation are also implemented in this module. The PCEP protocol extensions described in Sec. III, including extended PCReq and PCRep messages, are implemented in the Network Module. Link-disjoint path computation algorithms are implemented in the Computation Module. In this study, we implemented an algorithm proposed in [10] for link-disjoint path computation. However, it is open to any algorithm due to the modularity of the open-source PCE emulator.

5 5 Fig. 6: Germany50 Topology V. EMULATION STUDY The emulation study mainly uses Germany50 network topology with 50 nodes and 88 links, as shown in Figure 6. In the emulation, we randomly select service endpoints, i.e., source and destination nodes, where the source node acts as a Path Computation Client (PCC). Each client generates one request at one time and the average inter-arrival time between each connection in the network is set to be 1second. The emulation study is designed in a real network scenario, where network load varies as connections are dynamically established and released. The network load (Erlang) is defined as u h, where u is connection arrival rate and h is the mean connection holding time.the bandwidth required by connection requests is randomly generated, varying between 3Gbps and 6Gbps. For each network load, average around connections are generated in order to obtain a statistically relevant value. A. Scalability analysis The scalability is analyzed based on three time parameters, referred to as queuing delay, computation delay and signaling delay, which reflect the effect of survivability extensions on a PCE. All the time parameters are resulted due to the precessing time in each module of the PCE emulator. As shown in Figure 5, queuing delay is defined as the time that a path computation request needs to wait before being processed, while computation delay is defined as the time that computation module takes to compute a solution. Finally, signaling delay is the time the whole signaling flow takes. It is calculated from a client s out a path computation request till it s a response. We first study the scenario where all the connection requests require a dedicated protection, i.e., 1+1 protection. As shown in Figure 7, signaling delay increases with increasing of network load, while queuing delay and computation delay stay stable. It is due to the fact that the main contributor of signaling delay is the session processing time in session management module. When the number of connections increases, the number of sessions that have to be processed in the session management module increases. The session processing time depends on the speed of physical processor, a session needs to wait for a longer time for its turn to get processed with the same hardware when network load is high. However, a PCE server can still process the PCReq messages efficiently, which is reflected by the almost unchanged queuing delay. On the other hand, the computation module is not effected either by the increasing load and survivability extensions. Upon receiving a PCReq, it can quickly obtain a solution, which is less than 1ns. Figure 7 shows that a PCE with survivability extensions is scalable regardless of network load.

6 6 14 x Signalling delay 10 Nanosecond Computational Delay Queuing Delay Network Load (Erlang) Fig. 7: Time measurements vs. different network loads; all connections require 1+1 protection (Germany 50) 12 x Signaling Delay Nanosecond Computation Delay Queuing Delay 0 20% 50% 80% 100% Protection Ratio Fig. 8: Time measurements vs. the ratio of connections require 1+1 protection (Germany 50); network load = 30 Erlang We further study the scalability of a PCE in processing mixed path computation requests, i.e., only a certain percentage of connections require protection. For those that do not require dedicated protection, the PCE will only compute a single path and returns the path information to the PCC. Figure 8 shows the time measurements at 30Erlang. As it can be seen, the queuing delay and computation delay are not significantly affected by ratio of the connection requests requiring protection. When 20% of connections require protection, a request needs to wait 0.152ms before it is processed by the PCE (Queuing delay). However, queuing delay remains small even all connections require protection (0.208ms in average). Figure 8 also shows that the difference of computational time observed is very small when the number of connections requiring protection is increasing. In terms of signaling delay, more connections that require dedicated protection will lead to higher signaling delay. However, the time measurements illustrated in Figure 8 show that the extended PCE is scalable in networks with mixed path computation requests. B. Effect on Network Performance Blocking probability is another factor under study in this paper, which shows the effect of a PCE with survivability extensions on network performance. It is defined as the ratio of blocked connection requests among all connection

7 7 Blocking Probability (%) Ratio=20% Ratio=50% Ratio=80% Ratio=100% Network Load (Erlang) Fig. 9: Blocking probability vs. network loads vs. ratio of connection requests requiring 1+1 protection (Germany50) requests. As it can be seen in Figure 9, a higher blocking probability is observed when more connection requests requiring protection. For instance, about 20% blocking probability is observed when all connections require backup paths at 50Erlang. However, only 6% blocking probability has been observed when only 20% of the connections require backup paths at the same network load. It is due to the fact that more network resource has to be allocated in case of protection. Figure 9 also shows that increasing network load leads to a higher blocking probability. For example, about 7% of the connection requests are blocked at 30Erlang while 20% blocking probability is observed at 50Erlang when all connections require protection. The results shown in Figure 9 are rather intuitive, which are included here to show the effectiveness of the extended PCE for survivable path computation. C. Effect of Network size The final emulation study is on the effect of size of the network where PCE with survivability is deployed. In addition to Germany50 network, we also use Atalanta network with 15 nodes and 22 links shown in Figure 10 [11]. The same factors are measured, i.e., signaling delay, queuing delay and computation delay. We study two scenarios: 1) 50% of the connection requests requiring protection; and 2) all the connection requests need a backup path in the second scenario(100% protection). As it is shown in Table I, smaller network leads to less processing time in a PCE under the same condition. The results shown here are obtained at network load of 30Erlang. Around 10ms signaling delay is observed in Germany50 network when all connections require protection ( 100% protection). However, it takes only 4ms in Atalanta network. The same trend can be observed in terms of queuing delay and computation delay. For example, it results in 0.2ms queuing delay in average in Germany50 network in case of 100% protection while it is only 0.07ms in Atalanta network under the same condition. Table I also shows that when the number of requests requiring protection is smaller in a network, PCE can process path computation requests much faster, especially when network is large. For instance, the PCE takes 1ms less in signaling when only 50% of connection requests requiring protection in Germany50 network, comparing with 100% protection. However, only 0.04ms reduction is observed in Atlanta network in terms of signaling delay when 50% of connection requiring protection, comparing with the scenario where all connections are protected. Finally, we compare the performance of networks with different size in terms of blocking probability. Figure 11 shows that a smaller network leads to much higher blocking probability. It can be seen that, 38.9% connection requests are blocked in Atlanta network when network load is 50Erlang in the 100% scenario. In Germany50 network, only 8.84% blocking probability is observed at the same network load. Even when network load is low, the blocking probability is also much higher in Atlanta network comparing with Germany50 network. For instance,

8 8 Fig. 10: Atlanta Network Topology TABLE I: Time measurements in Germany50 (G50) and Atlanta networks; network load = 30Erlang Network/ Signaling delay Queuing delay Computation delay (Ratio) (Avg. ns) (Avg. ns) (Avg. ns) G50 (100%) G50 (50% ) Atlanta (100%) Atlanta (50%) in case of 100% protection scenario, more than 25% of requests are blocked in Atlanta network, while less than 10% is observed in Germany50 network at 30Erlang. When 50% of the requests that need a backup path, only 4.8% blocking probability is seen in Germany50 network at 30Erlang, which is much smaller comparing with 18.3% in Atlanta network. VI. CONCLUSION AND DISCUSSION In this report, we presented the first implementation of PCE with survivability extensions. We first proposed extensions to PCE communication protocol, referred to as PCEP to facilitate survivable path computation. We Blocking Probability (%) Atlanta, 100% protection Atlanta, 50% protection Germany50, 50% protection Germany50, 100% protection Network Load (Erlang) Fig. 11: Blocking probability vs. network size vs. network load

9 9 presented a reference architecture and designed the signaling flow for extended PCEP protocol. We implemented the proposed extensions based on an open-source PCE emulator [2] and evaluated it in a large scale network, namely Germany50. Three time parameters that reflects the scalability of the extended PCE emulator are measured in the emulation study, namely, signaling delay, queuing delay and computation delay. The results show that the presented PCE with survivability extensions scale well regardless of network load. It is also capable of efficiently processing mixed path computation requests, which can be protection or without protection. We also studied the network performance in terms of blocking probability when the extended PCE is applied in a network. Finally, we used a different network, referred to as Atlanta network for emulation study to show the effect of the network size on the extended PCE. The results show that a smaller network can reduce the time parameters but can result in a higher blocking probability. However, our implementation of PCE with survivability extensions is scalable in networks with different size and performs well regarding the network performance. VII. ACKNOWLEDGMENT This work has been partially supported by GEYSERS (FP7-ICT ) project funded by the European Commission through the 7th ICT Framework Program. REFERENCES [1] J. Vasseur and J. L. Roux, Path computation element communication protocol, RFC 5440, Mar [2] Open source path computation element emulator. [Online]. Available: [3] E. Oki, T. Takeda, J. L. Roux, and A. Farrel, Framework for pce-based inter-layer mpls and gmpls traffic engineering, RFC 5623, Sept [4] J. Vasseur, R. Zhang, N. Bitar, and J. L. Roux, A backward-recursive pce-based computation (brpc) procedure to compute shortest constrained inter-domain traffic engineering label switched paths, RFC 5441, Apr [5] I. Bryskin, D. Papadimitriou, L. Berger, and J. Ash, Policy-enabled path computation framework, RFC 5394, Dec [6] J. Vasseur, J. L. Roux, and Y. Ikejiri, A set of monitoring tools for path computation element (pce)-based architecture, RFC 5886, Jun [7] Q. Zhao, D. King, F.Verhaeghe, T. Takeda, Z. Ali, and J. Meuric, Extensions to the path computation element communication protocol (pcep) for point-to-multipoint traffic engineering label switched paths, RFC 6006, Sept [8] Y. Lee, G. Bernstein, J. Martensson, T. Takeda, and T.Otani, Pcep requirements for wson routing and wavelength assignment, IETF Internet Draft, Jul [9] F. Zhang, X. Zhang, Y. Lee, R. Casellas, and O. G. de Dios, Applicability of stateful path computation element (pce), IETF Internet Draft, Mar [10] J. W. Suurballe, Disjoint paths in a network, Networks, vol. 4, no. 2, pp , [Online]. Available: [11] Osurvivable fixed telecommunication network design. [Online]. Available: