Hi Michael good conversation, see responses in line below. Cheers Greg On 1/29/2014 2:49 AM, Scharf, Michael (Michael) wrote: > > Hi Greg, > > > > Some comments inline [MS]. > > > > Michael > > > > *From:*alto [mailto:[email protected]] *On Behalf Of *Greg Bernstein > *Sent:* Tuesday, January 28, 2014 4:54 PM > *To:* [email protected] > *Subject:* Re: [alto] Work items for re-chartering > > > > Great points Michael. In our paper available at > http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf > in section III we give a number of reduction/transformation > procedures. We looked at this from the point of view of lists of > paths, most suitable when there are few path choices and a limited > number of source-destination pairs of interest. And we looked at this > from the point of view of a "service specific" graphs which were > transformed from the original graph based on source-destination pairs > of interest and limits on additive paths measures such as delay. > > > > [MS] I haven't digged through all the maths in the paper. I fully > agree that there can be service specific graphs, similar to service > specific ALTO maps, which are possible as of today. However, the key > question to me is whether the ALTO protocol actually needs protocol > primitives to deal with this. For instance, referring to the paper, if > the ALTO server would expose the graph shown in Figure 6, the ALTO > client could calculate the different "views" in Figure 7 without > requiring ALTO functions for this (other than e.g. well-defined > metrics, e.g., based on draft-wu-alto-te-metrics). As I already said, > I am open to adding such functions to ALTO (as optional extensions), > but we need something that is easy to understand as a starting point. > --> The idea (in a VPN or other somewhat controlled context) is that the network provider would take its internal graph representation such as shown in figure 6 and reduce it based on such items as a limited collection of potential source-destination pairs of interest to the client, previously agreed on QoS measures or metrics. Such a process would not be subject to standardization. However, the paper was trying to show that such "graph transformations" could be as simple or complicated as the provider chose (but also that they were viable). > > > ---snip--- > > * Path definitions > Standardize a format for paths in terms of nodes or links. This > allows for path only topology sharing and abstraction. This is > also useful/needed for multi-layer network descriptions. OGF NML > has a "path" in terms of "links" in its "serial-compound link" notion. > > [MS] What is the difference between a path and a link? How would an > application use such a path? > --> When we first presented the "high bandwidth use case" (summer of 2012) we did it in terms of lists of "abstract paths" (see section III.A of the paper) and their mutual dependencies via share links. This is particularly effective if the number of source-destination pair candidates is limited, and the number of paths choices between a source-destination pair is limited (e.g., IP with OSPF based routing as the underlying technology).
I'm getting set to teach a graduate course on network design course and have been surveying texts and the literature. Depending upon the underlying technology and constraints two general approaches are typically used: (a) link-path formulation, and (b) node-link formulation. Our proposed extensions to ALTO to deal with bandwidth constraints (capacitated design problem) can benefit from both formulations depending on the context. However we want to keep the JSON encoding as simple as possible. > > * Ports on Nodes > These should be supported but not required, similar to what is > done in GraphML. > > [MS] I think I agree to that. > > > Ports are useful in asymmetric switching nodes such as ROADMs. > > * Multi-Layer Modeling > For this we need the adaptation concept. We can define this as an > edge with properties if we are building on basic graph notions of > vertices and edges. > Note that OGF doesn't define layer networks, but just assigns > "encodings" to links, ports, adaptations, and switching services. > > [MS] I don't understand this. What would be an ALTO-like example? > --> Once again I would use a VPN/private network example. For example consider a campus of data centers with optical switches (WSON) used for the inter-building network and SDN (OpenFlow) Ethernet switches for intra building. This would be a yet more sophisticated network consumer, but not unreasonable given current networking trends. Although advanced I think we can allow for this type of extension via a default single layer model with optional layer parameters as opposed to required layer parameter on very link, port, switching service as done in the OGF. > > * Need to separate graph notions from network notions. > Graphs only have vertices and edges. Graph description languages > or frameworks (e.g. NetworkX) do allow for these to have > properties. Networks have nodes, links, and adaptations... Hence > why OGF NML has a separate Adaptation/De-adaptation classes. > > [MS] Same here. > > * Many graph models support hyper-edges which can be used to model > some LANs and such. > > [MS] Possibly useful, but an ALTO-like example for using such a > feature would really help, too. > --> Just an idea not a requirement. > > > > > > > GraphML > > > > OGF NML > > > > SNDlib > > > > NetworkX JSON > > Node ids > > > > Explicit, Required, Unique > > > > Explicit, Required, Unique > > > > Explicit, Required, Unique > > > > Implicit via ordering in nodes array. But can use "id" attribute when > converting from JSON to python representation > > Link ids > (these also allow parallel links without ports) > > > > Explicit, Required unique > > > > Explicit, Required, Unique > > > > Explicit, Required, Unique > > > > Implicit via ordering in links array. . > > Node properties > > > > Can contain a graph, ports, data, locator. Arbitrary data via a (key, > data) mechanism. > > > > Can contain location, has "life time concept", name, ports. Not > directly associated with links but only through ports. > > > > Can contain coordinates > > > > Arbitrary. > > Link properties > > > > Can contain a graph. Arbitrary data via (key, data) mechanism.S > > > > Not currently defined. > > > > Routing cost, setup cost, pre-installed and additional modules that > have increments of capacity. Must include source/target node references. > > > > Arbitrary properties can be added. > > Paths > > > > No > > > > serial compound links/"ordered list of links" > > > > Yes > > > > No. > > Layers > > > > No, but could add a "property" for this. > > > > This seems to be implemented by assigning ports, links, adaptation, > and switching service all have a "encoding" parameter. Nodes and > Topologies do not. > > > > No > > > > No. Can add via a property. > > Nodes > > > > Can contain arbitrary data including graphs. > > > > In topology object. > > > > Contained in a "nodes" element. > > > > Contained in nodes list. > > Ports > > > > Yes. Contained within nodes. > > > > Yes. have "encoding" parameter, relationship to link. > > > > No. > > > > No. Could add as a node and link property. > > Adaptation concept > > > > No. Could add as link property > > > > Yes. > > > > No. > > > > Could add as a link property. > > > > [MS] Good table. But GraphML, OGF NML, and SDNlib are all not JSON. > And I think that an implicit ordering like in NetworkX JSON is > inferior to explicit identifiers for edges/vertices. > --> I was interested in their models structure and capability. SNDlib is used for conveying network design problems. OGF takes most of its models from ITU. JSON seems to be able to accommodate all these modeling situations. I agree with you on NetworkX's drawback on implicit ordering of the node array. Tinkerpop avoids this. But neither NetworkX's JSON or Tinkerpop's are JSON formally defined. > > --snip-- -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
