create new tag
, view all tags

Application Specific Topology (AST)

What's AST?

AST stands for Application Specific Topology. The original concept of AST was developed under the DRAGON project. Eventually, AST becomes an independent project so that more resources can be pulled in for development, integration and testing.

There are an increasing number of large-scale, globally distributed applications that require more sophisticated network services than what the traditional best effort network infrastructure can provide. The characteristics of the network service requirements for these applications are as followed:

  • Dedicated network resources: an application doesn’t need to worry about its impact on other network users, or vice versa.
  • Deterministic performance: the network service is repeatable and predictable.
  • Very high performance: the network service can have multi-Gbs flows with no latency or loss of packets, minimal jitters and globally reachable.
  • Reservation and Scheduling in Advance: the application can reserve and schedule its usage of the network and non-network resources
  • Flexible and Dynamic: the user can acquire these dedicated network resources on a short notice from many potential service or resource providers.
  • Application Specific: The user’s perspective of the “network” is a customized and integrated set of resources that address the needs of the particular application community instead of a first-come first-served one-size fits all shared environment.
To accommodate the needs of these high performance application users, developments in the networking technologies, such as the continued evolution of optical network technologies combined with dynamic provisioning mechanisms such as Generalized Multi-protocol label Switching (GMPLS), can fulfill the needs. And the emergence of hybrid networks, networks that incorporates both packet and circuit technologies, also enables the network capability to serve these high-end users. Nevertheless, from the application perspectives, the understanding of the underlying networking technologies is irrelevant; the focus is on the delivery of the services the applications need.

Application Specific Topology Description Language (ASTDL) is the tool developed to define, instantiate and manage those application specific networks. Indeed, ASTDL provides the ability to describe all the resources to be incorporated into an application – include those resources that reside on end systems (not particularly network resources). The entire distributed application topology can thereby be formally and completely specified and captured in an XML text file that can be processed by web services agents or other tools. The Application Specific Topology Builder (ASTB) is a tool that locates reserves, and instantiates the entire specified topology.

AST Architecture




AST_master is the server for accepting any AST-related request. To coordinate tasks on provisioning a topology and manage resources within that topology, AST_master plays the most important role. Simply speaking, AST_master is the “brain” or server for ASTB implementation. It is the agent that interfaces with individual users and applications. It listens to requests and bears the responsibility to distribute tasks to resource instantiation agents to fulfill the requirement in that topology. It also facilitates more advanced operation on AST, such as dynamic AST and compound AST. AST_master processes resource descriptors to “extend” its knowledge on resources so that AST_master can include new resources effortlessly. It also provides mechanisms for users to manage the active AST.


  • AST_master will be run on your local machine
  • Once a SETUP_REQ is submitted to an AST_master, any subsequent requests on that particular AST instance, such as MOD_REQ, RELEASE_REQ, should be sent to the same AST_master.
  • AST_master maintains a database of all current and past AST instances under "/usr/local/ast//" (more information on this AST database can be found under ...
  • Configuration file is located at "/usr/local/dragon/etc/ast_master.conf". Currently, the configuration file contains information that should be placed under resource broker.
  • Command Line Interface (CLI) is provided by telnet to port 2612
  • Commands:
    • To run AST_master, "ast_master -d"
    • To submit request to AST_master, "ast_master -f "
    • To verify xml files, "ast_master -v "
Components within AST_master

Mapper Module

There are two types of topology setup request that AST_master expects to receive:

  • logical AST - containing the virtual framework of the AST without the indications of the "exact" physical location of resources
  • physical AST - the actual instantiation of the AST
When AST_master receives a logical AST request from clients, it can map the logical AST to several different physical AST by contacting resource brokers to reserve resources and construct a viable overall topology plan. The interaction between resource broker and manager module follows the model described in Topology Instantiation Protocol (TIP), which will be illustrated in later session. Once the AST_master determines the physical AST, the manager module in AST_master takes the physical AST and instantiate it. Often times, if the application users don’t want to expose the resource brokers for the resources to AST_masters, users can always submitted a physical AST to AST_masters.

Please note, users can also write their own mapper function to translate the logical AST to physical AST before submitting the AST to AST_master.

Manager Module

The manager module takes the physical AST and processes the requests accordingly. Manager module possesses knowledge on where to locate and how to contact resource instantiation agents, the components located locally on the resources that take care of all the AST related operation. The manager module is also responsible on processing the responses from resource instantiation agents to determine the status of that particular AST. The interaction between minions and manager module also follows the TIP.

Resource Instantiation Agent / Minions

Minions are agents residing on resources to receive and process requests from AST_master. The communications between minions and AST_master is also using ASTDL format. Minions don't need to be resides on the same host as the resource; in fact, a proxy minion would be desired in some cases.


  • A generic minion is provided in the software.
  • Minions will understand resource descriptor to understand the syntax of each resource and process the requests accordingly.
  • node_agent
    • an example of node minions that we developed to work with dragon_node_pc
    • configuration file is at /usr/local/dragon/etc/node_agent.conf
    • log file is at /var/log/node_agent.log
  • dragond
    • the link minions is provided as a module in the dragond daemon
    • this minion serves to provision, monitor and tear down LSP in the DRAGON environment upon requests from users

Resource Broker

More information about Resource Broker can be found on its individual page.

Strictly speaking, resource broker is not a component within AST. It's an individual daemon that provides allocation of resources to AST.

Topology Processing Overview



We are extremely grateful to the the Laboratory for Telecommunications Sciences for supporting the AST project. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Laboratory for Telecommunications Sciences.

Topic attachments
I Attachment Action Size Date Who Comment
JPEGjpg ASTarchitecture.jpg manage 10.5 K 2008-04-09 - 14:56 UnknownUser  
JPEGjpg ASTtopoProcess.jpg manage 17.7 K 2008-04-09 - 14:57 UnknownUser  
Topic revision: r12 - 2013-07-02 - XiYang
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback