idnits 2.17.1 draft-li-dtn-sd-dtn-sat-net-01.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 (December 8, 2016) is 2689 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 Qi Xu 4 Expires: June 2017 Guanwen Li 5 Guanglei Li 6 Beijing Jiaotong University 7 December 8, 2016 9 software defined dtn-based satellite networks 10 draft-li-dtn-sd-dtn-sat-net-01.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 June 8, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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 3.4. Use case ................................................ 7 85 4. Security Considerations ...................................... 8 86 5. IANA Considerations .......................................... 8 87 6. Conclusions .................................................. 8 88 7. References ................................................... 8 89 7.1. Normative References .................................... 8 90 7.2. Informative References .................................. 9 92 8. 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 We apply the idea of SDN to satellite network by separating control 141 plane and forwarding plane in satellite network control structure 142 and taking advantage of the global view of a controller. The whole 143 space network is divided into two parts, control plane and 144 forwarding plane. The control plane contains Geosynchronous Earth 145 Orbit (GEO) satellites, on which SDN controllers are deployed. The 146 forwarding plane contains Medium Earth Orbit (MEO) satellites and 147 Low Earth Orbit (LEO) satellites, and OpenFlow enabled switches are 148 deployed on them. 150 We implement DTN with the help of ION in space network. The topology 151 configuration mode of ION is reading the configuration scripts (.rc 152 file), which contains the information of connections and nodes. To 153 achieve the goal of separating the control plane and forwarding 154 plane in the space network, we adopt two set of unrelated ION 155 configuration scripts when creating the topology. One is the script 156 of Bundle tunnel (or we can say the control link). The other one is 157 the script of data link. Two ION processes run in the MEO/LEO 158 satellite nodes without affecting each other. 160 3.2. Bundle tunnel 162 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 163 X X 164 X Bundle tunnel header X 165 X X 166 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 167 X X 168 X Bundle tunnel payload X 169 X X 170 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 172 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 173 X +---------------------+--------------------+ X 174 X | Ethernet header | IP header | X 175 X +---------------------+--------------------+ X 176 X | UDP header | LTP header | X 177 X +---------------------+--------------------+ X 178 X |Primary Bundle header| Payload header | X 179 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 180 X | OpenFlow signaling data | X 181 X +------------------------------------------+ X 182 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 184 Figure 1 186 We deploy OpenFlow over DTN by a method of tunnel. That is, 187 signaling packets are transmitted in bundle tunnel when controller 188 (GEO satellite) sets up connection to switches (MEO satellites) and 189 when controllers send instructions to switches. The encapsulation 190 format of the bundle tunnel is shown in Figure 1. Because DTN is 191 implemented in ION in an overlay way, the first half of the Bundle 192 tunnel header is the same as normal IP packets. The difference is 193 that there are a 4-byte LTP header, a 14-byte Primary Bundle header, 194 and a 5-byte Payload header before the payload data field due to the 195 protocol stack of DTN. The link layer field is removed from the 196 OpenFlow signaling packets between controller and switches and then 197 the remaining fields are encapsulated in payload data. 199 The design of the Bundle tunnel adopts a dual process approach. One 200 process is responsible for receiving OpenFlow signaling packets from 201 the local controller or switches. Then signaling data are separated 202 out and encapsulated in the Bundle packets. Finally, the Bundle 203 packets are sent to the control link. The other process is 204 responsible for receiving Bundle packets from the control link and 205 decapsulating the Bundle packets and get the OpenFlow signaling 206 data. Then the signaling data are sent to the local controller or 207 switches. In this way, the SDN controller in GEO satellite can 208 communicate with the OpenFlow enabled switches in MEO/LEO 209 satellites. 211 3.3. Satellite gateway 213 +------------+ +------------+ 214 |Application <-----------------------------------> Application| 215 | data | | data | 216 +------------+ +----------+----------+ +------------+ 217 | |ground| | Bundle |space | Bundle | 218 | | link | +----------+link +------------+ 219 | TCP/UDP <------> TCP/UDP | LTP <------> LTP | 220 | | | +----------+ +------------+ 221 | | | | UDP | | UDP | 222 +------------+ +---------------------+ +------------+ 223 | IPv4/6 | | IPv4/6 | IPv4/6 | | IPv4/6 | 224 +------------+ +----------+----------+ +------------+ 225 ground node satellite gateway satellite node 227 Figure 2 229 We use DTN protocol stack in space network and TCP/IP stack in the 230 terrestrial network, so there should be protocol translation for 231 data transmission and service delivery in the Software Defined DTN- 232 based satellite networks framework. We develop DTN to TCP/IP 233 bidirectional protocol translation and deploy this function on the 234 satellite gateways. We deploy DTN with Interplanetary Overlay 235 Network (ION) and modify ION to adapt to IPv6. In this way, ION is 236 IPv4/6 dual stack. If the ground nodes run in IPv6 stack, there is 237 no need for complex protocol translation between IPv4 and IPv6 at 238 the satellite gateway. 240 The protocol stacks of the ground node, satellite gateway node, and 241 satellite node are shown in Figure 2. The physical layer and the 242 data link layer are omitted because they are not involved in the 243 proposed framework. The bidirectional translation between IP packets 244 that belongs to TCP/IP stack and the Bundle packets that belongs to 245 DTN stack is achieved at the satellite gateway by adopting 246 hierarchical, modular, and multi-process protocol translation 247 function. 249 3.4. Use case 251 GEO satellite 252 +---+XX+---+ 253 +---+XX+---+ 254 X X X X 255 XX X X XX 256 XX X X X 257 Bundle tunnels XX X X X Bundle tunnels 258 XXX X X X 259 XXX X X XX 260 XX X +---+XX+---+ XX 261 +---+XX+---+ X +---+XX+---+ XX 262 +---+XX+---+ X MEO/LEO XX 263 MEO/LEO X satellite3 XX 264 satellite1 X ^ + XX 265 X | | X 266 X | | +---+XX+---+ 267 X | +---------> +---+XX+---+ 268 +---+XX+---+ | Space links MEO/LEO 269 +---+XX+---+----+ satellite4 270 MEO/LEO + 271 satellite2 | 272 ^ | 273 | | 274 +---------+ +----------+ 275 | | 276 + v 277 +-----------+ X X +--------+ 278 |Data Center+------------->XXX XXX+------> User | 279 +-----------+ Ground XXXXX XXXXX +--------+ 280 links Satellite Satellite 281 gateway 1 gateway 2 283 Figure 3 285 The use case of proposed framework is shown in Figure 3. The GEO 286 satellite set up control link to the four MEO/LEO satellites. The 287 data center data are transmitted among the four MEO/LEO satellites. 288 The ION configuration script of the control plane is about the 289 connections of one GEO satellite to four MEO/LEO satellites. The ION 290 configuration script of the forwarding plane is about the 291 connections among the four MEO/LEO satellites. That is to say, two 292 sets of unrelated ION processes are running in the four MEO/LEO 293 satellites. 295 A user applies for data from the data center via satellite networks. 296 The traffic is sent to satellite gateway 1 and converted from IP 297 packets to Bundle packets. The controller in GEO satellite send 298 instructions to the MEO/LEO satellites and configure the flow tables 299 of the switches in MEO/LEO satellites. Then the traffic is forwarded 300 via the path: satellite2-->satellite3-->satellite4 under control of 301 GEO satellite. Then, the traffic is sent to satellite gateway 2 and 302 converted from Bundle packets to IP packets. Finally, the data are 303 sent to the user. 305 4. Security Considerations 307 Introducing SDN in DTN-based space network can bring in some 308 problems that any SDN-based frameworks have. The proposed framework 309 adopts a centralized control architecture. So if GEO satellite is 310 attacked (by viruses or physical attack), security problem should be 311 considered. The possible solution may be reserving spare GEO 312 satellite. When the GEO satellite in use breaks down, the spare one 313 will take on the responsibility. 315 5. IANA Considerations 317 This document does not update or create any IANA registries. 319 6. Conclusions 321 This document describes the key points of the design of the proposed 322 Software Defined DTN-based satellite networks framework: Separated 323 control plane and forwarding plane in space network, Bundle tunnel, 324 and satellite protocol translation gateway. And we describe the use 325 case of the proposed framework in this document. 327 7. References 329 7.1. Normative References 331 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 332 R., Scott, K., Fall, K., and Weiss, H., "Delay-Tolerant 333 Networking Architecture", RFC 4838, April 2007. 335 [RFC5050] Scott, K., and Burleigh, S., "Bundle Protocol 336 Specification", RFC 5050, RFC5050, November 2007. 338 [RFC5325] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 339 Transmission Protocol - Motivation", RFC 5325, September 340 2008. 342 [RFC5326] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 343 Transmission Protocol - Specification", RFC 5326, 344 September 2008. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 7.2. Informative References 351 [BURLEIGH07] Burleigh S. "Interplanetary Overlay Network: An 352 Implementation of the DTN Bundle Protocol" Consumer 353 Communications and NETWORKING Conference (CCNC), 2007, 354 vol. 45(2). pp. 147-153, 2007. 356 [NUNES14] B. Nunes, M. Mendonca, X. Nguyen, K. Obraczka, & T, 357 Turletti, "A survey of software-defined networking: Past, 358 present, and future of programmable networks," 359 Communications Surveys & Tutorials, IEEE, vol. 16 (3), pp. 360 1617-1634, Feb. 2014. 362 [LARA14] A. Lara, A. Kolasani, & B. Ramamurthy, "Network Innovation 363 using Openflow: A Survey," Communications Surveys & 364 Tutorials, IEEE, vol. 16(1), pp. 493-512, Feb. 2014. 366 8. Acknowledgments 368 This work in this document was supported by National High Technology 369 of China ("863 program") under Grant No.2015AA015702. 371 Authors' Addresses 373 Taixin Li 374 Beijing Jiaotong University 375 Beijing, 100044, P.R. China 377 Email: 14111040@bjtu.edu.cn 379 Huachun Zhou 380 Beijing Jiaotong University 381 Beijing 100044, P.R. China 383 Email: hchzhou@bjtu.edu.cn 385 Qi Xu 386 Beijing Jiaotong University 387 Beijing, 100044, P.R. China 389 Email: 15111046@bjtu.edu.cn 391 Guanwen Li 392 Beijing Jiaotong University 393 Beijing, 100044, P.R. China 395 Email: 14120079@bjtu.edu.cn 397 Guanglei Li 398 Beijing Jiaotong University 399 Beijing, 100044, P.R. China 401 Email: 15111035@bjtu.edu.cn