idnits 2.17.1 draft-li-dtn-sd-dtn-sat-net-03.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (November 14, 2017) is 2354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay Tolerant Networking Taixin Li 2 Internet Draft Huachun Zhou 3 Intended status: Informational Bohao Feng 4 Expires: May 2018 Qi Xu 5 Guanwen Li 6 Beijing Jiaotong University 7 November 14, 2017 9 software defined dtn-based satellite networks 10 draft-li-dtn-sd-dtn-sat-net-03.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 May 14,2018. 47 Copyright Notice 49 Copyright (c) 2017 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 Delay/Disruption Tolerant Networking (DTN) is designed for a severe 65 environment where communication quality is not guaranteed. It works 66 as an overlay network associated with Bundle Protocol (BP) and some 67 convergence layer protocols like Licklider Transmission Protocol 68 (LTP). DTN is suitable for satellite networks. Because communication 69 delay is long and peer-to-peer communication is not guaranteed in 70 satellite networks. We implement SDN to solve the problems of 71 controllable, manageable, and flexible in satellite networks. In 72 this document, we propose a framework of Software Defined DTN-based 73 satellite networks, using Bundle tunnel and protocol translation 74 gateway. 76 Table of Contents 78 1. Introduction ................................................. 3 79 2. Conventions used in this document ............................ 3 80 3. Key points of the design ..................................... 3 81 3.1. Separated control plane and forwarding plane ............ 4 82 3.2. Bundle tunnel ........................................... 5 83 3.3. Satellite gateway ....................................... 6 84 4. Use case ..................................................... 7 85 5. Security Considerations ...................................... 8 86 6. IANA Considerations .......................................... 8 87 7. Conclusions .................................................. 8 88 8. References ................................................... 9 89 8.1. Normative References .................................... 9 90 8.2. Informative References .................................. 9 92 9. Acknowledgments ............................................. 9 94 1. Introduction 96 Delay/Disruption Tolerant Networking (DTN) [RFC4838] is designed for 97 a severe environment where connectivity of network is intermittent 98 and communication quality is not guaranteed. It works as an overlay 99 network associated with Bundle Protocol (BP) [RFC5050] and 100 convergence layer protocols like Licklider Transmission Protocol 101 (LTP) [RFC5325] [RFC5326]. 103 We implement DTN in the satellite networks to meet the need of high 104 transmission delay with the help of Interplanetary Overlay Network 105 (ION) [BURLEIGH07]. ION is an implementation of DTN architecture and 106 is designed to enable inexpensive insertion of DTN functionality 107 into embedded systems. 109 SDN [NUNES14] is a state-of-the-art network concept, introducing new 110 possibilities for network management and configuration methods by 111 decoupling the control decisions from forwarding hardware. A 112 controller communicates with the switches by southbound interface, 113 such as OpenFlow [LARA14], which is the core technology of SDN. We 114 apply the idea of SDN to satellite network by separating control 115 plane and forwarding plane in satellite network control structure 116 and taking advantage of the global view of a controller. 118 In this document, we propose a framework of Software Defined DTN- 119 based satellite networks, using Bundle tunnel to deploy OpenFlow 120 over DTN and protocol translation gateway to achieve protocol 121 translation between Bundle packets and IP packets. 123 2. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Key points of the design 131 The idea of SDN is applied in the proposed framework. The control 132 link between the control plane and the forwarding plane is Bundle 133 tunnel. Because we use DTN protocol stack in space network and the 134 protocol stack of ground network is TCP/IP. There should be a 135 protocol translation gateway to achieve protocol translation between 136 Bundle packets and IP packets. 138 3.1. Separated control plane and forwarding plane 140 +------------------------------------+ 141 | +-------------+ | 142 |Control plane |GEO satellite| | 143 | +-------------+ | 144 +--------------+---------------------+ 145 | Control link 146 | One set of ION 147 | configuration script 148 +--------------+---------------------+ 149 | +-------------+ | 150 | +--+MEO satellite| | 151 | | +-------------+ | 152 |Forwarding | Data link | 153 | plane | Another set of ION | 154 | | configuration script| 155 | | +-------------+ | 156 | +--+LEO satellite| | 157 | +-------------+ | 158 +------------------------------------+ 160 Figure 1 Illustration of the two planes 162 We apply the idea of SDN to satellite network by separating control 163 plane and forwarding plane in satellite network control structure 164 and taking advantage of the global view of a controller. The whole 165 space network is divided into two parts, control plane and 166 forwarding plane. The control plane contains Geosynchronous Earth 167 Orbit (GEO) satellites, on which SDN controllers are deployed. The 168 forwarding plane contains Medium Earth Orbit (MEO) satellites and 169 Low Earth Orbit (LEO) satellites, and OpenFlow enabled switches are 170 deployed on them. 172 We implement DTN with the help of ION in space network. The topology 173 configuration mode of ION is reading the configuration scripts (.rc 174 file), which contains the information of connections and nodes. As 175 is shown in Figure 1, to achieve the goal of separating the control 176 plane and forwarding plane in the space network, we adopt two set of 177 unrelated ION configuration scripts when creating the topology. One 178 is the script of Bundle tunnel (or we can say the control link). The 179 other one is the script of data link. Two ION processes run in the 180 MEO/LEO satellite nodes without affecting each other. 182 3.2. Bundle tunnel 184 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 185 X X 186 X Bundle tunnel header X 187 X X 188 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 189 X X 190 X Bundle tunnel payload X 191 X X 192 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 194 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 195 X +---------------------+--------------------+ X 196 X | Ethernet header | IP header | X 197 X +---------------------+--------------------+ X 198 X | UDP header | LTP header | X 199 X +---------------------+--------------------+ X 200 X |Primary Bundle header| Payload header | X 201 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 202 X | OpenFlow signaling data | X 203 X +------------------------------------------+ X 204 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 206 Figure 2 Illustration of bundle tunnel 208 We deploy OpenFlow over DTN by a method of tunnel. That is, 209 signaling packets are transmitted in bundle tunnel when controller 210 (GEO satellite) sets up connection to switches (MEO satellites) and 211 when controllers send instructions to switches. The encapsulation 212 format of the bundle tunnel is shown in Figure 2. Because DTN is 213 implemented in ION in an overlay way, the first half of the Bundle 214 tunnel header is the same as normal IP packets. The difference is 215 that there are a 4-byte LTP header, a 14-byte Primary Bundle header, 216 and a 5-byte Payload header before the payload data field due to the 217 protocol stack of DTN. The link layer field is removed from the 218 OpenFlow signaling packets between controller and switches and then 219 the remaining fields are encapsulated in payload data. 221 The design of the Bundle tunnel adopts a dual process approach. One 222 process is responsible for receiving OpenFlow signaling packets from 223 the local controller or switches. Then signaling data are separated 224 out and encapsulated in the Bundle packets. Finally, the Bundle 225 packets are sent to the control link. The other process is 226 responsible for receiving Bundle packets from the control link and 227 decapsulating the Bundle packets and get the OpenFlow signaling data. 228 Then the signaling data are sent to the local controller or switches. 229 In this way, the SDN controller in GEO satellite can communicate 230 with the OpenFlow enabled switches in MEO/LEO satellites. 232 3.3. Satellite gateway 234 +------------+ +------------+ 235 |Application <-----------------------------------> Application| 236 | data | | data | 237 +------------+ +----------+----------+ +------------+ 238 | |ground| | Bundle |space | Bundle | 239 | | link | +----------+link +------------+ 240 | TCP/UDP <------> TCP/UDP | LTP <------> LTP | 241 | | | +----------+ +------------+ 242 | | | | UDP | | UDP | 243 +------------+ +---------------------+ +------------+ 244 | IPv4/6 | | IPv4/6 | IPv4/6 | | IPv4/6 | 245 +------------+ +----------+----------+ +------------+ 246 ground node satellite gateway satellite node 248 Figure 3 Protocol stacks 250 We use DTN protocol stack in space network and TCP/IP stack in the 251 terrestrial network, so there should be protocol translation for 252 data transmission and service delivery in the Software Defined DTN- 253 based satellite networks framework. We develop DTN to TCP/IP 254 bidirectional protocol translation and deploy this function on the 255 satellite gateways. We deploy DTN with Interplanetary Overlay 256 Network (ION) and modify ION to adapt to IPv6. In this way, ION is 257 IPv4/6 dual stack. If the ground nodes run in IPv6 stack, there is 258 no need for complex protocol translation between IPv4 and IPv6 at 259 the satellite gateway. 261 The protocol stacks of the ground node, satellite gateway node, and 262 satellite node are shown in Figure 3. The physical layer and the 263 data link layer are omitted because they are not involved in the 264 proposed framework. The bidirectional translation between IP packets 265 that belongs to TCP/IP stack and the Bundle packets that belongs to 266 DTN stack is achieved at the satellite gateway by adopting 267 hierarchical, modular, and multi-process protocol translation 268 function. 270 4. Use case 272 GEO satellite 273 +---+XX+---+ 274 +---+XX+---+ 275 X X X X 276 XX X X XX 277 XX X X X 278 Bundle tunnels XX X X X Bundle tunnels 279 XXX X X X 280 XXX X X XX 281 XX X +---+XX+---+ XX 282 +---+XX+---+ X +---+XX+---+ XX 283 +---+XX+---+ X MEO/LEO XX 284 MEO/LEO X satellite3 XX 285 satellite1 X ^ + XX 286 X | | X 287 X | | +---+XX+---+ 288 X | +---------> +---+XX+---+ 289 +---+XX+---+ | Space links MEO/LEO 290 +---+XX+---+----+ satellite4 291 MEO/LEO + 292 satellite2 | 293 ^ | 294 | | 295 +---------+ +----------+ 296 | | 297 + v 298 +-----------+ X X +--------+ 299 |Data Center+------------->XXX XXX+------> User | 300 +-----------+ Ground XXXXX XXXXX +--------+ 301 links Satellite Satellite 302 gateway 1 gateway 2 304 Figure 4 Use case of the proposed framework 306 The use case of proposed framework is shown in Figure 4. The GEO 307 satellite set up control link to the four MEO/LEO satellites. The 308 data center data are transmitted among the four MEO/LEO satellites. 309 The ION configuration script of the control plane is about the 310 connections of one GEO satellite to four MEO/LEO satellites. The ION 311 configuration script of the forwarding plane is about the 312 connections among the four MEO/LEO satellites. That is to say, two 313 sets of unrelated ION processes are running in the four MEO/LEO 314 satellites. 316 A user applies for data from the data center via satellite networks. 317 The traffic is sent to satellite gateway 1 and converted from IP 318 packets to Bundle packets. The controller in GEO satellite send 319 instructions to the MEO/LEO satellites and configure the flow tables 320 of the switches in MEO/LEO satellites. Then the traffic is forwarded 321 via the path: satellite2-->satellite3-->satellite4 under control of 322 GEO satellite. Then, the traffic is sent to satellite gateway 2 and 323 converted from Bundle packets to IP packets. Finally, the data are 324 sent to the user. 326 5. Security Considerations 328 Introducing SDN in DTN-based space network can bring in some 329 problems that any SDN-based frameworks have. The proposed framework 330 adopts a centralized control architecture. So if GEO satellite is 331 attacked (by viruses or physical attack), security problem should be 332 considered. The possible solution may be reserving spare GEO 333 satellite. When the GEO satellite in use breaks down, the spare one 334 will take on the responsibility. 336 6. IANA Considerations 338 This document does not update or create any IANA registries. 340 7. Conclusions 342 This document describes the key points of the design of the proposed 343 Software Defined DTN-based satellite networks framework: Separated 344 control plane and forwarding plane in space network, Bundle tunnel, 345 and satellite protocol translation gateway. And we describe the use 346 case of the proposed framework in this document. 348 8. References 350 8.1. Normative References 352 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 353 R., Scott, K., Fall, K., and Weiss, H., "Delay-Tolerant 354 Networking Architecture", RFC 4838, April 2007. 356 [RFC5050] Scott, K., and Burleigh, S., "Bundle Protocol 357 Specification", RFC 5050, RFC5050, November 2007. 359 [RFC5325] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 360 Transmission Protocol - Motivation", RFC 5325, September 361 2008. 363 [RFC5326] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 364 Transmission Protocol - Specification", RFC 5326, 365 September 2008. 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 8.2. Informative References 372 [BURLEIGH07] Burleigh S. "Interplanetary Overlay Network: An 373 Implementation of the DTN Bundle Protocol" Consumer 374 Communications and NETWORKING Conference (CCNC), 2007, vol. 375 45(2). pp. 147-153, 2007. 377 [NUNES14] B. Nunes, M. Mendonca, X. Nguyen, K. Obraczka, & T, 378 Turletti, "A survey of software-defined networking: Past, 379 present, and future of programmable networks," 380 Communications Surveys & Tutorials, IEEE, vol. 16 (3), pp. 381 1617-1634, Feb. 2014. 383 [LARA14] A. Lara, A. Kolasani, & B. Ramamurthy, "Network Innovation 384 using Openflow: A Survey," Communications Surveys & 385 Tutorials, IEEE, vol. 16(1), pp. 493-512, Feb. 2014. 387 9. Acknowledgments 389 This work in this document was supported by National High Technology 390 of China ("863 program") under Grant No.2015AA015702. 392 Authors' Addresses 394 Taixin Li 395 Beijing Jiaotong University 396 Beijing, 100044, P.R. China 398 Email: 14111040@bjtu.edu.cn 400 Huachun Zhou 401 Beijing Jiaotong University 402 Beijing 100044, P.R. China 404 Email: hchzhou@bjtu.edu.cn 406 Bohao Feng 407 Beijing Jiaotong University 408 Beijing, 100044, P.R. China 410 Email: 11111021@bjtu.edu.cn 412 Qi Xu 413 Beijing Jiaotong University 414 Beijing, 100044, P.R. China 416 Email: 15111046@bjtu.edu.cn 418 Guanwen Li 419 Beijing Jiaotong University 420 Beijing, 100044, P.R. China 422 Email: 14120079@bjtu.edu.cn