[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Delay Tolerant Networking                                     Taixin Li
Internet Draft                                             Huachun Zhou
Intended status: Informational                                    Qi Xu
Expires: June 2017                                           Guanwen Li
                                                            Guanglei Li
                                            Beijing Jiaotong University
                                                      December 8, 2016



               software defined dtn-based satellite networks
                    draft-li-dtn-sd-dtn-sat-net-01.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on June 8, 2017.



Li                      Expires June 8, 2017                  [Page 1]


Internet-Draft     sd-dtn-based satellite networks       December 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   Delay/Disruption Tolerant Networking (DTN) is designed for a severe
   environment where communication quality is not guaranteed. It works
   as an overlay network associated with Bundle Protocol (BP) and some
   convergence layer protocols like Licklider Transmission Protocol
   (LTP). DTN is suitable for satellite networks. Because communication
   delay is long and peer-to-peer communication is not guaranteed in
   satellite networks. We implement SDN to solve the problems of
   controllable, manageable, and flexible in satellite networks. In
   this document, we propose a framework of Software Defined DTN-based
   satellite networks, using Bundle tunnel and protocol translation
   gateway.



Table of Contents


   1. Introduction ................................................. 3
   2. Conventions used in this document ............................ 3
   3. Key points of the design ..................................... 3
      3.1. Separated control plane and forwarding plane ............ 4
      3.2. Bundle tunnel ........................................... 5
      3.3. Satellite gateway ....................................... 6
      3.4. Use case ................................................ 7
   4. Security Considerations ...................................... 8
   5. IANA Considerations .......................................... 8
   6. Conclusions .................................................. 8
   7. References ................................................... 8
      7.1. Normative References .................................... 8
      7.2. Informative References .................................. 9


Li                      Expires June 8, 2017                  [Page 2]


Internet-Draft     sd-dtn-based satellite networks       December 2016


   8. Acknowledgments .............................................. 9

1. Introduction

   Delay/Disruption Tolerant Networking (DTN) [RFC4838] is designed for
   a severe environment where connectivity of network is intermittent
   and communication quality is not guaranteed. It works as an overlay
   network associated with Bundle Protocol (BP) [RFC5050] and
   convergence layer protocols like Licklider Transmission Protocol
   (LTP) [RFC5325] [RFC5326].

   We implement DTN in the satellite networks to meet the need of high
   transmission delay with the help of Interplanetary Overlay Network
   (ION) [BURLEIGH07]. ION is an implementation of DTN architecture and
   is designed to enable inexpensive insertion of DTN functionality
   into embedded systems.

   SDN [NUNES14] is a state-of-the-art network concept, introducing new
   possibilities for network management and configuration methods by
   decoupling the control decisions from forwarding hardware. A
   controller communicates with the switches by southbound interface,
   such as OpenFlow [LARA14], which is the core technology of SDN. We
   apply the idea of SDN to satellite network by separating control
   plane and forwarding plane in satellite network control structure
   and taking advantage of the global view of a controller.

   In this document, we propose a framework of Software Defined DTN-
   based satellite networks, using Bundle tunnel to deploy OpenFlow
   over DTN and protocol translation gateway to achieve protocol
   translation between Bundle packets and IP packets.



2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].



3. Key points of the design

   The idea of SDN is applied in the proposed framework. The control
   link between the control plane and the forwarding plane is Bundle
   tunnel. Because we use DTN protocol stack in space network and the
   protocol stack of ground network is TCP/IP. There should be a


Li                      Expires June 8, 2017                  [Page 3]


Internet-Draft     sd-dtn-based satellite networks       December 2016


   protocol translation gateway to achieve protocol translation between
   Bundle packets and IP packets.

3.1. Separated control plane and forwarding plane

   We apply the idea of SDN to satellite network by separating control
   plane and forwarding plane in satellite network control structure
   and taking advantage of the global view of a controller. The whole
   space network is divided into two parts, control plane and
   forwarding plane. The control plane contains Geosynchronous Earth
   Orbit (GEO) satellites, on which SDN controllers are deployed. The
   forwarding plane contains Medium Earth Orbit (MEO) satellites and
   Low Earth Orbit (LEO) satellites, and OpenFlow enabled switches are
   deployed on them.

   We implement DTN with the help of ION in space network. The topology
   configuration mode of ION is reading the configuration scripts (.rc
   file), which contains the information of connections and nodes. To
   achieve the goal of separating the control plane and forwarding
   plane in the space network, we adopt two set of unrelated ION
   configuration scripts when creating the topology. One is the script
   of Bundle tunnel (or we can say the control link). The other one is
   the script of data link. Two ION processes run in the MEO/LEO
   satellite nodes without affecting each other.
























Li                      Expires June 8, 2017                  [Page 4]


Internet-Draft     sd-dtn-based satellite networks       December 2016


3.2. Bundle tunnel

              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              X                                              X
              X            Bundle tunnel header              X
              X                                              X
              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              X                                              X
              X            Bundle tunnel payload             X
              X                                              X
              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              X +---------------------+--------------------+ X
              X |  Ethernet header    |    IP header       | X
              X +---------------------+--------------------+ X
              X |   UDP header        |    LTP header      | X
              X +---------------------+--------------------+ X
              X |Primary Bundle header|  Payload header    | X
              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              X |       OpenFlow signaling data            | X
              X +------------------------------------------+ X
              XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

                                Figure 1

   We deploy OpenFlow over DTN by a method of tunnel. That is,
   signaling packets are transmitted in bundle tunnel when controller
   (GEO satellite) sets up connection to switches (MEO satellites) and
   when controllers send instructions to switches. The encapsulation
   format of the bundle tunnel is shown in Figure 1. Because DTN is
   implemented in ION in an overlay way, the first half of the Bundle
   tunnel header is the same as normal IP packets. The difference is
   that there are a 4-byte LTP header, a 14-byte Primary Bundle header,
   and a 5-byte Payload header before the payload data field due to the
   protocol stack of DTN. The link layer field is removed from the
   OpenFlow signaling packets between controller and switches and then
   the remaining fields are encapsulated in payload data.

   The design of the Bundle tunnel adopts a dual process approach. One
   process is responsible for receiving OpenFlow signaling packets from
   the local controller or switches. Then signaling data are separated
   out and encapsulated in the Bundle packets. Finally, the Bundle
   packets are sent to the control link. The other process is
   responsible for receiving Bundle packets from the control link and
   decapsulating the Bundle packets and get the OpenFlow signaling


Li                      Expires June 8, 2017                  [Page 5]


Internet-Draft     sd-dtn-based satellite networks       December 2016


   data. Then the signaling data are sent to the local controller or
   switches. In this way, the SDN controller in GEO satellite can
   communicate with the OpenFlow enabled switches in MEO/LEO
   satellites.



3.3. Satellite gateway

      +------------+                                   +------------+
      |Application <-----------------------------------> Application|
      |   data     |                                   |    data    |
      +------------+      +----------+----------+      +------------+
      |            |ground|          |  Bundle  |space |   Bundle   |
      |            | link |          +----------+link  +------------+
      |  TCP/UDP   <------> TCP/UDP  |   LTP    <------>    LTP     |
      |            |      |          +----------+      +------------+
      |            |      |          |   UDP    |      |    UDP     |
      +------------+      +---------------------+      +------------+
      |   IPv4/6   |      | IPv4/6   |  IPv4/6  |      |   IPv4/6   |
      +------------+      +----------+----------+      +------------+
       ground node           satellite gateway         satellite node

                                Figure 2

   We use DTN protocol stack in space network and TCP/IP stack in the
   terrestrial network, so there should be protocol translation for
   data transmission and service delivery in the Software Defined DTN-
   based satellite networks framework. We develop DTN to TCP/IP
   bidirectional protocol translation and deploy this function on the
   satellite gateways. We deploy DTN with Interplanetary Overlay
   Network (ION) and modify ION to adapt to IPv6. In this way, ION is
   IPv4/6 dual stack. If the ground nodes run in IPv6 stack, there is
   no need for complex protocol translation between IPv4 and IPv6 at
   the satellite gateway.

   The protocol stacks of the ground node, satellite gateway node, and
   satellite node are shown in Figure 2. The physical layer and the
   data link layer are omitted because they are not involved in the
   proposed framework. The bidirectional translation between IP packets
   that belongs to TCP/IP stack and the Bundle packets that belongs to
   DTN stack is achieved at the satellite gateway by adopting
   hierarchical, modular, and multi-process protocol translation
   function.





Li                      Expires June 8, 2017                  [Page 6]


Internet-Draft     sd-dtn-based satellite networks       December 2016


3.4. Use case

                           GEO satellite
                           +---+XX+---+
                           +---+XX+---+
                          X   X  X    X
                        XX   X    X    XX
                      XX    X     X      X
   Bundle tunnels   XX      X     X       X    Bundle tunnels
                 XXX       X       X       X
              XXX         X        X        XX
            XX           X    +---+XX+---+    XX
    +---+XX+---+        X     +---+XX+---+      XX
    +---+XX+---+       X        MEO/LEO           XX
      MEO/LEO         X        satellite3           XX
     satellite1      X         ^        +             XX
                     X         |        |               X
                     X         |        |           +---+XX+---+
                     X         |        +---------> +---+XX+---+
               +---+XX+---+    | Space links          MEO/LEO
               +---+XX+---+----+                     satellite4
                 MEO/LEO                                 +
                satellite2                               |
                      ^                                  |
                      |                                  |
                      +---------+             +----------+
                                |             |
                                +             v
    +-----------+               X             X        +--------+
    |Data Center+------------->XXX           XXX+------>  User  |
    +-----------+   Ground    XXXXX         XXXXX      +--------+
                    links   Satellite     Satellite
                            gateway 1     gateway 2

                                Figure 3

   The use case of proposed framework is shown in Figure 3. The GEO
   satellite set up control link to the four MEO/LEO satellites. The
   data center data are transmitted among the four MEO/LEO satellites.
   The ION configuration script of the control plane is about the
   connections of one GEO satellite to four MEO/LEO satellites. The ION
   configuration script of the forwarding plane is about the
   connections among the four MEO/LEO satellites. That is to say, two
   sets of unrelated ION processes are running in the four MEO/LEO
   satellites.




Li                      Expires June 8, 2017                  [Page 7]


Internet-Draft     sd-dtn-based satellite networks       December 2016


   A user applies for data from the data center via satellite networks.
   The traffic is sent to satellite gateway 1 and converted from IP
   packets to Bundle packets. The controller in GEO satellite send
   instructions to the MEO/LEO satellites and configure the flow tables
   of the switches in MEO/LEO satellites. Then the traffic is forwarded
   via the path: satellite2-->satellite3-->satellite4 under control of
   GEO satellite. Then, the traffic is sent to satellite gateway 2 and
   converted from Bundle packets to IP packets. Finally, the data are
   sent to the user.



4. Security Considerations

   Introducing SDN in DTN-based space network can bring in some
   problems that any SDN-based frameworks have. The proposed framework
   adopts a centralized control architecture. So if GEO satellite is
   attacked (by viruses or physical attack), security problem should be
   considered. The possible solution may be reserving spare GEO
   satellite. When the GEO satellite in use breaks down, the spare one
   will take on the responsibility.



5. IANA Considerations

   This document does not update or create any IANA registries.



6. Conclusions

   This document describes the key points of the design of the proposed
   Software Defined DTN-based satellite networks framework: Separated
   control plane and forwarding plane in space network, Bundle tunnel,
   and satellite protocol translation gateway. And we describe the use
   case of the proposed framework in this document.



7. References

7.1. Normative References

   [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
             R., Scott, K., Fall, K., and Weiss, H., "Delay-Tolerant
             Networking Architecture", RFC 4838, April 2007.


Li                      Expires June 8, 2017                  [Page 8]


Internet-Draft     sd-dtn-based satellite networks       December 2016


   [RFC5050] Scott, K., and Burleigh, S., "Bundle Protocol
             Specification", RFC 5050, RFC5050, November 2007.

   [RFC5325] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider
             Transmission Protocol - Motivation", RFC 5325, September
             2008.

   [RFC5326] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider
             Transmission Protocol - Specification", RFC 5326,
             September 2008.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References

   [BURLEIGH07] Burleigh S. "Interplanetary Overlay Network: An
             Implementation of the DTN Bundle Protocol" Consumer
             Communications and NETWORKING Conference (CCNC), 2007,
             vol. 45(2). pp. 147-153, 2007.

   [NUNES14] B. Nunes, M. Mendonca, X. Nguyen, K. Obraczka, & T,
             Turletti, "A survey of software-defined networking: Past,
             present, and future of programmable networks,"
             Communications Surveys & Tutorials, IEEE, vol. 16 (3), pp.
             1617-1634, Feb. 2014.

   [LARA14] A. Lara, A. Kolasani, & B. Ramamurthy, "Network Innovation
             using Openflow: A Survey," Communications Surveys &
             Tutorials, IEEE, vol. 16(1), pp. 493-512, Feb. 2014.



8. Acknowledgments

   This work in this document was supported by National High Technology
   of China ("863 program") under Grant No.2015AA015702.











Li                      Expires June 8, 2017                  [Page 9]


Internet-Draft     sd-dtn-based satellite networks       December 2016


   Authors' Addresses

   Taixin Li
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 14111040@bjtu.edu.cn


   Huachun Zhou
   Beijing Jiaotong University
   Beijing 100044, P.R. China

   Email: hchzhou@bjtu.edu.cn


   Qi Xu
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 15111046@bjtu.edu.cn


   Guanwen Li
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 14120079@bjtu.edu.cn


   Guanglei Li
   Beijing Jiaotong University
   Beijing, 100044, P.R. China

   Email: 15111035@bjtu.edu.cn













Li                      Expires June 8, 2017                 [Page 10]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/