BITS, short for Bunch of Interconnected Technology Stuff, is an inter-institutional collaboration providing a shared environment for academics, resource sharing, research, and exploration.
It currently includes Corning Community College (via the LAIR), SUNY Geneseo (via the DSLAB), SUNY IT, and hopefully GST BOCES (at their Bush Campus).
In many ways, BITS is a research network. The different endpoints will each have people, and perhaps a greater significance of focused expertise… Geneseo generally has been more involved with cluster and visualization programming… the LAIR has seen more infrastructural and resource establishment… and SUNY IT utilized BITS in one of their student's graduate projects.
BITS as a project is an evolution of an evolution. The core idea for this started with Homma Farian at SUNY Geneseo's Distributed Systems Laboratory (DSLAB), which provided interested students the opportunity to learn more about systems administration and distributed systems.
In 2005, the first instantiations of the LAIR came into being, which were initial attempts at offering High-Performance Computing resources to students at Corning Community College.
By 2007, CCC was preparing to offer a High-Performance Computing curriculum as a concentration in its new Information Technology program, and the LAIR and DSLAB were enjoying an informal but growing collaboration. SUNY IT expressed interest and soon became a third endpoint in this shared universe.
In April of 2008, at SUNY Geneseo's G.R.E.A.T. Day and CCSCNE 2008 at RIT, two joint LAIR/DSLAB students posters were presented.
In May of 2008, BITS resources were used by Jeffrey Wells, a SUNY IT Computer Science graduate student, in his thesis on “Heterogeneous Grid Design and Implementation”.
In April of 2009, at SUNY Geneseo's G.R.E.A.T. Day, a joint LAIR/DSLAB student poster was presented on “Data Compression”.
Currently 3 sites/endpoints (of varying levels of activity) exist:
The intention of the collaboration is to establish availability to resources and scenarios that might otherwise not be as feasible or possible at one particular endpoint. We focus on establishing localized BITS “bubbles” at each location, so this environment should not have any conflicts with local efforts (or even other collaborations).
This way, we can explore things like BITS-wide user authentication, and have common means of resource access. There's also the prerequisite of trust- the aim is not to consider the other endpoints untrustworthy… but instead to assume they're here to participate and collaborate as well, so welcoming exploration is preferred (also why we have local “bubbles”, to avoid any existing bureaucratic concerns).
Although by no means required, Linux and other Open Source operating systems (such as OpenBSD) are preferred. Also, the utilization of Open Source software is recommended to avoid any entangling legal issues.
The intent is for all endpoints to have the ability to access and utilize resources, both local and remote (ideally with more and more transparency being introduced over time so the location of resources is not as noticeable). There currently exist some authentication and network structures used to coordinate resources between the endpoints.
What's important is that all these details are not set in stone… change is welcomed, but any change must come with the willingness to see it implemented BITS-wide… also part of that trust… access to remote resources could be granted to see new resources implemented.
For example, some exploration in Geneseo now may see a change to our backbone VPN (currently we use OpenVPN, but OpenVPN doesn't play nice with mobile devices)… they're looking into OpenSWAN which does more of a PPTP/L2TP connection. If they get that all figured out, we could see that implemented to all the BITS-endpoints.
Documentation is also very important. On the Lab46 web-server, a wiki is deployed which serves as both an information resource for my students, as well as BITS resources. Students in Geneseo contribute to it, and it has been very helpful in keeping tabs on on-going work, projects, or just sharing ideas.
All end-points will have access to the Lab46 wiki, and will each get a specific namespace to use.
Even though some information may be segmented to a particular endpoint, because it is all part of the same wiki, searching for information provided by anyone at any endpoint is possible. Plus, the wiki (utilizing the dokuwiki software) uses plain text files to store wiki content, so organizational changes to wiki structure can be performed quite easily.
There also exists an irc server in the LAIR, in which the Geneseo students also participate (Geneseo also has an internal irc server on their end of the BITS network, giving us the opportunity to explore joining irc channels).
The LAIR has a mail server providing SMTP and IMAP4 services, which will hopefully be extended to all endpoints at some point in the future.
Also, the wiki, while currently centralized in the LAIR, will hopefully be synchronized and made available locally at all endpoints, providing load balanced access to documentation.
We're currently using a 10.x.y.z style networking scheme… each endpoint receives a unique “x”, and then has complete control over how to delegate their “y” and “z” ( /16 ).
The LAIR uses 10.80.y.z, and currently has 3 /24 subnets:
The DSLAB uses 10.81.y.x, and currently has 2 /24 subnets:
SUNY IT has 10.82.y.x, and has 1 /24 subnet:
GST BOCES Bush Campus will have 10.83.y.x.
Each end-point connects over an OpenVPN connection to create a “backbone” network (basically a network connecting all the BITS routers), currently a 10.10.10.x:
So each router has a minimum of 2-3 interfaces:
Each router currently provides firewall, NAT, VPN, DNS, DHCP services… and the routers synchronize routes via OpenBGPD (the OpenBSD-enhanced routing daemon).
Because the LAIR has been the party generally rolling out the routers for the other endpoints, OpenBSD has been the predominant OS used (secure by default, helping to keep the “less trusted outside world” at bay)… plus, the PF packet filter is really darn nice. This isn't required, however… SUNY IT was running FreeBSD… and the existing OpenBSD routers are of differing releases. In the end, the above-listed services should be provided.
Additionally, traffic from one BITS network to another, especially if providing a BITS-wide resource, is trusted. If there were specific efforts underway (such as any cyber-security efforts), those resources could be isolated in specific subnets and locked down as appropriate.
The intent is for each BITS endpoint to make available resources that can be utilized by other BITS users, from any point in the BITS “universe”…
To join, the first step is to have a router in place to join the backbone network. This is accomplished by establishing an OpenVPN connection to an existing BITS backbone network router, and running OpenBGPD to handle all route transactions.
Certificates and configuration files will be provided.
To provide experience working with DNS, and providing a convenient means of accessing resources, we run our own private DNS zones within BITS to facilitate access.
If the endpoint has a popular name (such as “LAIR” or “DSLAB”), that is recommended for use as the BITS domain. All end-points currently use the “.lan” top-level domain.
As resources are brought on-line, redundant resources at each endpoint should be given particular names.
The idea behind BITS is to play and have fun learning. With collaboration, the potential to play with other toys and experiment with new scenarios (local area, wide area, different networks, different resources).
Although we may informally be out to take over the world, this is not meant as a precursor for creating a formal grid or huge collaboration. BITS has benefit from the generally rural and small-town mentalities of its member end-points, giving these individuals and groups the ability to play and explore and implement without some “large majority” trying to run the show or conform for some purpose of receiving a grant.
While applying for grants is not outside the scope of BITS, care should be taken to ensure we do not sell our soul in the process of engaging in such activity. First and foremost, this is an environment for people to play, learn, and explore, and all efforts should be taken to ensure that mentality persists (while also considering certain organizational structures to ensure this fun happens at a BITS-level, and not just some pocket of a particular endpoint– hence the VPN, DNS, wiki, and communication/network structures).