Information that needs to be distributed can be broken down into two basic types, streams and bundles:

• A Bundle is a single chunk of information that must be kept together to have logical meaning. An email message is an example of a bundle.
• A Stream is a sequence of bundles that are associated in some way. A sequence of video frames from a single presentation is an example of a stream.

The Layer8 architecture allows streams and bundles to originate at any authorized location within an enterprise and ensures that bundles are delivered to, and received by, every authorized recipient throughout the enterprise -- even in the face of hardware or network failures. Each stream or bundle has a complete and secure audit trail of both its delivery path and destination.

The entire Layer8 system is managed by a system of certificates and keys. If there is an existing PKI (public key infrastructure) it can be leveraged to make management easier and more secure.

System Layout

The Layer8 (L8) network layout consists of endpoints, sources, sinks, repositories, and nodes.

Sources and sinks are where data enters or exits the L8 system. They are software components of the L8 system.

• Endpoints are outside the L8 system itself and are where the data ultimately originated or ended. They can be people, external gateways, or other places where information originates or ends up.
• Repositories are places where information is stored. A repository can act as a source or a sink. For example, if an audio recording of a shareholder’s meeting is held in a repository and someone wishes to listen to that meeting, the repository will act as a source and stream the recording as a series of bundles. The person’s audio client will act as the endpoint, connected to an L8 sink, receiving the bundles.
• Nodes are the engines of the L8 architecture. They make routing and authorization decisions to ensure that a bundle reaches all and only those sinks authorized to receive that bundle.

The L8 architecture is logically based upon multicast trees. Each multicast tree is a spanning tree layered on top of the existing nodes and connections between them. Sources send streams of bundles to multicast trees and each recipient of that multicast spanning tree receives a copy of those bundles.

Nodes may fail or the ability for two nodes to reach each other may be lost. To ensure that this does not affect data reliability, sources and sinks are able to switch which node they send bundles to and receive bundles from. Source and nodes will not discard a bundle until they have ensured that every authorized recipient has acknowledged that bundle. Nodes can change which other nodes they send bundles to directly.

Direct source-to-sink messages are also supported. A spanning tree can be trivially formed out of the ‘preferred’ links each node uses to reach a particular destination. Note that bundles are never sent over links that are not part of the spanning tree of destinations for that particular bundle. (Unless the spanning tree changes during the bundle’s lifetime, in which case it may take parts of both trees.)

Direct source-to-sink messages can be used to implement more traditional query/response mechanisms. Even these mechanisms benefit from the self-healing topology, secure authentication, persistent tracking, and reliable delivery features of an L8 system.

Store and Forward

The system also provides for interim or long term storage in for both Bundles and Streams. Packets and Streams can both be marked to use, or not use the storage system. Much like a memo system with folders this facility allows nodes to replay a stream or re-read a bundle and to organize the data in folders. Stored information can only be retrieved from those users at the specific terminals that it was originally sent to.

Eyeball-to-Eyeball Security

Every link that a bundle takes is taken into account by the L8 architecture. The security parameters of a bundle are always associated with that bundle and a bundle will not cross a link whose security parameters are inconsistent of those of the bundle.

A system of keys and certificates are used to authenticate sources, sinks, nodes and end points. Certificates are also used to grant specific privileges or limitations to specific sources, sinks, and endpoints.

For example, if a particular person is at a particular machine, the person can be identified to the system by his smartcard and the machine by the key stored in it. The L8 system would impose the restrictions and grant the privileges specified by the certificates for both the endpoint and the source/sink.

Multilayer certificates can be used. For example, one certificate from one PKI system can confirm a person’s identity while other certificates from another PKI system grant that person particular privileges. This way, an enterprise that already has a PKI can use its existing mechanisms of identifying individuals while using another system to manage the L8 system.

Digital Chain of Custody

The L8’s Digital Chain of Custody (DCC) feature provides for tracking, responsibility, and positive acknowledgement in the delivery of bundles. The chain of custody is bidirectional and exists at the source when a bundle is created until confirmation is obtained and delivered from every registered endpoint for that bundle.

At the lowest possible level, DCC would consist of positive acknowledgement to the source endpoint of a bundle that it was received by a node that was a member of the multicast group a bundle was sent to. This means that the message is confirmed to have left the source and that there is a node responsible for delivering it. Of course, it’s theoretically possible that the node could be unable to send the bundle to any other nodes or sinks and then crashes.

At the highest possible level, DCC would consist of positive acknowledgement for every recipient endpoint. Note that this is the endpoint that acknowledges, not the sink. So if the endpoint is a human reading text, the human would have to actually acknowledge the receipt of the message, displaying it on his screen would not constitute reception.

At higher levels, each node that receives the bundle tracks where it got the bundle from, who it is responsible for sending the bundle to, and who has already acknowledged it. This information and the bundle itself will remain with the node until it is able to collapse the chain of custody by acknowledging reception of each endpoint, node, or sink to the appropriate endpoint, node, or source.

[Picture] Person A, Keyboard, Source, Node A, Node B, Sink, Display, Person B

Consider a scenario involving a keyboard as an endpoint connected to a source. That source is connected to a node called A. That node is connected to a node called B which is currently servicing a sink. The sink’s endpoint is a display.

Note that the links between the source and node A, node A and node B, and node B and the sink are encrypted. Each element is identified to each other element (including persons A and B) by certificates. The data bundle itself can also be encrypted such that only authorized recipients can decrypt it. When a node decrypts the bundle, it is really returned to its original encrypted state rather than its doubly encrypted state (once for the recipient, once to secure its progress over a particular link.)

If the highest level of DCC is enabled, and person A types a message at his keyboard, and a bundle is created at his source. That bundle is then assigned a unique identifier for tracking purposes and a table is made of the recipients to which the bundle is tracked. In this case, that table would consist of person B’s display.

The source would then decide to send the bundle to node A. (We are assuming that node A is authorized to receive the bundle on behalf of its recipients.) The bundle would be encrypted and transmitted to node A. Node A would then create a tracking entry for the bundle including its data, the fact that it is responsible for getting the bundle to person B’s display and that it is responsible for acknowledging this to A’s source.

Node A would then make a routing decision and decide to send the bundle to node B. It would then encrypt the bundle, and send it to B, noting this in its tracking entry. Node B would decrypt the bundle, and create a tracking entry. Node B would know that it was responsible for getting the bundle to person B’s display and reporting this to node A. Node B would then encrypt the bundle and send it to the sink.

When the sink receives the bundle, it will create a tracking entry as well. The tracking entry will record that it must receive an acknowledgement from the endpoint (person B) and report this to node B. At this point, the sink will send the bundle to the display.

When person B acknowledges receipt of the bundle, say by clicking on it, his endpoint will report this to his sink. The sink will report this to node B, which will report it to node A, which will report it to the source, which will display confirmation to person A.

At this point, each node will collapse its tracking entry merely to record that the bundle was sent successfully, just in case the acknowledgement was missed somewhere along the line. These can later collapse further into a range of acknowledgments indicating that the same target acknowledged a range of bundles that are part of the same stream.

Ultimately, the acknowledgements can be archived or discarded. At the highest level, repositories store tracking records indicating the originating endpoint, source, sink, destination endpoint, and range of bundles successfully acknowledged.

Alarms can be configured if acknowledgements are not received in a timely fashion.

The level of DCC used as well as the type and severity of alarms is dependent upon the level requested by the source endpoint and the minimum and maximum levels authorized for the given data class.

Integration

The L8 architecture includes a source/sink toolkit. This makes it easy for implementers to create their own sources and sinks. They can also specify DCC levels and generate and process acknowledgements in whatever manner is appropriate.

Consider, for example, an airline. They can create a multicast data stream to represent flight progress information. Any device that is capable of sending flight progress information can be integrated with the source/sink toolkit to form a source of flight progress data.

Once this is done, any device anywhere that has a need to access flight progress information can simply be linked with the source/sink toolkit to act as a sink. Thus, flight progress information becomes immediately available at any authorized point in the enterprise.

Message Type:

• Broadcast to all users
• Broadcast to a group of users identified by a group certificate
• Broadcast to a group of ‘interested’ (those that choose to receive the content) users/stations.
• Bundle or stream to a specific user
• Bundle or stream to a specific user
• Bundle or stream to a specific user for receipt only at specified stations

All message types can be sent:

• In the clear (non-encrypted)
• Encrypted based on end user certificate
• The above with a station certificate
• The above with route path certificate(s)
• The above based on a specific window of time for delivery.

All messages can be flagged for immediate (flash) non-stored, or for store and forward with a specific time limit for how long it can be stored.

The system has a built in cryptographically secure storage mechanism that allows users to store streams/bundles either for archival purposes or for store and forward applications.