create new tag
, view all tags

Developer Corner


Main purpose for this page is to help developers to

  • define new resources for their applications to AST
  • develop the minions for the new resources

Status: Currently, AST is written in C and is working for the DRAGON GMPLS control plan. Suggestion is to provide another AST version written in Python for its portability and ease to read and to extend AST to work with the Dynamic Circuit Network (DCN).

Introducing New Resource Type

Define New Resources

  1. Edit resource definition file under /usr/local/ast_file/res_def.xml (This is an SVN controlled file located under ast_master direcotry, and when you run "make install", this file will be placed at /usr/local/ast_file/res_def.xml), and add new resource type, such as
<resource res_type="node or link" subtype="new_resource_name">
    <agent port="2623"></agent>
  1. (optional) add the schema under zebra/ast_master/xml_schema/*.rng; the rng file is written in Relax NG to describe the expected schema. For more information please refers to ResourceDescriptor. If you choose not to specify the schema, ast_master will simply pass your resource along to the indicated agency.
  2. agent port is mandatory so that ast_master will know which port to send the xml requests to. Your minions for this resource type should open the agent port and use that port to accept any TIP communication.

Develop Minions and the ast_master for the new resource

Both ast_master and minions will link to the same code in parsing and processing the different requests on the resources. This way, it will be easier to update a resource, and let the update sync to ast_master and all related minions.

In AST code, "struct res_mod" is defined to describe each resource type.

struct res_mod {
  const char* name;
  enum resource_type res_type;
  void *(*read_func)(struct application_cfg*, xmlNodePtr, int);
  int (*validate_func)(struct application_cfg*, struct resource*, int);
  int (*process_resp_func) (struct application_cfg *, struct resource *, struct resource *);
  int (*compose_req_func)(char*, struct application_cfg*, struct resource*);
  void (*print_func)(FILE*, void*, int);
  void (*print_cli_func)(struct vty*, void*);
  void (*free_func) (void*);
  int (*minion_proc_func)(enum action_type, struct resource*);
  void *(*old_read_func) (struct application_cfg*, xmlNodePtr, int);
  void (*old_print_func)(FILE*, struct resource*, int);

As you can see, there are many different functions defined for your resource. Ast_master will call the right functions with the appropriate set of parameters during the processing. Thus, your job is to define your new resource in "struct res_mod" and define the appropriate functions to process this resource. Here is some further explanation of each functions in the res_mod and when these functions will be called.

struct res_mod {

  functions related to a resource:

  void *(*read_func)(struct application_cfg*, xmlNodePtr, int);
        read_func() will be used by all modules in ast: minions,
        ast_master etc to read the resource from xmlNodePtr (res_details)
                NULL: when failed to read
                the specific app_res pointer: when succeed

  int (*validate_func)(struct application_cfg*, void*, int);
        after reading the whole xml file, ast_master will call
        validate_func on ALL resources, nodes first and then link;
        if there is any ptr within a resource that's pointing to another
        resource, this is the func should do that
                0: no error
                non-zero: error

  int (*process_setup) (struct application cfg* existing ast,
                        struct resource *the_existing_one,
                        struct resource *the incoming_one,
                        int agent)
        Even though the whole struct resource is passing to the func,
        this function should only updates the void* res pointer and
        xmlNodePtr; agent will differentiate ways to process.
                master - receving SETUP_RESP from minions
                minion - receving SETUP_REQ from minions

  int (*process_app) (struct application cfg* existing ast,
                        struct resource *the_existing_one,
                        struct resource *the incoming_one,
                        struct resource *the incoming_one,
                        int agent)
        used when
                master - receving app_complete
                minions - receving ast_complete

  int (*process_release) (struct application cfg* existing ast,
                        struct resource *the_existing_one,
                        struct resource *the incoming_one,
                        int agent)
        used when
                master - receving release_req
                minions - receving releaset_resp

  int (*print_cli)(struct vty*, void*);
  void (*print_func)(FILE*, void*, int);
  void (*free_func) (void*);

Please take a look on dragon_app_pc and dragon_link resources to see how these functions are defined. It will be a good idea to put your new res_mod into a separate C files. For example, we currently have both dragon_link and dragon_node_pc defined in dragon_app.c and dragon_app.h. And any minions that need to use dragon_app will include the *.h files and compile with the *.o file.

For example,

struct res_mod dragon_node_pc_mod = 

defines dragon_node_pc resource.

You should also define an "init" function for your resources, i.e.

  if (all_res_mod.total + 2 > 10) {
    zlog_info("Failed to add the dragon application module; too many resource in this instance");
    return 1;


  all_res_mod.res[all_res_mod.total] = &dragon_node_pc_mod;
  all_res_mod.res[all_res_mod.total+1] = &dragon_link_mod;

  return 0;

To "inform" minions or ast_msater about this new resource module, you should call this "init" function when ast_master and minions is in the initialization mode.


To develop the minions, you can take a node at the node_agent.

  1. Rename the zebra/ast_master/node_agent.c to YOUR_APP.c
  2. For the processing of the TIP messages, the functions under "struct res_mod" probably will be enough to handle that. Suggestions include:
    • Modify YOUR_APP.c to read the configuration that your resources will need.
    • Add a CLI if that will to monitor your minions.
Topic revision: r7 - 2008-06-20 - FionaLeung
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback