From greg.j.kazz at jpl.nasa.gov  Thu Mar  5 18:20:11 2015
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Thu, 5 Mar 2015 18:20:11 +0000
Subject: [Sls-slp] Final Check on Proposed Changes to CCSDS 130.2-G-2
Message-ID: <D11DDE5A.20AD2%greg.j.kazz@jpl.nasa.gov>

Dear SLP WG,

I’ve put the change request that we worked on during the last SLP WG meeting in London out on the SLP CWE site under
http://tiny.cc/bce1ux

I will allocate a short period of time on our SLP WG agenda at Caltech as a final confirmation that this file contains the final edits to Space Data Link Protocols GB. The red lines were made to stay consistent with soon to be released SDLS Blue Book.

Regards,

Greg Kazz
Chairman CCSDS SLP WG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20150305/cb1ea547/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Tue Mar 17 01:15:21 2015
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Tue, 17 Mar 2015 01:15:21 +0000
Subject: [Sls-slp] FW: Comments on recent USLP drafts
In-Reply-To: <1426512848.2476.15.camel@MCq>
References: <1426512848.2476.15.camel@MCq>
Message-ID: <D12CCDD1.20E36%greg.j.kazz@jpl.nasa.gov>

Dear SLP WG,

We will discuss Marjorie¹s comments at our meeting on Monday at Caltech.

Safe Journey!

Greg
CCSDS SLP WG chairman

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

>Greg,
>
>I have had a look at the two latest draft documents for USLP and have a
>few comments.
>
>[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 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.
>
>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.
>
>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.
>
>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.
>
>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.
>- 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.)
>- 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.
>
>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.
>
>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.
>
>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?
>
>Best regards,
>Marjorie
>
>
>Marjorie de Lande Long
>I B + M A de Lande Long
>Software + Consultancy
>marjorie at delandelong.com
>
>




From greg.j.kazz at jpl.nasa.gov  Tue Mar 17 15:14:40 2015
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Tue, 17 Mar 2015 15:14:40 +0000
Subject: [Sls-slp] FW: Comments on recent USLP drafts
In-Reply-To: <4EF9F303214ADB458948F9AD7A608EB313C03E50@ap-embx-sp30.RES.AD.JPL>
References: <1426512848.2476.15.camel@MCq>
	<D12C862B.20E28%greg.j.kazz@jpl.nasa.gov>
	<4EF9F303214ADB458948F9AD7A608EB313C03E50@ap-embx-sp30.RES.AD.JPL>
Message-ID: <D12D9289.20E47%greg.j.kazz@jpl.nasa.gov>

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>

From greg.j.kazz at jpl.nasa.gov  Tue Mar 24 05:04:01 2015
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Tue, 24 Mar 2015 05:04:01 +0000
Subject: [Sls-slp] Files to download from today's SLP WG meeting
Message-ID: <D1363E4F.20F9E%greg.j.kazz@jpl.nasa.gov>

All,

Please go to the following URL on the CWE to download the presentations made at today’s SLP WG meeting. I created a draft response to SANA (Response-CMC-A file) to our CMC action item on SCID assignments. The original SANA generated report on the current status of SCIDs V1 and V2 is also included in that directory. Under the USLP sub-directory, please find Ed Greenberg and my presentation on USLP. See you tomorrow at 9 AM.

Best regards,
Greg Kazz
Chairman CCSDS SLP WG

http://tinyurl.com/p4k5zex



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20150324/04e6af3e/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Tue Mar 24 21:11:56 2015
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Tue, 24 Mar 2015 21:11:56 +0000
Subject: [Sls-slp] Updated USLP White book based upon SLP WG meeting results
 March 24 2015
Message-ID: <D137212B.20FD7%greg.j.kazz@jpl.nasa.gov>

All,

The update to the format of the USLP document structure that we discussed in the SLP WG meeting today March 24 is now on the CWE for you to download at:

http://tiny.cc/x4s0vx

Please let me know if you have any comments or concerns if at all possible during the meetings this week.

Thanks!

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20150324/ff21b60b/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Thu Mar 26 19:42:42 2015
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Thu, 26 Mar 2015 19:42:42 +0000
Subject: [Sls-slp] Draft SLP WG Meeting Minutes
Message-ID: <D139AF3F.210BF%greg.j.kazz@jpl.nasa.gov>

Dear SLP WG members and associates,

Please review the draft SLP WG meeting minutes attached as a Word document and let me know if you have any comments, issues etc.

Thanks!

Greg Kazz
Chairman CCSDS SLP WG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20150326/b46f8dbf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SLP_Meeting_Notes.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 154153 bytes
Desc: SLP_Meeting_Notes.docx
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20150326/b46f8dbf/attachment.docx>