< draft-yang-alto-topology-05.txt		draft-yang-alto-topology-06.txt >
	ALTO WG G. Bernstein		ALTO WG G. Bernstein
	Internet-Draft Grotto Networking		Internet-Draft Grotto Networking
	Intended status: Standards Track Y. Lee		Intended status: Standards Track Y. Lee
	Expires: April 30, 2015 Huawei		Expires: September 10, 2015 Huawei
	W. Roome		W. Roome
	M. Scharf		M. Scharf
	Alcatel-Lucent		Alcatel-Lucent
	Y. Yang		Y. Yang
	Yale University		Yale University
	October 27, 2014		March 9, 2015
	ALTO Topology Extensions		ALTO Topology Extensions: Node-Link Graphs
	draft-yang-alto-topology-05.txt		draft-yang-alto-topology-06.txt
	Abstract		Abstract
	The Application-Layer Traffic Optimization (ALTO) Service has defined		The Application-Layer Traffic Optimization (ALTO) Service has defined
	network and cost maps to provide basic network information. In this		network and cost maps to provide basic network information. In this
	document, we discuss designs to provide abstracted graph		document, we discuss designs to provide abstracted (node-link) graph
	representations of network topology. We start with a basic		representations of network topology.
	application use case of multi-flow scheduling using ALTO. We show
	that ALTO cost maps alone cannot provide sufficient information. We
	then define one key, generic component to address the issues:
	introducing path vectors in cost maps. We specify two approaches to
	complement path vectors and achieve a complete design: an approach
	using opaque network elements and another using a graph (node-link)
	representation.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 2, line 7 ¶		skipping to change at page 1, line 45 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 30, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Review: the Base Single-Node Representation . . . . . . . . . 4		2. Review: the Base Single-Node Representation . . . . . . . . . 3
	3. The Multi-flow Scheduling Use Case . . . . . . . . . . . . . 5		3. Topology using a Graph (Node-Link) Representation . . . . . . 4
	4. Path-Vector as Cost Metric Representation . . . . . . . . . . 6		3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Minimal Topology through Network Element Properties Map . . . 9		3.2. A Node-Link Schema . . . . . . . . . . . . . . . . . . . 5
	6. Topology using a Graph (Node-Link) Representation . . . . . . 10		3.3. Discussions . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Use Case: Compact Representation . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.2. Use Case: Application Path Selection . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6.3. A Node-Link Schema . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4. Discussions . . . . . . . . . . . . . . . . . . . . . . . 14		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7.2. Informative References . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 16
	Appendix A. Graph Transformations and Operations to Build		Appendix A. Graph Transformations and Operations to Build
	Topology Representation for Applications . . . . . . 16		Topology Representation for Applications . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Topology is a basic information component that a network can provide		Topology is a basic information component that a network can provide
	to network management tools and applications. Example tools and		to network management tools and applications. Example tools and
	applications that can utilize network topology include traffic		applications that can utilize network topology include traffic
	engineering, network services (e.g., VPN) provisioning, PCE,		engineering, network services (e.g., VPN) provisioning, PCE,
	application overlays, among others [RFC5693,I-D.amante-i2rs-topology-		application overlays, among others [RFC5693,I-D.amante-i2rs-topology-
	use-cases, I-D.lee-alto-app-net-info-exchange].		use-cases, I-D.lee-alto-app-net-info-exchange].
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 10 ¶
	infrastructure, and each representation may be better suited for its		infrastructure, and each representation may be better suited for its
	own set of deployment scenarios. For example, the current ALTO base		own set of deployment scenarios. For example, the current ALTO base
	protocol [RFC7285] is designed for a setting of exposing network		protocol [RFC7285] is designed for a setting of exposing network
	topology using the extreme "my-Internet-view" representation, which		topology using the extreme "my-Internet-view" representation, which
	abstracts a whole network as a single node that has a set of access		abstracts a whole network as a single node that has a set of access
	ports, with each port connects to a set of endhosts called endpoints.		ports, with each port connects to a set of endhosts called endpoints.
	The base protocol refers to each access port as a PID. This "single-		The base protocol refers to each access port as a PID. This "single-
	node" abstraction achieves simplicity and provides flexibility. A		node" abstraction achieves simplicity and provides flexibility. A
	problem of this abstraction, however, is that the base protocol as		problem of this abstraction, however, is that the base protocol as
	currently defined does not provide sufficient information for use		currently defined does not provide sufficient information for use
	cases such as the multi-flow scheduling use case (see Section 2)		cases such as the multi-flow scheduling use case (see [draft-yang-
	defined in this document.		alto-path-vector]).
	An opposite of the single-node representation is the complete raw		An opposite of the single-node representation is the complete raw
	topology, spanning across multiple layers, to include all details of		topology, spanning across multiple layers, to include all details of
	network states such as endhosts attachment, physical links, physical		network states such as endhosts attachment, physical links, physical
	switch equipment, and logical structures (e.g., LSPs) already built		switch equipment, and logical structures (e.g., LSPs) already built
	on top of the physical infrastructural devices. A problem of the raw		on top of the physical infrastructural devices. A problem of the raw
	topology representation, however, is that its exposure may violate		topology representation, however, is that its exposure may violate
	privacy constraints. Also, a large raw topology may be overwhelming		privacy constraints. Also, a large raw topology may be overwhelming
	and unnecessary for specific applications. Since the target of ALTO		and unnecessary for specific applications. Since the target of ALTO
	is general applications which do not want or need to understand		is general applications which do not want or need to understand
	detailed routing protocols or raw topology collected in routing		detailed routing protocols or raw topology collected in routing
	information bases (RIB), raw topology does not appear to be a good		information bases (RIB), raw topology does not appear to be a good
	fit for ALTO.		fit for ALTO.
	A main objective of this document is to specify a new type of ALTO		A main objective of this document is to specify a new type of ALTO
	Information Resources, which provide abstracted graph representations		Information Resources, which provide abstracted graph (node-link)
	of a network to provide only enough information for applications. We		representations of a network to provide only enough information for
	call such Information Resources ALTO topology maps, or topology maps		applications. We call such Information Resources ALTO topology maps,
	for short. Different from the base single-node abstraction, a		or topology maps for short. Different from the base single-node
	topology map includes multiple network nodes. Different from the raw		abstraction, a topology map includes multiple network nodes.
	topology representation that uses real network nodes, a topology map		Different from the raw topology representation that uses real network
	may use abstract nodes, although they will be constructed from the		nodes, a topology map may use abstract nodes, although they will be
	real, raw topology, in order to provide grounded information. The		constructed from the real, raw topology, in order to provide grounded
	design of this document is based on the ALTO WG discussions at IETF		information. The design of this document is based on the ALTO WG
	89, with summary slides at http://tools.ietf.org/agenda/89/slides/		discussions at IETF 89, with summary slides at
	slides-89-alto-2.pdf.		http://tools.ietf.org/agenda/89/slides/slides-89-alto-2.pdf.
	The organization of this document is organized as follows. We first		The organization of this document is organized as follows. We first
	review the ALTO base protocol in Section 2. Then in Section 3, we		review the ALTO base protocol in Section 2. In Section 3, we give a
	give the multi-flow scheduling use case as an example. In Section 4,		node-link representation.
	we specify path vector as a key component to handle multi-flow
	scheduling. In Sections 5 and 6, we give two graph representations
	to complete the design. Section 7 gives a framework of topology
	transformations to help with the understanding of deriving multiple
	representations of the topology of the same network infrastructure,
	for applications.
	2. Review: the Base Single-Node Representation		2. Review: the Base Single-Node Representation
	We distinguish between endhosts and the network infrastructure of a		We distinguish between endhosts and the network infrastructure of a
	network. Endhosts are sources and destinations of data that the		network. Endhosts are sources and destinations of data that the
	network infrastructure carries. The network itself is neither the		network infrastructure carries. The network itself is neither the
	source nor the destination of data.		source nor the destination of data.
	For a given network, it provides "access ports" (interfaces, or		For a given network, it provides "access ports" (interfaces, or
	access points) where data signal from endhosts enter and leave the		access points) where data signal from endhosts enter and leave the
	skipping to change at page 5, line 8 ¶		skipping to change at page 4, line 41 ¶
	Figure 1: Base Single-Node Topology Abstraction.		Figure 1: Base Single-Node Topology Abstraction.
	There can be multiple ways to partition the set AP. Each partition		There can be multiple ways to partition the set AP. Each partition
	is called a network map. Given a complete partition of AP, the ALTO		is called a network map. Given a complete partition of AP, the ALTO
	base protocol introduces PID to represent each partition subset. The		base protocol introduces PID to represent each partition subset. The
	ALTO base protocol then conveys the pair-wise connection properties		ALTO base protocol then conveys the pair-wise connection properties
	between one PID and another PID through the "single-node". This is		between one PID and another PID through the "single-node". This is
	the cost map.		the cost map.
	3. The Multi-flow Scheduling Use Case		3. Topology using a Graph (Node-Link) Representation
	There are use cases where simple cost metrics cannot convey enough
	information to the applications about pair-wise connection properties
	between one PID and another PID. See [I-D.bernstein-alto-topo] for a
	survey of use-cases where extended network topology information is
	needed. This document uses a simple use case to illustrate the idea.
	Consider an application overlay (e.g., a large data analysis system)
	which needs to schedule the traffic among a set of endhost source-
	destination pairs, say eh1 -> eh2, and eh3 -> eh4. A simple cost
	metric such as 'available bw' for eh1 -> eh2 and eh3 -> eh4 may not
	reflect whether the two paths for eh1 -> eh2 and eh3 -> eh4 share a
	bottleneck.
	More concretely, assume that the network has 7 switches (sw1 to sw7)
	forming a dumb-bell topology. Switches sw1/sw3 provide access on one
	side, s2/s4 provide access on the other side, and sw5-sw7 form the
	backbone. Endhosts eh1 to eh4 are connected to access switches sw1
	to sw4 respectively. Assume that the bandwidth of each link is 100
	Mbps. Assume that the network is abstracted with 4 PIDs, with each
	representing the hosts at one access switch.
	+------+
	| |
	--+ sw6 +--
	/ | | \
	PID1 +-----+ / +------+ \ +-----+ PID2
	eh1__| |_ / \ ____| |__eh2
	| sw1 | \ +--+---+ +---+--+ / | sw2 |
	+-----+ \ | | | |/ +-----+
	\_| sw5 +---------+ sw7 |
	PID3 +-----+ / | | | |\ +-----+ PID4
	eh3__| |__/ +------+ +------+ \____| |__eh4
	| sw3 | | sw4 |
	+-----+ +-----+
	Figure 2: Base Single-Node Topology Abstraction.
	Now, consider a cost map providing end-to-end available bandwidth.
	There can be two possible interpretations on the semantics of the
	value of PIDi -> PIDj reported by the cost map: (1) it represents
	reserved bandwidth from PIDi -> PIDj, or (2) it represents possible
	bandwidth for PIDi -> PIDj, if no other applications use shared
	resources. The common understanding is (2), just as when we look at
	the number of available seats on a flight.
	Assume that the application receives from the cost map that both PID1
	-> PID2 and PID3 -> PID4 have bandwidth 100 Mbps. It cannot
	determine that if it schedules the two flows together, whether it
	will obtain a total of 100 Mbps or 200 Mbps. This depends on whether
	the flows share a bottleneck:
	o Case 1: If PID1 -> PID2 and PID3 -> PID4 use different paths, for
	example, when the first uses sw1 -> sw5 -> sw7 -> sw2, and the
	second uses sw3 -> sw5 -> sw6 -> sw7 -> sw4. Then the application
	will obtain 200 Mbps.
	o Case 2: If PID1 -> PID2 and PID3 -> PID4 share the bottleneck, for
	example, when both use the direct link sw5 -> sw7, then the
	application will obtain only 100 Mbps.
	To allow applications to distinguish the two possible cases, the
	network needs to provide more details.
	4. Path-Vector as Cost Metric Representation
	A key component to address the problem in the preceding section is to
	introduce path vectors as a cost metric, which is a set of path
	vectors from a source PID to a destination PID, where each path
	vector is a sequence (array) of network elements. Note that this
	design does not specify that a path vector is a sequence of network
	links. Rather, as a general design, a path is a sequence of network
	elements.
	A schema for introducing path vectors in cost maps is the following
	extension of Section 11.2.3.6 of [RFC7285]:
	object {
	cost-map.DstCosts.JSONValue -> JSONString<0,*>;
	meta.cost-mode = "path-vector";
	} InfoResourcePVCostMap : InfoResourceCostMap;
	Specifically, the preceding specifies that InfoResourcePVCostMap
	extends InfoResourceCostMap. The body specifies that the first
	extension is achieved by changing the type of JSONValue defined in
	DstCosts of cost-map to be an array of JSONString; the second
	extension is that the cost-mode of meta MUST be "path-vector".
	An example cost map using path-vector is the following:
	GET /costmap/pv HTTP/1.1
	Host: alto.example.com
	Accept: application/alto-costmap+json,application/alto-error+json
	HTTP/1.1 200 OK
	Content-Length: TDB
	Content-Type: application/alto-costmap+json
	{
	"meta" : {
	"dependent-vtags" : [
	{ "resource-id": "my-default-network-map",
	"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
	},
	{"resource-id": "my-topology-map", // See below
	"tag": "4xee2cb7e8d63d9fab71b9b34cbf76443631554de"
	}
	],
	"cost-type" : {"cost-mode" : "path-vector"
	}
	},
	"cost-map" : {
	"PID1": { "PID1":[],
	"PID2":["ne56", "ne67"],
	"PID3":[],
	"PID4":["ne57"]
	},
	"PID2": { "PID1":["ne75"],
	"PID2":[],
	"PID3":["ne75"],
	"PID4":[]
	},
	"PID3": { "PID1":[],
	"PID2":["ne57"],
	"PID3":[],
	"PID4":["ne57"]
	},
	"PID4": { "PID1":["ne75"],
	"PID2":[],
	"PID3":["ne75"],
	"PID4":[]}
	}
	}
	The example illustrates that there are two key extensions to the ALTO
	base protocol:
	o It introduces a new "cost-mode" named "path-vector";
	o To indicate the resource that provides information on the elements
	of path vectors (e.g., ["ne5", "ne67"] for the path vector from
	PID1 to PID2, it introduces a new dependency. In the example, it
	is indicated by a resource named "my-topology-map".
	5. Minimal Topology through Network Element Properties Map
	A missing piece to complete the path-vector design to resolve the
	ambiguity in the use case is how to provide information on the
	elements of the path vectors. A minimal approach is to introduce
	network element properties (NEP) maps, where each NEP map provides a
	mapping from a network element to its properties such as bandwidth or
	shared risk link group (srlg).
	A schema of an NEP map is:
	object-map {
	JSONString -> NetworkElementProperties; // name to properties
	} NetworkElementMapData;
	object-map {
	JSONString bw;
	JSONString srlg<0,*>;
	[JSONString type;] // should be from an enumeration only
	} NetworkElementProperties;
	An example network element property map:
	GET /nepmap HTTP/1.1
	Host: alto.example.com
	Accept: application/alto-nepmap+json,application/alto-error+json
	HTTP/1.1 200 OK
	Content-Length: TBD
	Content-Type: application/alto-nepmap+json
	{
	"meta" : {
	"vtag": {
	"resource-id": "my-topology-map",
	"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
	}
	},
	"nep-map" : {
	"ne57" : {"bw" : 100, "srlg" : [1, 3]}, // link sw5->sw7
	"ne75" : {"bw" : 100, "srlg" : [1, 3]}, // link sw7->sw5
	"ne56" : {"bw" : 100, "srlg" : [1]}, // link sw5->sw6
	"ne65" : {"bw" : 100, "srlg" : [1]}, // link sw6->sw5
	"ne67" : {"bw" : 100, "srlg" : [3]}, // link sw6->sw7
	"ne76" : {"bw" : 100, "srlg" : [3]}, // link sw7->sw6
	}
	}
	An advantage of the representation is that it does not need to
	distinguish between network nodes vs network links, as an application
	in typical cases do not need to make the distinction between network
	nodes and network links. At the same time, the design introduces an
	optional "type" field, which can indicate the type (e.g., link, layer
	2 switch, layer 3 router), of the network element.
	6. Topology using a Graph (Node-Link) Representation
	6.1. Use Case: Compact Representation
	A potential problem of the path vector representation is its lacking		3.1. Use Cases
	of compactness. For example, suppose a network has N PIDs, then it
	will need to represent N * (N-1) paths, if each source-destination
	pair has one path computed using a shortest-path algorithm. On the
	other hand, the underlying graph may have only O(F * N) elements,
	where F is the average degree of the topology, and hence can be a
	much smaller value than N. For such settings, in particular, when
	privacy protection is not an issue (e.g., in the same-trust domain
	setting), a node-link representation can be more compact.
	6.2. Use Case: Application Path Selection		[draft-yang-alto-path-vector] proposes path vectors to extend the
			preceding topology to expose network elements. A potential problem
			of the path vector representation, however, is its lacking of
			compactness. For example, suppose a network has N PIDs, then it will
			need to represent N * (N-1) paths, if each source-destination pair
			has one path computed using a shortest-path algorithm. On the other
			hand, the underlying graph may have only O(F * N) elements, where F
			is the average degree of the topology, and hence can be a much
			smaller value than N. For such settings, in particular, when privacy
			protection is not an issue (e.g., in the same-trust domain setting),
			a node-link representation can be more compact.
	Another setting where a node-link graph approach is more complete		Another setting where a node-link graph approach is beneficial is
	(than the partial NEP approach) can be motivated by the multi-flow		application guided path selection. With a topology graph, an
	scheduling use case discussed in Section 3. In particular, consider		application can compute maximum flows to discover the desired paths
	that the network routing is Case 2 (only 100 Mbps total bandwidth),		and signal (out the scope of this document) to the network to set up
	and the application can benefit from the routing in Case 1 (200		the paths. The computation can be done by the application itself, or
	Mbps). With a topology graph, the application can compute maximum		through a third entity such as a PCE server. The recent development
	flows to discover the desired paths and signal (out the scope of this		of SDN makes this use case more possible. A requirement of realizing
	document) to the network to set up the paths. The computation can be		this use case is that the path computed by the application is
	done by the application itself, or through a third entity such as a		realizable, in particular, when the topology is an abstract topology.
	PCE server. The recent development of SDN makes this use case more		By realizable, we mean that a path computed on the abstract topology
	possible. A requirement of realizing this use case is that the path		can be converted to configurations on network devices to achieve the
	computed by the application is realizable, in particular, when the		properties in the abstract topology.
	topology is an abstract topology. By realizable, we mean that a path
	computed on the abstract topology can be converted to configurations
	on network devices to achieve the properties in the abstract
	topology.
	6.3. A Node-Link Schema		3.2. A Node-Link Schema
	A schema for the graph (node-link) representation, based on the types		A schema for the graph (node-link) representation, based on the types
	already defined in the base ALTO protocol, is the following:		already defined in the base ALTO protocol, is the following:
	object {		object {
	TopologyMapData topology-map;		TopologyMapData topology-map;
	} InfoResourceTopologyMap : ResponseEntityBase;		} InfoResourceTopologyMap : ResponseEntityBase;
	object {		object {
	NodeMapData nodes;		NodeMapData nodes;
	skipping to change at page 12, line 39 ¶		skipping to change at page 6, line 39 ¶
	JSONString dst;		JSONString dst;
	JSONString type;		JSONString type;
	CostValue costs<0,*>;		CostValue costs<0,*>;
	} LinkProperties;		} LinkProperties;
	object {		object {
	CostMetric metric;		CostMetric metric;
	JSONValue value; // value type depends on metric type		JSONValue value; // value type depends on metric type
	} CostValue;		} CostValue;
	An example using the schema:		In particular, the schema distinguishes two types of links: edge-
			attach, and core, where the former is for a link between a network
			element and a group of endhosts (PID), and the later is between two
			network elements.
			An example using the schema is:
	GET /topologymap HTTP/1.1		GET /topologymap HTTP/1.1
	Host: alto.example.com		Host: alto.example.com
	Accept: application/alto-topologymap+json,application/alto-error+json		Accept: application/alto-topologymap+json,application/alto-error+json
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Length: TBD		Content-Length: TBD
	Content-Type: application/alto-topologymap+json		Content-Type: application/alto-topologymap+json
	{		{
	"meta" : {		"meta" : {
	"dependent-vtags" : [		"dependent-vtags" : [
	{ "resource-id": "my-default-network-map",		{ "resource-id": "my-default-network-map",
	"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"		"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
	}		}
	skipping to change at page 14, line 44 ¶		skipping to change at page 9, line 4 ¶
	"type": "core",		"type": "core",
	...		...
	},		},
	"e67" : {"src" : "sw6",		"e67" : {"src" : "sw6",
	"dst" : "sw7",		"dst" : "sw7",
	"type": "core",		"type": "core",
	...		...
	}		}
	}		}
	}		}
	}		}
	6.4. Discussions		3.3. Discussions
	The node-link schema specified in the preceding section is still a		The node-link schema specified in the preceding section is still a
	standard graph representation of a network (graph). An alternative		standard graph representation of a network (graph). An alternative
	design, which may provide substantial benefit, is using a property		design, which may provide substantial benefit, is using a property
	graph design. In particular, in a property graph based design, it is		graph design. In particular, in a property graph based design, it is
	unnecessary that a node in the property graph represents a network		unnecessary that a node in the property graph represents a network
	node, a link in the property graph represents a network link.		node, a link in the property graph represents a network link.
	Instead, network nodes, network links and network paths can all be		Instead, network nodes, network links and network paths can all be
	represented as nodes in a property graph, and links represent their		represented as nodes in a property graph, and links represent their
	relationship. This design can be flexible in modeling settings such		relationship. This design can be flexible in modeling settings such
	skipping to change at page 15, line 22 ¶		skipping to change at page 9, line 30 ¶
	Property-graph frameworks such as Gremlin can provide powerful and		Property-graph frameworks such as Gremlin can provide powerful and
	compact querying languages for application's usage.		compact querying languages for application's usage.
	Using either the standard node-link graph in the preceding section or		Using either the standard node-link graph in the preceding section or
	the property graph abstraction, one may not use a rigid hierarchical		the property graph abstraction, one may not use a rigid hierarchical
	design. Consider a model that uses a strict hierarchy, and a higher		design. Consider a model that uses a strict hierarchy, and a higher
	layer node can specify a set of nodes in the lower layer as		layer node can specify a set of nodes in the lower layer as
	supporting nodes; a higher layer link can specify a set of links in		supporting nodes; a higher layer link can specify a set of links in
	the lower layer as supporting links [draft-clemm-i2rs-yang-network-		the lower layer as supporting links [draft-clemm-i2rs-yang-network-
	topo-01]. To test the problem of that model, consider a simple		topo-01]. To test the problem of that model, consider a simple
	topology such as our topology in Section 3. Assume that the network		topology. Assume that the network consists of 3 data centers (dc1,
	consists of 3 data centers (dc1, dc2, and dc3). dc1 has two routers		dc2, and dc3). dc1 has two routers dc11 and dc12; dc2 has dc21 and
	dc11 and dc12; dc2 has dc21 and dc22; and dc3 has dc31 and dc32. The		dc22; and dc3 has dc31 and dc32. The connections are that (1) two
	connections are that (1) two routers in the same data center are		routers in the same data center are connected; (2) dc11, dc21 and
	connected; (2) dc11, dc21 and dc31 are mutually connected; same for		dc31 are mutually connected; same for dc12, dc22, and dc32.
	dc12, dc22, and dc32.
	The network can provide different abstract topologies: for tenants in		The network can provide different abstract topologies: for tenants in
	dc1, they see dc11, dc12, and dc2, dc3; same for tenants in dc2, and		dc1, they see dc11, dc12, and dc2, dc3; same for tenants in dc2, and
	dc3. In other words, each tenant in a DC sees the detailed topology		dc3. In other words, each tenant in a DC sees the detailed topology
	of its DC and the other data centers are abstracted to be single		of its DC and the other data centers are abstracted to be single
	nodes.		nodes.
	This case turns out to be not doable for their pure hierarchical		This case turns out to be not doable for their pure hierarchical
	layer approach, where a top layer node/link has supporting nodes/		layer approach, where a top layer node/link has supporting nodes/
	links. Specifically, thee model cannot have cross-layer links such		links. Specifically, thee model cannot have cross-layer links such
	as dc11 -> dc2.		as dc11 -> dc2.
	7. Security Considerations		4. Security Considerations
	This document has not conducted its security analysis.		This document has not conducted its security analysis.
	8. IANA Considerations		5. IANA Considerations
	This document does not specified its IANA considerations, yet.		This document does not specified its IANA considerations, yet.
	9. Acknowledgments		6. Acknowledgments
	The author thanks discussions with Xiao Shi, Xin Wang, Erran Li,		The author thanks discussions with Xiao Shi, Xin Wang, Erran Li,
	Tianyuan Liu, Andreas Voellmy, Haibin Song, and Yan Luo.		Tianyuan Liu, Andreas Voellmy, Haibin Song, and Yan Luo.
	10. References		7. References
	10.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	10.2. Informative References		7.2. Informative References
	[I-D.amante-i2rs-topology-use-cases]		[I-D.amante-i2rs-topology-use-cases]
	Medved, J., Previdi, S., Lopez, V., and S. Amante,		Medved, J., Previdi, S., Lopez, V., and S. Amante,
	"Topology API Use Cases", draft-amante-i2rs-topology-use-		"Topology API Use Cases", draft-amante-i2rs-topology-use-
	cases-01 (work in progress), October 2013.		cases-01 (work in progress), October 2013.
	[I-D.clemm-i2rs-yang-network-topo]		[I-D.clemm-i2rs-yang-network-topo]
	Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N.,		Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N.,
	and H. Ananthakrishnan, "A YANG Data Model for Network		and H. Ananthakrishnan, "A YANG Data Model for Network
	Topologies", draft-clemm-i2rs-yang-network-topo-01 (work		Topologies", draft-clemm-i2rs-yang-network-topo-01 (work
End of changes. 27 change blocks.
	295 lines changed or deleted		82 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/