Patent Application
20130107754
The present disclosure relates to the field of data networks. More specifically, the present disclosure relates to a method for configuring a delay/disruption-tolerant network node, and to a configurable node operable in a delay/disruption-tolerant network.
Delay/disruption-Tolerant Networks (DTN) are capable of operating in highly stressed environments, under conditions of intermittent connectivity, long delays, variable delays and/or high transmission error rates. An example of application of DTN relates to the use of man-made nodes present in deep space, such as satellites, probes and rovers, travelling at great distances from earth within the Solar System. Request For Comments (RFC) 4838 published by the Internet Engineering Task Force (IETF), describes a “Delay-Tolerant Networking Architecture”. RFC 4838 generally describes how problems stemming from use of the traditional Transaction Control Protocol/Internet Protocol (TCP/IP) suite are overcome using a message-oriented overlay on top of TCP/IP.
DTN nodes are identified by use of Endpoint IDentifiers (EID), each DTN node having its own EID and having a routing table of EIDs assigned to neighboring nodes. A specific EID is manually assigned to each DTN node. Because a given DTN node needs to be known by routing tables of its neighboring nodes, adding a new DTN node to a network or modifying an existing DTN node involves a reconfiguration of a plurality of nodes. While some DTN nodes may be present on the ground and may be easily reconfigured, ground-based DTN nodes may be in communication with neighboring DTN nodes present in deep space. Reconfiguration of distant DTN nodes poses evident challenges.
Therefore, there is a need for improved methods and nodes for configuring DTN nodes.
Embodiments of the disclosure will be described by way of example only with reference to the accompanying drawings, in which:
The foregoing and other features will become more apparent upon reading of the following non-restrictive description of illustrative embodiments thereof, given by way of example only with reference to the accompanying drawings.
Various aspects of the present disclosure generally address one or more of the problems of reconfiguring Delay/disruption-Tolerant Network nodes. The present disclosure introduces a method for configuring a DTN node. The method involves generation of a unique identifier part of an endpoint identity. The endpoint identifier is obtained by concatenation of a static identifier part of the endpoint identity with the unique identifier part. A corresponding node is also introduced.
The following terminology is used throughout the present disclosure:
Those of ordinary skill in the art will readily appreciate that communication between nodes, or endpoints, may rely on support from various types of networks comprising various types of communication links and intermediate nodes. Consequently, in the context of the present disclosure, communication between various nodes may be made via other nodes that are not necessarily shown on the drawings. It should thus be understood that expressions such as “sending to” or “receiving from” do not imply that a sending node and a receiving node are connected via a direct physical link.
Referring now to the drawings,
On
It should be understood that the contact header 100 as shown on
The four (4) lower layers 210-216 of the protocol stack 200 form an IP protocol stack and may comprise an IP version 4 (IPv4) protocol suite or an IP version 6 (IPv6) protocol suite, as are well-known to those of ordinary skill in the art. These layers 210-216 may be replaced by other protocol layers without departing from the scope of the present disclosure. The convergence layer 208 may be consequently replaced by another convergence layer without departing from the scope of the present disclosure.
The Peer Node 602 may also generate its own EID, for example by generating its own UID at step 416 and by concatenating a static identifier part with its own UID to form its own EID at step 418. The Peer Node 602 may then store its own EID into a memory at step 420. Alternatively, the Peer Node 602 may have a manually configured EID, stored in a memory at step 420.
The Peer Node 602 may also update the DTN Node 500 with its own EID. For this, the Peer Node 602 may insert its own EID into a contact header at step 422 and forward that contact header towards the DTN Node 500 at step 424.
It should be understood that step 424 does not necessarily follow any of steps 402-414 since EIDs may be independently generated in the DTN Node 500 and in the Peer Node 602, or independently assigned in the Peer Node 602. Likewise, decisions taken in the DTN Node 500 and in the Peer Node 602 to propagate their respective EIDs are independent and may occur at any time following generation or assignment of their respective EIDs. Consequently, the order of steps shown on
Having received the contact header from the Peer Node 602 at step 424, the DTN Node 500 updates its routing table with the EID of the Peer Node 602 at step 426.
The other Peer Node 604 may also generate its own EID, for example by generating its own UID at step 430 and by concatenating a static identifier part with its own UID to form its own EID at step 432. The Peer Node 604 may then store its own EID into a memory at step 434. Alternatively, the Peer Node 604 may have a manually configured EID, stored in a memory at step 434. The Peer Node 604 may then insert its own EID into a contact header at step 436.
A TCPCL connection may be established between the DTN Node 500 and the Peer Node 604 at step 440, the connection being initiated either by the DTN Node 500 or by the Peer Node 604. The DTN Node 500 may then forward a contact header towards the Peer Node 604 at step 442, either carrying the EID of the DTN Node 500 or carrying the EID of the Peer Node 602. Of course, the DTN Node 500 may forward both EIDs in the same step 442 or in distinct steps. The Peer Node 604 updates its routing table with the received EID or EIDs at step 444 and may then forward its own EID to the DTN Node 500 at step 446. The DTN Node 500 may then update its routing table with the EID of the Peer Node 604 at step 448.
An EID of a peer node may be received at the communication port 508, for example as a part of a bundle. The communication port 508 may then forward the EID of the peer node to the processor 502, which in turn may store the EID of the peer node in the routing table 506.
The DTN node 500 may further comprise other elements (not shown) in support of DTN applications conferred thereto. The processor 502 may be capable of generating a UUID. The processor 502 may also be capable of forming or decoding contact headers 100 according to the format described in the foregoing description of
Those of ordinary skill in the art will realize that the description of the nodes and methods for configuring DTN nodes are illustrative only and are not intended to be in any way limiting. Other embodiments will readily suggest themselves to such persons with ordinary skill in the art having the benefit of the present disclosure. Furthermore, the disclosed methods and nodes may be customized to offer valuable solutions to existing needs and problems of configuring DTN nodes.
In the interest of clarity, not all of the routine features of the implementations of the methods and nodes for configuring DTN nodes are shown and described. It will, of course, be appreciated that in the development of any such actual implementation of the methods and nodes, numerous implementation-specific decisions may need to be made in order to achieve the developer's specific goals, such as compliance with application-, system-, network- and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the field of DTN having the benefit of the present disclosure.
In accordance with the present disclosure, the components, process steps, and/or data structures described herein may be implemented using various types of operating systems, computing platforms, network devices, computer programs, and/or general purpose machines. In addition, those of ordinary skill in the art will recognize that devices of a less general purpose nature, such as hardwired devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or the like, may also be used. Where a method comprising a series of process steps is implemented by a computer or a machine and those process steps may be stored as a series of instructions readable by the machine, they may be stored on a tangible medium.
Systems and modules described herein may comprise software, firmware, hardware, or any combination(s) of software, firmware, or hardware suitable for the purposes described herein. Software and other modules may reside on servers, workstations, personal computers, computerized tablets, personal digital assistants (PDA), and other devices suitable for the purposes described herein. Software and other modules may be accessible via local memory, via a network, via a browser or other application or via other means suitable for the purposes described herein. Data structures described herein may comprise computer files, variables, programming arrays, programming structures, or any electronic information storage schemes or methods, or any combinations thereof, suitable for the purposes described herein.
Although the present disclosure has been described hereinabove by way of non-restrictive, illustrative embodiments thereof, these embodiments may be modified at will within the scope of the appended claims without departing from the spirit and nature of the present disclosure.
