[Sls-slp] RE: [Sis-ipo] Adding a note to Encapsulation Service

Walsh, William william.walsh at linquest.com
Tue Apr 21 04:22:10 UTC 2009

Greg, Dave,


Did this discussion refer to the 2, 4 vs 8 byte encap headers,

with 1, 2 or 4 byte length fields?

Note that most programs that I've talked to explicitly exempt their

contractors from supporting the 8 byte encap header.


If this comment regards the choices of idle packets, i.e. 1-byte vs.

variable - I'm not sure that part is a bandwidth issue.


I apologize that I don't clearly remember the context of the discussion








From: sis-ipo-bounces at mailman.ccsds.org
[mailto:sis-ipo-bounces at mailman.ccsds.org] On Behalf Of Greenberg, Edward
Sent: Monday, April 20, 2009 9:17 PM
To: Kazz, Greg J; sls-slp at mailman.ccsds.org; sis-ipo at mailman.ccsds.org
Subject: Re: [Sis-ipo] Adding a note to Encapsulation Service


I agree with Dave's comment except it should be a normative statement not a

On 4/20/09 9:12 PM, "Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov> wrote:

During today's SIS-IPO meeting, Dave Israel made what I believe is a very
good suggestion, discovered during interoperability testing IP/IPE over
Encapsulation over AOS frames.
The problem with the current wording of the Encapsulation Service
Specification is that two independent implementations will not interoperate
if the receive side of the interface implements Encapsulation packet size
differently with respect to the transmit side.
The proposed note would be added to the Encapsulation Service Pink Sheets,
which is a topic for discussion in the SLS-SLP WG meeting on Friday.  The
section is Length of Length Field
The proposed note is:
NOTE  -  An implementation on the transmitting end may choose to either use
a fixed Encapsulation header size or adaptively/dynamically adjust the size
of the Encapsulation Header size according to the payload size in order to
optimize bandwidth use (minimize header overhead).  Therefore, an
implementation must be capable of receiving encapsulation packets
implementing either case.    


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20090420/02da3b7d/attachment.html>

More information about the SLS-SLP mailing list