The CFDP InterAgency Test Program

1
The CFDP Inter-Agency Test
Program
A Tale of a Distributed Testbed Richard Carper,
NASA/JPL/GST Massimiliano Ciccone, ESA/ESTEC Eric
Bornschlegl, ESA/ESTEC T5-30
2
The CCSDS File Delivery Protocol (CFDP)

• The CCSDS File Delivery Protocol (CFDP) is
  capable of operating in a wide variety of mission
  configurations.
• from
• relatively simple low earth orbit spacecraft
• to
• complex arrangements of orbiters and landers
  supported by multiple ground facilities and
  transmission links.

3
The CFDP can work for

• reliable or un-reliable Point to Point file (or
  large data block) Transfer,
• reliable file transfer via a Proxy entity, and
• for a reliable or unreliable End-to-End Transfer
  via one or multiple WayPoint entities.
• The CFDP is described in more detail in another
  paper in this Session

4
Projects Considering CFDP

• The CFDP is also appropriate for non-space uses

5
Testing and Protocol Development

• In support of the CFDP protocol development an
  international inter-Agency test program has been
  created
• Five independent implementations of the CFDP were
  made by five different organizations located
  around the world
• The objectives of the test program were to
• Validate the protocol specification
• Clarify the wording of the specification to
  reduce the possibility of differing
  interpretations
• Demonstrate the interoperability of independent
  implementations
• Provide tested reference implementations for
  potential users

6
History

• The first Testing Workshop was hosted in May,
  2000, at APL, Columbia, Maryland It was
  sufficiently productive that it resulted in a
  series of Workshops
• Further face-to-face Workshops were held at DERA,
  Farnborough UK, in November 2000, and then at
  JPL, Pasadena, USA, in May, 2001
• Following the Pasadena Workshop the testing
  migrated to what has become a distributed
  international Inter-Agency Testbed, operating
  over the Internet

7
Face-to-Face Workshops

• The initial Workshops were primarily mutual
  software debugging and development sessions among
  the various protocol implementers
• These were very productive in that role, and also
  established mutual confidence and respect among
  the implementers - a team building process

8
Drivers for a Distributed Testing

• As the implementations (and the process) matured,
  testing began to focus less on software
  development and more on testing the protocol
  specification
• In addition, face-to-face workshops have some
  significant disadvantages
• As they involve extensive travel they are
  necessarily infrequent
• As they involve arranging for a significant
  amount of equipment and working area they require
  a considerable investment of resources by the
  host
• Due to the above, they are expensive

9
Development of the Distributed Testbed
10
Migration to Distributed Testing

• The Internet was the obvious technology to use
  for a distributed testing capability.
• Free
• Available 24 hours per day, 365 days per year
• Provides almost unlimited connectivity (I.e., no
  limit on number of parties involved in tests)
• All involved parties were already connected

11
Migration to Distributed Testing

• Initially the implementers were reluctant to move
  to the Internet because (I believe) it reduced
  their ability to assist one another in debugging,
  and because of the apparent difficulty of
  establishing parallel communications for
  coordination
• The first problem diminished as the maturity of
  the implementations increased
• The latter problem was solved by the simple
  solution of using the AOL Instant Messenger
  service - multi-party, interactive, realtime,
  permanent record (save as a file) and free.

12
CFDP Distributed Testbed
13
Experience with Distributed Testing via the
Internet

• The CFDP implementers have used the Internet for
• testing their implementations with one another as
  part of their software development
• testing the interoperability of the separately
  developed implementations
• proctored tests prior to finalization and
  approval of the CFDP specification

14
Testing Results
15
Results of Testing

• Face-to-face Workshops
• Tests too numerous to keep track of were executed
  in developing both the implementations and the
  protocol
• Distributed Testing
• Both implementation and protocol testing
  continued, on an ad hoc basis
• As a major benchmark, a series of proctored tests
  were held as a Final Exam Week before
  requesting that the CFDP go from Red (draft) to
  Blue (final) status

16
Finals Week for Core Capabilities

• 15 Test Sessions of approximately 4 hours each
  were held with implementers and a proctor
• 490 tests were conducted, of which 462 were
  successful
• Of the unsuccessful tests, areas of the
  specification which were subject to different
  interpretations were found, but no true errors in
  the protocol
• Four of the tests (all successful) simulated an
  inter-entity range of 2.7 million miles (mission
  configuration tests)
• A Finals Week will be held for each of the
  expanded capabilities of the CFDP

17
Lessons Learned

• Testing of an in-design protocol by using
  independently created implementations greatly
  improves the protocol and the specification
  document, and increases confidence in them
• Both face-to-face testing workshops and
  distributed testing are valuable and
  complimentary
• To keep testing focussed and organized, it is
  essential to have a set of common test
  plans/descriptions for all to use in
  inter-implementation testing

18
Limitations of Distributed Testing via the
Internet

• Testing vertically involves a low fidelity model
  (UDP and other Internet lower layer protocols
  between protocol-under-test layers, when they are
  located remotely from one another)
• Because of the Internet layers and the unknown
  delays in the Internet, accurate short term
  performance measurements cannot be made
• HOWEVER - functional testing is valid

19
Current Protocol Status

• The CFDP Core (point-to-point) specification is
  a fully approved CCSDS Recommendation
• The CFDP Extended specification,
  Store-and-Forward Overlay (SFO), and Data
  Product Manager (DPM) are currently draft
  additions to the approved Recommendation, and it
  is planned that they will be fully approved by
  the time of this presentation.
• These additions provide for multiple relay
  operations, using waypoints both in series and
  in parallel.

20
What Next?

• The evolution of CFDP will continue, and the
  distributed testbed will continue in its
  proofing role
• A weakness of current testing is that it has all
  been over UDP. Vertical testing needs to be
  done over other underlying protocols, such as
  Packet Tm/Tc, AOS, SCPS, and Prox-1
• It may be feasible to create a testbed in which
  various implementations are left on-line all (or
  at least most) of the time. This would provide
  support to developers whenever needed, and at
  their convenience