Revision as of 13:03, 13 July 2014

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Return to GSoC 2014 Accepted Projects page.

Project overview

Project name: Licklider Transmission Protocol (LTP).

Student: Rubén Martínez

Mentors: Tom Henderson, Tommaso Pecorella

Abstract: Licklider Transmission Protocol (LTP) is a point to point protocol for environments with long round-trip delays (such as deep space communications). This project will provide a RFC compliant implementation, it will consist of a ns-3 module with its corresponding testsuits, examples, helpers and documentation.

Code Repository : http://code.nsnam.org/rmartinez/ns-3-dev-ltp

Approach

This protocol can be deployed at two different leves: on top of either the Data-Link-Layer or the Transport Layer (UDP). The best approach should be to start with an UDP implementation, this will ensure compliance with already existing implementations. A data-link-layer implementation can also be done depending on how the project advances, and will be be taken into consideration after the results of the mid-term review (see schedule section).

Development methodology

I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing. Development will be divided on 3 main tasks:

Task 1: This task consist in developing the ltp-headers and a SDNV codec (Self-Delimiting Numeric Values) a type of data encoding used in DTN protocols. This task consist on defining several data-structures and their serialization/deserialization methods.

Task 2: This task will focus on developing the backbone of the protocol by defining the classes: ltp-packet-queues, ltp-session-records and the basic structure of the ltp-protocol. This will define the main data structures required in control logic used to handle: packets, sessions, protocol state, timers, etc.
Task 3: This task will focus on the Send() and Receive() methods of the ltp-protocol class, these methods implement the control logic of the protocol.

Testing approach

This project will have testing and cross-validation against existing implementations.

First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes. This project will have two kind of tests:

Unit Tests: each task will have a group of test vectors, those tests will ensure that the internal workings of each developed class works in isolation.
System tests: these tests will be provided mainly with examples, it will consist on using the developed module together with already tested ns-3 modules.

Lastly, the implementation will be cross-validated against existing implementations of the LTP, such as ION-DTN (JPL) or LTPlib (Trinity College Dublin). This cross-validation will be performed using a shared file descriptor to which both implementations can read or write traffic. The FdNetDevice class provided by the ns-3 API will be used to achieve this task.

Design

Block Diagram

LTP Protocol Send Logic

LTP Protocol Receive Logic

Deliverables

The final product of the project will be a ns-3 module, so the main deliverables will be the several sections of this module:

Deliverable 1 - model and helper: will contain the main functionalities of the protocol and the helper classes to simplify its use.

Deliverable 1.1 - Packet Headers and SDNV codec.

Deliverable 1.2 - LTP-Protocol auxiliary structures (Data Queues and Session State Records).

Deliverable 1.3 - LTP-Protocol Core.

Deliverable 1.4 - LtpNetDevice.

Deliverable 1.5 - LtpStackHelper.

Deliverable 2 - test: this deliverable will contain the several testsuits used.

Deliverable 2.1 - Unit Tests. Packet Headers and SDNV codec: check correctness.

Deliverable 2.2 - Unit Tests, LTP-Protocol Auxiliary, check methods, timeouts and data handling correctness.

Deliverable 2.3 - Unit Tests, NetDevice implementation, check methods.

Deliverable 2.4 - Unit Tests: protocol implementation, communication between nodes, retransmissions, cancellation of communication.

Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the protocol.
Deliverable 4 - Cross-Validation: This deliverable will contain several tests using FdNetDevices to perform cross-validation with existing implementations. (4.1 early tests basic protocol, 4.2 final validation).

Schedule

Week 1 - May 19 - May 25. D-1.1. D-2.1.
Week 2 - May 26 - June 1.
Week 3 - June 2 - June 8. D-1.2. D-2.2.
week 4 - June 9 - June 15.
Week 5 - June 16 - June 22.
Week 6 - June 23 - June 29: Mid-Term Evaluation.
Week 7 - June 30 - July 6. D-1.3. D-2.3. D-4.1.
Week 8 - June 7 - July 13.
Week 9 - July 14 - July 20. D-1.4.
Week 10 - July 21 - July 27. D-1.5
Week 11 - July 28 - August 3. D-3, D-2.4
Week 12 - August 4 - August 10. D-4.2

Mid Term Review

The code is composed of 2 patches in Rietveld issues 97540043 [1] and 105340046 [2].

The first corresponds to the SDNV [3] encoding supportused in DTN protocols, from which I contributed the test-suite.

The second is a partial implementation of the LTP protocol containing: packet data structures, protocol management classes and basic API functions for communication with higher layer protocols.

To run test suites, the command is ./test.py -s ltp-protocol. Additionally the interested reader can look at the ltp-protocol.rst document, or the wiki page [4] for details on the purpose of each class and how they interact with each other.

Priority Features List

Link state cues (callbacks in convergence layer adapter) : Link Up, Link Down, CP received, RS received, EOB dequeued, CX dequeued.
Management Information Base: Database with times of operation of LTP engines, provides link state cues: Remote peer link Up, Remote peer link Down.
Drop packet procedures: simple discard or Cancellation segment transmission.
Start Transmission procedure: Event triggered on reception of Link Up signal. Response: dequeue and tx all packets.
Start CP Timer: Event triggered on reception of CP received signal, Response: start CP timer.
Stop CP timer : Event triggered on reception of RS segments, response: stop CP timer.
Start RS Timer: Event triggered on reception of RS Timer signal, Response: start RS timer.
Stop RS Timer: Event triggered by reception of RA, response: stop RS timer.
Start Cancel Timer: Event triggered on reception of CX dequeued, response: start cancel timer.
Stop Cancel Timer: Event triggered on reception of CAX segment, response: stop cancel timer.
Stop Transmission procedure: Event triggered on reception of Link Down, Response: start dequeing of segments.
Suspend Timers: Event triggered on reception of Remote peer link Down, Response: suspend timers.
Resume Timers: Event triggered on reception of Remote peer link Up, Response: resume timers.
Retrans CP: Event triggered by expiration of CP timer, Response: Check Retransmission limit, enqueue new CP segment.
Retrans RS: Event triggered by expiration of RS timer, Response: Check Retransmission limit, enqueue new RS segment.
Signify Red Part: Reception of EORP and CP, response: Send notification to Client Service instance.
Signify Green Data Segment: Reception of GD segment, response: Send notification to Client Service instance.
Signify Transmission Completed: All data transmited (signal EOB dequeued) and RP ackd, response: send notification to client service instance and start Close session.
Send RP: Original reception of regular CP or asynchronous CP. Response: perform checks then: 1. drop and send CR OR 2. compute bounds of reception claim and send RP.
Retrans Data: triggered on reception of RS, response: Send RA segment, stop CP timer, if reception claim indicates incomplete data reception: check retransmission limit then send CS if exceeded or retransmit missed Data segment if not.
Retransmit Cancellation segment: triggered on expiration of Cancel timer. response: send copy of CX.
ACK cancellation: triggered on reception of CX, response: if received CS send CAS, if received CR sned CAR.
Cancel Session: triggered on reception of CAX, reponse: stop cancel timer and close session.
Handle Miscolored segments: reception of red-part with offset higher than green-part. response: discard
Handle System Error conditions.
Notifications to Client Service instance: session start, green-part segment arrival, red-part reception, transmission session completion, transmission-session cancellation, reception-session cancellation, initia-transmission complation.
Security Extensions.

Weekly Reports

Week 1

Finished - Deliverables 1.1 and 2.1

Providing SDNV [1] encoding support (this a numeric format commonly used on packet fields of DTN protocols). This encoding format was already implemented in Dizhi Zhou's BP wiki/SOCIS2013BundleProtocolProject project. I have expanded it with the corresponding test-suite and moved it to src/network/utils/, for use in both Bundle and LTP protocols. Currently under review in https://codereview.appspot.com/97540043/]
Implementation of all LTP packet structures, this includes: Segment Header, Segment Trailer, and Content Header (for all segment variants: data, reports, report acknowledgments, etc.). The implementation including the corresponding tests and documentation.

Week 2

Working on Deliverables 1.2 and 2.2

Implementation of the Ltp queue-set, this is a class containing the dual queue structure (internal operations and application data) used for LTP outbound traffic. The implementation and the corresponding test case can be found on the project repository.

Implementation of the session state record, this is a class to keep track of the state of an LTP transmission session, this class is basically a wrapper that handles several flags, counters, timers and lists. An early version can be found in the project repository.

Week 3

Working on Deliverables 1.2 and 2.2

Fixed several issues in the session state record.
Provided a test-case for the session state record.
Provided an early concept design for the LTP API.

Week 4

Working on Deliverables 1.3 and 2.3

Finished the design of the LTP API functions used for interaction with the upper layer.
Included all the required auxiliary structures inside the LTP core class.
Performed minor fixes to auxiliary structures.
Provided a test-case for the LTP API functions.

Week 5