TSSP Framework

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)

TSSP High-level Concepts

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.

Channel Usage

• Send – Is a two step operation that combines establishing and filling/populating a communication channel. The construction of the channel is determined by the communication initiator over an available route.
  • Route – the send operation assumes the existence of a known (i.e. static) or unknown (i.e. dynamic) route through which the data fragments will travel. Routes with multiple hops imply multiple instances of data fragments. The route used by the send characterizes the communication channel, but does not define the end point.
    • dynamic – results from decision making processes that occur after a send has already been initiated
    • static – is determined prior to the execution of a send
  • Reuse – once a send has been performed, the communication channel can be reused by filling/populating it with new data. Although it requires administrative access to the channel, it is classified under send because it represents data transfer.
• Receive – Is a generalized operation that allows the recipient of the communication to access the content in the communication channel.

Channel Management

• 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.
• Bandwidth – Alters the data capacity of the communication channel by increasing or reducing the amount of reserved space.

Operation Actors and Steps

Send

I. Route (dynamic)
 A. Actors
  1. data transport client (see Internet Backplane Protocol)
  2. depot directory client (see Resource Discovery Standardization)
  3. depot selection agent
  4. metadata transfer client (see exnode Management Service Protocol)
 B. Steps
  1. obtain non-empty depot set
  2. determine next depot (if any)
  3. reserve and fill channel (allocate & store) 
  4. repeat steps 1-3 until depot set is empty
  5. publish/record metadata
II. Route (static)
 A. Actors
  1. data transport client 
  2. depot directory client 
  3. route generator?
  4. metadata transfer client 
 B. Steps
  1. obtain non-empty depot set
  2. order depot set
  3. determine next depot (if any)
  4. reserve and fill channel (allocate & store) 
  5. repeat steps 3 and 4 until depot set is empty
  6. publish/record metadata 
III. Reuse
 A. Actors
  1. data transport client
  2. metadata transfer client 
 B. Steps
  1. obtain metadata of selected channel
  2. fill channel (store)

Receive

 A. Actors
  1. data transport client 
  2. metadata transfer client
 B. Steps
  1. obtain metadata of selected channel
  2. consume channel content (does not free up channel capacity)

Teardown

 A. Actors
  1. IBP client 
  2. metadata transfer client
 B. Steps
  1. obtain metadata of selected channel
  2. force expiration of reserved bandwidth (results in content loss and increased system bandwidth)

Duration

 A. Actors
  1. IBP client 
  2. metadata transfer client
 B. Steps
  1. obtain metadata of selected channel
  2. reconfigure channel for longer or shorter duration (can result in data loss and teardown)

Bandwidth

 A. Actors
  1. IBP client 
  2. metadata transfer client
 B. Steps
  1. obtain metadata of selected channel
  2. reconfigure channel for greater or lesser capacity (can result in content loss?)

Open TSSP Issues

Channel creation

• Issues (see send->route)
  • What's the result when a TSSP request exceeds the depot's limits (duration, space)?
  • What level(s) of security/authorization does TSSP need to handle?
• Impacts
  • Impacted by logistical network configuration
  • Impacts resource discovery interface - where can I reserve space?
  • Impacts metadata service interface - where/how do I record the metadata?

Channel management

• Structure (see teardown and send->route)
  • Issues
    • Trim (partial teardown?)
    • Migrate (route(dynamic) + trim)
    • Teardown
  • Impacts
    • Impacted by logistical network configuration
    • Impacts resource discovery interface - where can I reserve space?
    • Impacts metadata service interface - where/how do I recover and update the metadata? what do I do when the channel is in use?
• Persistence (see duration)
  • Issues
    • Duration policy - limits based on usage profile?
    • Warming policy - limits based on usage profile and/or resource availability?
  • Impacts
    • Impacted by logistical network configuration
    • Impacts metadata service interface - where/how do I recover the metadata?

(TSSP does not alter the configuration of the network, only allocation properties, i.e. channel)

Channel access

• Issues (affects all operations)
  • Concurrent (block/nonblock I/O)
  • Permission management - determining TSSP access to different combinations of caps
• Impacts
  • Impacted by IBP service implementation
  • Impacts metadata service interface - where/how do I recover the metadata? what do I do if the channel is in use?
  • Impacts TSSP(channel_mgmt) - do I have access to the metadata needed in order to execute a task?

End-to-End services

• Issues (see send->route and receive)
  • Which, if any, are standard for TSSP?
• Impacts
  • Impacts metadata schema - what E2E service tags do I have to support?

(back to Protocol Standardization Efforts)