ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
BP for CCSDS Section 6 ReferenceRequirement TextTest / item to logSimple1
2
3
6.1.1RFC5050
4
6.1.1ECOSSubsumed by 6.2.1.1.f below.
5
6.1.1CBHESubsumed by 6.2.1.1.e below.
6
6.1.1Section 3 of this documentCovered below
7
6.1.1Services described in section 4Covered below
8
6.2.1.1.aBundle structure as described in RFC 5050 sections 3.1, 4.0, 4.2, 4.4, 5.8, and 8
9
RFC5050 3.1 -- DefinitionsBundle is composed of 'blocks' -- block format and concatenation.X
10
RFC5050 4.0 -- Bundle FormatEach bundle has at least two block structuresX
11
First block must be the primary bundle blockX
12
No bundle may have more than one primary bundle blockX
13
At most one payload blockX
14
Only the block in sequence must have 'last block' bit set to one; all others (except primary) must have 'last block' set to zero.X
15
RFC5050 4.2 -- Bundle Processing Control Flags0 - Bundle is a fragment
16
1 - Application data unit is an administrative record
17
2 - Bundle must not be fragmented
18
3 - Custody transfer requested
19
4 - Destination endpoint is singletonX
20
5 - Acknowledgement by application requested
21
7,8 - Proirity00
22
9 to 13 - Reserved
23
14 - Request reporting of bundle reception
24
15 - Request reporting of custody acceptance
25
16 - Request reporting of bundle forwarding
26
17 - Request reporting of bundle delivery
27
18 - Request reporting of bundle deletion
28
19, 20 - Reserved
29
RFC5050 4.4 -- Endpoint IDsEndpoint IDs are text strings identified by <scheme name>:<scheme-specific part>
Note: this is how Endopoint IDs are expressed to the user / application or in the dictionary when NOT using CBHE.		X
30
EIDs stored in dictionary of primary bundle block -- references are first, last character index.
31
dtn:none is supported
32
RFC5050 5.8 -- Bundle FragmentationConcatenation of fragment payloads == original payloadX
33
Bundle processing flags of primary blocks of fragments have the fragment bit set.
34
Fragment offsest and total ADU length set in primary bundle blocks of fragments.
35
All blocks that precede the payload block at the time of fragmentation must be replicated in the fragment with the lowest offset
36
All blocks that follow the payload block at the time of fragmentation must be replicated in the fragment with the highest offset.
37
If the 'Block must be replicated in every fragment' bit is set to 1, then the block must be replicated in every fragment.
38
If the 'Block must be replicated in every fragment' bit is set to zero, the block should be replicated in only one fragment.
39
The relative order of all blocks that are present in a fragment must be the same as in the bundle prior to fragmentation.
40
RFC5050 8 -- Security ConsiderationsBundle Security Protocol Implementation not mandatory per Normative References
41
6.2.1.1.bBlock structure as described in RFC 5050 sections 4.1, 4.5, 4.5.1, 4.5.2, 4.5.3, 4.6, 4.7
42
RFC5050 4.1 -- Self-Delimiting Numeric Values (SDNVs)Self-delimiting numerical values -- ensure that we exercise at least 1- and 2-byte SDNV lengths.1
43
RFC5050 4.5
44
RFC5050 4.5.1 -- Primary Bundle BlockPrimary Bundle Block Format -- bundle transmission / reception indicates compliance.X
45
RFC5050 4.5.2 -- Canonical Bundle Block FormatBlock type codeList of block type codes: [- (Primary Block), 0 (Payload Block)]
46
Block processing control flags (covered below)
47
Block EID reference count (optional)List of block EID reference counts: [N/A, 0]
48
Block data lengthList of block data lengths: [N/A, ????]
49
Block data (type-specific)List of block data: [N/A, payload]
50
RFC5050 4.5.3 -- Bundle Payload BlockBundle Payload Block Format: 'block contains EID Reference field' never set.X
51
RFC5050 4.6 -- Extension BlocksWhenever a bundle is forwarded that contains one or more extension blocks that could not be processed, the "Block was forwarded without being processed" flag must be set to 1 within the block processing flags of each such block
52
For each block flagged in this way, the flag may optionally be cleared (i.e., set to zero) by another node that subsequently receives the bundle and is able to process that block
53
RFC5050 4.7 -- Dictionary RevisionCause a dictionary revision to happen (DTN2)
54
6.2.1.1.cAdministrative record generation and structure as described in RFC 5050 section 5.1, 6.0, 6.1, and 6.2;
55
RFC 5050 5.1 -- Generation of Administrative Records
56
Generation of adminstrative record: bundle reception status report
57
Generation of adminstrative record: custody acceptance status report (succeeded)
58
Generation of adminstrative record: custody acceptance status report (failed)
59
Generation of administrative record: bundle forwarding status report
60
Generation of administrative record: bundle delivery status report
61
Generation of administrative record: bundle deletion status report
62
RFC 5050 6.0 -- Administrative Record ProcessingN/A -- no section 6.0; all subsections (6.1--6.3 inclusive) covered below.
63
RFC 5050 6.1 -- Administrative RecordsCorrect processing of administrative records indicates compliance; manual packet inspection may also be used.
64
RFC 5050 6.2 -- Generation of Administrative RecordsEvidence of transmission of administrative records indicates compliance.
65
6.2.1.1.dRFC 5050 sections 6.1.1, 6.1.2, and 6.3;
66
RFC 5050 6.1.1 -- Bundle Status ReportsCorrect processing / display of administrative records indicates compliance; manual inspection of packets may be done as well.
67
RFC 5050 6.1.2 -- Custody Transfer SignalsCorrect custody behavior indicates compliance; manual inspection of packets may be done as well.
68
RFC 5050 6.3Correct custody behavior indicates compliance.
69
6.2.1.1.eCBHE in accordance with RFC 6260 and section 3 of this document;Use of ipn: scheme and packet inspection to verify CBHE is used.X
70
6.2.1.1.fECOS in accordance with annex C and section 3 of this document.
71
C2 a)Block Type: XX
72
C2 b)Block processing control flags: block replicated in every fragment is 1
73
C2 c)Block contains no EID references
74
C2 d)Block data length is 2+N
75
C2 e)Block data comprises at least two and possibly three fields.
76
C2 f)First field is 8-bit flags
77
0x01 -- Critical bundles forwarded on every path (covered below)
78
0x02 -- Streaming - use best-effort CL (covered below)
79
0x04 -- Block contains flow label
80
0x08 -- Bundle requires reliable transmission (use reliable CL) (covered below)
81
C2 g)8-bit ordinal priority value
82
C3.1.1ECOS block precedes payload
83
C3.1.2No bundle shall contain more than one ECOS block
84
C3.1.3If the ECOS block contains a flow label, bit 0x04 of the flags byte shall be 1 and the flow label shall be represented as an SDNV
85
C3.1.4Ordinal byte contains unsigned integer
86
Value of ordinal byte for custody signals shall be 255
87
C3.2.2Critical bundles (flag 0x01) forwarded along all reasonable paths
88
Streaming bundles (flag 0x02) forwarded using non-reliable CLs
89
Reliable bundles (flag 0x08) forwarded via reliable CLs
90
Streaming service (0x02 and 0x08) forwarded via streaming CLA
91
6.2.1.2.1.aSender bundle transmission as described in RFC 5050 sections 3.3, 4.3, 5.15, and 5.2
92
RFC5050 3.3 -- Services Offered by Bundle Protocol AgentsCommencing a registration (local)X
93
Terminating a registration (local)
94
Switching a registration between Active and Passive States (local)
95
Transmitting a bundle to an identified bundle endpoint.X
96
Canceling a transmission (local)
97
Polling a registration that is in the passive state (local)
98
Delivering a received bundle.X
99
RFC5050 4.3 -- Block Processing Control Flags
100
 0 - Block must be replicated in every fragment.List of entries for this flag: [N/A, ???]