Overview of the RSVP-TE Network Simulator: Design and Implementation

Transcription

1 Overview of the RSVP-TE Network Simulator: Design and Implementation D. Adami, C. Callegari, S. Giordano, F. Mustacchio, M. Pagano, F. Vitucci Dept. of Information Engineering, University of Pisa, ITALY s.giordano, fabio.mustacchio, m.pagano, Abstract In a multi-service IP network, it is a key challenge to provide Quality of Service (QoS) to end-user applications while effectively using network resources. In the last years, the DiffServ architecture has emerged as a scalable solution to provide QoS in IP networks, but, in order to optimize the use of transmission resources, this architecture must be complemented with efficient Traffic Engineering (TE) mechanisms. The MultiProtocol Label Switching (MPLS) technology is a suitable method to provide TE. The integrated use of MPLS and DiffServ is a hot topic in next generation networks. In such context, a full comprehensive simulation environment could be useful to speed up the design and the validation of new functionalities. In particular, a key issue towards the effective deployment of DiffServ/MPLS networks is represented by the enhancement in the MPLS architecture signalling protocol. In this paper, the design and the development of a new software module to simulate the RSVP-TE protocol in the Network Simulator (NS) is presented.. Introduction The explosive growth of the Internet and the convergence of communication services, such as IP telephony or VoIP, to IP-based networks, brought to life new issues in the design of next generation networks. These issues strictly depend on the side in which the interaction users network is observed. From the user perspective, end-to-end Quality of Service (QoS) should be provided to fulfil multimedia applications requirements. The basic QoS requirements are the dynamism (e.g. the service should last as long as the user needs), the tailoring (e.g. the network resources allocated for the service should exactly fulfil the end-user requirements) and a seamless integration (e.g. the mechanisms involved in QoS support should be transparent to end-users applications). From the Service Providers perspective, requirements concern the operative traffic engineering (TE) functionalities so as to manage in an optimized way the available resources and to assure service survivability, even in case of faults or dynamic network topology changes. IP networks, designed to provide a best-effort service according to a connectionless approach, are not able to meet these requirements. Hence, in the last years, many research efforts have been focused on the development of enhanced network architectures to address and solve these issues [][][]. The combined use of the Differentiated Services (DiffServ) [] and MultiProtocol Label Switching (MPLS) [] architectures seems to be an attractive solution to provide guaranteed QoS for multimedia traffic while effectively using network resources. Some MPLS architectural features, which make it appealing to support QoS and TE [][][8] functionalities, are the following: separation of control and forwarding planes, which assures scalability; constraint-based routing and explicit path forwarding, which allow an effective management of the available resources; recovery mechanisms, which guarantee service survivability in case of faults. However, as MPLS by itself cannot provide service differentiation, there is the need to complement it with another technology capable of providing such a feature. The DiffServ architecture emerges as a scalable and effective solution to address this issue [9].

2 Since a framework has been defined to integrate MPLS and DiffServ technologies [], this is an open research field and improved mechanisms towards a fully deployment of required functionalities have to be tested. In this scenario a simulation environment is useful to perform a functional assessment of the proposed approaches and to compare different solutions, reducing the complexity and the time needed to develop prototypal network devices. Unfortunately, a full comprehensive simulation environment for MPLS/DiffServ networks has not been developed yet. Therefore, our activity has been devoted to the implementation of software modules that allow the simulation of such a scenario. The starting point for our implementation is represented by the Network Simulator version. (NS) [], along with the MPLS Network Simulator version (MNS) [][] and RSVP Network Simulator (RSVP\ns) modules [][]. The focus of the paper is on the implementation of a RSVP-TE protocol module, named RSVP-TE\ns, to be used as label distribution protocol in MNS. Indeed, RSVP-TE is the most commonly implemented signalling protocol in commercial routers and several research activities, as well as IETF working groups [][], address the issues related to the extensions of this protocol to support enhanced functionalities in MPLS/DiffServ networks. Moreover, several experimental test-beds, equipped both with Linux platforms and commercial routers, adopt this solution [8][9]. The paper is organized as follows. Section describes the MPLS node architecture in the NS environment, with emphasis on the RSVP-TE control plane characteristics. Section discusses our implementation of the RSVP-TE\ns module along with the LSP management functionalities available in the simulator. Section provides a description of the tests performed for a functional validation of the developed module. Section concludes the paper with some final remarks.. MPLS node architecture The basic idea behind MPLS is to append a short fixed-length label to packets at the ingress router of an MPLS domain. Packet forwarding is then based on the assigned label and not on longest prefix address matching, as in traditional IP forwarding mechanisms. When a packet is received by an edge router of the MPLS domain, named Label Edge Router (LER), it is associated to a label on the basis of a Forwarding Equivalence Class (FEC). The packets associated to the same label traverse the MPLS network along the same path, identified as Label-Switched Path (LSP). Interior routers that perform label switching and label-based packet forwarding are called Label Switching Routers (LSRs). In order to establish, maintain and tear-down LSPs a signalling protocol, such as the Label Distribution Protocol (LDP) or the RSVP-TE protocol, has to be used. An LDP implementation is integrated in the NS MNS module. Since RSVP-TE is widely deployed in experimental and working MPLS networks and several research activities are focused on enhancing such a protocol in an MPLS/DiffServ scenario, we decided to replace the CR-LDP signalling protocol module with our own implemented RSVP-TE\ns module. The reference model of an MPLS node is sketched in figure. Note that in the MNS implementation a strict distinction between control plane and forwarding functionalities can be found. Such a feature reflects the separation between control and data planes in the MPLS architecture. For this reason, our work concerns only control plane mechanisms. RSVP-TE Messages Routing Information Packets IN Control Plane Data Plane Routing Protocol Address Classifier MPLS Classifier Label Info Base Resource Manager RSVP-TE Service Classifier Explicite Route Base Admission Control Packet Scheduler Packets OUT Figure. Reference model of an MPLS node In particular, in our simulator environment, labels distribution and allocation are performed by the RSVP-TE agent we implemented. The agent supports downstream on demand label allocation and upstream distribution. The RSVP-TE agent receives the labels by the downstream LSRs and passes them to the MPLS classifier, so that it can create the tables used for label switching. The data plane operations are the following: at first, when a packet is received by an LSR, the MPLS classifier checks if the packet is labelled. If the packet has a label or may be associated to an FEC, the MPLS classifier executes label-based forwarding, otherwise it transfers the packet to the address classifier which forwards it according to the Layer routing protocol. To perform label switching, an MPLS node in the MNS implementation handles three tables: the Label Information Base (LIB), whose entries contain incoming label, incoming interface, outgoing label and outgoing interface;

3 the Partial Forwarding Table (PFT), which contains a subset of the information written in the LIB; the Explicit Route information Base (ERB), which contains information about the Explicit- Route LSP (ER-LSP). More in detail, when a labelled packet is received by an LSR, the node retrieves the incoming label, then a table look up is performed to find the corresponding entry in the LIB. At this point, the LSR may execute two different operations. If it is an egress LER, it removes the label from the packet and then forwards it according to the Layer routing protocol, passing it to the address classifier. Instead, if it is an LSR, it replaces the incoming label with the outgoing one (Label Swapping) and then performs label-based forwarding. If the packet has to be forwarded on an explicit path, the MPLS node also uses the ERB, which is managed by the service classifier to map a flow into an ER-LSP. The PFT is used in packet forwarding only by the ingress LER. In this case, the node receives an unlabelled packet and uses the PFT to associate a label to the packet itself, which is then forwarded according to label switching mechanisms. The RSVP-TE agent we added in the MPLS node is able to perform two additional procedures: the Label Stacking and the Penultimate Hop Popping. The first one, which consists in managing multiple labels in a packet, is used to create a level of hierarchy in large networks, improving traffic flows scalability. Instead, Penultimate Hop Popping is used to simplify the operations executed on a labelled packet by the egress LER. This means that the penultimate LSR of the LSP executes label popping, instead of label swapping. Then it forwards an unlabelled packet towards the egress LER. To enable such a feature, the LIB contains additional information about the operation the node has to execute for a specific LSP. Path Messages LIB ERB MPLS Node Link Admission Control Policing RSVP-TE Resource Manager Packet Scheduler WFQ Resv Messages Figure. Resource reservation process In order to support QoS, the developed module is also able to perform resource reservation for the LSP itself. The RSVP-TE agent is responsible for this action too. The resource reservation process, shown in figure, can be summarized as follows. When a Path message is received at the ingress interface of the LSR, the RSVP- TE agent performs Admission control and Policing functions. If there are enough available resources it forwards the Path message to the downstream LSR. After Admission control and Policing operations have been performed all along the LSP, a Resv message is generated and forwarded upstream along the LSP. An LSR, when processing a Resv message, allocates resources and calls the resource manager to properly configure the queues in the packet scheduler. The scheduler used with the RSVP-TE module is the Weighted Fair Queuing (WFQ), which is already implemented in NS. Moreover, the RSVP-TE agent calls the MPLS classifier to create the corresponding entries in the LIB and PFT tables used for label switching.. RSVP-TE\ns module In this section, we illustrate the main functionalities of the developed module. RSVP-TE\ns has been implemented in compliance with the standard defined in []. The simulator functionalities can be divided in two distinct sets: the first one (see section.) concerns LSPs establishment; the second one (see section.) is about LSPs tear-down... LSP Establishment Two different commands may be used to establish an LSP: the first one is used when the ingress LER wants to establish an ER-LSP, while the second one is used when it wants to create an ER-LSP with a reserved bandwidth. <ingress-lsr> create-erlsp-rsvpte <egress-lsr> <sessionid> <FlowID> <TunnelID> <er> <ingress-lsr> create-erbwlsp-rsvpte <egress-lsr> <sessionid> <FlowID> <TunnelID> <rate> <bucket> <ttl> <er> In both cases, the Path message sent by the ingress LER contains, in addition to the classical RSVP objects, a LABEL_REQUEST object, used for requesting to the downstream nodes the allocation of the labels. The simulator allows to create an LSP that follows an explicit path by specifying in the <er> option a sequence

4 of nodes addresses. This field, if not empty, is used to create an EXPLICIT_ROUTE_OBJECT (ERO), which is added to the Path message. When an LSR receives a Path message, it performs several operations; the first ones are related to admission control and policing. Then the node processes the ERO: it inserts the ERO contents in its Path State Block (PSB) and then it looks for the next abstract node, to forward the Path message to. The insertion of the ERO value in the PSB is needed in order to assure that Resv messages follow, in the upstream direction, the same route of the Path ones. Once the egress LER has received and processed the Path message, it generates a Resv message that contains, in the LABEL object, the label value to be used by the upstream node. When an LSR receives the Resv message, the node sets a new label value to be suggested to the upstream node. Moreover, if the issued command is for an ER-LSP with bandwidth reservation, the LSR calls the Resource manager which, in turn, executes the resource allocation Subsequently, it passes the label contained in the Resv message (outgoing label) and the new label (incoming label) to the MPLS classifier, which uses them to create the corresponding entry in the label switching tables. Finally, the LSR generates a Resv message, with a LABEL object containing the value of the suggested label, and forwards it to the previous node as stored in the PSB. When the ingress LER processes the Resv message the LSP is established. Another command may be used to bind a flow to the LSP... LSP Tear down the egress LSR, after processing each ResvErr message, sends to the <downstream node> a ResvTear message, in order to release the previously allocated resources; the ingress LER, after processing each PathErr message, sends to the <upstream node> a PathTear message, in order to release the previously allocated resources; the ingress LER delete the corresponding entry in the LIB, PFT and ERB tables. After these operations, all the flows bound to an LSP that has been torn down are forwarded according to a Layer routing protocol. This allows applying different rerouting techniques.. Functional validation tests In this section we present some of the tests carried out to validate the new functionalities added to the simulator. The network topology (figure ) is quite simple, but appropriate to highlight the most important functionalities of RSVP-TE\ns. The second set of functionalities allows to tear down an LSP when a failure occurs. The following command drives the simulation of a link failure <upstream node> break-link <downstream node> <ID downstream node> <ID upstream node> The following subsequent actions, related to the handling of this event, are automatically performed: the link between the <downstream node> and the <upstream node> fails; the rsvp-agent of the <upstream node> sends, for each LSP that is established on the broken link, a PathErr message upstream, so as to notify the ingress LER of the failure; the rsvp-agent of the <downstream node> sends, for each LSP that is established on the broken link, a ResvErr message downstream, so as to notify the egress LSR of the failure; Figure : Network topology In this network scenario, nodes - are MPLSenabled, whereas nodes, and act as traffic sources, that send a data traffic stream to the nodes, and respectively. Moreover, the bandwidth assigned to each link is Mbps. In figures -9, the packets belonging to each flow are identified by the source node number. The first test is performed to verify the resources allocation mechanism along an LSP. A Constant Bit Rate (CBR) data traffic at Kbps is generated by the node and received by the node ; the links _ and _ are congested due to the traffic generated by the nodes and. According to the Layer routing protocol (OSPF) all the flows are forwarded along the same path, so that each flow experiments packet losses on the congested links.

5 Indeed, as shown in figure, the throughput of the flow is about Kbps when no LSP is established. An LSP is then set-up (t= sec) with a reserved bandwidth equal to Kbps, between the nodes and. The binding of the flow to the LSP is completed at. seconds and the throughput rises at Kbps as a consequence of a proper resource allocation process. In figure the Path message for the ER-LSP establishment through,, 9, 8,,, nodes is shown. At 8. seconds the binding of the flows to the LSP is completed and the flows are forwarded according to label switching (figure ). The subsequent phase aims at testing the fault notification mechanisms. In order to test this aspect, a fault is forced on the link _, so that node sends a PathErr message (figure ). Figure : Flow rate (src ) on link _ Figure : Label switching The second test is performed to assess label distribution and fault recovery functionalities. The network topology is the same as in the previous test and all the sources generate CBR traffic at Kbps. After. seconds of simulation, three ER-LSP are established: LSP includes nodes,, 9, 8,,, and it is associated to flow ; LSP includes nodes,, and it is associated to flow ; LSP includes nodes,, 9, 8,, and it is associated to flow. PathErr Message Path Message Figure : Path message for flow from to Figure : Failure and PathErr message After receiving the PathErr message, node sends a PathTear message downstream to release the previously allocated resources and to delete the label switching table entries associated to the LSP. As a consequence, flow from node to node is now forwarded according to the Layer routing protocol, as shown in figure 8. Figure 9 shows the throughput at node. From t = seconds to t =. seconds, no packet is received. Then, traffic flows are forwarded according to Layer routing protocol. No decrease in the received throughput can be observed, since no congestion occurs along the new path.

6 Figure 8: Situation after link failure Figure 9: Flow rate (src ) on link _ Finally, we assess the simulator behaviour, when a link, on which several LSPs are established, fails. In order to test this aspect, a link failure is forced on link _. As supposed, nodes and send respectively a PathErr and a ResvErr message. After processing the corresponding PathTear and ResvTear messages, the two LSPs (which are established on the broken link) are released and the corresponding flows are, once again, forwarded according to the Layer routing protocol.. Conclusions In this paper, we discuss the development and validate the functionalities of a new software module that implements the RSVP-TE signalling protocol in the NS simulation tool. The new module provides a complete implementation of the control plane mechanisms needed for label distribution and label binding as well as link failure handling in MPLS networks. It is relevant to emphasize that this module has been developed taking into account extensibility and flexibility issues, so that enhancements to the signalling protocol (i.e. definition of new objects) could be easily introduced. Hence, the module we implemented could be useful to plan and assess new functionalities in MPLS/DiffServ or GMPLS networks.. Acknowledgments This work was partially supported by the Euro-NGI Network of Excellence funded by the European Commission References [] X. Xiao, L.M. Ni, Internet QoS: A Big Picture, IEEE Network Magazine, March 999 [] Trimintzios, P. Andrikopoulos, I. Pavlou, G. Flegkas, P. Griffin, D. Georgatsos, P. Goderis, D. T'Joens, Y. Georgiadis, L. Jacquenet, C.; Egan, R., A management and control architecture for providing IP Differentiated Services in MPLS-based Networks, IEEE Communications Magazine, May [] Engel, T. Granzer, H. Koch, B.F. Winter, M. Sampatakos, P.; Venieris, I.S. Hussmann, H. Ricciato, F. Salsano, S., AQUILA: Adaptive resource control for QoS using an IP-based layered architecture, IEEE Communications Magazine, January [] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss., An Architecture for Differentiated Services, IETF RFC, December 998 [] E. Rosen, A. Viswanathan, R. Callon., Multiprotocol Label Switching Architecture, IETF RFC, January [] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus., Requirements for Traffic Engineering over MPLS, IETF RFC, September 999 [] G. Swallow MPLS Advantages for Traffic Engineering, IEEE Communications Magazine, December 999 [8] X. Xiao, A. Hannan, B. Bailey, L. Ni, Traffic engineering with MPLS in the Internet, IEEE Network Magazine, March. [9] B. Carpenter, K. Nichols Differentiated Services in the Internet, Proceedings of the IEEE, September [] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen, MPLS support of Differentiated Services, IETF RFC, May [] The Network Simulator vers.. (NS) Home Page [] The MPLS Network Simulator version Home Page [] G. Ahn, W. Chun Design and Implementation of MPLS Network Simulator (MNS) Supporting QoS, ICOIN- [] The RSVP module for NS Home Page index.html [] M. Greis RSVP\ns: An Implementation of RSVP for the Network Simulator ns- [] IETF MPLS WG [] IETF CCAMP Working Group [8] G. Carrozzo, N. Ciulli, S. Giordano, G. Giorgi, M. Listanti, U. Monaco, F. Mustacchio, G. Procissi, F. Ricciato,. Architecture and protocols for the seamless and integrated next generation IP networks, QoS-IP [9] D. Adami, N. Carlotti, S. Giordano, M. Pagano, M. Repeti, Performance analysis of the Control and Forwarding plane in a MPLS router, OpNeTec [] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallowl. RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 9, December