- Email: [email protected]
Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE
Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
Contents lists available at ScienceDirect
Optical Switching and Networking journal homepage: www.elsevier.com/locate/osn
Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE Jin Seek Choi a,n, Sungtae Kang a, Young Lee b a b
Hanyang University, 17 Haengdang-dong, Seongdong-gu, Seoul 133-791, Republic of Korea Huawei USA, 5340 Legacy Drive Suite 173, Plano, TX 75024, USA
a r t i c l e i n f o
abstract
Article history: Received 24 November 2014 Received in revised form 28 July 2015 Accepted 24 September 2015
In this paper, we present a topology discovery protocol for a stateful path computation element (PCE), in which the PCE has an out-of-band control channel to every switch in a unified control. The proposed protocol is an extended version of the PCE communication protocol (PCEP) called the Generalized TOPology (G-TOP) protocol that allows the PCE to automatically construct the network topology as a controller without using a distributed routing protocol. With the G-TOP protocol, the centralized PCE controller proactively extracts neighbor information as well as link status information from switches when it starts. The controller also reactively updates topology changes that arise from the switch when detecting faults or changes in the link state. We implement the proposed protocol, and show that the proposed protocol reduces not only the topology discovery/updating time but also traffic to the controller. & 2015 Elsevier B.V. All rights reserved.
Keywords: Topology discovery Controller-driven Event-driven Path computation element Software defined topology discovery control
1. Introduction The topology represents the actual up-to date information about the connectivity, distance, latency and link capacity between the nodes at different levels of abstraction. Network services including virtual private networks and leased line services rely heavily on the network topology. In particular, topology-aware algorithms (e.g., path computation, policy, quality of service (QoS), routing, resource reservation, fault management) may improve network service performance by exploiting network topology. To provide network service, acquiring an accurate network topology is therefore very important for network operators. In transport networks, a path computation element (PCE) is a specialized server separated from the switches n
Corresponding author. Tel.: þ 82 2 2220 1129; fax: þ82 2 2220 1723. E-mail address: [email protected] (J.S. Choi).
that is capable of computing an optimal end-to-end path or route based on network inventories such as the network topology and traffic engineering (TE) information (link and node states) [1,2]. A Stateful PCE is a PCE that enables both the instantiation of a path (initiate or tear-down) while keeping label switched path database (LSPDB) and path computation, subject to network inventories at the TE database (TED). The topology discovery protocol is not yet involved in the Stateful PCE, in which the TED collects and maintains up-to-date network topology as well as TE information populated by distributed routing protocol or other management tools. The Stateful PCE coupled with the topology discovery protocol has a critical role in building a unified control and management framework [3,4], especially where the networks do not run an interior gateway protocol-TE (IGP-TE). Many topology discovery protocols have been proposed for the PCE [5–9]. Most of them have focused on distributed routing protocol based on open shortest path first-traffic engineering (OSPF-TE) [5,6]. However, distributed protocol
http://dx.doi.org/10.1016/j.osn.2015.09.006 1573-4277/& 2015 Elsevier B.V. All rights reserved.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
2
takes several seconds to be stabilized any topology change since a link state advertisement (LSA) packet is gradually flooded by hop-by-hop relay method [10]. One study implies that long convergence time and large number of LSAs flooded in the network might cause scalability problems in OSPF-TE and impose limitations on OSPF-TE applications [17]. Moreover, the LSA is not advertised before a timeout is elapsed once an LSA has been generated. One can reduce the timeout to get more dynamic topology view, but the increased data collection overhead associated with LSA traffic can affect the performance of the PCE. As alternatives to distributed routing protocols, centralized approaches have been proposed [7–9]. Within the centralized approaches, a topology server proactively tracks an accurate view of network topology by extracting dynamic changes of the network topology via simple network management protocol (SNMP) [8], OpenFlow protocol [7] or PCE communication protocol (PCEP) [9]. These proactive approaches provide a convenient mechanism to the centralized server to extract network topology directly stored in each switch/router using probe packets. However, the performance of the proactive mechanisms relies on the frequency of probe packets as indications of link up/down status and switch connectivity in dynamic network environments. In addition, the traffic of the probe packets is critical to the scalability of the centralized topology server especially when the network size increases. To the best of our knowledge, there has been no report of PCEP-centric topology discovery protocol using reactive mechanism that is triggered upon the associated events occurring within switches. In this paper, we propose a topology discovery protocol, called Generalized TOPology discovery protocol (G-TOP) for a Stateful PCE, in which the proposed protocol proactively collects the topology information from the switch, and reactively updates the topology change through an
Network operator
GUI /UNI
out-of-band control channel. Our contribution is a detailed design of the integrated protocol combined with a controller-driven proactive discovery protocol and an event-driven reactive discovery protocol in a unified architecture. The G-TOP protocol enables to collect topology and TE information in a single transaction, while SNMP is huge transactions for the same number of managed objects. We design and implement the proposed protocol as an extended PCEP. From an experimental testbed, we show that the proposed protocol not only simplifies the discovering procedure through a controllerdriven mechanism but also reduces the delay and the probe traffic for fault monitoring through an event-driven mechanism. The rest of this paper is organized as follows: In Section 2, we describe the network architecture. In Section 3, we describe the proposed protocol in detail. Section 4 briefly introduces our implementation and experimental results that validate the feasibility of the proposed framework. Finally, in Section 5, we make some conclusions and present future research directions.
2. Network architecture Fig. 1 shows the overall network architecture for the proposed G-TOP protocol. The network consists of a centralized PCE controller and a set of switches with different forwarding technology such as Ethernet and optical links. The controller integrates the topology discovery and provisioning functions as a next step beyond a Stateful PCE. The controller constructs and maintains the up-to-date view of the network topology at TED without using distributed routing and signaling protocols. The controller has a direct connection to each switch using an out-of-band control channel clearly separated
PCE controller
TED
NNI Path Request /Path Reply
PCE controller
G-TOP
LLDP
LLDP
LLDP
LLDP
LLDP
User equipment LLDP
LLDP/OAM Packet
Packet switch Packet link
Optical switch Optical link
G-TOP server G-TOP client
Fig. 1. Network architecture for G-TOP protocol.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
from the data-forwarding channel. Through the control channel, the controller-driven discovery protocol extracts the neighbor information stored in each switch from each switch and builds an entire view of the network topology when it starts. Next, the protocol keeps tracks of the up-todate network state information about the nodes, links, physical connectivity, and link utilization through the event-driven updating protocol that is triggered upon the associated events occurring within the switches. Each switch makes full use of switch-specific management plane including operation, administration, and maintenance (OAM) and link layer discovery protocol (LLDP) on top of the forwarding engine [12]. OAM is the processes and activities for link monitoring and fault detection. LLDP is a feasible mechanism to discover a switch’s neighbor and monitor the connectivity between the switches. By using the LLDP protocol, the management plane maintains up-to-date neighbor information and monitors the physical connectivity. In some optical transport network infrastructure, the Link Management Protocol (LMP) or link-state routing protocol may be used for neighbor discovery [2]. The controller has either a user-to-network interface (UNI) or a graphical user interface (GUI) to communicate with the customer node or the network operators, respectively. It also has a network-to-network interface (NNI) to communicate with the other PCE controllers. In addition, the controller has an interface to the TED to store and retrieve the up-to-date network state information.
3. G-TOP protocol We design a topology discovery protocol, called G-TOP protocol. The G-TOP protocol integrates the controllerdriven discovery protocol and event-driven updating protocol in a unified way.
3
discovery process (i) runs at each switch, which periodically sends “LLDP packets” to its neighbors through the interfaces that are directly connected. The “LLDP packet” is a unidirectional packet specified in IEEE 802.1AB that includes the system name and interface name as the type length values (TLVs) in a distributed way. The polling cycle can be reconfigured at the desired rate. While receiving the “LLDP packets” consecutively, the management plane recognizes the neighbor information as well as the health of the interfaces. The management plane maintains these management information bases (MIBs) as the values of the variables for switch and its neighbors, which can provide a feasible mechanism to build connectivity between switches. The topology discovery process (ii) is a straightforward controller-driven procedure to extract neighbor information from the switches. The controller directly polls the switches on-demand to get the MIB variables of the switch. The controller extracts the switch information as well as the neighboring information from every switch and builds the entire topology view. This process can be automatically enabled on the controller after establishing the association with the switch. The G-TOP client also keeps track of the topology changes by using an event-driven updating process (iii). The “LLDP packets” indicate whether a given adjacency is up or down. While receiving the “LLDP packets” consecutively, the G-TOP client recognizes the health of the interfaces. On the other hand, the G-TOP client detects the failure of the link when it stops receiving “LLDP packets” for a specified length of time or it receives an OAM message that indicates an error on the link. The updating process is triggered upon changes in connectivity such as interface up/down or neighbor up/down. This triggered event can be automatically enabled on a switch when the G-TOP client detects a topology change. Thus, the controller can keep track of the dynamic topology view by using an event-driven update.
3.1. Functional architecture 3.2. Protocol architecture Fig. 2 shows the functional architecture for the G-TOP protocol. As shown in this figure, the discovery function is divided into three independent processes: (i) distributed neighbor discovery, (ii) controller-driven topology discovery, and (iii) event-driven topology updating. The neighbor
The G-TOP protocol is a transactional server and client protocol as an extended PCEP protocol specified by IETF RFC 5440 [13]. The PCEP was originally designed only for exchanging path requests and response messages over a
PCE controller (G-TOP server)
Switch (G-TOP client) (i)
(ii)
Switch & neighbors MIBs
Poll Switch MIB
Receive LLDP/OAM
Send LLDP/OAM
G-TOP protocol
Update TED
Fault detection (iii)
Fig. 2. Functional architecture for the topology discovery process.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
4
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
TCP connection using the well-known port 4189. In this paper, we extend the PCEP into G-TOP to support the network-wide topology information and event notification including status updating information. Typically, PCEP consists of three phases: In the initialization phase, the PCEP server and client exchange OPEN messages and reply KEEPALIVE message to setup session at both sides after establishing the TCP connection. Next, the client can send PCE Request with a set of constraints and attributes to compute an end-to-end path or route in the path request/response phase. The server replies the Path Response with the Explicit Route Objects (EROs) if the path computation succeeds. The client can then close the session or leave it open and monitor the session by means of KEEPALIVE messages in the final close phase. In this paper, we newly define the G-TOP protocol consisting of four phases: initialization, node discovery, neighbor discovery,
and status updating phases. Fig. 3 shows the G-TOP protocol and message sequences. In the initialization phase, the G-TOP server and client exchange OPEN messages and reply KEEPALIVE message to setup a permanent TCP session at both sides. After establishing the TCP session, the controller directly sends the node identification (Node ID) request to the switch, and receives the corresponding client’s Node ID response as a controllerdriven topology discovery protocol as shown in Fig. 4. The Node ID response message includes the Node object and a set of Port objects, in which the Node object consists of the system name, IP address, switching capacity and number of interface ports, and the Port object consists of the local port IDs, port descriptions, and their bandwidth features. Upon receiving a Node ID response, the controller identifies the node and the physical characteristics of each interface. Next, the controller consecutively performs the neighbor discovery procedure as follows; the controller sends an
Fig. 3. G-TOP protocol and operational procedure.
Fig. 4. Node discovery procedure and the Node ID response message formats captured by Wireshark.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
LLDP request to collect the information about the physical connectivity to its neighbors, as shown in Fig. 5. The client will return the LLDP response including the node objects and the set of PORT-Top objects. The PORT-top object consists of a local port object and the corresponding remote port object, in which the local/remote port object includes the media service access point (MSAP) assigned to its physical port. A pair of MSAPs represents the physical connectivity between the two ports. From the information, the controller can construct the entire network topology. The client keeps monitor the status while exchanging KEEPALIVE messages. When the client detects a fault or status change, then G-TOP protocol provides one event-driven
5
notification for the topology update, called the “LLDP update message.” A switch sends an “LLDP update message” to the controller when it detects any failure or change in the status of the node. The message includes the specific Node object and the corresponding Port-Top objects as shown in Fig. 6. The controller immediately updates the status of the node and its physical connectivity upon receiving this message. After updating the status, the controller saves the result in the TED. The main contribution of this G-TOP protocol is the extension of the PCEP protocol to support the retrieving node and neighbor information as well as the event notification for any failure or change in the status of the physical connectivity
Fig. 5. Topology discovery procedure and the LLDP response message format captured by Wireshark.
Fig. 6. Topology update procedure and the LLDP update message formats captured by Wireshark.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
6
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
from the switches. However, the proposed protocol can be extended to include other functionalities such as the provisioning framework [12] and fault recovery in the future. It is an evolutionary approach of the Stateful PCE to the software defined networking [18]. The G-TOP protocol addressed in this paper uses TCP. The overhead associated with TCP does not increase as the number of managed objects increase, which is not the case for SNMP. As such, the extended PCEP over TCP provides a better operational efficiency as compared to SNMP, especially for a large number of managed objects.
4. Implementation and experimental results We design a PCE controller that integrates all of the topology discovery and monitoring functions with a Stateful PCE as a clean separation from the switch. The controller automatically collects the topology information about the nodes, their neighbors, and TE state for the link bandwidth, link cost, link utilization via controller-driven G-TOP protocol, and builds the entire network topology map at the TED. Once the topology and TE maps are established, the controller keeps monitoring the node and link status by using the event-driven G-TOP protocol. The controller maintains the up-to-date topology and TE status map at the TED. Based on the TED, the controller computes an explicit path or route under constraints. The controller also enables the provisioning capabilities as a PCE controller [12]. We have implemented the PCE controller based on a Java framework by integrating all of the control functions (i.e., topology discovery, path computation, and provisioning) as a clean separation from the switches. We have also implemented the G-TOP protocol on top of the controller and switches. The controller consists of three major building blocks: the GUI panel, the control panel of nodes and links, and the controller, as shown in Fig. 7. Each block includes its constituting components with a separate module, which handles a specific process. As shown in Fig. 8, we have also implemented a G-TOP client on top of the Linux 2.6.35.6 operating system as an extension of the open-source software libpcep-0.1 [14]. The client can cooperate with underlying
OAM and LLDP protocols to support provisioning and automatic protection switching (APS) [15]. The LLDP protocol keeps monitoring the physical connectivity and neighbor information. It is one-way protocol that operates on all its physical interfaces. It periodically sends an in-band “LLDP packets” specified in IEEE 802.1AB at every 10 s [16]. While receiving the LLDP packets consecutively, the switch recognizes the health of the interfaces. On the other hand, the management function detects the failure of the link when it stops receiving LLDP packets for three consecutive time. Based on these implementations, we have constructed a test-bed for the validation of the proposed protocol. Fig. 9 shows the test-bed system used in this experiment. The test-bed system consists of three G-TOP clients over a Multi-Protocol Label Switch-Transport Profile (MPLS-TP) switch, one PCE controller, traffic generator, and receiver. We run the controller on Lenovo E420 with dual cores of Intel i5 2.3 Giga Hz processors and 4 Giga Byte memory space using 1 Giga bps Ethernet interface. From the experimental test-bed, we evaluated the performance of the proposed protocol. We measured the delays for controller-driven topology discovery and eventdriven topology updating procedures. These delays are critical to evaluate the performance of the proposed protocol and to validate the practicality. The shorter delay lowers the operating cost to the network operator, which results in more efficient resource utilization from the running times of the protocol. In the case of a fault, the faster fault monitoring results in a more reliable service for the network operators. Table 1 summarizes the topology discovery time as well as the topology updating time over the simple ring topology on the test-bed. The latency for the node and neighbor discovery was about 3 ms and 2 ms, respectively. The topology updating time was about 10 ms. The node and neighbor discovery times consists of the processing time including the signaling latency between the controller and a switch to retrieve the information about the nodes and their connectivity from the switch. The topology updating time consists of the processing time including the signaling latency as well as status updating at TED except for the detecting time. The processing time of
Fig. 7. Functional blocks of the PCE controller.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
7
Fig. 8. Functional blocks of the G-TOP client and MPLS-TP switch.
Fig. 9. Test-bed system.
Table 1 Topology discovery time.
Table 2 Performance comparison of topology updating time.
Type
Method
Delay (ms)
Method
Delay
No. of hops
Node discovery time Neighbor discovery time LLDP updating time
Controller-driven G-TOP Controller-driven G-TOP Event-driven G-TOP
3.4 2.0 9.8
Proposed OSPF [11] OpenFlow [7]
9.8 ms 5.3 s 214 ms
3–20 ring 9 mesh 200 mesh
updating information may vary depending on the CPU power, the number of nodes along the path, and the traffic conditions. Table 2 shows the updating time for the various protocols. As shown in this table, the proposed protocol is comparable to that of the OpenFlow protocol but outperforms that of the OSPF-TE protocol [6,10] and that of the OpenFlow based approach [7,19]. Therefore, we can conclude that the proposed topology discovery protocol can reduce the time for topology discovery and updating by combining the advantages of the controller-driven approach and event-driven approach.
Figs. 10 and 11 show the performance results that were carried out on the emulated test-bed on PC instead of MPLSTP switches due to the demonstration complexity. We emulated the up to 20 switches on the same PC. Fig. 10 shows the G-TOP control traffic captured by WireShark on the controller for topology discovering and updating procedures (see the dotted line). Fig. 10 also shows the OpenFlow traffic captured by WireShark on the control channel. As shown in Fig. 10 (see the solid line), the switch periodically transmits LLDP messages for neighbor discovery. Nevertheless, each switch only
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
8
100000
OpenFlow traffic
the number of switches. This result verifies the practicality of our protocol for large networks in scalable environments.
G-TOP traffic
Control traffic [kbytes/sec]
10000 1000
5. Conclusions 100 10 1 0.1 0
10
20
30
40
50
60
70
Number of Switches
Fig. 10. G-TOP and OpenFlow control traffic on the simple ring topology (emulation).
14
Topology update (link failure)
12
Information processing overhead
Time (ms)
10 8 6 4 2 0
0
5
10
15
20
25
Number of switches Fig. 11. Topology updating times and the inherent information processing overhead for event-driven updating procedures (emulation).
sends event notification to the controller upon detecting failure. This means that the proposed protocol clearly separates the control traffic from the data and OAM traffic. On the other hand, the OpenFlow based controller periodically polls all the interfaces of the switches by transmitting/receiving network-wide LLDP Packet Out/In packets. The aggregated probe packets concentrate on the controller. However, the concentrated traffic can seriously influence on the performance of the controller when the LLDP interval is reduced as shown in Fig. 10. From the results, we can conclude that the proposed protocol can enormously reduce the traffic load on the controller compared to the OpenFlow protocol, which results in improving the efficiency and scalability of the controller. Fig. 11 shows the topology updating times versus the different number of switches for the simple ring topology. The latency means the performance of the network view for updating state in response to topology change events. Fig. 11 shows the latency of updating the status of a link to the network view in a simple ring topology. In the performance view, the inherent overhead of updating TED and GUI has a significant impact on the overall controller performance. From the figure, fortunately we observed that the proposed protocol achieves the topology updating time independent of
In this paper, we demonstrated the details of a PCEP based topology discovery architecture for Stateful PCE, and its experimental implementation. First, we described the Stateful PCE controller integrating the node and the topology discovery functions. Next, we proposed a G-TOP protocol for controller-driven topology discovery and event-driven fault monitoring as an extension of PCEP. Finally, we measured the performance of the experimental test-bed. The experimental results show that the PCEP based topology discovery protocol is a good solution to provide a cost-effective topology discovery mechanism for network operators. Moreover, the proposed protocol enables a simple and efficient way to get the up-to-date network topology and detect faults. In particular, the PCEP-based protocol can reduce the latencies for topology discovery as well as fault monitoring compared to that of the distributed routing protocol. The proposed protocol can quickly react to the changes occurring in the network through event-driven interactions and reduce the traffic as well as the operational costs on the controller. Therefore, the proposed framework can achieve efficiency while greatly improving scalability by clearly separating the management traffic from the controller. This study is the first step towards a PCEP based approach for Stateful PCE. Based on this study, we plan to extend the framework for PCEP based software-defined networking.
Acknowledgments This research was supported by Basic Science Research Program through the National Research Foundation of Korea funded by the Ministry of Education, Science and Technology, Republic of Korea (H6121-2013-1298).
References [1] E. Oki, I. Inoue, and K. Shiomoto, Path computation element (PCE)based traffic engineering in MPLS and GMPLS networks, In: Proceedings of the IEEE Sarnoff Symposium, 2007, pp. 1–5. [2] R. Munoz, R. Casellas, R. Martinez, R. Vilalta, PCE: what is it, how does it work and what are its limitations? J. Lightw. Technol. 32 (2014) 528–543. [3] F. Paolucci, F. Cugini, A. Giorgetti, N. Sambo, P. Castoldi, A survey on the path computation element (PCE) architecture. Communications surveys and tutorials, IEEE Commun. Surv. Tutor. 15 (4) (2013) 1819–1841, http://dx.doi.org/10.1109/SURV.2013.011413.00087. [4] M. Chamania, M. Drogon, A. Jukan, An open-source path computation element (PCE) emulator: design, implementation, and performance, J. Lightw. Technol. 30 (4) (2012) 414–426, http://dx.doi.org/ 10.1109/JLT.2011.2170402. [5] L. Valcarenghi, F. Paolucci, P. Castoldi, F. Cugini, D. Adami, D. Ficara, et al., Topology discovery and performance information services for cal grids, in: Proceedings of the Fourth International Conference on Broadband Communications, Networks and Systems (BROADNETS), 2007, pp. 124–130. [6] L. Lei, T. Tsuritani, I. Morita, R. Casellas, R. Martinez, R. Munoz, Control plane techniques for Elastic Optical Networks: GMPLS/PCE
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
[7]
[8]
[9]
[10] [11]
[12]
vs OpenFlow, in: Proceedings of the IEEE Globecom Workshops (GC Wkshps), Dec. 3–7, 2012, pp. 352–357. Y. Zhao, R. He, H. Chen, J. Zhang, Y. Ji, H. Zheng, et al., Experimental performance evaluation of software defined networking (SDN) based data communication networks for large scale flexi-grid optical networks, Opt. Express 22 (2014) 9538–9547. J. Medved, S. Previdi, V. Lopez, S. Amante, Topology API Use Cases, draft-amante-i2rs-topology-use- cases-01 (work in progress), October 2013. J.S. Choi, A hybrid topology discovery protocol for mobile backhaul, In: Proceedings of the 16th Communications and Networking Symposium (CNS'13), San Diego, USA, 2013. D. Katz, K. Kompella, D. Yeung, Traffic engineering to OSPF version 2, Request for comments 3630, 2003. T. Miyamura, D. Shimazaki, S. Arakawa, Y. Koizumi, S. Kamamura, K. Sasayama et al., Experimental demonstration of adaptive virtual network topology control mechanism based on SDTN architecture, in: Proceedings of the 39th European Conference and Exhibition on Optical Communication (ECOC), 2013, pp. 1–3. J.S. Choi, Design and implementation of a PCE-based softwaredefined provisioning framework for carrier-grade MPLS-TP
[13] [14] [15] [16]
[17]
[18] [19]
9
networks, Photonic Network Communications, 2014 doi: 10.1007/ s11107-014-0472-0. J.P. Vasseur, J.L. Le Roux, PCEP protocol, RFC 5440, Mar 2009. 〈http://sourceforge.net/projects/libpcep/files/〉. 〈http://sourceforge.net/projects/openlldp/〉. IEEE Standard Local and Metropolitan Area Networks, station and media access control connectivity discovery, IEEE Std 802.1AB-2005, 0_1-158, 2005 http://dx.doi.org/10.1109/IEEESTD.2005.96285. S. Huang, K. Kitayama, F. Cugini, F. Paolucci, A. Giorgetti, L. Valcarenghi, P. Castoldi, An experimental analysis on OSPF-TE convergence time, in: Proceedings of SPIE 7137, Network Architectures, Management, and Applications VI, 713728, november 19, 2008. A. Farrel, D. King, Unanswered questions in the path computation element architecture, RFC 7399, October 2014. F. Pakzad, M. Portmann, W.L. Tan, J. Indulska, Efficient topology discovery in software defined networks, in: Proceedings of the 8th International Conference on Signal Processing and Communication Systems (ICSPCS), December 15–17, 2014, pp. 1–8.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
Contents lists available at ScienceDirect
Optical Switching and Networking journal homepage: www.elsevier.com/locate/osn
Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE Jin Seek Choi a,n, Sungtae Kang a, Young Lee b a b
Hanyang University, 17 Haengdang-dong, Seongdong-gu, Seoul 133-791, Republic of Korea Huawei USA, 5340 Legacy Drive Suite 173, Plano, TX 75024, USA
a r t i c l e i n f o
abstract
Article history: Received 24 November 2014 Received in revised form 28 July 2015 Accepted 24 September 2015
In this paper, we present a topology discovery protocol for a stateful path computation element (PCE), in which the PCE has an out-of-band control channel to every switch in a unified control. The proposed protocol is an extended version of the PCE communication protocol (PCEP) called the Generalized TOPology (G-TOP) protocol that allows the PCE to automatically construct the network topology as a controller without using a distributed routing protocol. With the G-TOP protocol, the centralized PCE controller proactively extracts neighbor information as well as link status information from switches when it starts. The controller also reactively updates topology changes that arise from the switch when detecting faults or changes in the link state. We implement the proposed protocol, and show that the proposed protocol reduces not only the topology discovery/updating time but also traffic to the controller. & 2015 Elsevier B.V. All rights reserved.
Keywords: Topology discovery Controller-driven Event-driven Path computation element Software defined topology discovery control
1. Introduction The topology represents the actual up-to date information about the connectivity, distance, latency and link capacity between the nodes at different levels of abstraction. Network services including virtual private networks and leased line services rely heavily on the network topology. In particular, topology-aware algorithms (e.g., path computation, policy, quality of service (QoS), routing, resource reservation, fault management) may improve network service performance by exploiting network topology. To provide network service, acquiring an accurate network topology is therefore very important for network operators. In transport networks, a path computation element (PCE) is a specialized server separated from the switches n
Corresponding author. Tel.: þ 82 2 2220 1129; fax: þ82 2 2220 1723. E-mail address: [email protected] (J.S. Choi).
that is capable of computing an optimal end-to-end path or route based on network inventories such as the network topology and traffic engineering (TE) information (link and node states) [1,2]. A Stateful PCE is a PCE that enables both the instantiation of a path (initiate or tear-down) while keeping label switched path database (LSPDB) and path computation, subject to network inventories at the TE database (TED). The topology discovery protocol is not yet involved in the Stateful PCE, in which the TED collects and maintains up-to-date network topology as well as TE information populated by distributed routing protocol or other management tools. The Stateful PCE coupled with the topology discovery protocol has a critical role in building a unified control and management framework [3,4], especially where the networks do not run an interior gateway protocol-TE (IGP-TE). Many topology discovery protocols have been proposed for the PCE [5–9]. Most of them have focused on distributed routing protocol based on open shortest path first-traffic engineering (OSPF-TE) [5,6]. However, distributed protocol
http://dx.doi.org/10.1016/j.osn.2015.09.006 1573-4277/& 2015 Elsevier B.V. All rights reserved.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
2
takes several seconds to be stabilized any topology change since a link state advertisement (LSA) packet is gradually flooded by hop-by-hop relay method [10]. One study implies that long convergence time and large number of LSAs flooded in the network might cause scalability problems in OSPF-TE and impose limitations on OSPF-TE applications [17]. Moreover, the LSA is not advertised before a timeout is elapsed once an LSA has been generated. One can reduce the timeout to get more dynamic topology view, but the increased data collection overhead associated with LSA traffic can affect the performance of the PCE. As alternatives to distributed routing protocols, centralized approaches have been proposed [7–9]. Within the centralized approaches, a topology server proactively tracks an accurate view of network topology by extracting dynamic changes of the network topology via simple network management protocol (SNMP) [8], OpenFlow protocol [7] or PCE communication protocol (PCEP) [9]. These proactive approaches provide a convenient mechanism to the centralized server to extract network topology directly stored in each switch/router using probe packets. However, the performance of the proactive mechanisms relies on the frequency of probe packets as indications of link up/down status and switch connectivity in dynamic network environments. In addition, the traffic of the probe packets is critical to the scalability of the centralized topology server especially when the network size increases. To the best of our knowledge, there has been no report of PCEP-centric topology discovery protocol using reactive mechanism that is triggered upon the associated events occurring within switches. In this paper, we propose a topology discovery protocol, called Generalized TOPology discovery protocol (G-TOP) for a Stateful PCE, in which the proposed protocol proactively collects the topology information from the switch, and reactively updates the topology change through an
Network operator
GUI /UNI
out-of-band control channel. Our contribution is a detailed design of the integrated protocol combined with a controller-driven proactive discovery protocol and an event-driven reactive discovery protocol in a unified architecture. The G-TOP protocol enables to collect topology and TE information in a single transaction, while SNMP is huge transactions for the same number of managed objects. We design and implement the proposed protocol as an extended PCEP. From an experimental testbed, we show that the proposed protocol not only simplifies the discovering procedure through a controllerdriven mechanism but also reduces the delay and the probe traffic for fault monitoring through an event-driven mechanism. The rest of this paper is organized as follows: In Section 2, we describe the network architecture. In Section 3, we describe the proposed protocol in detail. Section 4 briefly introduces our implementation and experimental results that validate the feasibility of the proposed framework. Finally, in Section 5, we make some conclusions and present future research directions.
2. Network architecture Fig. 1 shows the overall network architecture for the proposed G-TOP protocol. The network consists of a centralized PCE controller and a set of switches with different forwarding technology such as Ethernet and optical links. The controller integrates the topology discovery and provisioning functions as a next step beyond a Stateful PCE. The controller constructs and maintains the up-to-date view of the network topology at TED without using distributed routing and signaling protocols. The controller has a direct connection to each switch using an out-of-band control channel clearly separated
PCE controller
TED
NNI Path Request /Path Reply
PCE controller
G-TOP
LLDP
LLDP
LLDP
LLDP
LLDP
User equipment LLDP
LLDP/OAM Packet
Packet switch Packet link
Optical switch Optical link
G-TOP server G-TOP client
Fig. 1. Network architecture for G-TOP protocol.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
from the data-forwarding channel. Through the control channel, the controller-driven discovery protocol extracts the neighbor information stored in each switch from each switch and builds an entire view of the network topology when it starts. Next, the protocol keeps tracks of the up-todate network state information about the nodes, links, physical connectivity, and link utilization through the event-driven updating protocol that is triggered upon the associated events occurring within the switches. Each switch makes full use of switch-specific management plane including operation, administration, and maintenance (OAM) and link layer discovery protocol (LLDP) on top of the forwarding engine [12]. OAM is the processes and activities for link monitoring and fault detection. LLDP is a feasible mechanism to discover a switch’s neighbor and monitor the connectivity between the switches. By using the LLDP protocol, the management plane maintains up-to-date neighbor information and monitors the physical connectivity. In some optical transport network infrastructure, the Link Management Protocol (LMP) or link-state routing protocol may be used for neighbor discovery [2]. The controller has either a user-to-network interface (UNI) or a graphical user interface (GUI) to communicate with the customer node or the network operators, respectively. It also has a network-to-network interface (NNI) to communicate with the other PCE controllers. In addition, the controller has an interface to the TED to store and retrieve the up-to-date network state information.
3. G-TOP protocol We design a topology discovery protocol, called G-TOP protocol. The G-TOP protocol integrates the controllerdriven discovery protocol and event-driven updating protocol in a unified way.
3
discovery process (i) runs at each switch, which periodically sends “LLDP packets” to its neighbors through the interfaces that are directly connected. The “LLDP packet” is a unidirectional packet specified in IEEE 802.1AB that includes the system name and interface name as the type length values (TLVs) in a distributed way. The polling cycle can be reconfigured at the desired rate. While receiving the “LLDP packets” consecutively, the management plane recognizes the neighbor information as well as the health of the interfaces. The management plane maintains these management information bases (MIBs) as the values of the variables for switch and its neighbors, which can provide a feasible mechanism to build connectivity between switches. The topology discovery process (ii) is a straightforward controller-driven procedure to extract neighbor information from the switches. The controller directly polls the switches on-demand to get the MIB variables of the switch. The controller extracts the switch information as well as the neighboring information from every switch and builds the entire topology view. This process can be automatically enabled on the controller after establishing the association with the switch. The G-TOP client also keeps track of the topology changes by using an event-driven updating process (iii). The “LLDP packets” indicate whether a given adjacency is up or down. While receiving the “LLDP packets” consecutively, the G-TOP client recognizes the health of the interfaces. On the other hand, the G-TOP client detects the failure of the link when it stops receiving “LLDP packets” for a specified length of time or it receives an OAM message that indicates an error on the link. The updating process is triggered upon changes in connectivity such as interface up/down or neighbor up/down. This triggered event can be automatically enabled on a switch when the G-TOP client detects a topology change. Thus, the controller can keep track of the dynamic topology view by using an event-driven update.
3.1. Functional architecture 3.2. Protocol architecture Fig. 2 shows the functional architecture for the G-TOP protocol. As shown in this figure, the discovery function is divided into three independent processes: (i) distributed neighbor discovery, (ii) controller-driven topology discovery, and (iii) event-driven topology updating. The neighbor
The G-TOP protocol is a transactional server and client protocol as an extended PCEP protocol specified by IETF RFC 5440 [13]. The PCEP was originally designed only for exchanging path requests and response messages over a
PCE controller (G-TOP server)
Switch (G-TOP client) (i)
(ii)
Switch & neighbors MIBs
Poll Switch MIB
Receive LLDP/OAM
Send LLDP/OAM
G-TOP protocol
Update TED
Fault detection (iii)
Fig. 2. Functional architecture for the topology discovery process.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
4
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
TCP connection using the well-known port 4189. In this paper, we extend the PCEP into G-TOP to support the network-wide topology information and event notification including status updating information. Typically, PCEP consists of three phases: In the initialization phase, the PCEP server and client exchange OPEN messages and reply KEEPALIVE message to setup session at both sides after establishing the TCP connection. Next, the client can send PCE Request with a set of constraints and attributes to compute an end-to-end path or route in the path request/response phase. The server replies the Path Response with the Explicit Route Objects (EROs) if the path computation succeeds. The client can then close the session or leave it open and monitor the session by means of KEEPALIVE messages in the final close phase. In this paper, we newly define the G-TOP protocol consisting of four phases: initialization, node discovery, neighbor discovery,
and status updating phases. Fig. 3 shows the G-TOP protocol and message sequences. In the initialization phase, the G-TOP server and client exchange OPEN messages and reply KEEPALIVE message to setup a permanent TCP session at both sides. After establishing the TCP session, the controller directly sends the node identification (Node ID) request to the switch, and receives the corresponding client’s Node ID response as a controllerdriven topology discovery protocol as shown in Fig. 4. The Node ID response message includes the Node object and a set of Port objects, in which the Node object consists of the system name, IP address, switching capacity and number of interface ports, and the Port object consists of the local port IDs, port descriptions, and their bandwidth features. Upon receiving a Node ID response, the controller identifies the node and the physical characteristics of each interface. Next, the controller consecutively performs the neighbor discovery procedure as follows; the controller sends an
Fig. 3. G-TOP protocol and operational procedure.
Fig. 4. Node discovery procedure and the Node ID response message formats captured by Wireshark.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
LLDP request to collect the information about the physical connectivity to its neighbors, as shown in Fig. 5. The client will return the LLDP response including the node objects and the set of PORT-Top objects. The PORT-top object consists of a local port object and the corresponding remote port object, in which the local/remote port object includes the media service access point (MSAP) assigned to its physical port. A pair of MSAPs represents the physical connectivity between the two ports. From the information, the controller can construct the entire network topology. The client keeps monitor the status while exchanging KEEPALIVE messages. When the client detects a fault or status change, then G-TOP protocol provides one event-driven
5
notification for the topology update, called the “LLDP update message.” A switch sends an “LLDP update message” to the controller when it detects any failure or change in the status of the node. The message includes the specific Node object and the corresponding Port-Top objects as shown in Fig. 6. The controller immediately updates the status of the node and its physical connectivity upon receiving this message. After updating the status, the controller saves the result in the TED. The main contribution of this G-TOP protocol is the extension of the PCEP protocol to support the retrieving node and neighbor information as well as the event notification for any failure or change in the status of the physical connectivity
Fig. 5. Topology discovery procedure and the LLDP response message format captured by Wireshark.
Fig. 6. Topology update procedure and the LLDP update message formats captured by Wireshark.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
6
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
from the switches. However, the proposed protocol can be extended to include other functionalities such as the provisioning framework [12] and fault recovery in the future. It is an evolutionary approach of the Stateful PCE to the software defined networking [18]. The G-TOP protocol addressed in this paper uses TCP. The overhead associated with TCP does not increase as the number of managed objects increase, which is not the case for SNMP. As such, the extended PCEP over TCP provides a better operational efficiency as compared to SNMP, especially for a large number of managed objects.
4. Implementation and experimental results We design a PCE controller that integrates all of the topology discovery and monitoring functions with a Stateful PCE as a clean separation from the switch. The controller automatically collects the topology information about the nodes, their neighbors, and TE state for the link bandwidth, link cost, link utilization via controller-driven G-TOP protocol, and builds the entire network topology map at the TED. Once the topology and TE maps are established, the controller keeps monitoring the node and link status by using the event-driven G-TOP protocol. The controller maintains the up-to-date topology and TE status map at the TED. Based on the TED, the controller computes an explicit path or route under constraints. The controller also enables the provisioning capabilities as a PCE controller [12]. We have implemented the PCE controller based on a Java framework by integrating all of the control functions (i.e., topology discovery, path computation, and provisioning) as a clean separation from the switches. We have also implemented the G-TOP protocol on top of the controller and switches. The controller consists of three major building blocks: the GUI panel, the control panel of nodes and links, and the controller, as shown in Fig. 7. Each block includes its constituting components with a separate module, which handles a specific process. As shown in Fig. 8, we have also implemented a G-TOP client on top of the Linux 2.6.35.6 operating system as an extension of the open-source software libpcep-0.1 [14]. The client can cooperate with underlying
OAM and LLDP protocols to support provisioning and automatic protection switching (APS) [15]. The LLDP protocol keeps monitoring the physical connectivity and neighbor information. It is one-way protocol that operates on all its physical interfaces. It periodically sends an in-band “LLDP packets” specified in IEEE 802.1AB at every 10 s [16]. While receiving the LLDP packets consecutively, the switch recognizes the health of the interfaces. On the other hand, the management function detects the failure of the link when it stops receiving LLDP packets for three consecutive time. Based on these implementations, we have constructed a test-bed for the validation of the proposed protocol. Fig. 9 shows the test-bed system used in this experiment. The test-bed system consists of three G-TOP clients over a Multi-Protocol Label Switch-Transport Profile (MPLS-TP) switch, one PCE controller, traffic generator, and receiver. We run the controller on Lenovo E420 with dual cores of Intel i5 2.3 Giga Hz processors and 4 Giga Byte memory space using 1 Giga bps Ethernet interface. From the experimental test-bed, we evaluated the performance of the proposed protocol. We measured the delays for controller-driven topology discovery and eventdriven topology updating procedures. These delays are critical to evaluate the performance of the proposed protocol and to validate the practicality. The shorter delay lowers the operating cost to the network operator, which results in more efficient resource utilization from the running times of the protocol. In the case of a fault, the faster fault monitoring results in a more reliable service for the network operators. Table 1 summarizes the topology discovery time as well as the topology updating time over the simple ring topology on the test-bed. The latency for the node and neighbor discovery was about 3 ms and 2 ms, respectively. The topology updating time was about 10 ms. The node and neighbor discovery times consists of the processing time including the signaling latency between the controller and a switch to retrieve the information about the nodes and their connectivity from the switch. The topology updating time consists of the processing time including the signaling latency as well as status updating at TED except for the detecting time. The processing time of
Fig. 7. Functional blocks of the PCE controller.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
7
Fig. 8. Functional blocks of the G-TOP client and MPLS-TP switch.
Fig. 9. Test-bed system.
Table 1 Topology discovery time.
Table 2 Performance comparison of topology updating time.
Type
Method
Delay (ms)
Method
Delay
No. of hops
Node discovery time Neighbor discovery time LLDP updating time
Controller-driven G-TOP Controller-driven G-TOP Event-driven G-TOP
3.4 2.0 9.8
Proposed OSPF [11] OpenFlow [7]
9.8 ms 5.3 s 214 ms
3–20 ring 9 mesh 200 mesh
updating information may vary depending on the CPU power, the number of nodes along the path, and the traffic conditions. Table 2 shows the updating time for the various protocols. As shown in this table, the proposed protocol is comparable to that of the OpenFlow protocol but outperforms that of the OSPF-TE protocol [6,10] and that of the OpenFlow based approach [7,19]. Therefore, we can conclude that the proposed topology discovery protocol can reduce the time for topology discovery and updating by combining the advantages of the controller-driven approach and event-driven approach.
Figs. 10 and 11 show the performance results that were carried out on the emulated test-bed on PC instead of MPLSTP switches due to the demonstration complexity. We emulated the up to 20 switches on the same PC. Fig. 10 shows the G-TOP control traffic captured by WireShark on the controller for topology discovering and updating procedures (see the dotted line). Fig. 10 also shows the OpenFlow traffic captured by WireShark on the control channel. As shown in Fig. 10 (see the solid line), the switch periodically transmits LLDP messages for neighbor discovery. Nevertheless, each switch only
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
8
100000
OpenFlow traffic
the number of switches. This result verifies the practicality of our protocol for large networks in scalable environments.
G-TOP traffic
Control traffic [kbytes/sec]
10000 1000
5. Conclusions 100 10 1 0.1 0
10
20
30
40
50
60
70
Number of Switches
Fig. 10. G-TOP and OpenFlow control traffic on the simple ring topology (emulation).
14
Topology update (link failure)
12
Information processing overhead
Time (ms)
10 8 6 4 2 0
0
5
10
15
20
25
Number of switches Fig. 11. Topology updating times and the inherent information processing overhead for event-driven updating procedures (emulation).
sends event notification to the controller upon detecting failure. This means that the proposed protocol clearly separates the control traffic from the data and OAM traffic. On the other hand, the OpenFlow based controller periodically polls all the interfaces of the switches by transmitting/receiving network-wide LLDP Packet Out/In packets. The aggregated probe packets concentrate on the controller. However, the concentrated traffic can seriously influence on the performance of the controller when the LLDP interval is reduced as shown in Fig. 10. From the results, we can conclude that the proposed protocol can enormously reduce the traffic load on the controller compared to the OpenFlow protocol, which results in improving the efficiency and scalability of the controller. Fig. 11 shows the topology updating times versus the different number of switches for the simple ring topology. The latency means the performance of the network view for updating state in response to topology change events. Fig. 11 shows the latency of updating the status of a link to the network view in a simple ring topology. In the performance view, the inherent overhead of updating TED and GUI has a significant impact on the overall controller performance. From the figure, fortunately we observed that the proposed protocol achieves the topology updating time independent of
In this paper, we demonstrated the details of a PCEP based topology discovery architecture for Stateful PCE, and its experimental implementation. First, we described the Stateful PCE controller integrating the node and the topology discovery functions. Next, we proposed a G-TOP protocol for controller-driven topology discovery and event-driven fault monitoring as an extension of PCEP. Finally, we measured the performance of the experimental test-bed. The experimental results show that the PCEP based topology discovery protocol is a good solution to provide a cost-effective topology discovery mechanism for network operators. Moreover, the proposed protocol enables a simple and efficient way to get the up-to-date network topology and detect faults. In particular, the PCEP-based protocol can reduce the latencies for topology discovery as well as fault monitoring compared to that of the distributed routing protocol. The proposed protocol can quickly react to the changes occurring in the network through event-driven interactions and reduce the traffic as well as the operational costs on the controller. Therefore, the proposed framework can achieve efficiency while greatly improving scalability by clearly separating the management traffic from the controller. This study is the first step towards a PCEP based approach for Stateful PCE. Based on this study, we plan to extend the framework for PCEP based software-defined networking.
Acknowledgments This research was supported by Basic Science Research Program through the National Research Foundation of Korea funded by the Ministry of Education, Science and Technology, Republic of Korea (H6121-2013-1298).
References [1] E. Oki, I. Inoue, and K. Shiomoto, Path computation element (PCE)based traffic engineering in MPLS and GMPLS networks, In: Proceedings of the IEEE Sarnoff Symposium, 2007, pp. 1–5. [2] R. Munoz, R. Casellas, R. Martinez, R. Vilalta, PCE: what is it, how does it work and what are its limitations? J. Lightw. Technol. 32 (2014) 528–543. [3] F. Paolucci, F. Cugini, A. Giorgetti, N. Sambo, P. Castoldi, A survey on the path computation element (PCE) architecture. Communications surveys and tutorials, IEEE Commun. Surv. Tutor. 15 (4) (2013) 1819–1841, http://dx.doi.org/10.1109/SURV.2013.011413.00087. [4] M. Chamania, M. Drogon, A. Jukan, An open-source path computation element (PCE) emulator: design, implementation, and performance, J. Lightw. Technol. 30 (4) (2012) 414–426, http://dx.doi.org/ 10.1109/JLT.2011.2170402. [5] L. Valcarenghi, F. Paolucci, P. Castoldi, F. Cugini, D. Adami, D. Ficara, et al., Topology discovery and performance information services for cal grids, in: Proceedings of the Fourth International Conference on Broadband Communications, Networks and Systems (BROADNETS), 2007, pp. 124–130. [6] L. Lei, T. Tsuritani, I. Morita, R. Casellas, R. Martinez, R. Munoz, Control plane techniques for Elastic Optical Networks: GMPLS/PCE
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i
J.S. Choi et al. / Optical Switching and Networking ∎ (∎∎∎∎) ∎∎∎–∎∎∎
[7]
[8]
[9]
[10] [11]
[12]
vs OpenFlow, in: Proceedings of the IEEE Globecom Workshops (GC Wkshps), Dec. 3–7, 2012, pp. 352–357. Y. Zhao, R. He, H. Chen, J. Zhang, Y. Ji, H. Zheng, et al., Experimental performance evaluation of software defined networking (SDN) based data communication networks for large scale flexi-grid optical networks, Opt. Express 22 (2014) 9538–9547. J. Medved, S. Previdi, V. Lopez, S. Amante, Topology API Use Cases, draft-amante-i2rs-topology-use- cases-01 (work in progress), October 2013. J.S. Choi, A hybrid topology discovery protocol for mobile backhaul, In: Proceedings of the 16th Communications and Networking Symposium (CNS'13), San Diego, USA, 2013. D. Katz, K. Kompella, D. Yeung, Traffic engineering to OSPF version 2, Request for comments 3630, 2003. T. Miyamura, D. Shimazaki, S. Arakawa, Y. Koizumi, S. Kamamura, K. Sasayama et al., Experimental demonstration of adaptive virtual network topology control mechanism based on SDTN architecture, in: Proceedings of the 39th European Conference and Exhibition on Optical Communication (ECOC), 2013, pp. 1–3. J.S. Choi, Design and implementation of a PCE-based softwaredefined provisioning framework for carrier-grade MPLS-TP
[13] [14] [15] [16]
[17]
[18] [19]
9
networks, Photonic Network Communications, 2014 doi: 10.1007/ s11107-014-0472-0. J.P. Vasseur, J.L. Le Roux, PCEP protocol, RFC 5440, Mar 2009. 〈http://sourceforge.net/projects/libpcep/files/〉. 〈http://sourceforge.net/projects/openlldp/〉. IEEE Standard Local and Metropolitan Area Networks, station and media access control connectivity discovery, IEEE Std 802.1AB-2005, 0_1-158, 2005 http://dx.doi.org/10.1109/IEEESTD.2005.96285. S. Huang, K. Kitayama, F. Cugini, F. Paolucci, A. Giorgetti, L. Valcarenghi, P. Castoldi, An experimental analysis on OSPF-TE convergence time, in: Proceedings of SPIE 7137, Network Architectures, Management, and Applications VI, 713728, november 19, 2008. A. Farrel, D. King, Unanswered questions in the path computation element architecture, RFC 7399, October 2014. F. Pakzad, M. Portmann, W.L. Tan, J. Indulska, Efficient topology discovery in software defined networks, in: Proceedings of the 8th International Conference on Signal Processing and Communication Systems (ICSPCS), December 15–17, 2014, pp. 1–8.
Please cite this article as: J.S. Choi, et al., Design and evaluation of a PCEP-based topology discovery protocol for stateful PCE, Optical Switching and Networking (2015), http://dx.doi.org/10.1016/j.osn.2015.09.006i