Topology schema for VIRL, v0.9
(C) Copyright 2012-2014 Cisco Systems Inc. All rights reserved.
This optional decimal value is used to indicate the instance document's schema version compatibility, which is not necessarily the version of the schema that updated the document. VM Maestro uses this to enforce version specific changes.
This specifies the topology's layout mode. Schematic uses x/y locations, whereas Geographic uses lat/lon coordinates.
This specifies which validation rules should be enforced before sending the document to the simulation back-end. This may be as simple as warning the user about incompatibilities or missing elements (which is what VM Maestro does through visual problem markers on the graphical editor).
Note: The current list of available options for this attribute is just a suggestion, as there are currently no other implementers.
Connections define links (physical or not) between any model elements.
A connection's endpoints may be nodes, but may also be a model element within a node.
For instance, when connecting to a CRS1, it may terminate at a specific port within the platform complex.
For bi-direction connections, the target and source elements are interchangeable, but that is up to the actual model's interpretation.
The src and dst attributes are XPath expressions identifying the connection's endpoints.
Note: In the case of using pre-built components, it is possible that these refer to internal components that are not necessarily present in the document. Parsers must allow for this. (Please contact me, Dan Bourque, for suggestions on how to achieve this)
This is a temporary, optional attribute to affect the rendering of the line. Eventually, this will likely be replaced with a type or state attribute, to separate the visual from model state.
A group may contain any number of sub-groups and/or nodes, allowing us unlimited depth nesting. This effectively allows us to define arbitrarily huge topologies while allowing the UI to remain performant and intuitive.
Any string, rendered as its label in VM Maestro. It may include special characters (e.g. newline, accents, etc), but must be escape-sequenced.
Specifies the node's x/y location on a canvas, in a comma-separated x,y string.
This optional attribute might contain the node's geolocation, in a comma-separated latitude,longitude string. This is only present if the node is geographically located on a map. Otherwise, only the location attribute is needed.
This specifies the topology's layout mode. Schematic uses x/y locations, whereas Geographic uses lat/lon coordinates.
Nodes represent all edge devices on a network, and are the basic building blocks of a topology. A node may be as simple as an IP Phone, or as complex as a fully stacked CRS1.
Any string, rendered as its label in VM Maestro. It may include special characters (e.g. newline, accents, etc), but must be escape-sequenced.
This indicates the node's type, and determines which (if any) schema specific validation rules to enforce on it.
If used, this attribute indicates a more specific category of node. The list of valid subtypes depends on the back end used to simulate the topology.
Specifies the node's x/y location on a canvas, in a comma-separated x,y string.
This optional attribute might contain the node's geolocation, in a comma-separated latitude,longitude string. This is only present if the node is geographically located on a map. Otherwise, only the location attribute is needed.
This optional attribute may specify the OpenStack VM Image to use for this node.
This optional parameter may specify the OpenStack's Flavor (a.k.a. profile) to use for this node.
This optional parameter may specify the OpenStack's Volume to use for this node.
This optional attribute may specify the IPV6 address for this node.
This optional attribute indicates whether or not this node is to be skipped during the simulation launch. By default, all nodes in a topology are launched.
Nodes of type ROUTER may declare interfaces. Nodes of type VXR expose their interfaces by declaring ports within the VXR platform complex instead.
Any string. The valid format, such as GigabitEthernet0/0/0/2, depends on the parent node's subtype. This string will be rendered as a connection endpoint's label decoration in VM Maestro.
This optional attribute may specify the IPv4 address for this node.
This optional attribute may specify the IPv6 address for this node.
This optional attribute may specify the IPv4 net prefix length for this node.
This optional attribute may specify the IPv6 net prefix length for this node.
New platforms must be added here.
A generic specification mechanism is not used so that illegal platforms are detected at configuration-time rather than run-time.
When a new concrete platform object is added to the C++ inheritance for the "Platform" object, manually add it below.
ServerCard's may only go into a "server" shelf, enforced at run time by the object factory.
A lcc "Shelf" may contain "LineCard" and "RouteCard".
Note that the route cards are numbered 0 and 1 here but may be translated to a different nomenclature by the system.
A fcc "Shelf" may contain only "ServiceCard" objects.
The route card type defines the multi/single-chassis fabric architecture because the route card now controls the S123 and S13 fabric ASICs.
Although the DTD does not enforce strict legal combinations, run-time will fail if the chassis complement does not fit the route card (and service card) types correctly.
Allow Port elements on RouteCard boards even though this is not realistic as this allows for generic boards within a platform-independent context.
CRS and Topaz line cards must have a PLIM.
Panini and Scapa line cards must NOT have a PLIM and must specify the Ports within the LineCard block.
The "topaz" platform supports the "pearl" line card.
The "scapa" platform supports the "scapa_xxx" line cards.
Arch is "x86_64" or "ppc" to indicate the virtual-machine architecture or it may be another string indicating a Linux-native process model named "vxr-another_string", so arch="foo" would try to start a well-known process named "vxr-foo".
A server "Shelf" may contain only "ServerCard" objects.
Service cards are only used in fabric card chassis.
Fabric chard chassis only exist in multi-chassis platforms.
The FabricCard element can describe either a "card" or "proxy" process.
Currently, "fabric" is a Panini proxy, panini_fc and topaz_fc are VM cards, and scapa_fc is a proxy.
The slot number is not used for proxy processes.
Port vlan specifications are strings that are used to build an association table for line card connectivity.
For example, if you say vlan="foobar", eventually a vlan number (or other transport handle) is assigned and every Port that has vlan="foobar" will be on that vlan.
The connect CDATA can be "socket", "tap" or a host:port specification like "192.168.1.1:8080".
"socket" is the default if connect is not specified.
The connect attribute is not relevent for a MPI transport.
The dump attribute will add tcpdump capture of that vlan.
The "tgn" attribute is not used by VXR but is used by dev-test scripts that parse the XML.
An extensions block may be added to any abstract model object. This extensions block contains one or more entry, which is a key/value pair, allowing any metadata to be attached to any model element.
This type field will typically be any of the java.lang.* classes, such as String, Integer, Boolean, etc.
However, it may even be any custom package's class, such as com.cisco.MySpiffyClass. The only requirement is that this class's .toString() output may be used as the input parameter to the same class's constructor, in order to produce an exact copy of the original instance.
The ipv4Type data type is an xs:string of decimal digits separated by '.' (period) characters. It
represents the 32-bit dotted-decimal notation of IPv4 addresses. Valid IPv4 addresses contain a series of four
one-byte long decimal numbers (0 - 255) separated by the '.' character (a total of three '.' characters
appear). A valid value of the IPv4Address data type is "212.23.123.0". See RFC 790 in Section 2.2.2 for
further details on IPv4 addresses.
The ipv6Type data type is an xs:string of hexadecimal digits ('0'-'9' and 'A'-'F' or 'a'-'f')
separated by ':' (colon) characters. It represents the 128-bit notation of IPv6 addresses. Fully expanded
IPv6 addresses contain a series of eight two-byte long hexadecimal numbers separated by the ":" character (a
total of seven ':' characters appear). A single two-byte long hexadecimal number contains up to four
hexadecimal digits. All valid IPv6 addresses are supported in the MDL. A valid value of the ipv6Type
data type is "2001:DB8:0000:0056:0000:ABCD:EF12:1234". See RFC 2460 for further details on IPv6 addresses and
valid shorthand notations.
Space separated number. The valid format, such as 0 0 0 2, or 0 1, depends on the parent node's subtype.