EDIFY - Revision history

Cb at 16:18, 18 July 2006

2006-07-18T16:18:01Z

← Older revision		Revision as of 16:18, 18 July 2006
Line 34:		Line 34:

	I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf here]. Have a look if you're interested what their solution looks like...		I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf here]. Have a look if you're interested what their solution looks like...


			==Material==
			* the paper: [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] by Mooi Choo Chuah, Liang Cheng, Brian D. Davison
			* my slides: [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf are here]

Cb at 16:13, 18 July 2006

2006-07-18T16:13:17Z

← Older revision		Revision as of 16:13, 18 July 2006
Line 3:		Line 3:

	The authors of the paper i investigated think that the "classic" DTN architecture has some severe flaws when it comes to ''dynamic'' groups of ''mobile'' DTN nodes. The proposal - named [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] - points out these flaws in the current (2006) DTN architecture and proposes some enhancements to correct these.		The authors of the paper i investigated think that the "classic" DTN architecture has some severe flaws when it comes to ''dynamic'' groups of ''mobile'' DTN nodes. The proposal - named [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] - points out these flaws in the current (2006) DTN architecture and proposes some enhancements to correct these.


	=="Classic" DTNs==		=="Classic" DTNs==

Cb: /* Intro */

2006-07-18T16:12:51Z

Intro

← Older revision		Revision as of 16:12, 18 July 2006
Line 2:		Line 2:
	So you´ve got the net, now what about the data it should deliver? After examining different aspects of DTNs from TCP replacements over routing to network coding, this section deals with the actual transport of data.		So you´ve got the net, now what about the data it should deliver? After examining different aspects of DTNs from TCP replacements over routing to network coding, this section deals with the actual transport of data.

	The authors of the paper i investigated think that the "classic" DTN architecture has some severe flaws when it comes to ''dynamic'' groups of ''mobile'' ~~dtn~~ nodes. The proposal - named [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] - points out these flaws in the current (2006) DTN architecture and proposes some enhancements to correct these.		The authors of the paper i investigated think that the "classic" DTN architecture has some severe flaws when it comes to ''dynamic'' groups of ''mobile'' DTN nodes. The proposal - named [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] - points out these flaws in the current (2006) DTN architecture and proposes some enhancements to correct these.


	=="Classic" DTNs==		=="Classic" DTNs==

Cb at 16:12, 18 July 2006

2006-07-18T16:12:30Z

← Older revision		Revision as of 16:12, 18 July 2006
Line 2:		Line 2:
	So you´ve got the net, now what about the data it should deliver? After examining different aspects of DTNs from TCP replacements over routing to network coding, this section deals with the actual transport of data.		So you´ve got the net, now what about the data it should deliver? After examining different aspects of DTNs from TCP replacements over routing to network coding, this section deals with the actual transport of data.

		⚫	The authors of the paper i investigated think that the "classic" DTN architecture has some severe flaws when it comes to ''dynamic'' groups of ''mobile'' dtn nodes. The proposal - named [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] - points out these flaws in the current (2006) DTN architecture and proposes some enhancements to correct these.
	The authors of the paper i investigated
⚫	~~think~~ ~~that~~ that the "classic" DTN architecture has some severe flaws when it comes to ''dynamic'' groups of ''mobile'' dtn nodes. The proposal - named [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] - points out these flaws in the current (2006) DTN architecture and proposes some enhancements to correct these.


Line 15:		Line 14:
	To actually be able to communicate with different regions, each region possesses at least one special '''gateway''' node, translating between the region's own protocol and DTN-speak and resolving global (R,L)-style DTN names into local, region-specific ones.		To actually be able to communicate with different regions, each region possesses at least one special '''gateway''' node, translating between the region's own protocol and DTN-speak and resolving global (R,L)-style DTN names into local, region-specific ones.

	While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.		While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions...

Cb at 16:11, 18 July 2006

2006-07-18T16:11:03Z

← Older revision		Revision as of 16:11, 18 July 2006
Line 16:		Line 16:

	While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.		While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.


	==Problems==		==Problems==

Cb: /* "Classic" DTNs */

2006-07-18T16:10:34Z

"Classic" DTNs

← Older revision		Revision as of 16:10, 18 July 2006
Line 8:		Line 8:
	=="Classic" DTNs==		=="Classic" DTNs==
	First, I'll try to clarify some DTN-related things and buzzwords, to be able to explain which flaws of the current design the "Enhanced Disruption and Fault Tolerant Network" tries to correct. I'll concentrate on aspects that relate to EDIFY.		First, I'll try to clarify some DTN-related things and buzzwords, to be able to explain which flaws of the current design the "Enhanced Disruption and Fault Tolerant Network" tries to correct. I'll concentrate on aspects that relate to EDIFY.


	The [http://www.dtnrg.org/docs/tutorials/warthman-1.1.pdf concept] of the [http://www.dtnrg.org DTN research group] views a DTN as a network of networks, as some sort of overlay on top of other nets, being able to support communication between these (maybe diverse) nets. These possibly diverse nets are also called '''region''' in DTN terminology ([http://www.cs.berkeley.edu/~kfall/dtn-icir.pdf]).		The [http://www.dtnrg.org/docs/tutorials/warthman-1.1.pdf concept] of the [http://www.dtnrg.org DTN research group] views a DTN as a network of networks, as some sort of overlay on top of other nets, being able to support communication between these (maybe diverse) nets. These possibly diverse nets are also called '''region''' in DTN terminology ([http://www.cs.berkeley.edu/~kfall/dtn-icir.pdf]).
Line 16:		Line 15:
	To actually be able to communicate with different regions, each region possesses at least one special '''gateway''' node, translating between the region's own protocol and DTN-speak and resolving global (R,L)-style DTN names into local, region-specific ones.		To actually be able to communicate with different regions, each region possesses at least one special '''gateway''' node, translating between the region's own protocol and DTN-speak and resolving global (R,L)-style DTN names into local, region-specific ones.

	While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.		While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.

	==Problems==		==Problems==

Cb at 16:09, 18 July 2006

2006-07-18T16:09:34Z

← Older revision		Revision as of 16:09, 18 July 2006
Line 25:		Line 25:

	Another mere management problem is the joining of regions: The traditional approach makes no statements about merging of networks, not answering some important questions: How is the new region called? Does it get the name of the first or the second region coming together? More important: Who is going to be the new region's gateway?		Another mere management problem is the joining of regions: The traditional approach makes no statements about merging of networks, not answering some important questions: How is the new region called? Does it get the name of the first or the second region coming together? More important: Who is going to be the new region's gateway?


	===mobile regions===		===mobile regions===
Line 30:		Line 31:


			==Solution ?==
⚫	~~These are more or less the core problems that EDIFY tries to solve. They mainly do this by using a new naming scheme for DTNs.~~ I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf here]. Have a look if you're interested ~~how~~ their solution looks like...
			The mentioned problems are the central ones that EDIFY wants to solve. They mainly do this by using a new naming scheme for DTNs.

		⚫	I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf here]. Have a look if you're interested what their solution looks like...

Cb: /* mobile regions */

2006-07-18T16:00:57Z

mobile regions

← Older revision		Revision as of 16:00, 18 July 2006
Line 30:		Line 30:


	These are more or less the core problems that EDIFY tries to solve. They do this ~~mainly~~ using a new naming scheme for DTNs. I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf here]. Have a look if you're interested how their solution looks like...		These are more or less the core problems that EDIFY tries to solve. They mainly do this by using a new naming scheme for DTNs. I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf here]. Have a look if you're interested how their solution looks like...

Cb at 15:59, 18 July 2006

2006-07-18T15:59:33Z

← Older revision		Revision as of 15:59, 18 July 2006
Line 1:		Line 1:
			==Intro==
	===Enhanced Disruption and Fault Tolerant Network===
			So you´ve got the net, now what about the data it should deliver? After examining different aspects of DTNs from TCP replacements over routing to network coding, this section deals with the actual transport of data.
⚫	First, I'll try to clarify some DTN-related things and buzzwords, to be able to explain which flaws of the current design the ~~[http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf~~ "Enhanced Disruption and Fault Tolerant Network" ~~aka. EDIFY]~~ tries to correct. I'll concentrate on aspects that relate to EDIFY.

			The authors of the paper i investigated
			think that that the "classic" DTN architecture has some severe flaws when it comes to ''dynamic'' groups of ''mobile'' dtn nodes. The proposal - named [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] - points out these flaws in the current (2006) DTN architecture and proposes some enhancements to correct these.


⚫	The [http://www.dtnrg.org/docs/tutorials/warthman-1.1.pdf concept] of the [http://www.dtnrg.org DTN research group] views as DTN as a network of networks, as some sort of overlay on top of other nets, being able to support communication between these (maybe diverse) nets. These possibly diverse nets are also called '''region''' in DTN terminology ([http://www.cs.berkeley.edu/~kfall/dtn-icir.pdf]).
			=="Classic" DTNs==
		⚫	First, I'll try to clarify some DTN-related things and buzzwords, to be able to explain which flaws of the current design the "Enhanced Disruption and Fault Tolerant Network" tries to correct. I'll concentrate on aspects that relate to EDIFY.


		⚫	The [http://www.dtnrg.org/docs/tutorials/warthman-1.1.pdf concept] of the [http://www.dtnrg.org DTN research group] views a DTN as a network of networks, as some sort of overlay on top of other nets, being able to support communication between these (maybe diverse) nets. These possibly diverse nets are also called '''region''' in DTN terminology ([http://www.cs.berkeley.edu/~kfall/dtn-icir.pdf]).

	DTN-wide addressing is now done via a tuple '''(region,locator)''', where ''region'' marks a network and ''locator'' a node belonging to this network. Note that addressing ''within'' a region/network can be completely different, it's up to the network how this is done. The (R,L)-addresses are specific to the overlying DTN, used to do inter-group addressing.		DTN-wide addressing is now done via a tuple '''(region,locator)''', where ''region'' marks a network and ''locator'' a node belonging to this network. Note that addressing ''within'' a region/network can be completely different, it's up to the network how this is done. The (R,L)-addresses are specific to the overlying DTN, used to do inter-group addressing.
Line 11:		Line 18:
	While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.		While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.

			==Problems==
			===ad-hoc regions===
	First, why are ''ad-hoc'' regions not supported: The assumption that is made is that nodes within a region are always able to communicate with their region members, gateway nodes being the most crucial ones.		First, why are ''ad-hoc'' regions not supported: The assumption that is made is that nodes within a region are always able to communicate with their region members, gateway nodes being the most crucial ones.

Line 17:		Line 26:
	Another mere management problem is the joining of regions: The traditional approach makes no statements about merging of networks, not answering some important questions: How is the new region called? Does it get the name of the first or the second region coming together? More important: Who is going to be the new region's gateway?		Another mere management problem is the joining of regions: The traditional approach makes no statements about merging of networks, not answering some important questions: How is the new region called? Does it get the name of the first or the second region coming together? More important: Who is going to be the new region's gateway?

			===mobile regions===
	Second, there are problems with ''mobile'' regions: Imagine a whole region/network moving around (e.g. some people in a plane). The traditional approach assumes static, non-moving regions/networks and so are it's assumptions about routing. However, with a moving network, one has to think about new aspects of routing data...		Second, there are problems with ''mobile'' regions: Imagine a whole region/network moving around (e.g. some people in a plane). The traditional approach assumes static, non-moving regions/networks and so are it's assumptions about routing. However, with a moving network, one has to think about new aspects of routing data...

Cb at 15:36, 18 July 2006

2006-07-18T15:36:05Z

New page

===Enhanced Disruption and Fault Tolerant Network===
First, I'll try to clarify some DTN-related things and buzzwords, to be able to explain which flaws of the current design the [http://www.cse.lehigh.edu/~chuah/publications/dtn_globecom_final.pdf "Enhanced Disruption and Fault Tolerant Network" aka. EDIFY] tries to correct. I'll concentrate on aspects that relate to EDIFY.

The [http://www.dtnrg.org/docs/tutorials/warthman-1.1.pdf concept] of the [http://www.dtnrg.org DTN research group] views as DTN as a network of networks, as some sort of overlay on top of other nets, being able to support communication between these (maybe diverse) nets. These possibly diverse nets are also called '''region''' in DTN terminology ([http://www.cs.berkeley.edu/~kfall/dtn-icir.pdf]).

DTN-wide addressing is now done via a tuple '''(region,locator)''', where ''region'' marks a network and ''locator'' a node belonging to this network. Note that addressing ''within'' a region/network can be completely different, it's up to the network how this is done. The (R,L)-addresses are specific to the overlying DTN, used to do inter-group addressing.

To actually be able to communicate with different regions, each region possesses at least one special '''gateway''' node, translating between the region's own protocol and DTN-speak and resolving global (R,L)-style DTN names into local, region-specific ones.

While this addressing scheme is quite fine with static regions, it is unable to deal with ''ad hoc'' or ''mobile'' regions.

First, why are ''ad-hoc'' regions not supported: The assumption that is made is that nodes within a region are always able to communicate with their region members, gateway nodes being the most crucial ones.

But in reality, this isn't true: regions/networks can be split, i.e. the communication within the region can be disrupted (imagine a platoon of soldiers having to split due to enemy fire). Now there are a number of region members that are unable to talk to their region's gateway. Therefore these nodes are now unreachable from other parts of the DTN...

Another mere management problem is the joining of regions: The traditional approach makes no statements about merging of networks, not answering some important questions: How is the new region called? Does it get the name of the first or the second region coming together? More important: Who is going to be the new region's gateway?

Second, there are problems with ''mobile'' regions: Imagine a whole region/network moving around (e.g. some people in a plane). The traditional approach assumes static, non-moving regions/networks and so are it's assumptions about routing. However, with a moving network, one has to think about new aspects of routing data...

These are more or less the core problems that EDIFY tries to solve. They do this mainly using a new naming scheme for DTNs. I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable [http://www2.informatik.hu-berlin.de/~beier/pdfs/iplanet-06-edify.pdf here]. Have a look if you're interested how their solution looks like...