[Sls-slp] JAXA RID against OID Frame
Marjorie de Lande Long
marjorie at delandelong.com
Thu Mar 5 08:54:04 UTC 2009
Greg and everyone,
> the way the standard is written today, it is possible for a project to
> think that they could put data into a packet secondary header of an
> OID packet and think it is a valid thing to do.
An Idle Packet for the Space Packet Protocol really is Idle. It is not
permitted to have a Packet Secondary Header. The standard (133.0-B-1,
September 2003) is clear on this point. Section 4.1.2.3.3.4 says
"The Secondary Header Flag shall be set to '0' for Idle Packets."
and a Note in 4.1.3.2.1.4 says
"The Packet Secondary Header is not allowed for Idle Packets."
This requirement was inherited from the old Blue Books (now Silver).
For example, 102.0-B-5 ("Packet Telemetry") says in section 3.1.2.2.d
"The Packet Secondary Header Flag shall be set to "0" for Idle Packets."
Best regards,
Marjorie
On Wed, 2009-03-04 at 16:34 -0800, Kazz, Greg J wrote:
> Ed,
>
>
>
> You are saying the service provider (DSN, SN, GN, ESA, etc) would not
> provide OID packets to the user. I agree. I was only saying that the
> way the standard is written today, it is possible for a project to
> think that they could put data into a packet secondary header of an
> OID packet and think it is a valid thing to do.
>
>
>
> Greg
>
>
>
>
> ______________________________________________________________________
> From: Greenberg, Edward
> Sent: Wednesday, March 04, 2009 4:18 PM
> To: Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari at esa.int
> Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY;
> Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org;
> gilles.moury at cnes.fr
> Subject: Re: [Sls-slp] JAXA RID against OID Frame
>
>
>
>
> NO, Projects should not be allowed to get fill/idle/OID packets.
> OID frames on the other hand can contain insert data if managed
> for the physical channel (TM or AOS)
>
>
> On 3/4/09 8:26 AM, "Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov> wrote:
>
> You are all thinking very logically. But flight projects often cut
> corners and find all sorts of unusual and esoteric ways of utilizing
> the standards. Consensus on this matter seems to be, yes it is
> possible, but the limit of the probability of doing so approaches
> zero.
>
> Greg
>
>
>
> ______________________________________________________________________
> From: Greenberg, Edward
> Sent: Wednesday, March 04, 2009 3:03 AM
> To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J
> Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY;
> Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org;
> gilles.moury at cnes.fr
> Subject: Re: [Sls-slp] JAXA RID against OID Frame
>
> I agree with Matt and Gian Paolo. If you want to send a packet with a
> meaningful secondary header and no useful information thengive it an
> APID with that interpretation, not one that says it only contains idle
> data. Have a wonderful time discussing this trivia.
>
>
> On 3/4/09 1:59 AM, "Cosby Matthew" <MCOSBY at qinetiq.com> wrote:
> Greg,
>
> I agree with Gian Paolo.
>
> When our TM systems detect an Idle Packet (APID set to 0x7FF) it
> discards it.
>
> >From the TM Spec.
> 4.3.2.5 Extracted Packets shall be delivered to the users on the basis
> of the PVN in their header. Incomplete Packets are not required to be
> delivered in cross support situations.
>
> NOTE . Idle Packets are discarded. Data Fields that contain only Idle
> Data are also discarded.
>
> This states that the Idle Packet is discarded and implies that there
> is no user data within the packet. There probability isn’t any where
> in the standard stating that you can’t put a secondary header in the
> Idle Packet, but this is implied as this packet is thrown out. So
> quoting Gian Paolo it would be crazy to put any useful data into the
> idle packet.
>
> Regards,
>
> Matt.
>
> Matthew Cosby
>
> QinetiQ
> Bldg X107 Rm G003
> Cody Technology Park
> Ively Road, Farnborough
> Hants, GU14 0LX
>
> Tel: 01252 396313
> Email: mcosby at QinetiQ.com
> Fax: 01252 392969
> Web: www.QinetiQ.com <http://www.qinetiq.com>
> QinetiQ - The Global Defence and Security Experts
>
> P Please consider the environment before printing this email.
>
>
> ______________________________________________________________________
> From: sls-slp-bounces at mailman.ccsds.org
> [mailto:sls-slp-bounces at mailman.ccsds.org]
> <mailto:sls-slp-bounces at mailman.ccsds.org%5d> On Behalf Of
> Gian.Paolo.Calzolari at esa.int
> Sent: 03 March 2009 18:21
> To: Kazz, Greg J
> Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J.
> (GSFC-583.0); Jean-Luc.Gerner at esa.int;
> sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr;
> Greenberg,Edward
> Subject: RE: [Sls-slp] JAXA RID against OID Frame
>
>
>
> "Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov> wrote on 03-03-2009
> 18:21:35:
>
> > G.P.,
> >
> > But a Space Packet can contain a Secondary Header, which could
> > contain useful data as well. So in that sense, OID Packet also makes
> > sense. In other words, discarding an “Idle Packet” can have a
> > drawback or unintended consequence. CCSDS needs to use consistent
> > terminology across the board and I think that is what this JAXA rid
> > is pointing out. I am looking forward to Marjorie’s responses to
> > those rids as well.
> >
> > thanks,
> >
> > Greg
> >
>
> Greg,
> The Frame has a structure linked to the Virtual Channel and all
> frames on a VC have the secondary header (if this is used)
> independently they are OID or not.
> Conversely the Space Packet has a structure linked to the APID and a
> mission implementing a Packet Secondary Header on Idle Packets would
> just be crazy. :-) In addition, I think that, being the idle APID
> fixed, there is no chance for having a Secondary header in an Idle
> Packet [this is TBC].
>
> Comments/confirmations are welcome.
>
> Ciao
>
> Gian Paolo
> The information contained in this E-Mail and any subsequent
> correspondence is private and is intended solely for the intended
> recipient(s). The information in this communication may be
> confidential and/or legally privileged. Nothing in this e-mail is
> intended to conclude a contract on behalf of QinetiQ or make QinetiQ
> subject to any other legally binding commitments, unless the e-mail
> contains an express statement to the contrary or incorporates a formal
> Purchase Order.
>
> For those other than the recipient any disclosure, copying,
> distribution, or any action taken or omitted to be taken in reliance
> on such information is prohibited and may be unlawful.
>
> Emails and other electronic communication with QinetiQ may be
> monitored and recorded for business purposes including security,
> audit
> and archival purposes. Any response to this email indicates consent
> to this.
>
> Telephone calls to QinetiQ may be monitored or recorded for quality
> control, security and other business purposes.
>
> QinetiQ Limited
> Registered in England & Wales: Company Number:3796233
> Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
> Trading address: Cody Technology Park, Cody Building, Ively Road,
> Farnborough, Hampshire, GU14 0LX, United Kingdom
> http://www.qinetiq.com/home/notices/legal.html
> <http://www.QinetiQ.com/home/legal.html>
>
>
>
>
>
>
>
> _______________________________________________
> Sls-slp mailing list
> Sls-slp at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/sls-slp
More information about the SLS-SLP
mailing list