TSSP Framework - Revision history

Hunterh: /* Teardown */

2008-02-01T02:43:08Z

Teardown

← Older revision		Revision as of 21:43, 31 January 2008
Line 70:		Line 70:
	2. consume channel content (does not free up channel capacity)		2. consume channel content (does not free up channel capacity)

	== ~~Teardown~~ ==		== Expire ==
	A. Actors		A. Actors
	1. data transport client		1. data transport client

2008-01-03T15:40:01Z

Open TSSP Issues

← Older revision		Revision as of 10:40, 3 January 2008
Line 95:		Line 95:

	= Open TSSP Issues =		= Open TSSP Issues =
			(see [[TSSP Procedures]] for proposed issue resolutions)

	== Channel creation ==		== Channel creation ==
	* Issues (see send->route)		* Issues (see send->route)

2008-01-02T19:27:00Z

← Older revision		Revision as of 14:27, 2 January 2008
Line 140:		Line 140:
	== Algorithms ==		== Algorithms ==
	* Issues (see send->route and receive)		* Issues (see send->route and receive)
	** How do algorithms fit into our specification goals		** How do algorithms fit into our specification goals?
	** Should there be a standard algorithm for		** Should there be a standard algorithm for
	*** download		*** download
	*** upload		*** upload
	*** depot list generation		*** depot list generation

			== Fault Tolerance ==
			* Issues
			**Given a best-effort communication medium, how insistent should TSSP be with regards to successful completion of its operations?
			**Is it possible to find a common policy that can satisfy both simple (i.e. fast) and complex (i.e. time consuming) forms of channel creation and management?

	(back to [[Protocol Standardization Efforts]])		(back to [[Protocol Standardization Efforts]])

2008-01-02T18:34:27Z

← Older revision		Revision as of 13:34, 2 January 2008
Line 1:		Line 1:
	This draft is based on the assumption that a logistical network is viewed essentially as a communication medium. Therefore, we have used networking terms and concepts to identify the types of operations that the TSSP would be responsible for. (back to [[Protocol Standardization Efforts]])		This draft is based on the assumption that a logistical network is viewed essentially as a communication medium. Therefore, we have used networking terms and concepts to identify the types of operations that the TSSP would be responsible for. (back to [[Protocol Standardization Efforts]])

			'''Goal'''

			Q: "Given a logistical network, what can I do with it?"
			A: "Following this protocol/spec, you can at least achieve [these operations]."

	= TSSP High-level Concepts =		= TSSP High-level Concepts =

2008-01-02T18:14:50Z

Algorithms

← Older revision		Revision as of 13:14, 2 January 2008
Line 135:		Line 135:
	== Algorithms ==		== Algorithms ==
	* Issues (see send->route and receive)		* Issues (see send->route and receive)
	** How to algorithms fit into our specification goals		** How do algorithms fit into our specification goals
	** Should there be a standard algorithm for		** Should there be a standard algorithm for
	*** download		*** download

2007-12-21T12:13:55Z

TSSP High-level Concepts

← Older revision		Revision as of 07:13, 21 December 2007
Line 6:		Line 6:
	use is determined by access to the capability triplets associated with the allocations.		use is determined by access to the capability triplets associated with the allocations.

	~~reference~~ - [http://julian.ultralight.org/~fvlingen/managedNetwork/Annex10080807.pdf Managed Circuits] for bulk data transfers		related - [http://julian.ultralight.org/~fvlingen/managedNetwork/Annex10080807.pdf Managed Circuits] for bulk data transfers

	== Channel Usage ==		== Channel Usage ==

2007-12-21T01:03:51Z

TSSP High-level Concepts

← Older revision		Revision as of 20:03, 20 December 2007
Line 5:		Line 5:
	channel - used in this context it represents a set of IBP allocations. Channel		channel - used in this context it represents a set of IBP allocations. Channel
	use is determined by access to the capability triplets associated with the allocations.		use is determined by access to the capability triplets associated with the allocations.

			reference - [http://julian.ultralight.org/~fvlingen/managedNetwork/Annex10080807.pdf Managed Circuits] for bulk data transfers

	== Channel Usage ==		== Channel Usage ==

2007-12-20T18:41:36Z

Open TSSP Issues

← Older revision		Revision as of 13:41, 20 December 2007
Line 130:		Line 130:
	* Impacts		* Impacts
	** Impacts metadata schema - what E2E service tags do I have to support?		** Impacts metadata schema - what E2E service tags do I have to support?

			== Algorithms ==
			* Issues (see send->route and receive)
			** How to algorithms fit into our specification goals
			** Should there be a standard algorithm for
			*** download
			*** upload
			*** depot list generation

	(back to [[Protocol Standardization Efforts]])		(back to [[Protocol Standardization Efforts]])

2007-12-20T18:35:08Z

Channel Management

← Older revision		Revision as of 13:35, 20 December 2007
Line 18:		Line 18:
	* ''Teardown'' – Deconstructs the communication channel, preventing successful ''send''('''reuse''') and ''receive'' operations.		* ''Teardown'' – Deconstructs the communication channel, preventing successful ''send''('''reuse''') and ''receive'' operations.
	* ''Duration'' – Alters the life span of the communication channel by prolonging or shortening its existence.		* ''Duration'' – Alters the life span of the communication channel by prolonging or shortening its existence.
	* ''~~Bandwidth~~'' – Alters the data capacity of the communication channel by increasing or reducing the amount of reserved space.		* ''Capacity'' – Alters the data capacity of the communication channel by increasing or reducing the amount of reserved space.

	= Operation Actors and Steps =		= Operation Actors and Steps =

2007-12-20T18:34:08Z

Capacity

← Older revision		Revision as of 13:34, 20 December 2007
Line 79:		Line 79:
	2. reconfigure channel for longer or shorter duration (can result in data loss and ''teardown'')		2. reconfigure channel for longer or shorter duration (can result in data loss and ''teardown'')

	== ~~Bandwidth~~ ==		== Capacity ==
	A. Actors		A. Actors
	1. ~~IBP~~ client		1. data transport client
	2. metadata transfer client		2. metadata transfer client
	B. Steps		B. Steps