- Student: Dizhi Zhou
- Mentors: : Tommaso Pecorella, Luca Simone Ronga
- Abstract: this project aims to implement the bundle protocol (BP) in NS-3 which includes the bundle node structure and basic function of BP protocol. It is designed to support BP in IETF and CCSDS standard. First, the bundle node is the node installing bundle layer between application layer and transport layer in NS-3. The bundle node structure in this project is designed to be easily run on varied transport layer protocols and provides a unified socket interface to applications. Second, the basic functions of BP protocol are divided into three parts in this project: bundle transmission operations, custody signal support and bundle status report support(optional). This project also includes the test suites and documentations in BP.
- Code: the code can be found in here
- About me: I'm a Ph.D. student in the University of New Brunswick, Canada. My research interests include Multipath TCP (MPTCP) in cooperative wireless network and network simulation. You can find more information about my research in website or LinkedIn.
In NS-3, the bundle protocol (BP) can be seen as a special application, which provides transport layer services to other applications in a delay-tolerant network. The structure of BP in NS-3 is shown below:
applications | ----------------------------------------- | | | | BundleProtocol | | | | | BpClaProtocol ---- BpRoutingProtocol | | | | ----------------------------------------- | Sockets
The rectangle area represents the main classes of BP in NS-3.
- BundleProtocol class implements several BP APIs to applications, such as Register (), Open (), Bind () and so on. Applications can use these APIs to transmit bundles between bundle nodes. The name and functions of these APIs are referenced from a Linux bundle protocol implementation -- DTN2. The other functions implemented in the BundleProtocol class include bundle fragmentation and aggregation, bundle storage and registration storage;
- BpClaProtocol class is a pure abstract class for convergence layer adaptor (CLA). For each transport layer protocol, a new CLA class needs to be inherited from BpClaProtocol. In the existing implementation, only BpTcpClaProtocol is implemented. It uses TCP socket in the transport layer to transmit bundles;
- BpRoutingProtocol class is a pure abstract class, which defines the APIs of bundle routing protocol. In the existing implementation, only BpStaticRoutingProtocol is implemented, which uses a static map between local endpoint id and internet socket address.
In addition to above three core classes, the NS-3 bundle protocol model also includes classes:
- BundleProtocolHelper and BundleProtocolContainer classes, which are implemented to facilitate users to create a bundle node. Then endpoint id data structure is supported at a BpEndpointId class;
- BpEndpointId, which implements the endpoint id data structure for bundle protocol;
- BpHeader, which implements the primary bundle header in RFC 5050.
- BpPayloadHeader, which implements the bundle payload header in RFC 5050.
Bundle protocol APIs
Bundle protocol APIs are called by applications.
The Open () API installs the BundleProtocol and BpClaProtocol classes into a bundle node. Open () is always the first API needed to be called.
Register () API adds an entry in the persistent registration storage. A registration in BP is identified by an endpoint id, which can be get by BuildBpEndpointId () API. If the state field in the register information is "true" (active state), which means that this application desires to receive bundles, Register () triggers the BpClaProtocol to enable a transport layer connection to receive packet (e.g., listen state in TCP).
Unregister () triggers the convergence layer(CLA) to disable the transport layer to receive packets. For example, BpTcpClaProtocol will be called by Unregister to close the tcp connection.
Bind () APIs set the registration state of the local endpoint id to "true". If the state in Register () is "true" already, Bind () does nothing in this case.
This method is called by applications to send a application data unit (ADU) from the source endpoint id to the destination endpoint id. If the ADU size is larger than the bundle size, ADU is divided into several bundles while each bundle includes a primary bundle header and a bundle payload header. The bundle will be stored in the persistent bundle storage in BundleProtocol first. Then the BpClaProtocol establishes the transport layer connection with peer bundle node. Once the transport layer connection is available, the BpClaProtocol will retrieve and send the bundle by a FIFO order from the storage.
Application can use this API to get bundles stored from storage in a FIFO order. The bundle headers are removed before forwarding bundles to the application.
Build an endpoint id based on scheme and ssp strings. In BP of NS-3, each registration has a unique endpoint id. a BundleProtocol calss can be served for multiple registrations in a bundle node.
Users build an endpoint id and set the endpoint id to the bundle protocol.
An example script in src/bundle-protocol/examples is created to show the usage of these APIs. In this section, we show a sample code for registering an application in a bundle node to send bundles.
BpEndpointId eidSender ("dtn", "node0"); // build an endpoint id BundleProtocolHelper bpSender (eidSender); // create a bundle protocol helper bpSender.SetRoutingProtocol (route); // set the bundle routing protocol bpSender.SetRegisterInfo (info); // set the registration information BundleProtocolContainer senders = bpSender.Install (nodes.Get (0)); // the bundle protocol helper calls // following BP APIs: Open (), // SetBpEndpointId (), Register (), Bind (); Ptr<BundleProtocol> sender = senders.Get (0); sender->Send (packet, src, dst); // send the packet from endpoint id src to endpoint id dst. // The src and dst will be transferred into internet socket address // based on bundle routing protocol.
I divide the functions in this project into three parts:
- S1: functions to make sure the bundle can be sent from sender to receiver, node structure, send/receive/forward, static routing, naming syntax.
- S2: control functions for custody transfer, custody signal in AA.
12 weeks from Sep.4 to Nov.24:
- Week1: node structure: the class relationship in NS-3.
- Week2: node structure: the class relationship in NS-3.
- Week3: send and receive without forwarding procedure (two bundle nodes case).
- Week4: send and receive with forwarding procedure (three or more bundle nodes case, forward immediately, not custody transfer scheme).
- Week5: send and receive with forwarding procedure (three or more bundle nodes case, forward immediately, not custody transfer scheme).
- Week6: write test code and documentation for S1.
- Week7: custody signal support (store-and-forward, custody transfer).
- Week8: custody signal support (store-and-forward, custody transfer).
- Week8: write test code and documentation for S2.
- Week9: bundle status support* Week10: bundle status support.
- Week11: write test code and documentation for S3.
- Week12: wrap up.
I would like to express my special thanks of gratitude to Tommaso Pecorella and Tom Henderson, also thanks of Lalith Suresh and Luca Simone Ronga. Thanks for their valuable comments and helps on my work. Thanks for all mentors in NS-3 community to give me this opportunity in SOCIS project.