From jaf@arl.wustl.eduMon Feb 26 08:48:02 1996
Date: Tue, 20 Feb 96 11:41:41 CST
From: Andy Fingerhut <jaf@arl.wustl.edu>
To: hma@dworkin.wustl.edu, inder@dworkin.wustl.edu, rob@dworkin.wustl.edu
Cc: jaf@arl.wustl.edu
Subject: First draft of network design tool data structures

Comments are welcome.  It might visually resemble Java, because I put
lots of things in comments, but it ain't Java yet.

Andy

// Note that the x,y coordinates of places, and the lengths of
// conduits, are assumed to be in compatible coordinates.  The
// designation of their units is done by ... (to be specified later,
// probably by one or a couple of variables giving a scale).

// We might even want to define new classes "Length", "Cost",
// "Capacity", etc.  that are basically a combination of a value and a
// unit name.  A potential disadvantage is that Java won't let us
// overload arithmetic operators to use such classes in a "natural"
// way.  It is probably best to make these units a user-interface
// visible thing only, with everything internally expressed as
// unitless floating point values.  The user-interface will convert
// to and from the values with units that are displayed on screen.

// From looking briefly at the Java API documentation at
// http://java.sun.com/java.sun.com/JDK-1.0/api it appears that a
// class like Dictionary or HashTable would be appropriate for
// representing sets.  We can just treat the elements in the set as
// keys of the hash table, and ignore the feature of hash tables which
// lets us associate values with the keys.  For the links (see class
// link below), we could use this feature to associate an integer
// value with each key, where the keys were objects of type linktype.





// A place might be somewhere that a switch can be installed, such as
// a communications closet or computer room, or it might just be
// somewhere that cables can be routed through, to which more than two
// conduits are incident, such as a "T" intersection in a tunnel.

// switch_allowed is true iff a switch may be installed in the place.
// I can imagine wanting to make this more general, like a number of
// switches that can be installed at the place (0 if none allowed).

// Note: In the GUI, we might want to associate an icon with the
// place, which could be different from one place to another.

class place {
	String name;
	boolean switch_allowed;
	float x,y;
}


// A conduit is any place where a cable may be installed.  It connects
// two places, arbitrarily denoted l and r, for left and right.  It
// has a length, which is at least as large as the straight-line
// distance between the two points, but could be larger (e.g., a
// conduit between two places might make several right-angle turns).

// In a GUI, it would perhaps be nifty to represent a conduit by
// something other than just a straight line between them.  For
// example, a steam tunnel between two buildings might not be a
// straight line.  This is not a high-priority item on my list of
// things to implement, however.

// The installation cost seems like a reasonable thing to add, even if
// most algorithms we develop never use it.  It is the fixed cost of
// laying any cable at all on the path, e.g., trench-digging cost,
// right-of-way cost.

class conduit {
	String name;
	place l, r;
	float length;
	float install_cost;
}


// A place set is just a named collection of places and (optionally)
// other place sets.  It could be used to help specify traffic
// constraints, or just as a convenient way to group a set of places
// in the GUI.

// It would be nice when specifying traffic to have an easy way to
// take the complement of a placeset.  One way to do this would be to
// automatically create a placeset called "everything but X" every
// time a placeset called "X" is created or modified.  Just a thought.
// There may be a better way.

class placeset {
	String name;  // e.g., "Engineering School", "Computer Science"
	set of places and/or placesets.
}


// A physical_graph is a collection of places, some pairs of which are
// connected by conduits.  When installing a new cable between a pair
// of places, we assume that we always take the shortest path in the
// physical graph between those two places.

// I've also stuck in a set of placesets here, just because someone who
// created a physical_graph using the GUI would probably want to save the
// placesets with it.  This doesn't mean they have to be members of the
// same class, but it seems reasonable to do so.

// GUI note: we'd like also to have things that JST suggested like a
// scale parameter with a unit name, and a background image.  These might
// better be placed somewhere else than in the physical_graph class.

class physical_graph {
	set of places
	set of conduits
	set of placesets
}


// A single set pair constraint specifies the maximum traffic that may
// be simultaneously present from all nodes in set a to all nodes in
// set b.

class set_pair_constraint {
	placeset a, b;
	float limit;
}


// Traffic requirements are an arbitrary collection of
// set_pair_constraints.  Such a collection is general enough to
// specify alpha,omega type constraints, both for individual nodes and
// for sets of nodes, and it can specify a constraint from one node
// (or set of nodes) to another single node (or set of nodes), thus
// giving a "traffic matrix" style of specification.  You can also mix
// and match these two styles.

class traffic_requirements {
	set of set_pair_constraints
}


// A node is intended to be synonymous with "switch".
// place/position/location/etc. synonyms could start to get confusing.
// type is intended to specify things like the manufacturer and model
// number, in case we ever want to detail such things.

class node {
	String name;
	String type;
	place position;
}


// A link type would be something like "2.4 Gb/s link", with a raw
// capacity of 2400 (if expressed in Mb/s), a termination cost of
// $7000, and a cost per unit distance of whatever a single multi-mode
// fiber costs, plus perhaps installation costs.  Accurately modeling
// installation costs could be a nightmare, or even modeling the
// different kinds of multi-fiber cables commercially available.

class linktype {
	String name;
	float raw_capacity;
	float termination_cost;
	float cost_per_unit_distance;
}



// A "link" connects a pair of nodes, and may consist of one or more
// physical links.  For example, it might consist of 2 2.4 Gb/s links
// and one 600 Mb/s link.  Each physical link should be one of the
// kinds defined in an instance of the linktype class.

// It might be more detail than we care for, but we could also store a
// sequence of conduits over which this link passes, since it could go
// through several conduits, and there could be more than one sequence
// of conduits between the places where nodes l and r are installed.
// Any optimization algorithm should always use the shortest sequence
// of conduits from one place to another (a shortest path in the
// physical_graph), but we might want to represent an existing link
// which does not use such a shortest path.

class link {
	String name;
	node l,r;
	"multiset" of linktype  // a "multiset" because we can have more
				// than one of a 2.4 Gb/s link, for example.
	(or, for each linktype, a count of how many physical links to
	use of that type)
}


// Rob called this class "solution".  It represents a collection of
// switches and their interconnection by links.

class network {
	set of nodes	// also known as switches
	set of links
}
