idnits 2.17.1 draft-li-dtn-sd-dtn-sat-net-05.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 5, 2018) is 1999 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 5, 2019 Qi Xu 5 Guanwen Li 6 Beijing Jiaotong University 7 November 5, 2018 9 software defined dtn-based satellite networks 10 draft-li-dtn-sd-dtn-sat-net-05.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 5, 2019. 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 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 228 data. Then the signaling data are sent to the local controller or 229 switches. In this way, the SDN controller in GEO satellite can 230 communicate with the OpenFlow enabled switches in MEO/LEO 231 satellites. 233 3.3. Satellite gateway 235 +------------+ +------------+ 236 |Application <-----------------------------------> Application| 237 | data | | data | 238 +------------+ +----------+----------+ +------------+ 239 | |ground| | Bundle |space | Bundle | 240 | | link | +----------+link +------------+ 241 | TCP/UDP <------> TCP/UDP | LTP <------> LTP | 242 | | | +----------+ +------------+ 243 | | | | UDP | | UDP | 244 +------------+ +---------------------+ +------------+ 245 | IPv4/6 | | IPv4/6 | IPv4/6 | | IPv4/6 | 246 +------------+ +----------+----------+ +------------+ 247 ground node satellite gateway satellite node 249 Figure 3 Protocol stacks 251 We use DTN protocol stack in space network and TCP/IP stack in the 252 terrestrial network, so there should be protocol translation for 253 data transmission and service delivery in the Software Defined DTN- 254 based satellite networks framework. We develop DTN to TCP/IP 255 bidirectional protocol translation and deploy this function on the 256 satellite gateways. We deploy DTN with Interplanetary Overlay 257 Network (ION) and modify ION to adapt to IPv6. In this way, ION is 258 IPv4/6 dual stack. If the ground nodes run in IPv6 stack, there is 259 no need for complex protocol translation between IPv4 and IPv6 at 260 the satellite gateway. 262 The protocol stacks of the ground node, satellite gateway node, and 263 satellite node are shown in Figure 3. The physical layer and the 264 data link layer are omitted because they are not involved in the 265 proposed framework. The bidirectional translation between IP packets 266 that belongs to TCP/IP stack and the Bundle packets that belongs to 267 DTN stack is achieved at the satellite gateway by adopting 268 hierarchical, modular, and multi-process protocol translation 269 function. 271 4. Use case 273 GEO satellite 274 +---+XX+---+ 275 +---+XX+---+ 276 X X X X 277 XX X X XX 278 XX X X X 279 Bundle tunnels XX X X X Bundle tunnels 280 XXX X X X 281 XXX X X XX 282 XX X +---+XX+---+ XX 283 +---+XX+---+ X +---+XX+---+ XX 284 +---+XX+---+ X MEO/LEO XX 285 MEO/LEO X satellite3 XX 286 satellite1 X ^ + XX 287 X | | X 288 X | | +---+XX+---+ 289 X | +---------> +---+XX+---+ 290 +---+XX+---+ | Space links MEO/LEO 291 +---+XX+---+----+ satellite4 292 MEO/LEO + 293 satellite2 | 294 ^ | 295 | | 296 +---------+ +----------+ 297 | | 298 + v 299 +-----------+ X X +--------+ 300 |Data Center+------------->XXX XXX+------> User | 301 +-----------+ Ground XXXXX XXXXX +--------+ 302 links Satellite Satellite 303 gateway 1 gateway 2 305 Figure 4 Use case of the proposed framework 307 The use case of proposed framework is shown in Figure 4. The GEO 308 satellite set up control link to the four MEO/LEO satellites. The 309 data center data are transmitted among the four MEO/LEO satellites. 310 The ION configuration script of the control plane is about the 311 connections of one GEO satellite to four MEO/LEO satellites. The ION 312 configuration script of the forwarding plane is about the 313 connections among the four MEO/LEO satellites. That is to say, two 314 sets of unrelated ION processes are running in the four MEO/LEO 315 satellites. 317 A user applies for data from the data center via satellite networks. 318 The traffic is sent to satellite gateway 1 and converted from IP 319 packets to Bundle packets. The controller in GEO satellite send 320 instructions to the MEO/LEO satellites and configure the flow tables 321 of the switches in MEO/LEO satellites. Then the traffic is forwarded 322 via the path: satellite2-->satellite3-->satellite4 under control of 323 GEO satellite. Then, the traffic is sent to satellite gateway 2 and 324 converted from Bundle packets to IP packets. Finally, the data are 325 sent to the user. 327 5. Security Considerations 329 Introducing SDN in DTN-based space network can bring in some 330 problems that any SDN-based frameworks have. The proposed framework 331 adopts a centralized control architecture. So if GEO satellite is 332 attacked (by viruses or physical attack), security problem should be 333 considered. The possible solution may be reserving spare GEO 334 satellite. When the GEO satellite in use breaks down, the spare one 335 will take on the responsibility. 337 6. IANA Considerations 339 This document does not update or create any IANA registries. 341 7. Conclusions 343 This document describes the key points of the design of the proposed 344 Software Defined DTN-based satellite networks framework: Separated 345 control plane and forwarding plane in space network, Bundle tunnel, 346 and satellite protocol translation gateway. And we describe the use 347 case of the proposed framework in this document. 349 8. References 351 8.1. Normative References 353 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 354 R., Scott, K., Fall, K., and Weiss, H., "Delay-Tolerant 355 Networking Architecture", RFC 4838, April 2007. 357 [RFC5050] Scott, K., and Burleigh, S., "Bundle Protocol 358 Specification", RFC 5050, RFC5050, November 2007. 360 [RFC5325] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 361 Transmission Protocol - Motivation", RFC 5325, September 362 2008. 364 [RFC5326] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 365 Transmission Protocol - Specification", RFC 5326, 366 September 2008. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 8.2. Informative References 373 [BURLEIGH07] Burleigh S. "Interplanetary Overlay Network: An 374 Implementation of the DTN Bundle Protocol" Consumer 375 Communications and NETWORKING Conference (CCNC), 2007, 376 pp. 222-226, 2007. 378 [NUNES14] B. Nunes, M. Mendonca, X. Nguyen, K. Obraczka, & T, 379 Turletti, "A survey of software-defined networking: Past, 380 present, and future of programmable networks," IEEE 381 Communications Surveys & Tutorials, vol. 16 (3), pp. 1617- 382 1634, Feb. 2014. 384 [LARA14] A. Lara, A. Kolasani, & B. Ramamurthy, "Network Innovation 385 using Openflow: A Survey," IEEE Communications Surveys & 386 Tutorials, vol. 16(1), pp. 493-512, Feb. 2014. 388 9. Acknowledgments 390 This work in this document was supported by National High Technology 391 of China ("863 program") under Grant No.2015AA015702. 393 Authors' Addresses 395 Taixin Li 396 Beijing Jiaotong University 397 Beijing, 100044, P.R. China 399 Email: 14111040@bjtu.edu.cn 401 Huachun Zhou 402 Beijing Jiaotong University 403 Beijing 100044, P.R. China 405 Email: hchzhou@bjtu.edu.cn 407 Bohao Feng 408 Beijing Jiaotong University 409 Beijing, 100044, P.R. China 411 Email: 11111021@bjtu.edu.cn 413 Qi Xu 414 Beijing Jiaotong University 415 Beijing, 100044, P.R. China 417 Email: 15111046@bjtu.edu.cn 419 Guanwen Li 420 Beijing Jiaotong University 421 Beijing, 100044, P.R. China 423 Email: 16111011@bjtu.edu.cn