seeking a general purpose ccsds link layer protocol next generation data link protocol ( ngdlp )

Proposed Universal Frame Format 1

Seeking a General Purpose CCSDS Link layer Protocol

Next Generation Data Link Protocol (NGDLP)

Ed GreenbergGreg Kazz5/1/2012

5/1/12


Major Questions about Transfer Frames1. Should/Could we have a single transfer frame format? --for

all links? --for only TC and Prox? - Without significant if any protocol changes.

2. Should we allow multiple concatenated code words to carry a single frame?

- Using LDPC codes as done in TC with BCH codes3. Must we change the telemetry transfer frame to provide a

much larger frame size. - Currently limited by size of first header pointer

4. 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

5/1/12


Protocol Link Transmission Unit (PLTU)

• 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.

5/1/12

A PLTU contains a single frame and the attached synchronization marker


Universal TRANSFER FRAME STRUCTURE

A Transfer Frame shall be composed of seven major fields, positioned contiguously, in the following sequence:

1) Transfer Frame Header 2) Secondary Header (optional. self delimiting, flagged)3) Security Header (optional, managed)4. Transfer Frame Data Field (optional, controlled by length of frame)5) Security MAC (optional, managed)6) Operational Control Support data field (4 octets, optional, flagged)7) Frame Error Control data Field (2 octets, optional. managed)

Frame Header Frame Data Field Security

MAC OCS FECSecurity Header

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.

5/1/12

Secondary Header


Frame Structure Questions (1 of 7)

1. 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

5/1/12



2. 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?

5/1/12



3) 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?

5/1/12


Frame Structure Questions (4 of 7)4) 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?

5/1/12


Frame Structure Questions (5 of 7)5) 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?

6) 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)

5/1/12


Frame Structure Questions (6 of 7)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)

5/1/12


Frame Structure Questions (7 of 7)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

8) MAP ID (MID)– MAPs are useful when it is desired to share a VC among separate

entities but it complicates M-PDU processing.

5/1/12

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 approachProx: > 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 fieldAOS/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)

ASM FRAME Idle ASM FRAME

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)

A Single Frame StructureASM FRAME Idle


1. TRANSFER FRAME HEADER ---The Transfer Frame Header is mandatory and shall shall encompass the major fields, positioned contiguously, in the following sequence:

1) Transfer Frame Version Number (2 bits, mandatory);2) Bypass/Sequence Control Flag (1 bit, mandatory);3) Operational Control Field Flag (CLCW) included (1 bit, mandatory);4) Spacecraft Destination Identifier (12 bits, mandatory); ----25) Spacecraft Source Identifier (12 bits, mandatory);6) Data Field Content Identifiers (2 bits) (control command , VCA, M-PDU, B-PDU) 7) Virtual Channel Identifier (2 bits, mandatory); ----28) MAP ID (5 bits, mandatory);9) VC Sequence number Extension Flags (3 bits mandatory) -----110) Reserved spare bit (1 bits mandatory) 11) Frame Length (15 bits, mandatory) (Total Frame size including Security); ----212) VC Sequence Number Extension (0 to 7 bytes optional).(MSB)13) VC Sequence Number (8 bits, mandatory).(LSB) -----1 total 8-15 bytes

A Trial TRANSFER FRAME STRUCTURE (1 of 2)

5/1/12


2. SECURITY HEADER (managed size)j

3. 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.

4. SECURITY MAC (managed size)

5. CLCW 2 bytes (optional – flagged)

6. FEC 2/4 bytes (optional, managed)

Universal TRANSFER FRAME STRUCTURE (3 of 3)

5/1/12


Frame Format Features1. A singe coded frame (PLTU) can be composed of a integer number of code words.2. 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.]

3. PLTU can contain fill bits/octets in last code word of PLTU (determined by frame length field)4. Frame Data Field could be zero length (determined by frame length field and managed field sizes )5. CLCW is flagged [could possibly be only non-header, non-managed data object in frame]6. Frame sequence number extension is self defined in fixed location of header7. Frame size field is always in fixed location in frame header8. Number of Virtual Channels are reduced because each require independent counters9. A MAP field is included to add local addressing for each VC (providing a VC sub-addresses)10. Data Frame Content field identifies the type of data included in data field11. 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).

12. 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)

13. 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

5/1/12


Example PLTU Format

Frame Header Frame Data Field Security

MAC OCS FEC

Security Header

ASM Code Word Code Word Code Word Code Word Code Word

Fill

Example Link Layer Operation

PLTU

One (1) PLTU

PLTU PLTU PLTUI D L E I D L E

Note: Each PLTU can have different number of code words and idle can be of any size

5/1/12


Data Content Within Frame Data Field

The Data Field Content Identifier Field is 2 bits with 4 defined values:

1. 00 identifies the content of the data field as Command/Protocol Control data

2. 01 identifies the content of the data field as VCA data (octets)

3. 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.

4. 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.

5/1/12


Frame Use For TC

1) Transfer Frame Version Number 2) Bypass/Sequence Control Flag;3) Command Control Data4) Reserved spare bit 5) Spacecraft Identifier;

6) Virtual Channel Identifier;

7) Frame Length

8) VC Sequence Number

1) Transfer Frame Version Number 2) Bypass/Sequence Control Flag;3) Operational Control Field Flag4) Spacecraft Destination Identifier ;

5) Spacecraft Source Identifier ;

6) Data Field Content Identifiers 7) Virtual Channel Identifier;

8) MAP ID (5 bits, mandatory);

9) Frame Sequence number extension (0) 10) Reserved spare bit

11) Frame Length 12) VC Sequence Number Extension 13) VC Sequence Number

Telecommand Format New Format

5/1/12


Frame Use For Proximity

1) Transfer Frame Version Number 2) Bypass/Sequence Control Flag;3) PDU Type4) Data Field Construction ID5) Spacecraft Identifier;

6) Physical Channel Identifier7) Port ID 8) Source/Destination ID (not required because both addresses are included)

9) Frame Length 10) VC Sequence Number

1) Transfer Frame Version Number 2) Bypass/Sequence Control Flag;3) Operational Control Field Flag4) Spacecraft Destination Identifier

5) Spacecraft Source Identifier


8) MAP ID

9) Frame Sequence number extension (0) 10) Reserved spare bit


Proximity Format New Format

5/1/12


Frame Use For Telemetry

1) Transfer Frame Version Number 2) Spacecraft Identifier

6) Virtual Channel Identifier7) VC Sequence Counter

8) Replay Flag 9) Sequence Count Extension

1) Transfer Frame Version Number 2) Bypass/Sequence Control Flag;3) Operational Control Field Flag4) Spacecraft Destination Identifier

5) Spacecraft Source Identifier


8) MAP ID

9) Frame Sequence number extension 10) Reserved spare bit


AOS Format New Format

Note: Frame length is managed for Telemetry Secondary Header and/or Insert Zone

5/1/12


SERVICE MODES

OverviewThe 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.

1. 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.

2. 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.

5/1/12


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.

1. 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.

2. 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.

5/1/12


SUMMARY OF SERVICES (cont) 3. 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.

4. 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.

5. 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.

5/1/12


SUMMARY OF SERVICES (cont)

6. 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.

5/1/12

seeking a general purpose ccsds link layer protocol next generation data link protocol ( ngdlp )

Documents