In this chapter, we address the concerns of Vendors, Betasite users and network administrators as discussed in chapter 2.
3.1 To satisfy concerns from Vendors
Solutions to the first concern: Array of test zones
Figure 3: Structure of IPv6 Betasite
Figure 3 shows the IPv6 Betasite network topology, which provides seven test zones.
To ensure adequate hardware support for IPv6, 24 stackable and 2 chassis based switches have been deployed. We have about 20 prefixes with 64-bit prefix length.
All prefixes are in the range of 2001:f18:113:/48. Each zone provides a unique test environment for testing network devices depending upon their capability and requirements. There are more than 1000 IPv6 users in the dormitory network which comes to zone 2, zone 3 and links to the Ethernet switch and wireless access points. Then it passes through the Core Router in zone
10
4 to access ISP and TANET. IPv6 users in zone 1 generate diverse and complex traffic as they use different operating systems and access wide range of applications and services.
This traffic is captured in zone 5 and replayed in zone 7 for troubleshooting and debugging DUT defects. Packet sniffing is performed in zone 5 to serve two purposes. One reason is to capture and store IPv6 traffic and another reason is to test devices in offline mode.
We use a high performance interface card (DAG card) to capture and store the mirrored packets from Betasite core router. Unlike regular network interface cards, the DAG cards are optimized for sustained performance under extreme load conditions. We make use of a content filter to test devices in sniff mode. In our IPv6 Betasite, we test wide variety of IPv6 supported network devices such as core routers, layer 3 switches in zone 4, IPS/IDS, residential gateways in zone 6 and SOHO routers in zone 7. Apart from that we also provide customized environments for testing network devices that are not in current Betasite architecture.
Solutions to the second concern: Debugging
We provide customized environment in Betasite depending upon the needs of the vendor to debug the newly created functions. Moreover, we also provide traffic to the vendor in case he is performing a private debug operation. The ultimate purpose of providing this traffic is to enable the vendor to carry out the relevant DUT debugging operation. To exercise our control in this operation, the traffic provided is anonymized thereby preventing the misuse of this facility by the vendor.
3.2 To satisfy concerns from Betasite users
Solutions to the third concern: Easy migration to IPv6
Figure 4 shows part of our campus network topology which includes more than 1000 users located in the dormitories. Majority of the users employ those systems which have built-in IPv6 support. For them, access to IPv6 is provided by employing routers that have dual stack support. The preferred mechanism for interoperation with legacy nodes is to use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6 to communicate to IPv6 nodes. Users get IPv6 address through stateless address autoconfiguration mechanism configured in layer 3 switches.
Routing for the dual stack model is set up using RIP, OSPF, BGP protocols for IPv4 and RIPng, OSPFv3 protocols for IPv6.
11
R2
Dorm 2 Dorm 1
Dorm 3
S1
S2
S3
S4 R1
R1, R2: Routers S1...S4: Switches
Dual stack IPv4-only
VRRP Group S5
Figure 4: NCTU Campus network topology
Solutions to the forth concern: Access to IPv6 enabled services
Betasite allows the users to gain seamless access to several IPv6 applications such as:
Web, P2P, FTP, SSH, Telnet and others. One of the special services that we provide to IPv6 Betasite users which is exclusively because of IPv6 is Internet Protocol Television service, called IPTV. The process of how a user gets access to IPTV service is described below.
Figure 5: IPv6 Multicast packet transmission in IPv6 Betasite
12
Figure 5 shows multicast packet transmission in IPv6 Betasite. After installing VLC media player on the source as well as clients, streaming of video can be started to a source specific multicast group using VLC. PC running Ubuntu is used as a Multicast Source while Protocol Independent Multicast (PIM) routing is enabled on the betasite core router that enables the IPv6 hosts to join a network wide multicast group. With MLD snooping enabled on layer 2 switches, we control the distribution of multicast traffic only on those ports that are actively listening. To receive a particular multicast data stream, hosts join IPv6 multicast groups by sending an unsolicited MLD report to Betasite core router. In response to a snooped MLD report, the switch creates an entry in its Layer 2 forwarding table for the VLAN on which the report was received. When other hosts that are interested in this multicast traffic send MLD reports, the switch snoops their reports and adds them to the existing Layer 2 forwarding table entry.
Betasite core router is responsible for replicating the source content and forwarding it to multiple recipients. It uses the PIM protocol to build distribution trees for multicast routing in the network and Reverse Path Forwarding (RPF) techniques to ensure content is forwarded to the appropriate downstream paths without routing loops.
3.3 To satisfy concerns from Network Administrators
Solutions to the fifth concern: Speedy Network recovery
As shown in figure 2, there are two layer 3 switches for each dormitory. For continuous connectivity, automatic network recovery and auto redirect traffic, every layer-3 switch is connected to both R1 and R2. Network recovery is achieved by using the Neighbor Unreachability Detection mechanism provided by Neighbor Discovery (ND) protocol. This is done by sending unicast Neighbor Solicitation messages to the neighbor host. By this process, it will take a host about 38 seconds to learn that a router is unreachable before it will switch to another default router. While testing devices in zone 6, a bypass switch modified for IPv6 usage is used for network recovery. It contains an editable heartbeat packet in which we fill IPv6 values to test the DUT status. The bypass switch periodically sends heartbeat packets to check whether the DUT can forward the heartbeat packets back to it, and this period is determined by a configurable timer. When the number of lost heartbeat packets exceeds a threshold decided by a configurable counter, the bypass mode is turned on thereby recovering the network.
13
Solutions to the sixth concern: Status reporting and maintenance team
The success of application of Betasite is monitored by the following feedback mechanism.
It involves instantaneous report of the status of the on-going operations through a student club, known as Network Benefit Association, who are the actual beneficiaries of this plan. Further, there is a separate maintenance team which handles the technical aspects associated with the execution of this plan.
14