Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Rspecextensions2

Rspecextensions2

RSpec Extensions in Version 2

RSpec Extensions in Version 2

The major addition to RSPec version 2 is the ability to create and validate extensions. Extensions allow stakeholders to describe new resources and information about those resources without modifying the core RSpec. In addition, extensions can also be used to provide additional type-specific parameters or additional measurements about node usage and reliability. While extensions allow communication of additional information, it is important to remember that GENI actors which use an extension must be able to interact with those actors which do not implement that extension. This means that the information provided in extensions must be ignorable. We must also provide validation of extensions even when they are composed.

In the core RSpec specification, each element can contain any attributes or elements outside of the RSpec namespace. Each extension must be in a unique namespace different from the main RSpec namespace. It is therefore possible to validate just the portion of an RSPec document which conforms to the core specification independently of any extensions.

Anyone can define an extension by specifying a namespace for that extension and hosting a schema document. The schema document they host is independent of the core rspec schema and any other extension schema.

We use XML Document Schema Instance directives to specify which namespaces must be validated against which schemas. This allows the use of nearly every XML validator and parser currently available. The only disadvantage is that it is not possible to associate a particular symbol in the extension schema with a particular context in the RSpec schema and enforce validation. This means that it is possible for an incorrect document to allow an extension to pass validation even if it uses an element meant to extend nodes in a link context or vice versa. To make errors of this kind more evident, all extensions should prefix their start symbols with 'foo_' where foo is the context name.

Example Extension

To make this more concrete, we have created a simple extension which allows parameters to be specified when using the "gre-tunnel" link type. In particular, when setting up a GRE tunnel, the IP addresses of the endpoints inside the tunnel must currently be specified by the user.

Extension Schema:

The extension provides an "interface_ip" element to specify the addresses of the endpoints. It uses the 'interface_' prefix because the ip address should be specified in interface elements. We have constructed an example request which uses this extension. Note the 'xsi:schemaLocation' tag which specifies which schemas to use for which namespaces. Additional verification must be implemented beyond that provided by the XML parser/verifier to ensure that interfaces incident upon links of type gre-tunnel must contain addresses.

To see how extensions are implemented in the core RSpec specification, see RSpecSchema2.

Creating an Extension

We describe the process of developing an extension and creating a schema for it using bgpmux as an example. See RSpecCreatingExtension for details.