Thursday, November 13, 2014

2.2.2 Architecture of DTN

The DTN architecture implements store and forward message switching by overlaying the bundle layer on top of heterogeneous regional networks. Bundles also called messages (message switched). The bundle layer stores and forward bundle fragments between nodes. A single bundle layer protocol is used in all regional networks and make up a DTN.
DTN designed to use storage within the network to support the store and forward operation over a networking path as shown in Figure 2.8. IP end to end communication in between the source and destination must wait for complete path while DTN store and forward delivery did not need to wait for a complete path. DTN store and forward delivery will perform incremental progress without end to end path. 


Figure 2.8: Store and forward delivery
Application Data Units (ADUs) are a DTN-enabled application that sends messages of arbitrary length.  The bundle layer transformed the ADUs into "bundles" which is a one or more protocol data unit. Bundles are forwarded by DTN nodes and have two or more "blocks" of data as shown in Figure 2.9. 

Figure 2.9: Bundles
Application data or other information in each block used to deliver the containing bundle to its destinations.  Blocks used to hold information in the header or payload portion of protocol data units in other protocol architectures.  It is called "block" instead of "header" because blocks may not appear at the beginning of a bundle due to particular processing requirements [8].
Bundle layer as shown in Figure 2.10 support end to end transfer across heterogeneous network protocol stacks. An essential element of the bundle-based style of forwarding is that bundles have a place to wait in a queue until a communication contact is available.  Size of storage used in this operation is depending on the system requirement. The assumptions for this operation as follows:
i.                    Storage is available and well-distributed throughout the network.
ii.                  Storage is sufficiently persistent and robust to store bundles until forwarding can occur.
iii.                This "store-and-forward" model is a better choice than attempting to effect continuous connectivity or other alternatives.

Figure 2.10: Bundle Space
Bundle Protocol nodes and endpoints are identified by name. Bundle Protocol names are used Uniform Resource Identifier (URI). Each URI begins with a scheme name followed by a series of characters where the syntax is defined by the scheme. This is examples of Bundle Protocol name:
i.                    dtn://thismachine/ping
ii.                  dtn:pop:mailto:myemail@gmail.com
The bundle protocol is designed with a Primary Bundle Block, payload block which contains the ADU data itself and a set of other blocks. The following fields are all present in the primary bundle block [3]:
i.        Creation Timestamp - a concatenation of the bundle is creation time and a monotonically increasing sequence number such that the creation timestamp is guaranteed to be unique for each ADU originating from the same source.  The creation timestamp is based on the time-of-day an application requested an ADU to be sent (not when the corresponding bundle(s) are sent into the network).  DTN nodes are assumed to have a basic time synchronization capability.
ii.      Lifespan - the time-of-day at which the message is no longer useful.  If a bundle is stored in the network (including the source is DTN node) when its lifespan is reached, it may be discarded.  The lifespan of a bundle is expressed as an offset relative to its creation time.
iii.    Class of Service Flags - indicates the delivery options and priority class for the bundle.
iv.    Source EID - EID of the source.
v.      Destination EID - EID of the destination.
vi.    Report-To Endpoint ID - an EID identifying where should be sent.  This may or may not identify the same endpoint as the Source EID.
vii.  Custodian EID - EID of the current custodian of a bundle.
The lifespan field is very useful in an attempt to keep the email data in this offline email system for a longer period of time until it transferred to another device. Another block such as metadata block is used to identify the content. It could be used to implement ‘network as a database’ and can be encrypted separately from the payload. The payload block indicates information about the contained payload and the payload itself.
Binding interprets an endpoint identifier (EID) to select the next hop or next region specific layer the bundle can be forwarded toward its destination. Figure 2.11 shows the bundle layer through every region specific layer. Late binding means that the binding of a bundle is a destination to a particular set of destination identifiers or addresses does not necessarily happen at the bundle source. Binding might occur at the source, during transit or at the destination. DTN nodes use some form of persistence storage and stored bundles can maintain even if the system restarts. Persistence assumes that storage is available, distributed well through the network and store bundles sufficiently until forwarding can occur [9].

Figure 2.11: Bundle Overlay
DTN can store bundles at intermediate nodes. It can still route even there is a waiting time. Primarily the route will be forwarded to the nodes that will have connectivity later on. In Figure 2.12, data can be transferred directly between user computer A (PC A) and user computer B (PC B) when both are connected. When the PC B is disconnected, DTN routes data to Temporary Data Storage and deliver it later to the PC B. When the PC B is reconnected, data stored in the Temporary Data Storage is delivered even if PC A is disconnected. 

Figure 2.12: Bundle Routing
Security also can be provided to protect against unauthorized use. Bundle Authentication Block (BAB) as shown in Figure 2.13 [7], provides hop-by-hop authentication and integrity protection for the bundle between adjacent bundle nodes. Unauthorized resource utilization can be prevented by enabling modified bundles to be detected and discarded at the first node at the destination receiver.


Figure 2.13: Bundle Authentication Block (BAB)

No comments:

Post a Comment