[Sls-slp] FW: Comments on recent USLP drafts

[Kazz, Greg J (312B)]

Dear SLP WG,
Preliminary responses back on Marjorie’s comments. Please see below.
For discussion at the SLP meeting at Monday’s meeting.

Regards,

Greg
Chairman CCSDS SLP WG
From: <Greenberg>, "Edward (312B)" <edward.greenberg at jpl.nasa.gov<mailto:edward.greenberg at jpl.nasa.gov>>
Date: Monday, March 16, 2015 at 8:40 PM
To: Marjorie de Lande Long <marjorie at delandelong.com<mailto:marjorie at delandelong.com>>
Cc: "Stefan.Veit at dlr.de<mailto:Stefan.Veit at dlr.de>" <Stefan.Veit at dlr.de<mailto:Stefan.Veit at dlr.de>>, Cosby Matthew <MCOSBY at qinetiq.com<mailto:MCOSBY at qinetiq.com>>, "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Subject: RE: Comments on recent USLP drafts




On 3/16/15, 6:34 AM, "Marjorie de Lande Long" <marjorie at delandelong.com<mailto:marjorie at delandelong.com>>

wrote:

>

>[Documents:

>- Unified Space Link Protocol (USLP), Draft Green Book, CCSDS

>732.1-G-0.2, December 9, 2014 (file 732x1-G-0

>2_USLP_Green_Jan6_2015.doc)

>- Unified Space Link Protocol, Draft White Book, CCSDS 732.1-W-9,

>December 2014 (file 732x1w09.1_USLP_White_Jan6_2015.doc)]

>

>1. Relationship to COP-1/P

>

>The Draft Green Book, section 2.1.2.13, says 'We envision USLP being

>backward compatible with COP-1/P'.

The Green book provides a view of the total protocol which includes the COP.  Some insist that the COP is a transport function that utilizes the services provided by the link layer.    In addition, the Green book hints about using the insert zone for many things including carrying a sender’s SCID.

>The Draft White Book, Annex F, section F1, says 'The USLP frame can be

>structured to resemble the Telecommand frame' and then describes using

>the VC sequence counter for a Go-Back-N protocol.

>At this time  the White Book does not include the COP or the Protocol for PROX for any supervisory commands.  The format described in the White book provides a CLTW service that can support the COP as well as Security reporting.  It describes how to do segmentation and the use of “MAPs” for internal routing.   But we have just started and getting the data Protocol on the table is the first step.  The next step would be to introduce the State Tables and operations for COP , Prox and TC.

>However, the USLP defined in the Draft White Book does not appear to

>support the inclusion of a retransmission mechanism such as COP-1 or

>COP-P within a USLP protocol entity.  For example:

>- section 2.4.1 says that the USLP protocol does not perform

>retransmission of protocol data units, and

>- the COP-1 Management Service is not supported.

>

>Therefore, I think the compatibility with COP-1/P mentioned in the

>Draft Green Book needs some clarification.

>

>2. Flexible frame format to support future needs

>

>The design of the USLP frame format is intended to be flexible, with

>support for future needs, but I think this flexibility could be

>improved.  Here are a few considerations.

>

>2.1 Support for spacecraft addressing

>

>The only support for spacecraft addressing provided in the header of

>the USLP Transfer Frame is a single Spacecraft Identifier field with a

>single flag that indicates source or destination.  The Insert zone can be the carrier of the missing data.  This was intentional because adding the second address in every frame is overkill and this is a link protocol not a network protocol.  We did however consider that a relay could be used as a truck carrier for relaying a link data unit.

>

>For example, this does not support scenarios that prefer to have both

>source and destination Spacecraft Identifiers. (This is mentioned in

>the slide 'Possible Modifications to USLP' in the presentation 'Why we

>need USLP' from last November.)

>

>The Spacecraft Identifier may be used as a kind of network address:

>section 3.4 of the Draft Green Book discusses the use of USLP frames in

>a frame relay service.  In the current design of the USLP frame format

>the Spacecraft Identifier field supports up to 8192 Spacecraft

>Identifiers, and the design provides no mechanism for increasing the

>size of the field - this is a lot of spacecraft, but network addressing

>fields are famous for running out of bits.

We have been asked by some commenters to increase the SCID field.  It is easy right now to add a single bit and double the number of SCIDs available.

>

>2.2 Longer fields

>

>Some fields in the USLP frame could just be defined with a longer

>length.

>

>While it is good to keep down the overheads of the fixed parts of a

>frame header, these overheads are relatively smaller when the frames

>are longer.  By being too "economical" with the bits in the header,

>there may be less flexibility available in the future.   We can envision longer frames but there needs to be a balance and that is where economy is important.

>

>Just as an example (not a proposal for a specific change!), with the

>addition of one extra octet to the USLP Transfer Frame Header, the

>eight extra bits could be used to:

>- Increase the length of the Spacecraft Identifier field from 13 to 16

>bits.  You are correct and we have no problem accepting that.  We have been hammered by the fault tolerant enthusiasts to keep the frame size as small as possible for emergency ops.  Personally we believe that the improved uplink coding gain obviates that requirement by proving higher data rates.

>- Replace the 1-bit OCF Flag with a 3-bit field that supports other

>sizes of OCF than the current 4 octets. (The 4-octet OCF was designed

>for use with COP-1. An optionally larger OCF might be welcome for

>SDLS.)   A reasonable proposal, but again this can be handled in an insert zone.

>- Provide three additional reserved bits (or flags) to allow for future

>SLP needs.

>

>Another example is the Insert Zone, which is defined as having a

>1-octet length field as its first octet (4.1.4. in the Draft White

>Book).  There might be future applications for the Insert Zone that

>need to have more than 255 octets of insert data in a frame, so maybe

>the length field could be longer than 1 octet?  A 12-bit length field

>would allow an Insert Zone up to 4K octets.  On this we disagree.  If you need more that 255 bytes create a new frame.

>

>2.3 Support for the fields that no-one has thought of yet

>

>Provision for new fields could be supported by including some

>additional reserved bits in the frame header, which could be used later

>to signal the presence of new fields.  Sure

>

>3. Very high rate links

>

>Section 2.1.2.7 of the Draft Green Book discusses some very high rate

>links with rates exceeding 1 Gbit/sec.  It mentions a 30 Gbit/sec link,

>which could transfer 2,343,750 frames per second with a frame size of

>16,000 octets.

>

>The longer frame lengths supported by USLP make it possible to greatly

>reduce the frame rate on such links, compared to TM or AOS.  But even

>with USLP, a system designed to receive and process such a link might

>need to split the processing, perhaps across multiple parallel

>processors, or perhaps by directing some frames to storage for off-line

>processing.  In any case, the presence of variable-length frames on the

>link could add to the complexity of planning for a smooth and balanced

>handling of the frames.  True, but there is no requirement that a link management agreement can’t include fixed length frames.  I envision fixed length TFDFs to more efficiently use mass store.

>

>Does the USLP design include any other features to support these links?

>Would USLP include Application Profiles to limit the use of

>variable-length frames on very high rate links such as 30 Gbit/sec?

>

>4. Variable length frames, unaligned with the code blocks

>

>Perhaps my questions here should be addressed to SLS-C&S rather than

>SLS-SLP.

>

>The proposed method in USLP for handling of variable length transfer

>frames with a fixed length block code is similar to the method used by

>Proximity-1.  Proximity-1 frames have a maximum length of 2048 octets

>and use an LDPC code with an input block length of 128 octets(?).  So a

>maximum length frame can be sliced across 17 codeblocks.

>

>How well does this work with a very big frame, such as 60,000 octets?

>Presumably a longer code could be used with USLP, such as 892-octet

>LDPC?  - which would slice a 60,000 octet frame across 68 code blocks.

>Has this been tested at this sort of scale?  We know that the LDPC codes have no error floor.  Thus the code word error rates can be expected to approach zero if a high enough SNR is provided.  We have set the maximum frame size as 65k bytes but would 32k bytes be more reasonable?

>

>Best regards,

>Marjorie

>

>

>Marjorie de Lande Long

>I B + M A de Lande Long

>Software + Consultancy

>marjorie at delandelong.com<mailto:marjorie at delandelong.com>

>

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20150317/20dd6bdc/attachment.html>