Seeking a General Purpose CCSDS Link layer Protocol Next Generation Data Link Protocol ( NGDLP )

1. Seeking a General Purpose CCSDS Link layer ProtocolNext Generation Data Link Protocol (NGDLP) Ed Greenberg Greg Kazz 5/1/2012 Proposed Universal Frame Format

2. Major Questions about Transfer Frames • Should/Could we have a single transfer frame format? --for all links? --for only TC and Prox? - Without significant if any protocol changes. • Should we allow multiple concatenated code words to carry a single frame? - Using LDPC codes as done in TC with BCH codes • Must we change the telemetry transfer frame to provide a much larger frame size. - Currently limited by size of first header pointer • Can we get rid of TC segmentation by using M-PDU approach? - TC segmentation is used to provide sub-addressing within a VC and to provide the means to carry very large packets Proposed Universal Frame Format

3. Protocol Link Transmission Unit (PLTU) A PLTU contains a single frame and the attached synchronization marker • A PLTU is composed of a single coded frame prepended with an attached synchronization marker block. The coded frame will consist of an integer number of concatenated code words that form the code block. The last code word in the PLTU is determined from the frame length field presented after the first code word is decoded. • Only one coding option can be supported on a link at any one period of time, but different codes can be used on a link depending on the environment at the time. • Idle bits can be included between PLTUs if the link supports such an option. • Currently TM and AOS do not allow idle bit insertions but it is supported for TC and Proximity links. The new Framing would allow all link layer protocols to allow inclusion of idle as long as an insert zone is not included which is the recommended method. Proposed Universal Frame Format

4. UniversalTRANSFER FRAME STRUCTURE A Transfer Frame shall be composed of seven major fields, positioned contiguously, in the following sequence: • Transfer Frame Header • Secondary Header (optional. self delimiting, flagged) • Security Header (optional, managed) • Transfer Frame Data Field (optional, controlled by length of frame) • Security MAC (optional, managed) • Operational Control Support data field (4 octets, optional, flagged) • Frame Error Control data Field (2 octets, optional. managed) Frame Header Secondary Header Security Header OCS Frame Data Field Security MAC FEC Note An Insert Zone could replace a Secondary header but it only makes sense if the Frames are fixed in length and no idle is allowed between them. Proposed Universal Frame Format

5. Frame Structure Questions (1 of 7) • Version Number • Do we need one? • Will there ever be a mission that would allow multiple frame types to exist at the same time on the same link? • Typically the ground stations are the only places that even need to support multiple frame types but never on the same link at the same time and each link requires pre-pass individual configuration for frame type, coding and managed fields Proposed Universal Frame Format

6. Frame Structure Questions (2 of 7) • Spacecraft ID (SCID) • How many spacecraft IDs are required? • Should this be a Globally unique number • Should this just cover all the entities within an enterprise • Should this include small entities like rovers • Test entities (i.e. prototypes, simulators) • Should the SCID be split to define mission and entity (s/c or mode)? • Do we need both the source and destination identified? • Should we include a source and destination SCID in the frame? • Can the inclusion of a second SCID be signaled • If only one address is provided, is there a need to identify whether the data in the frame is source or destination address? Proposed Universal Frame Format

7. Frame Structure Questions (3 of 7) • Sequence Controlled or Bypass Flag(s) • Sequence is required: • for Command process using FARM and/or COP-1 • For Packet handling when using the M-PDU protocol on a VC. • for bit services using B-MPDU protocol on a VC. • for VCA services on a VC. • Bypass is presently used for FARM processing for TC and Proximity Control Commands that contain complete control commands. • Should the Sequence Number within a VC always be incrementing independent of Bypass Flag Contents or should the Sequence Number only be required to be incrementing when the Flag indicates Sequence? Proposed Universal Frame Format

8. Frame Structure Questions (4 of 7) • Frame Length • Emergency commanding at very low rates (i.e. 8 b/s) require a fairly short command that can be received within an approximate 6 second window. • Very high rate links desire a large frame size to reduce handling issues • Optical frames at gigabit rates could be as large as 32k octets • Commanding has always used a variable length frame • M-PDU first header pointer and B-PDU bit count field would best be limited to 16 bits (2 octets). • Should all frames that carry packets be required to use the M-PDU header or could the data content field (explained later) explicitly identify frames that contain an integer number of complete packets? Proposed Universal Frame Format

9. Frame Structure Questions (5 of 7) • Operational Control Field (CLCW) • May not be required in all links or at all times and thus it seems that inclusion could be flagged instead of managed. Agree? • Sequence Number (SN) • Links using a “Go Back N” Protocol probably only require a 8 bit number • A Go back N protocol would be very inefficient if there were large numbers of frames in transit. • High Rate Recorded Telemetry desires a large number to aid in the reordering process when needed • Both can be satisfied by including a mandatory 1 octet field and an Sequence Number Extension field of 3 bits, providing for an extension by up to 7 octets. • This can also be accommodated by including the MSBs in the secondary header (e.g. CNES’ method for TM Protocol) Proposed Universal Frame Format

10. Frame Structure Questions (6 of 7) • Data Field Content Identifiers (DFCID) • The contents of the frame data field need be limited to a single form that needs to be identified for link protocol processing. Is it necessary to identify the following data type that is included in the Frame Data Field Control Command Data? • An integer number of complete packets • A variable length frame is required and packet size is limited to available space within Frame Data Contents field • An octet string for VCA service • Packets that are handled by the M-PDU service • A string of bits for B-PDU service • Control Command Data used to control operations at the receiving end of the link (i.e. set the receiving data rate, a proximity hail) Proposed Universal Frame Format

11. Frame Structure Questions (7 of 7) • Virtual Channel Identifier (VCID) • How many are required • Each require a separate continuous counter • Typically a VC is constructed by a single entity that can be constructing the frame from data from different sources. • Because of the above, Idle Frames created independently and entered into the link stream, would either require their own VC or the sequence counter field associated with Idle Frames would need to be ignored by a receiving entity. • It would seam likely that in a secure link a separate VC would be the prudent option because of security counter constraints • MAP ID (MID) • MAPs are useful when it is desired to share a VC among separate entities but it complicates M-PDU processing. Proposed Universal Frame Format

12. Can we replace all the CCSDS link layer frames with a single Link Data Unit Format with a Protocol Suite that contains all the elements required for all link types? • Replace all forward error correction codes with high performance code (LDPC or ??) • This requires use of a high performance ASM (64 bits should be adequate) Transitioning of Current Frames • All > How should the frame/code block be terminated to accommodate multiple codewords which can allow variable length? • Proposed method: Allow only 1 frame per PLTU. • > What is the right allocation of bits to VC and MAP…we propose 2 and 5 • TC > Revise VC and MAP and replace TC Segmentation with AOS’ M-PDU approach • Prox: > How should CLCW be included? Optional inclusion with or without data. • > Having source and destination addresses in each frame could aid dissemination • > We are suggesting that the MAP can replace the Output Port field • AOS/TM: > Currently uses 1 LDPC code word per frame and must be fixed in length with no fill/idle between frames. This could be managed or use full capability of protocol • > Supports 32k byte frames for high rate data links (including Optical Links) A Single Frame Structure Idle ASM FRAME ASM FRAME ASM FRAME Idle

13. A Trial TRANSFER FRAME STRUCTURE (1 of 2) • TRANSFER FRAME HEADER ---The Transfer Frame Header is mandatory and shall shall encompass the major fields, positioned contiguously, in the following sequence: • Transfer Frame Version Number (2 bits, mandatory); • Bypass/Sequence Control Flag (1 bit, mandatory); 3) Operational Control Field Flag (CLCW) included (1 bit, mandatory); • Spacecraft Destination Identifier (12 bits, mandatory); ----2 • Spacecraft Source Identifier (12 bits, mandatory); • Data Field Content Identifiers (2 bits) (control command , VCA, M-PDU, B-PDU) • Virtual Channel Identifier (2 bits, mandatory); ----2 • MAP ID (5 bits, mandatory); 9) VC Sequence number Extension Flags (3 bits mandatory) -----1 10) Reserved spare bit (1 bits mandatory) 11) Frame Length (15 bits, mandatory) (Total Frame size including Security); ----2 12) VC Sequence Number Extension (0 to 7 bytes optional).(MSB) 13) VC Sequence Number (8 bits, mandatory).(LSB) -----1 total 8-15 bytes Proposed Universal Frame Format

14. UniversalTRANSFER FRAME STRUCTURE (3 of 3) • SECURITY HEADER (managed size)j • TRANSFER FRAME DATA FIELD (calculated size) • A Transfer Frame Data Field, if contained, shall have a 2 byte header The value in the header will point to the start of the first packet in the M-PDU data field or identifies the number of valid bits contained in the B-PDU data frame. • SECURITY MAC (managed size) • CLCW 2 bytes (optional – flagged) • FEC 2/4 bytes (optional, managed) Proposed Universal Frame Format

15. Frame Format Features A singe coded frame (PLTU) can be composed of a integer number of code words. The PLTU will contain only one frame but it can be of variable size [It is possible to establish a mode for a direct link where the PLTU is fixed size and inter-frame idle is not allowed.] PLTU can contain fill bits/octets in last code word of PLTU (determined by frame length field) Frame Data Field could be zero length (determined by frame length field and managed field sizes) CLCW is flagged [could possibly be only non-header, non-managed data object in frame] Frame sequence number extension is self defined in fixed location of header Frame size field is always in fixed location in frame header Number of Virtual Channels are reduced because each require independent counters A MAP field is included to add local addressing for each VC (providing a VC sub-addresses) Data Frame Content field identifies the type of data included in data field Segments have been dropped because the frame data field supports very long packets using M-PDU and having packets overflow between frames of he same Source+VC+MAP(GVCMID). Insert zone has been removed but could be supported if fixed framing is specified with no idle insertion. This could be a managed mode of operations (i.e. TM/AOS) 1 spare bit is included that can be used to flag a self delimited insert zone (MC) or secondary header (VC) if it is determined that one of them should be included Proposed Universal Frame Format

16. Example PLTU Format One (1) PLTU Code Word Code Word Code Word ASM Code Word Code Word Fill Frame Header Security Header OCS Frame Data Field Security MAC FEC Example Link Layer Operation IDLE IDLE PLTU PLTU PLTU PLTU Note: Each PLTU can have different number of code words and idle can be of any size Proposed Universal Frame Format

17. Data Content Within Frame Data Field • The Data Field Content Identifier Field is 2 bits with 4 defined values: • 00 identifies the content of the data field as Command/Protocol Control data • 01 identifies the content of the data field as VCA data (octets) • 10 identifies the content of the data field as M-PDU data (header + packets) • The first 2 bytes of the data field contains a value that points to the start of the first packet in the M-PDU data field • The remainder of the data field will contain Packet. The packets need not be fully contained within the field but can rollover the excess bytes to the next frame with the same Source S/C ID, VC and MAP. • 11 identifies the content of the data field as B-PDU data (header + bits) • The first 2 bytes of the data field contains a value that identifies the number of valid bits contained in the B-PDU data frame. Proposed Universal Frame Format

18. Frame Use For TC Telecommand FormatNew Format • Transfer Frame Version Number • Bypass/Sequence Control Flag; • Operational Control Field Flag • Spacecraft Destination Identifier ; • Spacecraft Source Identifier ; • Data Field Content Identifiers • Virtual Channel Identifier; • MAP ID (5 bits, mandatory); • Frame Sequence number extension (0) • Reserved spare bit • Frame Length • VC Sequence Number Extension • VC Sequence Number • Transfer Frame Version Number • Bypass/Sequence Control Flag; • Command Control Data • Reserved spare bit • Spacecraft Identifier; • Virtual Channel Identifier; • Frame Length • VC Sequence Number Proposed Universal Frame Format

19. Frame Use For Proximity Proximity FormatNew Format • Transfer Frame Version Number • Bypass/Sequence Control Flag; • Operational Control Field Flag • Spacecraft Destination Identifier • Spacecraft Source Identifier • Data Field Content Identifiers • Virtual Channel Identifier; • MAP ID • Frame Sequence number extension (0) • Reserved spare bit • Frame Length • VC Sequence Number Extension • VC Sequence Number • Transfer Frame Version Number • Bypass/Sequence Control Flag; • PDU Type • Data Field Construction ID • Spacecraft Identifier; • Physical Channel Identifier • Port ID • Source/Destination ID • (not required because both addresses are included) • Frame Length • VC Sequence Number Proposed Universal Frame Format

20. Frame Use For Telemetry AOS FormatNew Format • Transfer Frame Version Number • Bypass/Sequence Control Flag; • Operational Control Field Flag • Spacecraft Destination Identifier • Spacecraft Source Identifier • Data Field Content Identifiers • Virtual Channel Identifier; • MAP ID • Frame Sequence number extension • Reserved spare bit • Frame Length • VC Sequence Number Extension • VC Sequence Number • Transfer Frame Version Number • Spacecraft Identifier • Virtual Channel Identifier • VC Sequence Counter • Replay Flag • Sequence Count Extension Note: Frame length is managed for Telemetry Secondary Header and/or Insert Zone Proposed Universal Frame Format

21. SERVICE MODES Overview The Space Data Link Protocol provides two service modes (Sequence-Controlled and Expedited) that determine how reliably service data units supplied by the sending user are delivered to the receiving user. Each of these services can utilize the CCSDS SLS Service for Crypto services as required by the Mission. • Sequence-Controlled Service –The receiving entity will only accept frames that are delivered with the expected sequence number within a VC from a Source. A reporting field will inform the sender of expected sequence number and of progress conditions. • Expedited Service – The receiving entity will accept all valid frames and deliver them as directed. Current command and proximity operations have build a reliable delivery protocol (COP) on top of the sequence control service. • The COP utilizes an Automatic Repeat Request (ARQ) procedure of the ‘go-back-n’ type to control retransmission of lost frames. The retransmission mechanism ensures with a high probability of success that: a) no service data unit is lost; b) no service data unit is duplicated; c) no service data unit is delivered out of sequence. Proposed Universal Frame Format

22. SUMMARY OF SERVICES Overview Seven services are provided by the Next Generation Data Link Protocol (NGDLP). Three of them (MAP Packet, MAP Bitstream, MAP Channel Access) are provided for a MAP within a Virtual Channel (VC). Three of them (VC Operational Control Field, VC Frame and COP Management Service) are provided for a Virtual Channel. One of them (Master Channel Frame) is provided for a Master Channel. These services are unidirectional, asynchronous and sequence-preserving. The services do not guarantee completeness in the sequence of service data units delivered to a receiving user unless COP-1 is utilized for the Virtual Channel carrying the data. • MAP Packet Service • The MAP Packet Service transfers a sequence of variable-length, delimited, octet-aligned service data units known as Packets across a space link. The Packets transferred by this service must have a Packet Version Number (PVN) authorized by CCSDS. When the service does not guarantee completeness it will not signal gaps in the sequence of service data units delivered to the receiving user • A user of this service is a protocol entity that sends or receives Packets with a single PVN. A user is identified with the PVN and a GVCMID. Different users (i.e., Packets with different versions) can share a single VC MAP Channel, and if there are multiple users on a VC MAP Channel, the service provider multiplexes Packets of different versions to form a single stream of Packets to be transferred on that VC MAP Channel. • Bitstream Service • The Bitstream service provides transfer of a serial string of bits, whose internal structure and boundaries are unknown to the service provider, across a space link. The service is unidirectional, either asynchronous or periodic, and sequence-preserving.. • For a given service instance, only one user, identified with the GVCMID of the Virtual Channel, can use this service on a Virtual Channel. Bitstreams from different users are not multiplexed together within one VC MAP Channel. Proposed Universal Frame Format

23. SUMMARY OF SERVICES (cont) • Virtual Channel Access (VCA) Service • The VC MAP Channel Access (VCA) Service provides transfer of a sequence of privately formatted service data units of integer octets across a space link. The service may signal gaps in the sequence of service data units delivered to the receiving user. • For a given service instance, only one user, identified with the GVCID of the Virtual Channel, can use this service on a VC MAP Channel. Service data units from different users are not multiplexed together within one VC MAP Channel. • Virtual Channel Operational Control Field (VC_OCF) Service • The Virtual Channel Operational Control Field (VC_OCF) Service provides synchronous transfer of fixed-length data units, each consisting of four octets, in the Operational Control Field (OCF) of Transfer Frames of a Virtual Channel. The service is unidirectional and sequence-preserving. The transfer is synchronized with the release of Transfer Frames of a Virtual Channel. The service does not guarantee completeness, but it may signal gaps in the sequence of service data units delivered to the receiving user. • For a given service instance, only one user, identified with the GVCID of the Virtual Channel, can use this service on a Virtual Channel. Service data units from different users are not multiplexed together within one Virtual Channel. • Virtual Channel Frame (VCF) Service • The Virtual Channel Frame (VCF) Service provides transfer of a sequence of fixed-length NGDLP Frames of a Virtual Channel, created by an independent protocol entity, across a space link. The service is unidirectional, either asynchronous or periodic, and sequence-preserving. The service does not guarantee completeness, but it may signal gaps in the sequence of service data units delivered to the receiving user. • For a given service instance, only one user, identified with the GVCID of the Virtual Channel, can use this service on a Virtual Channel. Service data units from different users are not multiplexed together within one Virtual Channel. • The Virtual Channel Frame Service transfers the independently created NGDLP Frames through a space link, together with NGDLP Frames created by the service provider itself. This service is made available to trusted users who are certified during the design process to ensure that the independently created protocol data units do not violate the operational integrity of the space link. Necessarily, the independent Transfer Frames must have the same length as those generated by the service provider. Proposed Universal Frame Format

24. SUMMARY OF SERVICES (cont) • Master Channel Frame (MCF) Service • The Master Channel Frame (MCF) Service provides transfer of a sequence of fixed-length NGDLP Frames of a Master Channel, created by an independent protocol entity, across a space link. The service is unidirectional, either asynchronous or periodic, and sequence-preserving. The service does not guarantee completeness, but it may signal gaps in the sequence of service data units delivered to a receiving user. • For a given service instance, only one user, identified with the MCID of the Master Channel, can use this service on a Master Channel. Service data units from different users are not multiplexed together within one Master Channel. • The Master Channel Frame Service transfers the independently created NGDLP Frames through the space link, together with NGDLP Frames created by the service provider itself. This service is made available to trusted users who are certified during the design process to ensure that the independently created protocol data units do not violate the operational integrity of the space link. Necessarily, the independent Transfer Frames must have the same length as those generated by the service provider. RESTRICTIONS ON ABOVE SERVICES There are some restrictions on the services provided on a Physical Channel, as follows: • a) If the Master Channel Frame Service exists on a Master Channel, other services shall not exist simultaneously on that Master Channel. • b) If the Virtual Channel Frame Service exists on a Virtual Channel, other services shall not exist simultaneously on that Virtual Channel. • c) On a Virtual Channel on which the Virtual Channel Frame Service does not exist, only one Packet Service, Bitstream Service, or Virtual Channel Access Service shall exist simultaneously for each MAP on that VC. Proposed Universal Frame Format