Basic Information

Physical location: GS748

IPv4 address: 128.196.203.35

Hardware: dual Xeon E5-2680 @2.70GHz, 128GB memory, 8TB disk

Operating system: Ubuntu Server 12.04, 64-bit

How to connect from a CS machine

ssh maestro

How to connect from a non-CS machine

Add these to your ~/.ssh/config:

Host lectura
        User csusername
        HostName lectura.cs.arizona.edu

Host maestro
        User csusername
        ProxyCommand ssh lectura nc maestro 22

Replace csusername with your CS username.

Usage

You may run apps directly on the machine without root privilege. Common compilers and tools are installed, including: build-essential flex bison gdb valgrind default-jdk libboost1.48-all-dev texlive-full gnuplot imagemagick nodejs. Other specific packages include: ccnx dependency (libpcap-dev libexpat1-dev libssl-dev), ns-3 dependency (libc6-dbg libopenmpi-dev openmpi-bin libxml2-dev libdb-dev libbz2-dev), ndn-cxx dependency (libsqlite3-dev libcrypto++-dev), linear programming (glpk-utils). MATLAB is installed in /usr/local/MATLAB.

You may create virtual machines on VirtualBox, and run apps inside VMs. Root privilege is available in all VMs. Performance penalty due to virtualization is less than 5%.

Storage

The machine has one 4TB SAS disk, and one 4TB SATA disk. SAS disk is faster than SATA disk.

IO intensive virtual machines (such as those used for software development) should be stored on SAS disk (eg. in home directory).

Large datasets and CPU intensive workloads should be stored on SATA disk (/data1). Contact sysadmin if you need a folder on SATA disk.

Virtual Machines

Virtual machines execute in your user account as VBoxHeadless processes.

Automated provisioning with Vagrant

Vagrant is installed for automated VM provisioning.

If you choose to use Vagrant, please ensure all forwarding ports numbers are in your assigned range. To change SSH host port, add this line to Vagrantfile: (replace 88888 with sshhostport, a port number in your assigned range)

config.vm.network :forwarded_port, guest: 22, host: 88888, id: "ssh"

Host port number assignment

Every user is allocated 200 host port numbers. You may use any of your port numbers as the forwarding port. These port numbers are reachable from localhost only.

Current assignments are:

• bzhang, 30000-30199
• shijunxiao, 30200-30399
• yic, 30800-30999
• shravanaras, 31600-31799
• jenkins, 31800-31999
• rym, 32000-32199
• enewberry, 32200-32399
• weiweiliu, 32400-32599
• spencerlee, 32600-32799
• klaus, 32800-32999
• shuoyang, 30400-30599
• zhuoli, 30600-30799
• philoliang, 31000-31199
• marahman, 31200-31399
• chghasemi, 31400-31599

How to connect from maestro host machine or another VM

Add these to your ~/.ssh/config:

Host vmname
        User vmusername
        HostName maestro
        Port 88888
        LogLevel quiet
        StrictHostKeyChecking no
        UserKnownHostsFile /dev/null

Replace vmname with the name of your VM. Replace vmusername with the username inside a VM which is typically vagrant. Replace 88888 with the SSH forwarding port of your VM.

How to connect from a CS machine

Add these to your ~/.ssh/config:

Host vmname
        User vmusername
        ProxyCommand ssh maestro nc localhost 88888
        LogLevel quiet
        StrictHostKeyChecking no
        UserKnownHostsFile /dev/null

Replace vmname with the name of your VM. Replace vmusername with the username inside a VM which is typically vagrant. Replace 88888 with the SSH forwarding port of your VM.

How to connect from a non-CS machine

Add these to your ~/.ssh/config: (you also need the snippet from "Basic Information" section above)

Host vmname
        User vmusername
        ProxyCommand ssh maestro nc localhost 88888
        LogLevel quiet
        StrictHostKeyChecking no
        UserKnownHostsFile /dev/null

Replace vmname with the name of your VM. Replace vmusername with the username inside a VM which is typically vagrant. Replace 88888 with the SSH forwarding port of your VM.

If you have an account on dyadis, you may write ProxyCommand as "ProxyCommand ssh csusername@dyadis.cs.arizona.edu nc maestro 88888" for better performance.

How to share a VM with other user

Create a user inside the VM. Other user can connect to the VM by means described above.

System Updates

You are responsible for system updates on the virtual machines.

Windows virtual machine

To create a Windows virtual machine, follow these steps:

1. vagrant box add /opt/vmapi/osimage/vagrant-Windows10-Enterprise-32bit/20160202.box --name win10-20160202
2. Create a directory for virtual machine configuration, and cd into the directory.
3. vagrant init win10-20160202
4. Modify Vagrantfile:

   config.vm.network :forwarded_port, guest: 3389, host: 88888, id: "rdp"
   config.vm.network :forwarded_port, guest: 5985, host: 88888, id: "winrm"

   Substitute 88888 with two different ports in your assigned range.
5. vagrant up
6. You may now connect to the virtual machine with Microsoft Remote Desktop app.
7. Activate Windows with Windows 10 Enterprise product key

Problem Statement: Present-day networks are designed and operated to carry most traffic in the most reliable way without considerations of energy efficiency. A network usually builds many redundant links and aggressively over-provisions link bandwidth to accommodate potential link failures and traffic bursts.  This increases network reliability but also greatly reduces network's efficiency.

Idea: When there are multiple source-destination pairs and the traffic volume on each path is low, one can move traffic to a fewer number of paths so that the other paths do not carry any traffic for an extended period of time. 

Challenges: Network-level solutions require network-wide coordination of routers which, poses following challenges:

1. How to manipulate routing paths to make as many idle links as possible to maximize the power consumption?
2. How to achieve power conservation without significantly affecting network performance and reliability?

GreenTE is a power-aware traffic engineering mechanism that reduces network power consumption while still maintaining network performance at desired levels.

Network usage has evolved to be dominated by content distribution and retrieval by users. But the networking technology still speaks only of connections between hosts. To carry the Internet into the future, a conceptually simple yet transformational architectural shift is required, from today's focus on where -- addresses and hosts -- to what -- the content that users and applications care about. NDN moves the universal component of the network stack from IP to chunks of named content.

Routing and Strategy in NDN 

Overview: Goals

• Scalability: support large number of nodes, links, and names.
• Security: provide integrity, provenance, and pertinence of routing messages.
• Robustness: detect and recover form network problems quickly.
• Efficiency: use network resources efficiently.

Roles:

• Routing handles topological changes, focuses on scalability and security.
• Forwarding strategy handles churn, focuses on robustness and efficiency.

Link State Routing 

• Extend OSPF for name-based routing
• Name opaque LSAs to announce name prefixes
• Adjacency opaque LSAs to advertise links between NDN routers
• Scale by aggregation
• Map application names to ISP-assigned name prefixes
• Global routing is done based on ISP-assigned name prefixes
• Local Networks: Bootstrapping edge nodes connectivity
• When an end host boots up, it needs to learn the network environment

Routing Security

• Every routing element is named e.g. Autonomous Systems, Routers, Processes, Interfaces, etc.
• Routing updates are signed Data packets

Forwarding Strategy

• NDN enables adaptive forwarding decisions.
• Observe the delivery performance at data plane by matching returned Data and pending Interests.
• Detect problems at the time scale of round-trip time.
• Explore alternative paths without worrying about loops.
• Handle problems such as link failures, prefix hijacking, congestion, etc.
• Design and evaluation of different adaptive forwarding strategies.

Status and Plan

• Local bootstrapping program
• To be released in coming months
• OSPF name routing
• Based on Quagga, under testing, first release planned for coming months on NDN testbed.
• Forwarding Strategy
• Simulation based study
• Routing Security
• Basic design; intra-domain implementation first.

Announcement

1. Existing Node

           1.1.1.1 change node type to REAL_NODE

            Get node's nearest IN_FIB ancestor

           1.2.1.1 change node's selected_nexthop,original nexthop,merged_nexthop to new announced nexthop

           1.2.1.2 get nearest IN_FIB ancestor.

           1.2.1.3 update subtree of the node by using almost the same algorithms as aggregation part. The difference is when one node

                   is added into FIB, the new one will try to aggregate it with its sibling node.It will use the nearest IN_FIB ancestor to decide whether one node will be

IN_FIB or NON_FIB.

           1.2.1.4 aggregate current node with its sibling nodes if they're adjcent and have the same selected_nexthop

Get node's nearest IN_FIB ancestor.

             1.2.1.1 Node is FAKE_NODE

                  1.2.1.1.1 change node to REAL_NODE

                  1.2.1.1.2 Update Fake node in the sub tree of this node.When doing this, FAKE_NODE and TMP_NODE's original nexthop,merged_nexthops will be updated and the algorithm will stop at REAL_NODE with updating its merged_nexthops to its original nexthop.

                   1.2.1.1.3 Update current node's merged_nexthops

                   1.2.1.1.4 update subtree of the node.

                   1.2.1.1.5 aggregte current node with its sibling nodes if feasible

             1.2.1.2 Node is TMP_NODE

                    1.2.1.2.1 Change node type to REAL_NODE

             1.2.1.3 Node is REAL_NODE

                     do nothing

              Get node's nearest IN_FIB ancestor.

              1.2.2.1 Node is FAKE_NODE

                    1.2.2.1.1 Change node to REAL_NODE

                    1.2.2.1.2 Change node's original nexhop to new one

                    1.2.2.1.3 Update FAKE_NODE and TMP_NODE in the subtree of this node.

                    1.2.2.1.4 Update Current node's merged_nexthops

                    1.2.2.1.5 Update subtree of the node

                    1.2.2.1.6 aggregate current node with its sibling nodes if feasible 

              1.2.2.2 Node is TMP_NDOE

                     1.2.2.2.1 Change node to REAL_NODE

                     1.2.2.2.2 Change node's original nexhop to new one

                     1.2.2.2.3 Update FAKE_NODE and TMP_NODE in the subtree of this node.

                     1.2.2.2.4 Update Current node's merged_nexthops

                     1.2.2.2.5 Update subtree of the node

                     1.2.2.2.6 aggregate current node with its sibling nodes if feasible 

              1.2.2.3 NODE is REAL_NODE

                     1.2.2.3.1 Change node's original nexhop to new one

                     1.2.2.3.2 Update FAKE_NODE and TMP_NODE in the subtree of this node.

                     1.2.2.3.3 Update Current node's merged_nexthops

                     1.2.2.3.4 Update subtree of the node

                     1.2.2.3.5 aggregate current node with its sibling nodes if feasible 

2. New Node

2.3.2 update subtree of this node

           2.4.1 Update FAKE_NODE and TMP_NODE in the subtree of this node.

           2.4.2 set Current node's merged_nexthops

           2.4.3 Update subtree of the node

Withdrawl

    1.1 Get nearest IN_FIB ancestor

    1.2 IF node is IN_FIB, remove node from FIB

    1.3 Get nearest REAL_NODE

    1.4 set node's original_nexthop

          1.4.1 if nearest REAL_NODE exist and its prefix length larger than nearest IN_FIB ancestor prefix length, set node's original_nexthop as nearest REAL_NODE's.

          1.4.2 else set it as the nearest IN_FIB ancestor's.

   1.5 set node's selected_nexthop as -1

   1.6 set node's merged nexthop as the new original nexhop

   1.7 update subtree of this node

   1.8 aggregate current node with its sibling nodes if feasible recursively

   1.9 if node is NON_FIB,nearest IN_FIB ancestor is TMP_NODE and nearest IN_FIB ancestor original_nexthop is -1, recursively de-aggregate nearest IN_FIB

ancestor until nearest IN_FIB ancestor is REAL_NODE or is NULL. This step is for not inserting NULL node at root. Because if we do not de-aggregate those TMP_NODE,we'll

introduce extra routing space.

   2.1 Get nearest IN_FIB ancestor

   2.2 If node is IN_FIB, remove node from FIB

   2.3 Update FAKE_NODE, TMP_NODE in subtree of this node

   2.4 set node's original nexthop by using the same algorithms as Leaf node case

   2.5 Set nod's merged_nexthops

   2.6 update subtree of this node

   2.7 aggregate current node with its sibling nodes if feasible recursively

   2.8 deaggregate nearest TMP_NODE ancestor the same way as leaf node case.

Applying the detection algorithm to BGP updates collected by RouteViews Oregon monitor from 2003 through 2009, we identify five to twenty large route leaks every year. They typically hijack prefixes owned by a few tens of other networks, last from a few minutes to a few hours, and pollute routes at most vantage points of the data collector. In particular there are nine events detected in 2009 and six in 2008, none of which was mentioned on operator mailing lists such as NANOG, but all are confirmed through our communication with operators of affected networks.

The system can take real-time BGP data feed and conduct the detection quickly, enabling automated response to these attacks without requiring authoritative prefix ownership information or human intervention. This is important for all networks to protect their data traffic before the attack can be resolved.

The following table lists the large route leak events detected from 2003 through 08/12/2010 using data from RouteViews Oregon collector. 

2010:

2009:

2008:

2007:

2006:

2005:

2004:

2003:

• Beichuan Zhang

Students

Alumni

• Xin Zhao (MS)
• Michael Qing Ju (MS)
• Arun Madhavan (MS)
• Kyuhan Nam (MS)
• Kevin Luikens (BS)
• Varun Khare (PhD)
• Cheng Yi (PhD)
• Junxiao Shi (PhD)
• Gregory Lutostanski (PhD)

eFIT: enabling Future Internet innovations through Transit wire

History has shown that the essential value of the Internet does not lie on any particular protocol or application, but rather on the Internet's overall ability to enable innovations. The Internet has nurtured fantastic innovations that contributed to the welfare of the global society. Furthermore, Internet innovations are driven by the global user community and many of the innovations were not envisioned by the original Internet designers. If past history provides any lesson, it is that we cannot hope to predict a priori what new Internet innovations the next ten years may bring, but we know they will come as long as the global user community can be provided with a nurturing and enabling environment. Therefore we believe the foremost objective of the Internet architecture is to enable and facilitate future innovations over the Internet.

However the universal connectivity provided by the Internet is facing major challenges in sustaining user innovations. The current Internet architecture provides end-to-end connectivity by putting both network users and Internet service providers (ISPs) in the same address space and routing space. Not only has this architecture been eroding over the years, as demonstrated by the prevalent use of NAT which has been a roadblock to universal connectivity, but the architecture also created mutual constraints on both parties to explore their own innovations, as demonstrated by the slow adoption of new technologies such as IPv6, IP multicast and so on.

User networks and ISPs have different purposes, distinct characteristics, and are moving in almost opposite technological directions. However, they are tightly bundled together in the current architecture. We posit that the inter-dependency between network users and ISPs imposed by the existing architecture creates a major roadblock to future Internet innovation. As shown in the evolution of many natural and man-made systems, when a system grows larger in size by orders of magnitude, a change in form becomes necessary.

We propose a new Internet architecture design, eFIT, to achieve the objective of enabling future innovations by ensuring strong universal connectivity at the architectural level. eFIT places user networks and provider networks in different address spaces and routing spaces, removing the inter-dependency between the two worlds. With eFIT, users can treat the transit core of the Internet as simply a "transit wire" with strong universal connectivity, and providers are insulated from the various problems caused by explosive growth in user networks. Therefore both users and providers will be able to innovate freely on their own without any architectural constraints.

WIT: A Watchdog System for Internet Routing

The current Internet lacks defense mechanisms against false routing announcements, which can be caused by either malicious attacks or inadvertent operational mistakes. A well publicized example is the recent hijacking of YouTube's IP prefix by Pakistan Telecom [1, 2 ] in Feburary 2008. In this project we develop a monitoring system to detect false routing announcements and mitigation mechanisms to help operators take quick actions.

• Cyclops: Open Eye to Your Net
• "Safeguarding Data Delivery by Decoupling Path Propagation and Adoption," Mingui Zhang, Bin Liu, Beichuan Zhang, INFOCOM mini-conference, 2010
• "Understanding Resiliency of Internet Topology Against Prefix Hijack Attacks," Mohit Lad, Ricardo Oliveira, Beichuan Zhang, Lixia Zhang, International Conference on Dependable Systems and Networks (DSN), 2007
• "PHAS: A Prefix Hijack Alert System," Mohit Lad, Dan Massey, Dan Pei, Yiguo Wu, Beichuan Zhang, Lixia Zhang, USENIX Security Symposium, 2006

GreenNet: Energy Management for Network Infrastructure

On today's Internet, energy management is becoming an integral part of end hosts such as servers, personal computers and mobile devices, but the underlying network infrastructure, namely routers, switches and other network devices, still lacks effective energy management solutions. Currently the Internet Service Providers build and operate networks for maximum service availability, resulting in low energy efficiency since network devices are up all the time at full capacity. There are great opportunities to improve network energy efficiency, as well as great research challenges in how to maintain the quality of service at the desired level. In this project, we will measure and profile energy consumption of network devices, design novel routing techniques and energy management mechanisms for routers, and investigate potential cooperation between Internet Service Providers and Content Providers to achieve overall energy efficiency.

Internet Topology and its Evolution

The Internet has been evolving rapidly over time like a living organism, and so has its network topology. The evolution of the global Internet topology is the result of the interplay between many economic, technological and operational factors. In this project, we characterize the Internet topology and its evolution through empirical studies, develope theoretical models to understand the driving forces, predict topology in the forseeable future based on recent trends, and evaluate its impacts on routing architecture and protocol design.

BGP Routing Dynamics

The Border Gateway Protocol (BGP) is the de facto inter-domain routing protocol, which glues tens of thousands of network domains into what we know as the Internet. Due to the large scale of the system, the diversity of routing policies and the complexity of network operations, inter-domain routing in the wild is still not well understood. We analyze BGP routing data to understand routing stability, help identify and diagnose problems.

PSKI, a Public Space Key Infrastructure

Different from traditional public key infrastructures, which requires all participants to agree upon a hierarchy for trust delegation, PSKI doesn't enforce any rigid structure. PSKI makes user actions public to other users, take user feedbacks and make them public as well. We hope that the large number of users and the large amount of feedbacks can form a dynamic reputation system, which will help users make their trust decisions.