From greg.j.kazz at jpl.nasa.gov  Thu Oct  2 15:35:18 2008
From: greg.j.kazz at jpl.nasa.gov (Greg Kazz)
Date: Thu, 02 Oct 2008 08:35:18 -0700
Subject: [Sls-slp] Fwd: TC Retransmissions at SLS-SLP meeting Berlin
Message-ID: <6.2.3.4.2.20081002083333.02f65740@mail.jpl.nasa.gov>

Dear SLS-SLP WG members and associates,

Attached please find the latest proposal from ESA on TC retransmission.

You can also soon find it in the public folder in SLS-SLP on the CWE.

best regards,

Greg


>Subject: TC Retransmissions at SLS-SLP meeting Berlin
>From: Marjorie de Lande Long <marjorie at delandelong.com>
>To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
>Cc: "Gian.Paolo.Calzolari" <Gian.Paolo.Calzolari at esa.int>
>Date: Thu, 02 Oct 2008 11:26:12 +0200
>X-Mailer: Evolution 2.12.1
>X-Source-IP: hs65.order-vault.net [69.94.21.110]
>X-Source-Sender: marjorie at delandelong.com
>
>Greg,
>
>I assume you know already, but just to be sure: I would like to present
>the proposal for the TC Retransmissions at the SLS-SLP meeting in Berlin
>on 16th October.
>
>I enclose the latest version of the paper, TCretransmit7.pdf, which has
>been updated with background information including the scenarios
>foreseen for applying the systematic retransmissions.  Perhaps it would
>be helpful to include the paper in the CWE materials for the meeting.
>
>Thank you.
>
>Best regards,
>Marjorie
>
>Marjorie de Lande Long
>I B + M A de Lande Long
>Software + Consultancy
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TCretransmit7.pdf
Type: application/octet-stream
Size: 136574 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081002/20ebaf13/attachment.obj>

From greg.j.kazz at jpl.nasa.gov  Thu Oct  9 15:47:35 2008
From: greg.j.kazz at jpl.nasa.gov (Greg Kazz)
Date: Thu, 09 Oct 2008 08:47:35 -0700
Subject: [Sls-slp] Fw: CCSDS in Berlin: Applying Long Erasure Codes to CFDP 
Message-ID: <6.2.3.4.2.20081009084529.02f88ca0@mail.jpl.nasa.gov>

SLS-SLP WG,

Please try to attend the following presentations at the CCSDS WG 
meetings in Berlin:

Just after lunch on Thursday

Greg


>To: "Greg J. Kazz" <Greg.J.Kazz at jpl.nasa.gov>
>Subject: Fw: CCSDS in Berlin:  Applying Long Erasure Codes to CFDP
>X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
>From: Gian.Paolo.Calzolari at esa.int
>Date: Thu, 9 Oct 2008 11:29:16 +0200
>X-MIMETrack: Serialize by Router on esrinmta1/esrin/ESA at 
>10/09/2008 11:29:16,
>         Serialize complete at 10/09/2008 11:29:16
>X-Source-IP: esacom90-ext.esrin.esa.int [192.171.5.18]
>X-Source-Sender: Gian.Paolo.Calzolari at esa.int
>
>
>Greg,
>         I think attending would be interesting for SLP guys.
>What do you think?
>
>Ciao
>
>Gian Paolo
>----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 09-10-2008 11:28 -----
>Gian Paolo Calzolari/esoc/ESA
>
>05-10-2008 17:40
>To
>Bob Durst
>cc
>Dai Stanton <dstanton at keltik.co.uk>, Scott Burleigh 
><Scott.Burleigh at jpl.nasa.gov>, "Greg J. Kazz" 
><Greg.J.Kazz at jpl.nasa.gov>, Chris Taylor/estec/ESA at ESA, Jean-Luc 
>Gerner/estec/ESA at ESA, "Adrian J. Hooke" 
><adrian.j.hooke at jpl.nasa.gov>, Nestor Peccia/esoc/ESA at ESA
>Subject
>CCSDS in Berlin:  Applying Long Erasure Codes to CFDP
>
>
>
>Dear Bob,
>         we are planning to have a presentation on "Applying Long 
> Erasure Codes to CFDP " and I think it would be interesting if the 
> guys of your Area could attend.
>
>I plan to have that presentation (by Tomaso De Cola of DLR) on 
>Thursday just after lunch.
>
>I think this is a good opportunity for this new item.
>Please let me know about your opinion and participation.
>
>Ciao
>
>Gian Paolo






From greg.j.kazz at jpl.nasa.gov  Thu Oct 16 07:21:39 2008
From: greg.j.kazz at jpl.nasa.gov (Greg Kazz)
Date: Thu, 16 Oct 2008 00:21:39 -0700
Subject: [Sls-slp] Fwd: Re: Space Packet Protocol Green Book
Message-ID: <6.2.3.4.2.20081016002036.02f43cc8@mail.jpl.nasa.gov>

All,

Please find attached Takahiro's final update to the SPP GB.

For review today.

Greg

>Date: Fri, 10 Oct 2008 22:47:21 +0900
>From: Takahiro Yamada <tyamada at pub.isas.jaxa.jp>
>Reply-To: tyamada at pub.isas.jaxa.jp
>Organization: JAXA/ISAS
>User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; 
>rv:1.7.2) Gecko/20040804 Netscape/7.2
>X-Accept-Language: en-us, en
>To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
>CC: tomg at aiaa.org, jean-Luc.Gerner at esa.int
>Subject: Re: Space Packet Protocol Green Book
>X-MAIL: dam01.s.tksc.jaxa.jp m9ADlL7P029796
>X-Source-IP: tkes52.tksc.jaxa.jp [133.56.0.40]
>X-Source-Sender: tyamada at pub.isas.jaxa.jp
>
>Greg,
>
>>Will you be able to provide us with an updated version of the Space 
>>Packet Protocol Green Book before the meeting in Berlin?
>
>I'm very sorry for this last minute submission, but here it is. It 
>is consistent with the Pink Sheets on the Space Packet Protocol 
>provided by Tom.
>
>Please let me know when we discuss it at Berlin.
>
>I look forward to seeing you again there.
>
>Best regards,
>Takahiro Yamada.
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SPP_DGB5.doc
Type: application/octet-stream
Size: 472064 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081016/19b5439e/attachment.obj>

From greg.j.kazz at jpl.nasa.gov  Thu Oct 16 09:38:49 2008
From: greg.j.kazz at jpl.nasa.gov (Greg Kazz)
Date: Thu, 16 Oct 2008 02:38:49 -0700
Subject: [Sls-slp] Fwd: Emailing: CCSDS-211.2-B-1(Prox1.CandSL).CRC Pink
	0.D.doc
Message-ID: <6.2.3.4.2.20081016023727.02eec520@mail.jpl.nasa.gov>

Dear SLS-SLP WG,

Attached are pink sheets to the Prox-1 Coding and Sync specification 
from Gian-Paolo. Please take a look and make your comments available 
to him and our WG as well.

thanks,

Greg


>Subject: Emailing: CCSDS-211.2-B-1(Prox1.CandSL).CRC Pink 0.D.doc
>To: "Greg J. Kazz" <Greg.J.Kazz at jpl.nasa.gov>, Enrico.Vassallo at esa.int
>Cc: Jean-Luc.Gerner at esa.int
>X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
>From: Gian.Paolo.Calzolari at esa.int
>Date: Tue, 14 Oct 2008 11:32:59 +0200
>X-MIMETrack: Serialize by Router on esrinmta1/esrin/ESA at 10/14/2008 11:32:57
>X-Source-IP: esacom90-ext.esrin.esa.int [192.171.5.18]
>X-Source-Sender: Gian.Paolo.Calzolari at esa.int
>
>For your information and possible comments before Thursday afternoon when we
>plan to address again this item.
>
>Ciao
>
>Gian Paolo
>
>
>(See attached file: CCSDS-211.2-B-1(Prox1.CandSL).CRC Pink 0.D.doc)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS-211.2-B-1(Prox1.CandSL).CRC Pink 0.D.doc
Type: application/octet-stream
Size: 622592 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081016/34ff526b/attachment.obj>

From greg.j.kazz at jpl.nasa.gov  Thu Oct 23 18:18:09 2008
From: greg.j.kazz at jpl.nasa.gov (Greg Kazz)
Date: Thu, 23 Oct 2008 11:18:09 -0700
Subject: [Sls-slp] CCSDS Spring 2009 Meeting
Message-ID: <6.2.3.4.2.20081023111708.0301ed10@mail.jpl.nasa.gov>

All,

Next  meeting dates and location.

best regards,

Greg

>To: "SLS Channel Coding Working Groups" <sls-cc at mailman.ccsds.org>
>Cc: Jean-Luc.Gerner at esa.int, Gilles Moury <Gilles.Moury at cnes.fr>,
>         "Greg J. Kazz" <Greg.J.Kazz at jpl.nasa.gov>, Enrico.Vassallo at esa.int,
>         "Aaron Kiely" <aaron.kiely at jpl.nasa.gov>
>Subject: [SLS-CC] Spring 2009 Meeting
>X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
>From: Gian.Paolo.Calzolari at esa.int
>Date: Thu, 23 Oct 2008 12:01:58 +0200
>X-MIMETrack: Serialize by Router on esrinmta1/esrin/ESA at 
>10/23/2008 12:02:00,
>         Serialize complete at 10/23/2008 12:02:00
>X-Source-IP: esacom90-ext.esrin.esa.int [192.171.5.18]
>X-Source-Sender: Gian.Paolo.Calzolari at esa.int
>
>
>Dear All,
>         please be aware that the Adrian J. Hooke [Chairman of CCSDS 
> Engineering Steering Group (CESG)] just informed that the CMC has 
> also approved the proposal from NASA to host the Spring 2009 
> meeting from 20 through 25 April 2009 (6 days of meetings, 
> including Saturday) in Colorado Springs, USA.
>
>Best regards
>
>Gian Paolo Calzolari
>Space Link Coding and Synchronization Working Group (SLS-C&S) Chair
>
>____________________________________________
>
>Gian Paolo Calzolari
>Systems Engineer, OPS-OT
>
>European Space Agency ESA/ESOC
>Robert Bosch Str. 5
>D-64293-Darmstadt
>Tel +49-6151-902913 fax +49-6151-903046
>http://www.esa.int/esoc    Email: Gian.Paolo.Calzolari[at]esa.int
>[anti-spam: replace [at] with @ for the correct e-mail address]
>____________________________________________
>
>
>






From greg.j.kazz at jpl.nasa.gov  Thu Oct 23 20:27:51 2008
From: greg.j.kazz at jpl.nasa.gov (Greg Kazz)
Date: Thu, 23 Oct 2008 13:27:51 -0700
Subject: [Sls-slp] CCSDS area reports to CMC/CESG 
Message-ID: <6.2.3.4.2.20081023132622.02f0afb0@mail.jpl.nasa.gov>

All,

Attached is a pdf file containing all of the CCSDS area reports from 
the Fall 2008 Berlin meeting.

best regards,

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Integrated-CESG-Report-to-CMC-22October08.pdf
Type: application/octet-stream
Size: 471231 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081023/3a4852b5/attachment.obj>

From adrian.j.hooke at jpl.nasa.gov  Thu Oct 30 12:57:20 2008
From: adrian.j.hooke at jpl.nasa.gov (Adrian J. Hooke)
Date: Thu, 30 Oct 2008 08:57:20 -0400
Subject: [Sls-slp] Satellites approach the Shannon limit
Message-ID: <6.2.3.4.2.20081030085143.02dbb460@mail.jpl.nasa.gov>

http://www.physorg.com/news144420242.html

28 October 2008

Satellites approach the Shannon limit

(PhysOrg.com) -- Satellites are achieving unparalleled efficiency 
with a new protocol, DVB-S2. The performance of DVB-S2 satellite 
systems is very close to the theoretical maximum, defined by the 
Shannon Limit. That efficiency could be pushed even further by 
network optimisation tools and equipment recently developed by 
European researchers.

European researchers have created network optimisation hardware and 
software tools that are able to manage satellite resources more 
efficiently. The developed tools are able to push the state of the 
art in satellite transmission technology even further. The increased 
efficiencies lead to cheap broadband, TV and voice access from anywhere.

But vast numbers of Europeans also live in rural or even isolated 
regions and providing broadband access for them is more complicated.

But not, perhaps, for much longer. Recent progress in satellite 
technology has led to vastly improved bandwidth efficiencies. The 
newly developed DVB-S2, which stands for digital video broadcast 
satellite second generation, improves on DVB-S by a purported 30%.

"Using satellite resource management tools, based on cross-layer 
techniques, the IMOSAN project is trying to push that technology even 
further, in order to make it more attractive not only from the 
technical aspects, but from the business point of view as well," 
explains Anastasios Kourtis, coordinator of the EU-funded project.

Cross-layer techniques work across the application, service and 
physical layers of a communication medium to maximise efficient usage 
of bandwidth.

Approaching the Shannon Limit

The Shannon Limit establishes the maximum capacity of any channel. A 
channel is subject to bandwidth and noise restrictions, but its 
capacity can be improved with clever modulation and multiplexing 
techniques. The theoretical ultimate limit of a channel for specific 
bandwidth and signal-to-noise ratio is called the Shannon Limit.

Like the speed of light, that limit cannot be overcome and, again 
like the speed of light, it is very difficult even to approach it.

The inherent feature of DVB-S2, called Adaptive Coding and Modulation 
(ACM), allows a satellite system to adapt, in real time, to various 
transmission conditions and service demands. In this respect, 
satellite channels are very close to their theoretical limit.

"The IMOSAN consortium developed innovative software and hardware 
modules and protocols, called the Satellite Resource Management 
System (SRMS) that apply ACM to voice, data and TV in a clever way, 
allowing the provision of cost-effective 'triple-play' satellite 
services to users in rural or isolated areas," Kourtis explains.

SRMS was a key advance, but only one of a series of innovations and 
improvements the team performed on the DVB-S2 system. They also 
developed hardware and software that supports MPEG-2 HDTV. They 
developed software that can use both the older Multiprotocol 
Encapsulation (MPE) scheme and the newer Ultra Light Encapsulation 
(ULE) one. Both have also been optimised for IPv4 or IPv6.

IPv4 is the current Internet Protocol (IP) that we mainly use for all 
data communications. But the unique IP addresses are running out 
rapidly, and the protocol is creaking under the strain of modern 
network demands. IPv6 will address this shortage and offer other new 
features to improve the internet.

It offers so many unique addresses that it would be possible to give 
an address to every individual grain of sand on earth and still have 
enough numbers left to give a unique one to every individual on the 
planet, any pets they have and all the devices they own. IPv6 also 
provides better security and error correction and it is the IP 
standard of the future. Including it in their system means that 
IMOSAN has future-proofed its work.

The work of IMOSAN is expected to have significant impact on 
satellite communications.

"The innovative tools and techniques that were developed in the frame 
of IMOSAN, gave [us] a great opportunity [for] efficient 
collaboration among private-sector companies and public academic 
organisations, with a common goal: to provide cost-effective 
broadband satellite services to rural and isolated areas," Kourtis 
concludes. This should help tackle the digital divide problem.

This is part one of a two-part feature on the IMOSAN project funded 
by the ICT strand of the EU's Sixth Framework Programme for research. 
Part two will appear on 4 November.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081030/36c32849/attachment.html>

From peter.shames at jpl.nasa.gov  Fri Oct 31 15:52:03 2008
From: peter.shames at jpl.nasa.gov (Peter Shames)
Date: Fri, 31 Oct 2008 08:52:03 -0700
Subject: [Sls-slp] Fwd: Re: Space Packet Protocol Green Book
In-Reply-To: <6.2.3.4.2.20081016002036.02f43cc8@mail.jpl.nasa.gov>
References: <6.2.3.4.2.20081016002036.02f43cc8@mail.jpl.nasa.gov>
Message-ID: <ADA40231-A399-48CF-A66D-4A381DAEC635@jpl.nasa.gov>

Greg, Takahiro, Dai, et al,

My apologies for not being able to be present when this Green Book was  
discussed in Berlin, but my schedule during the week was just crazed.   
I hope you had a fruitful discussion of the draft document.   During  
my plane ride back to the US I took the time to read this draft Green  
Book and also the SPP that it relates from.  While reading the draft  
GB I had to go back and re-acquaint myself with the SPP itself because  
many of the features attributed to this Space Packet Protocol in the  
GB seemed to me to not really be firmly routed in my recollections of  
the capabilities of the actual SPP.  This re-reading of the SPP has  
caused me to also take the time to carefully review the Pink Sheets,  
which are being addressed separately.

I understand from talking to both JAXA and ESA representatives in the  
past that there is a great fondness for the SPP because of its  
"economy" and that there is also a strong desire to use it to do all  
sorts of things, foremost being to use it as a modest end to end  
routing protocol for application data.  The SPP is also used in some  
unique ways by our own Mars missions.   There has been a long standing  
discussion of whether the SPP is a "network" layer data object or an  
"application layer" data object.  After re-reading these documents I  
am convinced that it is really only an application layer data object,  
not a protocol in any formal sense, and that all of the properties  
ascribed to it re "routing", "data management", "end-to-end flows",  
multi-cast, etc are not firmly grounded in any solid technical  
capability or behavior that is defined in the SPP "protocol" itself.

Here is my reasoning:

- The SPP "protocol" is really only a data structure with a "tag"  
field, called the APID, as defined on pg 4-2 of the CCSDS 133.0-B-1  
Blue Book.

- The described behavior of the end nodes and intermediate nodes vis a  
vis routing and data transfer operations is at best a "sketch", it  
says assemble and multiplex packets and then "transfer Space Packets  
to the next protocol entity in the LDP using services of the  
underlying subnetwork. "  That is the essence of the whole "behavior"  
spec.

- The SPP itself contains only the APID as a unique identifying field  
that can be used to drive any of these so called "protocol"  
operations.  The optional "packet name" is as ambiguous as the APID in  
terms of end to end routing utility.

- In order to be useful the APID must retain meaning across all end  
elements and "intermediate nodes" .  However, the APID is stated as  
only being unique within the management domain in which it is  
defined.  For routing in the general case the packet may transit  
multiple domains, so this is a dis-connect that must be dealt with as  
collisions may easily occur between APID assignments in two different  
management domains.

- The "APID Qualifier" might offer some help but there is confusion in  
these two docs as to what the APID Qualifier is (SCID or MCID) and  
there is no clear statement in the SPP about what to do with it.

-  Since either of these APID Qualifiers (whichever it really is) are  
only relevant within the underlying link protocol of a "subnet",  
therefore there is no other unique field associated with an SPP end-to- 
end aside from the APID.

- This all means that the APID Qualifier as defined is essentially  
useless for end to end routing over multiple hops and admin domains.

- There is no clear protocol definition of how to do routing,  
forwarding, or store & forward operations, the whole "protocol" for  
intermediate nodes that are assigned this Relay (routing) function  
consists of these statements in CCSDS 133.0-B-1 :

> 4.3.2 PACKET RELAY FUNCTION

> 4.3.2.1 The Packet Relay Function shall be used to relay Space  
> Packets to the next protocol
> entity in the LDP of each Packet using services of the underlying  
> subnetwork.
> NOTE ñ There is an instance of the Packet Relay Function in each  
> intermediate system.

> 4.3.2.2 The Packet Relay Function shall receive Space Packets from  
> the underlying
> subnetworks and shall put the Packets into a queue in an appropriate  
> order that is set by
> management.  The algorithm to be used to order the Space Packets is  
> not specified by
> CCSDS, but shall be defined by project organizations considering  
> factors such as priority,
> release rate, etc.

> 4.3.2.3 The Packet Relay Function, then, shall examine the Path ID  
> of each Packet in the
> queue to identify the next Packet Protocol Entity in the LDP of the  
> Packet, and shall transfer
> the Packet using a service of the underlying subnetwork.

> 4.3.2.4 If the optional APID Qualifier is used, the APID Qualifier  
> of each received Packet
> shall be retrieved by a service of the subnetwork that carried the  
> Packet.  If the APID
> Qualifier is not used, the Path ID is derived directly from the APID  
> of the Packet.

> 4.3.2.5 The Packet Relay Function may transfer the Packet to  
> multiple protocol entities,
> which are not necessarily on the same subnetwork; i.e., it may  
> perform a multicast function.

> 4.3.2.6 The Packet Relay Function may temporarily store Packets,  
> using a storage service
> provided by the Intermediate System, before they are transferred to  
> the next Packet Protocol
> Entity, in case immediate transfer is impossible or impractical for  
> some reason.  The
> procedures for temporary storage of Packets are not specified by  
> this Recommendation.


- This is the heart of the “packet routing” function, but it says  
nothing about how to handle packets from different spacecraft, sort  
packets by path ID, identify paths based on Path ID, or direct packets  
to the correct paths.  It also does not say what to do with the APID  
Qualifier if this is relevant, just that it should be retrieved.

- This basically says "if a routing node gets a packet it sends it  
somewhere, somehow", but how it makes this decision, whether it stores  
the packet before sending it, where it gets the routing information  
from, how it is managed, how it determines whether a packet is "multi- 
cast", and how it even determines what to do w/ SPPs from someone  
else's system if there are APID collisions is all left up to  
"management".  This in essence says "It is someone else's problem" and  
nowhere in SPP or the GB elsewhere in CCSDS is it defined.

- All of the relay functions within SPP is done "by management",  
routing, store & forward, multi-path, etc

- Contrast this with the sorts of specifications for routing or  
forwarding data that are found in the Internet or in CFDP.

- We know that how some current spacecraft deal with the APID inter- 
management domain ambiguity is to use approaches like "packet in a  
packet" encapsulation such as is done by ESA for Mars relay data.  But  
note that this is not even mentioned as a strategy for handling APID  
collisions or intermediate node transfers in these docs.

- All of this really means that all of the hard work that needs to be  
done to make SPP work as a "network layer protocol" is done only by  
local arrangement, implementation choices, out of band signals and  
agreements, and therefore that there is no "standard" for doing this,  
thus interoperability cannot be possible in any general sense.

- The end result is that while APIDs may (and have been) useful within  
systems that all belong to the same administrative domain, and while  
it is pretty safe to rely on the SCID and a simple spacecraft to SLE  
end node path, or vice-versa, within one domain, there is not really  
any mechanism in the SPP that will adequately, without much tweaking  
and additional design, offer anything like a general purpose routing  
function.  EVERYTHING that is ascribed to SPP in this GB is done by  
out of band implementation, signaling, and management choices.

In the final analysis this Green Book, or the final version of it,  
must be clear about this.  My apologies, but the current draft of the  
GB reads like a fantasy where all sorts of magic properties are  
ascribed to the SPP, but all of them exist only as possibilities to be  
defined and managed as a local matter by the implementers.  The GB  
even talks about prioritization, reliability, retransmission, data  
management, and other topics that the SPP standard itself is truly  
silent about.

This is not to say that instances of systems using the SPP, by  
associating special meanings to certain assignments of the APID, can't  
be created to exhibit these properties, but neither the SPP standard  
itself, nor any other existing CCSDS document I know, of says how to  
do this in an interoperable fashion.   It makes me really  
uncomfortable to have all of this assertive language about the  
wonderful properties of the SPP floating around when in reality it is  
just fiction in terms of a real standard.  It is a description of some  
higher order behaviors that could be defined, but it is stated as a  
real property of a pretty ordinary tagged data structure.

The SPP is useful and has useful properties, and it can be adapted and  
configured to do a lot of things, but this description of what the SPP  
"does" does not really appear to be useful or accurate in its present  
form.   I took the liberty of trying to edit the document into a form  
that I believe more closely approximates the real properties of the  
SPP as can be found in the Blue Book.  I did leave in a lot of the  
possible uses of the SPP that had been described, but put in what I  
believe are necessary and essential caveats re its use.   We do not  
want to mislead our users about what this simple protocol is capable  
of, that would do them, and CCSDS, a disservice.

I suggest that the WG take a serious look at these comments and that  
we engage in some dialogue about it.  It may well be that the WG  
wishes to embark upon a careful definition of all of the necessary  
behavioral, routing, multi-cast and management specifications that  
would be needed to truly turn the SPP into a network layer routing  
protocol.  However, I doubt that it is worth the investment of time  
given the lack of any spare bits in the SPP that could be used for  
signaling, and the availability of CFDP and the in process DTN  
standards that do have routing and behavior well defined.

And please, if I have somehow, in my quick re-reading of the SPP Blue  
Book, overlooked some essential feature of the SPP that actually gives  
it all of these ascribed properties, do not hesitate to let me know  
what I have missed or misunderstood.

With all due respect, Peter


On 16 Oct 2008, at 12:21 AM, Greg Kazz wrote:

> All,
>
> Please find attached Takahiro's final update to the SPP GB.
>
> For review today.
>
> Greg
>
>> Date: Fri, 10 Oct 2008 22:47:21 +0900
>> From: Takahiro Yamada <tyamada at pub.isas.jaxa.jp>
>> Reply-To: tyamada at pub.isas.jaxa.jp
>> Organization: JAXA/ISAS
>> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;  
>> rv:1.7.2) Gecko/20040804 Netscape/7.2
>> X-Accept-Language: en-us, en
>> To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
>> CC: tomg at aiaa.org, jean-Luc.Gerner at esa.int
>> Subject: Re: Space Packet Protocol Green Book
>> X-MAIL: dam01.s.tksc.jaxa.jp m9ADlL7P029796
>> X-Source-IP: tkes52.tksc.jaxa.jp [133.56.0.40]
>> X-Source-Sender: tyamada at pub.isas.jaxa.jp
>>
>> Greg,
>>
>>> Will you be able to provide us with an updated version of the  
>>> Space Packet Protocol Green Book before the meeting in Berlin?
>>
>> I'm very sorry for this last minute submission, but here it is. It  
>> is consistent with the Pink Sheets on the Space Packet Protocol  
>> provided by Tom.
>>
>> Please let me know when we discuss it at Berlin.
>>
>> I look forward to seeing you again there.
>>
>> Best regards,
>> Takahiro Yamada.
>>
>>
>>
> <SPP_DGB5.doc>_______________________________________________
> Sls-slp mailing list
> Sls-slp at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/sls-slp






_______________________________________________________

Peter Shames
Manager - JPL Data Systems Standards Program
InterPlanetary Network Directorate
Jet Propulsion Laboratory, MS 301-230
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-0028

Internet:  Peter.Shames at jpl.nasa.gov
________________________________________________________
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the  
first time"

                                                                                              T 
.S. Eliot


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081031/1f273c89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SPP_DGB5-ps-16Oct08.doc
Type: application/msword
Size: 515072 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081031/1f273c89/attachment.doc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081031/1f273c89/attachment-0001.html>