Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Rspecreference


RSpec Reference

RSpec Reference

This is a systematic description of all aspects of the reference. For a formal syntactic description, see the schema.


  • GPS Coordinates -- We included the location of each node based on WGS84 standard definition of longitude and lattitude.
  • Country -- Different countries may have different laws about permissible activities on nodes. In addition, we can use the standard two-letter ISO 3166 code to distinguish them consistently.
  • City, State, Address -- We'll continue to store these in our database, but only country will go into the RSpec for now. The main rationale iss that we want the stuff in the RSpec to be 'machine readable' and this stuff is generally not - useful for humans, but hard to standardize for proper matching (eg. Salt Lake City/SLC, New York City/Manhattan, Calcutta/Kolkata, Mumbai/Bombay, etc.)


  • Contact information (name, email, telephone, shipping address) -- Each node in an RSPec contains the URN for its component manager. Therefore administrative information can be made as a separate RPC call to the component manager rather than embedding it into the RSpec.


  • Type of connection -- There will be a 'dummy' node that represents "the Internet", and there will be a link from the homenet, etc. node to it. This will have type, bandwidth, etc.
  • Bandwidth limits imposed, if any -- Not yet included
  • NAT and firewalls -- These will be represented as explicit middleboxes, exact details TBD. The node itself will have a link (type 'Ethernet', usually) to the nat/firewall, and that box will have a link to "the Internet" - this lets us also give the private and public IP addresses, and lets us represent multiple nodes behind the same NAT. The middleboxes will have some 'gateway' type, which will specify, in addition to the regular node stuff, which side is "inside", what functions that box can perform (NAT, firewalling, emergency cutoff, etc.) We're still a little fuzzy on how this will turn into XML, but have a general sense of it.
  • Reachability: Internet, I2, {other} -- Will handle this with multiple 'dummy nodes' as mentioned above for "commodity Internet"


  • Wireless Monitoring Devices (USRPs acting as spectrum analyzers) -- We added a <monitoring> tag to interfaces that could be used to tag stuff like this - probably just a simple string indicating that you can monitor it with a USRP.
  • 3 wireless devices that the users can configure in various ways -- Interfaces are explicit. So each interface can have independent configuration options.
  • Ability to get user traffic -- We added a 'user_traffic' attribute in the <monitoring> section indicating you are allowed to monitor end-user traffic on a particular interface.
  • A TV tuner / digitizer card -- Might handle this using an extension that just plops in assign's features/desires system.
  • RON nodes have BGP feeds from their local hosts in some cases -- Not sure how to handle this one, will have to talk to Dave Anderson and possibly Nick more about it.