Skip to content
GitLab
Commit 93640e1d authored by Robert Ricci's avatar Robert Ricci
Browse files

Merge in ptop/vtop schema from the assign-dev branch.

parent 568bba41
Hide whitespace changes
Inline Side-by-side
assign/ptop.rnc 0 → 100644
View file @ 93640e1d
#
# EMULAB-COPYRIGHT
# Copyright (c) 2007 University of Utah and the Flux Group.
# All rights reserved.
#
#
# Description of a physical topology
#
default namespace = "http://emulab.net/resources/ptop/0.1"
include "top.rnc"
## A simple policy specification - it may end up that policy does not belong in
## the ptop file directly
TypeLimitSpec = element type_limit {
## Name of the type we are limiting
element type_name { text },
## Limit as to the number of nodes of this type the experiment can use
element type_limit { xsd:integer { minInclusive = "0" } }
}
start = element ptop {
## The testbed that this physical topology came from - will be used for
## federation
attribute testbed { text },
## Nodes in the topology - zero or more
NodeSpec*,
## Links in the topology - zero or more
LinkSpec*,
## Any limits on how many nodes of a particular type this experiment can
## use.
TypeLimitSpec*
}
assign/ptop.rng 0 → 100644
View file @ 93640e1d
<?xml version="1.0" encoding="UTF-8"?>
<!--
EMULAB-COPYRIGHT
Copyright (c) 2007 University of Utah and the Flux Group.
All rights reserved.
-->
<!--
Description of a physical topology
-->
<grammar xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" ns="http://emulab.net/resources/ptop/0.1" xmlns="http://relaxng.org/ns/structure/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="top.rng"/>
<define name="TypeLimitSpec">
<a:documentation>A simple policy specification - it may end up that policy does not belong in
the ptop file directly</a:documentation>
<element name="type_limit">
<element name="type_name">
<a:documentation>Name of the type we are limiting</a:documentation>
<text/>
</element>
<element name="type_limit">
<a:documentation>Limit as to the number of nodes of this type the experiment can use</a:documentation>
<data type="integer">
<param name="minInclusive">0</param>
</data>
</element>
</element>
</define>
<start>
<element name="ptop">
<attribute name="testbed">
<a:documentation>The testbed that this physical topology came from - will be used for
federation</a:documentation>
</attribute>
<zeroOrMore>
<ref name="NodeSpec">
<a:documentation>Nodes in the topology - zero or more</a:documentation>
</ref>
</zeroOrMore>
<zeroOrMore>
<ref name="LinkSpec">
<a:documentation>Links in the topology - zero or more</a:documentation>
</ref>
</zeroOrMore>
<zeroOrMore>
<ref name="TypeLimitSpec">
<a:documentation>Any limits on how many nodes of a particular type this experiment can
use.</a:documentation>
</ref>
</zeroOrMore>
</element>
</start>
</grammar>
assign/ptop.xsd 0 → 100644
View file @ 93640e1d
<?xml version="1.0" encoding="UTF-8"?>
<!--
EMULAB-COPYRIGHT
Copyright (c) 2007 University of Utah and the Flux Group.
All rights reserved.
-->
<!--
Description of a physical topology
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://emulab.net/resources/ptop/0.1" xmlns:top="http://emulab.net/resources/top/0.2" xmlns:ptop="http://emulab.net/resources/ptop/0.1">
<xs:import namespace="http://emulab.net/resources/top/0.2" schemaLocation="top.xsd"/>
<xs:element name="type_limit">
<xs:complexType>
<xs:sequence>
<xs:element ref="ptop:type_name"/>
<xs:element name="type_limit">
<xs:annotation>
<xs:documentation>Limit as to the number of nodes of this type the experiment can use</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="type_name" type="xs:string">
<xs:annotation>
<xs:documentation>Name of the type we are limiting</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ptop">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="top:node">
<xs:annotation>
<xs:documentation>Nodes in the topology - zero or more</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="top:link">
<xs:annotation>
<xs:documentation>Links in the topology - zero or more</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="ptop:type_limit"/>
</xs:sequence>
<xs:attribute name="testbed" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
assign/top.rnc
View file @ 93640e1d
#
# EMULAB-COPYRIGHT
# Copyright (c) 2005-2006 University of Utah and the Flux Group.
# Copyright (c) 2005-2007 University of Utah and the Flux Group.
# All rights reserved.
#
default namespace = "http://emulab.net/resources/vtop/1.0"
element top {
## Project ID
attribute pid {text},
## Experiment ID
attribute eid{text},
## Group ID (optional)
attribute gid{text}?,
## User ID owning the experiment (optional)
attribute uid{text}?,
## Nodes in the topology - zero or more
element node {
attribute name {text},
element node_type {
element type_name { text },
## TODO - Change type
element type_slots { text }?
},
element desire {
element desire_name { text },
element desire_weight { text },
element violatable { empty }?
}*,
element node_option{
element option_name { text },
element option_value { text }
}*
}*,
## Links in the topology - zero or more
element link {
text
}*
#
# Definition of common data structures used for representing topologies -
# shared between vtop (virtual topology) and ptop (physical topology)
# formats.
#
default namespace = "http://emulab.net/resources/top/0.2"
## Representation of a single node type
NodeTypeSpec = element node_type {
## Name of the type - will almost certainly not be unique
element type_name { text },
## How many virtual nodes of this type this physical node can
## handle.
(element type_slots { xsd:integer { minInclusive = "1" } } |
element unlimited { empty }),
## A flag that indicates that this physical node *always*
## has this type - a node is only allowed to have one dynamic
## (ie. not flagged as static) type at a time, but any number
## of static types at a time
element static { empty }?
}
## A node in the topology
NodeSpec = element node {
## Name of the node - each node name must be unique within the
## top element
attribute name { text },
## Type specification - we use a named pattern here (defined below), so
## that it can be overriden in the virtual topology schema, where you are
## only allowed to have one
NodeSpec.NodeType,
## Legacy flags
NodeFlagSpec,
## Legacy features and desires
FeatureDesireSpec*,
## Types of virtual nodes that this physical node can satisfy
## Desires of this node, which should (or must) be matched by the
## physical node we are assigned to
PropertySpec*
}
## A node can (by default) have one or more types
NodeSpec.NodeType = NodeTypeSpec+
## Link types are currently just a siple string. They will almost certainly
## have to get more complicated, for two reasons:
## First, I want to allow virtual links to specify more than one type, so
## that we can ask for links that are, say, 'ethernet or loopback'
## Second, I want to have a lot more control over links that get mapped to
## multi-hop paths
## TODO: MAYBE this should be combined with NodeTypeSpec
LinkTypeSpec = element link_type {
element type_name { text }
}
## Links in the topology - zero or more
LinkSpec = element link {
## Name of the link - must be unique in the top
attribute name { text },
## First interface for this link - links are assumed to be
## symmetric, so the order of the interfaces does not currently
## matter
element source_interface { InterfaceSpec },
## Second interface for this link
element destination_interface { InterfaceSpec },
## TODO: In the future, the bandwidth, latency, and packet loss will be
## moved to features and/or properties
## Bandwidth of the link in kbps
element bandwidth { xsd:float { minExclusive = "0.0" } },
## Latency of the link in ms
element latency { xsd:float { minInclusive = "0.0" } },
## Static packet loss probability of the link as a fraction
## (ie. 0.01 == 1%)
element packet_loss { xsd:float { minInclusive = "0.0" } },
## Type of this link - we use a named pattern here (defined below), so
## that it can be overriden in the virtual topology schema, where you are
## only allowed to have one
LinkSpec.LinkType,
## Properties of this link
PropertySpec*
}
## A link can (by default) have zero or more types
LinkSpec.LinkType = LinkTypeSpec*
## "Legacy" assign features and desires - will be phased out in favor of
## properties
FeatureDesireSpec = element fd {
## Name of this feature or desire
element fd_name { text },
## Weight assocated with the feature or desire
element fd_weight { xsd:float },
## A flag indicating whether or not a failure to match the desire with a
## a feature is a constraint violation
element violatable { empty }?,
## Type information expressed in features and desires
((element global { empty }, element operator { "OnceOnly", "FirstFree" }) |
(element local { empty }, element operator { "+" }))?
}
## "Legacy" assign node flags - will be replaced with properties, and in some
## cases, explicit links
NodeFlagSpec =
## Gives the amount of bandwidth this node can forward through its loopback
## interface. In the future, we will make the loopback interface/link
## explicit in the topology
## Valid only for physical nodes
element trivial_bandwidth { xsd:integer },
## Specify that this node is a subnode of another node. We MIGHT
## try to do this with properties in the future
## Valid for both virtual and physical nodes
element subnode_of { text }?,
## Indicates that this node should never be considered identical to any
## other node. Could be done with a property
## Valid only for physical nodes
element unique { empty }?,
## Indicates that virtual links must either all be trivial (loopback), or
## none of them must be. Possibly expressible with properties?
element disallow_trivial_mix { empty }?
## Interfaces
InterfaceSpec = element interface {
## Name of the node, which must match one of the nodes in this topology
element node_name { text },
## Name of the interface itself
element interface { text },
## Properties of the interface
PropertySpec*
}
## Properties - new: replacements for features and desires. Not yet implemented
## in assign, and not yet fully fleshed out in this schema.
PropertySpec = element property {
## Name of this property
element property_name { text },
## Value associated with this property
## TODO: Add ranges and other types from rspec
element property_value { text | xsd:float },
## The penalty associated with this property
element property_penalty { xsd:float { minInclusive = "0.0" } },
## If this flag is present, not having the property is considered a violation
element violatable { empty }?,
## TODO: Add more operators - equality, range test, etc
## Flags for special types of operators
((element global { empty }, element operator { "OnceOnly", "FirstFree" }) |
(element local { empty }, element operator { "=", "+" }))?
}
assign/top.rng
View file @ 93640e1d
<?xml version="1.0" encoding="UTF-8"?>
<!--
EMULAB-COPYRIGHT
Copyright (c) 2005-2006 University of Utah and the Flux Group.
All rights reserved.
EMULAB-COPYRIGHT
Copyright (c) 2005-2007 University of Utah and the Flux Group.
All rights reserved.
-->
<element name="top" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" ns="http://emulab.net/resources/vtop/1.0" xmlns="http://relaxng.org/ns/structure/1.0">
<attribute name="pid">
<a:documentation>Project ID</a:documentation>
</attribute>
<attribute name="eid">
<a:documentation>Experiment ID</a:documentation>
</attribute>
<optional>
<attribute name="gid">
<a:documentation>Group ID (optional)</a:documentation>
</attribute>
</optional>
<optional>
<attribute name="uid">
<a:documentation>User ID owning the experiment (optional)</a:documentation>
</attribute>
</optional>
<zeroOrMore>
<element name="node">
<a:documentation>Nodes in the topology - zero or more</a:documentation>
<attribute name="name"/>
<element name="node_type">
<element name="type_name">
<text/>
<!--
Definition of common data structures used for representing topologies -
shared between vtop (virtual topology) and ptop (physical topology)
formats.
-->
<grammar xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" ns="http://emulab.net/resources/top/0.2" xmlns="http://relaxng.org/ns/structure/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="NodeTypeSpec">
<a:documentation>Representation of a single node type</a:documentation>
<element name="node_type">
<element name="type_name">
<a:documentation>Name of the type - will almost certainly not be unique</a:documentation>
<text/>
</element>
<choice>
<a:documentation>How many virtual nodes of this type this physical node can
handle.</a:documentation>
<element name="type_slots">
<data type="integer">
<param name="minInclusive">1</param>
</data>
</element>
<element name="unlimited">
<empty/>
</element>
</choice>
<optional>
<element name="static">
<a:documentation>A flag that indicates that this physical node *always*
has this type - a node is only allowed to have one dynamic
(ie. not flagged as static) type at a time, but any number
of static types at a time</a:documentation>
<empty/>
</element>
<optional>
<element name="type_slots">
<a:documentation>TODO - Change type</a:documentation>
<text/>
</element>
</optional>
</optional>
</element>
</define>
<define name="NodeSpec">
<a:documentation>A node in the topology</a:documentation>
<element name="node">
<attribute name="name">
<a:documentation>Name of the node - each node name must be unique within the
top element</a:documentation>
</attribute>
<ref name="NodeSpec.NodeType">
<a:documentation>Type specification - we use a named pattern here (defined below), so
that it can be overriden in the virtual topology schema, where you are
only allowed to have one</a:documentation>
</ref>
<ref name="NodeFlagSpec">
<a:documentation>Legacy flags</a:documentation>
</ref>
<zeroOrMore>
<ref name="FeatureDesireSpec">
<a:documentation>Legacy features and desires</a:documentation>
</ref>
</zeroOrMore>
<zeroOrMore>
<ref name="PropertySpec">
<a:documentation>Types of virtual nodes that this physical node can satisfy
Desires of this node, which should (or must) be matched by the
physical node we are assigned to</a:documentation>
</ref>
</zeroOrMore>
</element>
</define>
<define name="NodeSpec.NodeType">
<a:documentation>A node can (by default) have one or more types</a:documentation>
<oneOrMore>
<ref name="NodeTypeSpec"/>
</oneOrMore>
</define>
<define name="LinkTypeSpec">
<a:documentation>Link types are currently just a siple string. They will almost certainly
have to get more complicated, for two reasons:
First, I want to allow virtual links to specify more than one type, so
that we can ask for links that are, say, 'ethernet or loopback'
Second, I want to have a lot more control over links that get mapped to
multi-hop paths
TODO: MAYBE this should be combined with NodeTypeSpec</a:documentation>
<element name="link_type">
<element name="type_name">
<text/>
</element>
</element>
</define>
<define name="LinkSpec">
<a:documentation>Links in the topology - zero or more</a:documentation>
<element name="link">
<attribute name="name">
<a:documentation>Name of the link - must be unique in the top</a:documentation>
</attribute>
<element name="source_interface">
<a:documentation>First interface for this link - links are assumed to be
symmetric, so the order of the interfaces does not currently
matter</a:documentation>
<ref name="InterfaceSpec"/>
</element>
<element name="destination_interface">
<a:documentation>Second interface for this link</a:documentation>
<ref name="InterfaceSpec"/>
</element>
<element name="bandwidth">
<a:documentation>TODO: In the future, the bandwidth, latency, and packet loss will be
moved to features and/or properties
Bandwidth of the link in kbps</a:documentation>
<data type="float">
<param name="minExclusive">0.0</param>
</data>
</element>
<element name="latency">
<a:documentation>Latency of the link in ms</a:documentation>
<data type="float">
<param name="minInclusive">0.0</param>
</data>
</element>
<element name="packet_loss">
<a:documentation>Static packet loss probability of the link as a fraction
(ie. 0.01 == 1%)</a:documentation>
<data type="float">
<param name="minInclusive">0.0</param>
</data>
</element>
<ref name="LinkSpec.LinkType">
<a:documentation>Type of this link - we use a named pattern here (defined below), so
that it can be overriden in the virtual topology schema, where you are
only allowed to have one</a:documentation>
</ref>
<zeroOrMore>
<element name="desire">
<element name="desire_name">
<text/>
</element>
<element name="desire_weight">
<text/>
</element>
<optional>
<element name="violatable">
<ref name="PropertySpec">
<a:documentation>Properties of this link</a:documentation>
</ref>
</zeroOrMore>
</element>
</define>
<define name="LinkSpec.LinkType">
<a:documentation>A link can (by default) have zero or more types</a:documentation>
<zeroOrMore>
<ref name="LinkTypeSpec"/>
</zeroOrMore>
</define>
<define name="FeatureDesireSpec">
<a:documentation>"Legacy" assign features and desires - will be phased out in favor of
properties</a:documentation>
<element name="fd">
<element name="fd_name">
<a:documentation>Name of this feature or desire</a:documentation>
<text/>
</element>
<element name="fd_weight">
<a:documentation>Weight assocated with the feature or desire</a:documentation>
<data type="float"/>
</element>
<optional>
<element name="violatable">
<a:documentation>A flag indicating whether or not a failure to match the desire with a
a feature is a constraint violation</a:documentation>
<empty/>
</element>
</optional>
<optional>
<choice>
<a:documentation>Type information expressed in features and desires</a:documentation>
<group>
<element name="global">
<empty/>
</element>
</optional>
</element>
</zeroOrMore>
<element name="operator">
<value>OnceOnly</value>
<value>FirstFree</value>
</element>
</group>
<group>
<element name="local">
<empty/>
</element>
<element name="operator">
<value>+</value>
</element>
</group>
</choice>
</optional>
</element>
</define>
<define name="NodeFlagSpec">
<a:documentation>"Legacy" assign node flags - will be replaced with properties, and in some
cases, explicit links</a:documentation>
<element name="trivial_bandwidth">
<a:documentation>Gives the amount of bandwidth this node can forward through its loopback
interface. In the future, we will make the loopback interface/link
explicit in the topology
Valid only for physical nodes</a:documentation>
<data type="integer"/>
</element>
<optional>
<element name="subnode_of">
<a:documentation>Specify that this node is a subnode of another node. We MIGHT
try to do this with properties in the future
Valid for both virtual and physical nodes</a:documentation>
<text/>
</element>
</optional>
<optional>
<element name="unique">
<a:documentation>Indicates that this node should never be considered identical to any
other node. Could be done with a property
Valid only for physical nodes</a:documentation>
<empty/>
</element>
</optional>
<optional>
<element name="disallow_trivial_mix">
<a:documentation>Indicates that virtual links must either all be trivial (loopback), or
none of them must be. Possibly expressible with properties?</a:documentation>
<empty/>
</element>
</optional>
</define>
<define name="InterfaceSpec">
<a:documentation>Interfaces</a:documentation>
<element name="interface">
<element name="node_name">
<a:documentation>Name of the node, which must match one of the nodes in this topology</a:documentation>
<text/>
</element>
<element name="interface">
<a:documentation>Name of the interface itself</a:documentation>
<text/>
</element>
<zeroOrMore>
<element name="node_option">
<element name="option_name">
<text/>
</element>
<element name="option_value">
<text/>
</element>
</element>
<ref name="PropertySpec">
<a:documentation>Properties of the interface</a:documentation>
</ref>
</zeroOrMore>
</element>
</zeroOrMore>
<zeroOrMore>
<element name="link">
<a:documentation>Links in the topology - zero or more</a:documentation>
<text/>
</define>
<define name="PropertySpec">
<a:documentation>Properties - new: replacements for features and desires. Not yet implemented
in assign, and not yet fully fleshed out in this schema.</a:documentation>
<element name="property">
<element name="property_name">
<a:documentation>Name of this property</a:documentation>