| | 25 | <!-- begin deprecated --> |
| | 26 | |
| | 27 | <xsd:complexType name="projectType"> |
| | 28 | <xsd:annotation> |
| | 29 | <xsd:documentation> |
| | 30 | A description of the project used to access a testbed. Includes |
| | 31 | the testbed being accessed, the project name (often a local |
| | 32 | name, scoped by the testbed), and any users who have been |
| | 33 | granted access or for whom access is being requested. |
| | 34 | </xsd:documentation> |
| | 35 | </xsd:annotation> |
| | 36 | <xsd:sequence> |
| | 37 | <xsd:element name="testbed" type="tns:IDType" minOccurs="0" |
| | 38 | maxOccurs="1"/> |
| | 39 | <xsd:element name="name" type="tns:IDType" minOccurs="0" maxOccurs="1"/> |
| | 40 | <xsd:element name="user" type="tns:userType" minOccurs="0" |
| | 41 | maxOccurs="unbounded"/> |
| | 42 | </xsd:sequence> |
| | 43 | </xsd:complexType> |
| | 44 | |
| | 45 | <xsd:complexType name="emulabType"> |
| | 46 | <xsd:annotation> |
| | 47 | <xsd:documentation> |
| | 48 | A description of an Emulab sufficient for the federation system |
| | 49 | to create a sub experiment on it. Note that fedAttrs provide an |
| | 50 | extension mechanism by which testbeds may communicate additional |
| | 51 | information and preferences to federation systems that |
| | 52 | understand it. |
| | 53 | </xsd:documentation> |
| | 54 | </xsd:annotation> |
| | 55 | <xsd:sequence> |
| | 56 | <xsd:element name="project" type="tns:projectType"/> |
| | 57 | <xsd:element name="domain" type="xsd:string"/> |
| | 58 | <xsd:element name="boss" type="xsd:string"/> |
| | 59 | <xsd:element name="ops" type="xsd:string"/> |
| | 60 | <xsd:element name="fileServer" type="xsd:string"/> |
| | 61 | <xsd:element name="eventServer" type="xsd:string"/> |
| | 62 | <xsd:element name="fedAttr" type="tns:fedAttrType" minOccurs="0" |
| | 63 | maxOccurs="unbounded"/> |
| | 64 | </xsd:sequence> |
| | 65 | </xsd:complexType> |
| | 66 | |
| | 87 | <xsd:complexType name="capacityType"> |
| | 88 | <xsd:annotation> |
| | 89 | <xsd:documentation> |
| | 90 | A strawman network capacity description for access negotiation. |
| | 91 | This will come to include more and more interesting parameters. |
| | 92 | </xsd:documentation> |
| | 93 | </xsd:annotation> |
| | 94 | <xsd:sequence> |
| | 95 | <xsd:element name="rate" type="xsd:double"/> |
| | 96 | <xsd:element name="kind" type="tns:kindType"/> |
| | 97 | </xsd:sequence> |
| | 98 | </xsd:complexType> |
| | 99 | |
| | 100 | |
| | 101 | <xsd:simpleType name="userRole"> |
| | 102 | <xsd:annotation> |
| | 103 | <xsd:documentation> |
| | 104 | This defines the role the user/account is playing in the |
| | 105 | federated experiment. An account being accessed by the |
| | 106 | federation system to create the experiment is in the |
| | 107 | experimentCreation role and the accounts that experimenters will |
| | 108 | use to access local testbed services (e.g., rebooting a local |
| | 109 | node) are serviceAccess roles. |
| | 110 | </xsd:documentation> |
| | 111 | </xsd:annotation> |
| | 112 | <xsd:restriction base="xsd:string"> |
| | 113 | <xsd:enumeration value="serviceAccess"/> |
| | 114 | <xsd:enumeration value="experimentCreation"/> |
| | 115 | </xsd:restriction> |
| | 116 | </xsd:simpleType> |
| | 117 | |
| 102 | | |
| 103 | | <xsd:simpleType name="userRole"> |
| 104 | | <xsd:annotation> |
| 105 | | <xsd:documentation> |
| 106 | | This defines the role the user/account is playing in the |
| 107 | | federated experiment. An account being accessed by the |
| 108 | | federation system to create the experiment is in the |
| 109 | | experimentCreation role and the accounts that experimenters will |
| 110 | | use to access local testbed services (e.g., rebooting a local |
| 111 | | node) are serviceAccess roles. |
| 112 | | </xsd:documentation> |
| 113 | | </xsd:annotation> |
| 114 | | <xsd:restriction base="xsd:string"> |
| 115 | | <xsd:enumeration value="serviceAccess"/> |
| 116 | | <xsd:enumeration value="experimentCreation"/> |
| 117 | | </xsd:restriction> |
| 118 | | </xsd:simpleType> |
| 119 | | |
| 192 | | |
| 193 | | |
| 194 | | <xsd:complexType name="projectType"> |
| 195 | | <xsd:annotation> |
| 196 | | <xsd:documentation> |
| 197 | | A description of the project used to access a testbed. Includes |
| 198 | | the testbed being accessed, the project name (often a local |
| 199 | | name, scoped by the testbed), and any users who have been |
| 200 | | granted access or for whom access is being requested. |
| 201 | | </xsd:documentation> |
| 202 | | </xsd:annotation> |
| 203 | | <xsd:sequence> |
| 204 | | <xsd:element name="testbed" type="tns:IDType" minOccurs="0" |
| 205 | | maxOccurs="1"/> |
| 206 | | <xsd:element name="name" type="tns:IDType" minOccurs="0" maxOccurs="1"/> |
| 207 | | <xsd:element name="user" type="tns:userType" minOccurs="0" |
| 208 | | maxOccurs="unbounded"/> |
| 209 | | </xsd:sequence> |
| 210 | | </xsd:complexType> |
| 211 | | |
| 212 | | <xsd:complexType name="emulabType"> |
| 213 | | <xsd:annotation> |
| 214 | | <xsd:documentation> |
| 215 | | A description of an Emulab sufficient for the federation system |
| 216 | | to create a sub experiment on it. Note that fedAttrs provide an |
| 217 | | extension mechanism by which testbeds may communicate additional |
| 218 | | information and preferences to federation systems that |
| 219 | | understand it. |
| 220 | | </xsd:documentation> |
| 221 | | </xsd:annotation> |
| 222 | | <xsd:sequence> |
| 223 | | <xsd:element name="project" type="tns:projectType"/> |
| 224 | | <xsd:element name="domain" type="xsd:string"/> |
| 225 | | <xsd:element name="boss" type="xsd:string"/> |
| 226 | | <xsd:element name="ops" type="xsd:string"/> |
| 227 | | <xsd:element name="fileServer" type="xsd:string"/> |
| 228 | | <xsd:element name="eventServer" type="xsd:string"/> |
| 229 | | <xsd:element name="fedAttr" type="tns:fedAttrType" minOccurs="0" |
| 230 | | maxOccurs="unbounded"/> |
| 231 | | </xsd:sequence> |
| 232 | | </xsd:complexType> |
| 233 | | |
| 234 | | <xsd:complexType name="federatedExperimentType"> |
| 235 | | <xsd:annotation> |
| 236 | | <xsd:documentation> |
| 237 | | Naming and Emulab instantiation information about a federant. |
| 238 | | This is returned by various informational requests and as part |
| 239 | | of a successful creation message. |
| 240 | | </xsd:documentation> |
| 241 | | </xsd:annotation> |
| 242 | | <xsd:sequence> |
| 243 | | <xsd:element name="name" type="tns:IDType" minOccurs="1" |
| 244 | | maxOccurs="unbounded"/> |
| 245 | | <xsd:element name="emulab" type="tns:emulabType" minOccurs="0" |
| 246 | | maxOccurs="1"/> |
| 247 | | <xsd:element name="master" type="xsd:boolean"/> |
| 248 | | </xsd:sequence> |
| 249 | | </xsd:complexType> |
| 250 | | |
| 251 | | |
| | 241 | |
| | 344 | |
| | 345 | <xsd:simpleType name="connectionType"> |
| | 346 | <xsd:annotation> |
| | 347 | <xsd:documentation> |
| | 348 | Known subexperiment interconnection mechanisms |
| | 349 | </xsd:documentation> |
| | 350 | </xsd:annotation> |
| | 351 | <xsd:restriction base="xsd:string"> |
| | 352 | <xsd:enumeration value="ssh"/> |
| | 353 | <xsd:enumeration value="transit"/> |
| | 354 | </xsd:restriction> |
| | 355 | </xsd:simpleType> |
| | 356 | |
| | 357 | <xsd:complexType name="connectionInfoType"> |
| | 358 | <xsd:annotation> |
| | 359 | <xsd:documentation> |
| | 360 | The information needed to stitch together two segments. It is both |
| | 361 | exported from the nmaster and reported by the experiment controller to |
| | 362 | the access controller and by the access controller into the world. |
| | 363 | </xsd:documentation> |
| | 364 | </xsd:annotation> |
| | 365 | <xsd:sequence> |
| | 366 | <xsd:element name="type" type="tns:connectionType"/> |
| | 367 | <xsd:element name="peer" type="xsd:string" minOccurs="0" maxOccurs="1"/> |
| | 368 | <xsd:element name="fedAttr" type="tns:fedAttrType" minOccurs="0" |
| | 369 | maxOccurs="unbounded"/> |
| | 370 | </xsd:sequence> |
| | 371 | </xsd:complexType> |
| | 372 | |
| | 373 | <xsd:complexType name="serviceInfoType"> |
| | 374 | <xsd:annotation> |
| | 375 | <xsd:documentation> |
| | 376 | A generic service entry, basically a name and server |
| | 377 | </xsd:documentation> |
| | 378 | </xsd:annotation> |
| | 379 | <xsd:sequence> |
| | 380 | <xsd:element name="name" type="xsd:string"/> |
| | 381 | <xsd:element name="server" type="xsd:string" minOccurs="0" |
| | 382 | maxOccurs="1"/> |
| | 383 | <xsd:element name="fedAttr" type="tns:fedAttrType" minOccurs="0" |
| | 384 | maxOccurs="unbounded"/> |
| | 385 | <xsd:element name="visibility" type="xsd:string"> |
| | 386 | <xsd:restriction> |
| | 387 | <xsd:enumeration value="export"/> <!-- server --> |
| | 388 | <xsd:enumeration value="import"/> <!-- client --> |
| | 389 | <xsd:enumeration value="composition"/><!-- both --> |
| | 390 | </xsd:restriction> |
| | 391 | </xsd:element> |
| | 392 | </xsd:sequence> |
| | 393 | </xsd:complexType> |
| | 394 | |
| | 614 | |
| | 615 | <!-- This needs to go away as well. It's only part of an infoResponseType, |
| | 616 | which needs to be reworked overall --> |
| | 617 | <xsd:complexType name="federatedExperimentType"> |
| | 618 | <xsd:annotation> |
| | 619 | <xsd:documentation> |
| | 620 | Naming and Emulab instantiation information about a federant. |
| | 621 | This is returned by various informational requests and as part |
| | 622 | of a successful creation message. |
| | 623 | </xsd:documentation> |
| | 624 | </xsd:annotation> |
| | 625 | <xsd:sequence> |
| | 626 | <xsd:element name="name" type="tns:IDType" minOccurs="1" |
| | 627 | maxOccurs="unbounded"/> |
| | 628 | <!-- begin deprecated --> |
| | 629 | <xsd:element name="emulab" type="tns:emulabType" minOccurs="0" |
| | 630 | maxOccurs="1"/> |
| | 631 | <xsd:element name="master" type="xsd:boolean"/> |
| | 632 | <!-- end deprecated --> |
| | 633 | </xsd:sequence> |
| | 634 | </xsd:complexType> |
| | 635 | |
| | 636 | <!-- end go away --> |