idnits 2.17.1 draft-shi-dtn-amcud-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC4838], [RFC5326]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 168 has weird spacing: '...o nodes is kn...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2018) is 2129 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CGR' is mentioned on line 88, but not defined == Missing Reference: 'J' is mentioned on line 302, but not defined == Unused Reference: 'RFC5050' is defined on line 295, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Research Group Wenfeng Shi 2 Internet Draft Qi Xu 3 Intended status: Experimental Bohao Feng 4 Expires: December 24, 2018 Huachun Zhou 5 Beijing Jiaotong University 6 June 25, 2018 8 A Mechanism Coping with Unexpected Disruption in Space Delay 9 Tolerant Networks 10 draft-shi-dtn-amcud-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 19 10, 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on December 24, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Abstract 64 This document proposes a coping mechanism used to deal with the 65 unpredictable disruption problem and congestion control problem in 66 Space Delay Tolerant Networks (DTN) [RFC4838]. Since Licklider 67 Transmission Protocol (LTP) [RFC5326] provides retransmission-based 68 reliability for bundles, several times of retransmissions can be 69 seen as a failure occurred over links. The proposed mechanism is 70 used to direct the following packets to other nodes as soon as the 71 selected path is detected as disruption or congestion and probes the 72 availability of the links which has disrupted unexpectedly. 74 Table of Contents 76 1. Introduction ................................................ 2 77 2. Conventions used in this document............................ 3 78 3. The coping mechanism......................................... 3 79 4. Security Considerations...................................... 6 80 5. IANA Considerations ......................................... 7 81 6. References .................................................. 7 83 1. Introduction 85 Since the moving trajectory of nodes is scheduled in the space 86 network, it's possible to have a prior knowledge of contact 87 information between any nodes. Consequently, routing algorithms such 88 as Contact Graph Routing (CGR) [CGR] can calculate a delivery path 89 from the source to destination hop by hop based on the connectivity 90 relationship, propagation delay, data rate, etc. 92 However, due to the complexity of the space network, the satellite 93 and its associated links suffer from the electromagnetic 94 interference frequently and this may lead to unpredictable 95 disruption for a period of time. Then, the subsequent bundles sent 96 by the source using the initially contact information cannot be 97 transmitted successfully and retransmission is also occurred. As a 98 result, not only the timeliness of bundles cannot be guaranteed but 99 also limited resources of the node and link are consumed and wasted. 100 Thus, it is important to make a mechanism to handle the unexpected 101 disruption problem. 103 What's more, when the direct path to the destination is unreachable, 104 data will be stored at the intermediated nodes and this will consume 105 the node's storage resources. When the remaining storage space of 106 the contact end node is less than the contact capacity, it will 107 increase the risk of network congestion. However, the upstream nodes 108 have no chance to learn the congestion information. Routes that 109 calculated by the source nodes may not be the best choice. So it is 110 urgent to find a scheme to reflect the congestion status to the 111 upstream nodes. 113 This draft proposes a coping mechanism to deal with the contact 114 unexpected disruption problem and the network congestion problem. 115 The contact unexpected disruption coping mechanism works with 116 Licklider Transmission Protocol (LTP) [RFC5326] and routing 117 algorithms such as Contact Graph Routing (CGR) and it is used to not 118 only direct the following bundles to other nodes when the disruption 119 is occurred but also probe the availability of the disrupted links 120 during its claimed valid time. The congestion control mechanism 121 consists of contact congestion forecasting scheme and congestion- 122 aware data forwarding scheme. The contacts are divided into 123 different congestion levels according to nodes' storage resource. And 124 the data with different priority will be forwarded according to the 125 congestion level. 127 2. Conventions used in this document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 3. The coping mechanism 135 Since LTP provides retransmission-based reliability for bundles, 136 several times of retransmissions can be seen as a failure occurred 137 over links. Suppose CGR is used as the routing algorithm. Once the 138 retransmission is detected for more than two times, the contact used 139 in CGR is regarded as temporary corruption. Then, the node marks 140 this contact as temporary disrupted and recalculates the route for 141 subsequent bundles. Besides, a disruption advertisement for the 142 unavailable contact is sent to upstream nodes. When receiving the 143 advertisement, related nodes create disrupting contacts to prevent 144 the use of disrupted links indicated by the advertisement. However, 145 the advertisement may be useless when it arrives at some nodes whose 146 related contacts do not become available until the expiration of the 147 advertisement. Hence, a disruption advertisement group is defined to 148 assure the effectiveness of the contact disruption advertisement. 149 The group contains nodes indicated in corresponding contacts whose 150 "from time" are earlier than the disrupting contact's "to time". 152 When T seconds elapse, a probing message is sent by the node to the 153 destination shown in the disputed contact to check if the 154 connectivity has been recovered.Considering that the contact may be 155 disrupted caused by the damage of satellite, if the detection duration 156 is a fixed short value, it may incur more energy consumption. Thus, it's 157 necessary to set the detection duration dynamically.If the corresponding 158 response is received, the contact will be remarked as recovery and can 159 be used for the following bundles and a contact recovery advertisement 160 is sent to nodes belonging to the advertisement group. Otherwise, node 161 sends a probe message again 2T seconds later. If the corresponding 162 still haven t been received, the node will set the prove message 3T 163 seconds later. Also a maximum detection duration should be set to 164 guarantee the detection accuracy. In this way, the node probes the 165 disrupted link periodically until the contact is recovered or expired. 167 In the space network, the communication start time, end time and 168 transmission rate between two nodes is known in advance and is 169 configured into contact plan in CGR. Thus it is convenient to 170 compute the residual capacity of the contact. When the monitoring 171 node detects that the remaining storage capacity of the node is less 172 than the residual capacity of the contact whose end node is the 173 monitoring node, it will compute the congestion level of the contact. 174 If the remaining capacity of the monitoring node is less than thirty 175 percent of the residual capacity of the contact, the contact will be 176 marked as mild congested. If less than ten percent, the contact will 177 be marked as severe congested. If the capacity of the node is 178 exhausted, the contact will be marked as complete congested. When 179 the congestion level changed, the monitoring node will record the 180 new level of the contact in the contact plan and send contact 181 congestion advertisement to other nodes. 183 As soon as the other node receives the congestion advertisement, it 184 will update the congestion level of the corresponding contact 185 according to the advertisement. When calculating routes, the nodes 186 compute path congestion level as the highest congestion level of the 187 contact consisted in the path and forwarding different priority 188 bundles according to the path congestion level. If there exists no 189 congestion in the path, bundles of all priority can be forwarded in 190 the path. If the congestion level is mild, only urgent and standard 191 bundles can be forwarded. If the congestion level is severe, only 192 urgent bundle can be forwarded. If the congestion level is complete 193 congestion, all bundles should be forwarded using sub optimal path. 194 By this way, we can not only prevent data from been dropped when 195 network suffers from congestion but also leave the transmission 196 opportunity to high priority bundles. 198 +----------+ 199 |Satellite2| 200 +----------+ 201 / | \ 202 / | \ 203 / | \ 204 / | \ 205 +----------+ | +----------+ +----------+ 206 |Satellite1| | |Satellite4|------|Satellite5| 207 +----------+ | +----------+ +----------+ 208 \ | / 209 \ | / 210 \ | / 211 \ | / 212 +----------+ 213 |Satellite3| 214 +----------+ 215 Fig. 1 Example of unexpected contact disruption and congestion control. 217 An example is given to explain the contact disruption handling 218 mechanism. Assume that the contact between Satellite1 and Satellite2 219 is available from 1s to 300s, the contact between Stallite1 and 220 Satellite3 from 100s to 300s, the contact between Satellite3 and 221 Satellite4 from 100s to 300s, the contact between Satellite2 and 222 Satellite4 from 1s to 300s, the contact between Satellite2 and 223 Satellite3 from 1s to 300s, the contact between Satellite4 and 224 Satellite 5 from 400s to 500s. Either Satellite2 or Satellite3 can 225 be used by Satellite1 as relays to send bundles to Satellite5. At 226 initial, Satellite2 is selected to be used. Suppose at one time, 227 the link from Satellite2 to Satellite4 is disrupted. When Satellite2 228 detects the retransmission of bundles two times, it marks the 229 contact to Satellite4 as "temporary disrupted" and recalculates 230 routes for the subsequent bundles. Thus, those bundles will be sent to 231 Satellite3 and then to Satellite4 and Satellite5. In addition, 232 the disruption advertisement group is computed by Satellite2 233 containing Satellite1, Satellite3 and Satellite4. When Satellite1 234 receives the advertisement, it will mark the contact from Satellite2 235 to Satellite4 as "disrupted" and use Satellite3 as the relay. 237 At the same time, Satellite2 will send the probe message to 238 Satellite4 periodically and check if the link is recovered. If 239 Satellite2 receives a response, it will mark the contact as 240 "recovery" and send contact recovery advertisement to satellites 241 included in the advertisement group. If Satellite2 does not receive 242 a response after sending the probing messages, it will resend the 243 probing message again after T seconds. If Satellite2 still haven't 244 received the response after 2T seconds, it will resend the probing 245 message after 3T seconds. Assuming that the maximum detection 246 duration is set to 3T. If satellite2 still haven't received the 247 response after 3T, it will resend the probing message after 3T 248 seconds until the disrupted contact is recovered or expired. 250 Another example is also given to explain the congestion control 251 scheme. Assume that the storage capacity of satellite2 in figure 1 252 is 100Mbytes, the storage capacity of other satellites is 200Mbytes. 253 Assume thatsatellite1 sends one bulk bundle, one standard bundle and 254 one urgent bundle to satellite5 every second. We also assume that 255 the transmission rate is 200kbytes/s and the bundle size is 50kbytes. 256 Initially, Satellite2 is selected to be used. Since the contact time 257 between satellite2 and satellite4 is 100s, bundles will be stored at 258 satellite2 before the contact started. At the start of the 259 transmission, there exists no congestion. With the increase of data 260 stored at satellite2, the storage capacity decreased and when the 261 storage is less than thirty percent of the capacity between 262 satellite1 and sateliite2, satellite2 will find that the contact 263 between satellite1 and satellite2 is mild congested. It will send 264 congestion advertisement to satellite1. After satellite1 receives 265 the advertisement, it will mark the contact between satellite1 and 266 satellite2 as mild congested and using satellite3 as the relay for 267 bulk bundles. The standard and urgent bundle still be forwarded 268 using satellite2 as relay. When satellite2 detects the contact 269 between satellite1 and satellite2 is server congested, it will send 270 congestion advertisement to satellite1 and after satellite1 updates 271 the congestion level, it will forward bulk and standard bundle using 272 satellite3 as relay. When the storage capacity of satellite2 273 exhausted, the contact between satellite1 and satellite2 is complete 274 congested. satellite2 will send congestion advertisement to 275 satellite1. After satellite1 receives and updates the contact plan, 276 it will use satellite3 as relay for all bundles. 278 4. Security Considerations 280 To be done. 282 5. IANA Considerations 284 To be done. 286 6. References 288 [RFC4838] Burleigh S, Hooke A, Torgerson L, et al. RFC4838-Delay- 289 Tolerant Networking Architecture[J]. 2007. 291 [RFC5326] Ramadas M, Burleigh S, Farrell S. RFC 5326, Licklider 292 Transmission Protocol Specification[J]. IRTF DTN Research 293 Group, 2008. 295 [RFC5050] Burleigh, S. Bundle protocol specification. No. RFC 5050. 296 2007. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [I-D. burleigh-dtnrg-cgr] Burleigh S. Contact Graph Routing: draft- 302 burleigh-dtnrg-cgr-01, July 2010[J]. 304 Authors' Addresses 306 Wenfeng Shi 307 Beijing Jiaotong University 308 Beijing, 100044, P.R. China 310 Email: 14111038@bjtu.edu.cn 312 Qi Xu 313 Beijing Jiaotong University 314 Beijing, 100044, P.R. China 316 Email: 15111046@bjtu.edu.cn 318 Bohao Feng 319 Beijing Jiaotong University 320 Beijing, 100044, P.R. China 322 Email: 11111021@bjtu.edu.cn 324 Huachun Zhou 325 Beijing Jiaotong University 326 Beijing, 100044, P.R. China 328 Email: hchzhou@bjtu.edu.cn