NEXT GENERATION NETWORK (NGN) AVAILABILITY & RESILIENCE RESEARCH Progress Report No. 3 A Case Study on Simulation Scenario The University of Canterbury Team 21 December 2005
Progress Report This report presents a case study (in OPNET) on checking NGN resilience related functionalities in simulator in a step by step fashion. It describes the basic simulation scenario, parameter setting and expected results. It is also used as the basic simulation scenario for the future simulators survey work. Here we simplify the network scenario e.g., the numbers of core, edge, customer nodes, applications, traffic and link capacity etc. There are two main reasons behind it, the first one is easy to check the essential functionalities in different simulators and present a survey within a short time period. The second reason is that it is expected to explore some generic features based on a small picture of whole large real network with a reasonable scaling schemes. (Can we do this i.e., zoom in the real network?) The following figures come from OPNET. 1.Generic Topology Setup The basic scenario involves configuration of simple core network with attached end nodes as show in Figure 1. 1.1 Nodes Figure 1 Generic topology setup The core network consists of 5 nodes, which are node_0 to node_4. They are all IPbased routers. The another four end users are named respectively as httpuser, voiceuser1, SERVER, voiceuser2, which are all workstations. 1.2 Links
Figure 2 Link setup As shown in Figure 2, within the core, the links are represented by bidirectional DS1 (1.544 Mbps) connectors. At the edges the end-stations are attached via DS3 (44.736 Mbps). The links are selected for the purpose of preventing any bottlenecks in the access points that could impact the results of endto-end application performance. The main focus is turned to effects that can be experienced by the traffic in the core so that any side effects at the access parts are undesired. The design of links and traffic loads are interconnected to obtain proper simulation objectives. Question: Is it reasonable to use DS1 and DS3 to represent STM-4 and STM-16 links in real Telecom New Zealand network? 1.3 Traffic configuration 1.3.1 Explicit traffic In the initial configuration, there is only explicit traffic configured. Http and voice applications are used in simulation as shown in Figure3.
Figure 3 Application Configuration There are two Applications, one is Http and another is VoIP. Http traffic pattern is selected as Heavy Browsing, while voice corresponds to IP Telephony and Silence Suppressed. The reason for such traffic choice is to provide two traffic patterns that exhibit different behaviors. Http traffic is TCP-based whereas voice uses UDP. Question: Does it make sense to only use this two traffic models? 1.3.1.1 Http traffic Heavy Browsing is carried with constant distributed time between page requests (with mean value of 30 minutes). To emulate user behavior more accurately there are additional parameters set. The server option is set so that the browsing user accesses many links at one site before moving to a different one. Requested pages contain one 1-kByte object and five objects of sizes 500 Bytes and other two of 1700 Bytes. The traffic is of best effort type. 1.3.1.2 Voice traffic IP Telephony and Silence Suppressed employs G.729 (silence) encoder scheme. There is one encoded voice frame filled into a voice packet before being sent by the application to the lower layers. Voice user activity is characterized in speechsilence cycles. The times voice users spend in speech or silence mode are of a constant outcome 0.65 seconds for speech and 0.352 seconds for silence. In order to provide more steady results for traffic generation, the applications start times are set to constant 200 seconds for http and 250 seconds for voice. The reason for such amount of delay is to prevent a potential routing and signaling pre-convergence inconsistency. Both users stay active until the end of simulation
course. Additionally, the voiceuser1 and voiceuser2 communicate with each other, while htttuser is connecting to SERVER. It is very important to keep the configuration constant for all simulations so that the relevant results are compared, as e.g. all the delays for the flows can be measured in adequate equal traffic conditions. Otherwise, when more users would be involved, the communication pairs and thus paths could differ, and consequently the measures (e.g. delays) for streams are not relevantly evaluated. 1.3.2 Background Traffic Further scenarios consider additional background traffic flows that are developed by IP traffic flow model. There are conversation pairs configured by mapping the flows onto the topology. End stations communicate with each other in each-to-each manner. The flows are represented as arrows in Figure 4. Figure 4 Background traffic flows mapped The flows are configured with attributes presented in the Figure 5.
Figure 5 Traffic flow configuration attributes The specific traffic pattern is defined to 500,000 bits/second, 500 packets/second and last for 10 minutes i.e. until the end of simulation. There is no need to develop more complex traffic patterns. It is used only to load the network. Moreover, the constant value can be accurately distinguished while analyzing results. Figure 6 Background Traffic flow profile For the same reasons as indicated for explicit traffic, background flows are delayed so that they start after routing tables converge. The setting is configured within simulation configuration (background traffic delay set to 300 seconds). Task 1- Please check if your simulator can implement above settings, i.e., topology, links, traffic etc. 2.Standard Internet Routing (RIP and OSPF) Result
2.1 RIP, OSPF and Traffic Distribution For comparison purpose, before we employ MPLS functions in the network, we first do some exploration on traditional routing schemes e.g., RIP and OSPF. The results will be stored as the benchmarks for the future. It is known that both RIP and OSPF contribute to congestion conditions in the network, as they aggregate traffic in the shortest paths only. OSPF performs better in the sense that it can share load among multiple shortest paths. However, still longer paths resources are left idle. The effect is presented in Figure 7. a) b) Figure 7 Traffic paths chosen according to standard routing: a) RIP, b) OSPF In case of RIP, it is seen that only two links are utilized (node_0 to node_2, node_2 to node_1). The rest are left idle. When OSPF gets employed additional two links are used. Concluding, for RIP only 2 out of 7 links are utilized, whereas for OSPF link utilization reaches 4/7. In RIP, links node_0 to node_2 and node_2 to node_1 get over-utilized very quickly whereas the rest sustain idle. For OSPF, as more links take the traffic load, congestion is decelerated while traffic increases. The effect can be pictured by showing utilization of link node_0 to node_2 in scenario with explicit and background traffic when RIP or OSPF are configured as Figure 8 and 9. Figure 8 Utilization of link node_0 to node_2 with RIP configured
Figure 9 Utilization of link node_0 to node_2 with OSPF configured Task 2- Please check if your simulator can measure utilization of each link Consequently, the bottlenecks make queuing delays on links reach intolerable values or packets even get dropped. It is evident that RIP encourages severe delays, whereas delays in OSPF case are kept on a low level for both links. In fact, delays with OSPF do not exceed 0.006 second, whereas with RIP delays go beyond 4 seconds. (For RIP there are no delays in node_0 node_3 link as there is no traffic directed through this link) as Figure 10. a) b) Figure 10. Queuing delays in network with background traffic, statistics collected on links: a) node_0 to node_2, b) node_0 to node_3 Task 3- Please check if your simulator can measure Queuing delay of
each link. Inadequate resource utilization translates not only in waste of the infrastructure costs but also into the performance of users applications. The result can be exposed e.g. in terms of voice traffic characteristics: voice packet end-to-end delay represents time it takes for voice packet to reach destination node application layer, calculated from all nodes with active voice service; voice packet delay variation corresponds to variance among end-toend delays for voice packets; We can see in Figure 11: a) b) Figure 11 Voice packet metrics (with standard routing: RIP-red and OSPFblue) for a) End to end delay; b) End to end delay variation. Task 4- Please check if your simulator can measure voice packet end to end delay and packet delay variation. 3.MPLS TE implementation In the view of shown existing routing problems e.g., lower utilization as above, further simulations intend to demonstrate TE employment by means of MPLS and its aid for troublesome shortcomings. 3.1 MPLS Setup in the Core The core nodes get updated with MPLS functionality. (LER and LSR setting up)
3.2 MPLS parameters Figure 12. MPLS setup Several general MPLS parameters need to be configured within MPLS configuration object. Fundamentally, they involve definitions of FECs, traffic trunk profiles and traffic mapping in ingress node. Their configuration depends on the considered cases and is discussed within specific scenarios. 3.2.1 FECs Configuration There are several FECs configured as below Figure 13 FECs Configuration
FEC are oriented on destination router s IP address. They can be implemented in cases when sites require tunneling their whole traffic between locations. 3.2.2 Traffic Trunk Configuration Traffic trunks are aggregates of traffic flows, referenced at [RFC2702], and their specification can be described in terms of Maximum Bit Rate, Average Bit Rate and Maximum Burst Size. They are supposed to define conditions for traffic aggregates and thus can be used while resource utilization planning and when qualitative treatment of flows is being considered. Moreover, the traffic class and action for non-conforming packets is determined. Multiple LSP can be specified for each traffic trunk and then traffic gets distributed across these LSPs. For this simulated scenario there are two traffic trunks configured as shown in Figure 14. 3.2.3 LSPs Setup Figure 14 Traffic Trunks Configuration As the main focus is turned to MPLS TE features, both static and dynamic LSPs remain of interest. Configuration of dynamic LSPs requires more attention for signaling protocol configurations, whereas static LSPs demand manual path setup. 3.2.3.1 Dynamic LSPs The dynamic LSP is mapped into network by specifying at least its ingress and egress points. Also, there can be some strict nodes and links identified on the
route that the path must pass through. It is important to note that when loose elements fails the ingress tries to find another available route with some routing schemes e.g., OSPF, but if the strict elements fail then the entire LSP fails and only backup path can be used as support, if configured. 3.2.3.1 Static LSPs Static LSPs require strict hop-by-hop configuration. The attributes associated with static LSPs involve its type as well as the nodes on the paths together with corresponding actions at specific node and assigned labels. Here we define two static LSPs as below: Primary path: Node 0, 2, 1- shortest path Backup path: Node 0, 2, 3, 4, 1- hardly found with traditional routing protocol, e.g., OSPF Figure 15 Static LSP attributes Fi 3.3 Ingress node configuration In MPLS core the ingress LERs require additional configuration as they are entrance points that should recognize and classify incoming traffic and, if relevant, direct to appropriate LSPs. Moreover, the configuration should ensure that egress point can be reached and that LSP is set up when packets destined for it arrive. First of all, we should define what FECs and from which interfaces packets ought to be mapped to adequate LSPs, e.g., in Figure 16
Figure 16 Traffic Mapping in Ingress node Task 5- Please check if your simulator can configure these MPLS features, e.g., FECs, Traffic trunks, Dynamic and Static LSPs, Traffic Mapping in Ingress node, define primary and backup path in MPLS model etc. 4 Action upon failure conditions Network failure situations cause special conditions for the network to cope with. The failure and recovery side effects become very dangerous for traffic streams when there is no other mechanism than simple routing to handle them. Therefore, MPLS feature of resiliency engineering is exposed here, as it provides great advantage and promise for proper traffic handling upon failure. In order to investigate network performance in failure conditions, the simulator should have a Failure/Recovery object can be used to introduce link/node breakdown, e.g., in OPNET, Link node_1 node_2 fails at 480 s of simulation time is failed as shown in Figure 17.
Figure 17 Define Link/Node failures In order to show effects of failure, voice application performance is analyzed. There propose to compare two scenarios i.e. with OSPF routing, another with voice traffic pushed to flow explicit way and with MPLS recovery by backup paths employment as shown in Figure 18. a) b) Figure 18 Failure recovery scenario setup: a) LSPs direct traffic through the failing shortest path links, b) MPLS recovery setup acting upon failures by means of backup LSPs, Task 6- Please check if your simulator can configure link/node failure. We expect the following results can be collected from running OSPF and MPLS scenarios with link/node failure
Re-convergence time Each link utilization Throughput of link taking over traffic from the failed link Packet loss in failure Results for voice packet end-to-end delay, delay variation and jitter. Task 7- Please check if your simulator can collect above results