From greg.j.kazz at jpl.nasa.gov Tue Apr 4 17:32:50 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Tue, 04 Apr 2006 10:32:50 -0700 Subject: [Sls-slp] Fwd: [Cesg-all] CCSDS Spring '06 Meetings Registration - Now Open Message-ID: <6.2.0.14.2.20060404102843.02f4e3f0@mail.jpl.nasa.gov> All, Note: Password is lower case ccsds. regards, Greg Kazz Chairman SLS-SLP, SLS-HRU, SIS-IPO WGs >Registration for the CCSDS Spring 2006 Meetings is now open! > > > >¯ CCSDS Technical Meetings – Rome, Italy > >Hosted by the Agenzia Spaziale Italiana (ASI), the CCSDS Spring 2006 >Technical Meetings will take place from June 12 – 16, 2006, in Rome, >Italy, the week right before SpaceOps 2006. The CESG meeting will be on >Saturday, June 17, 2006. All CCSDS meetings, including the CESG meeting, >will be held in a facility owned by the Italian Ministry for Internal >Affairs located at the following address: > > >Istituto Superiore Antincendi (ISA) >Via del Commercio 13, Roma 00154 (Italy) > >Identification information due by May 26th, 2006! >In order to access the ISA meeting site and speed the check-in process, >ASI and ISA have requested that each participant submit identification >information in advance of the meeting date. For your convenience only, we >have attached a password protected form that you may use to send this >information to ASI. The temporary password is CCSDS. > >Please fill out the form and then forward it directly to our ASI points of >contact, Ms. Loredana Bruca and Mr. Lorenzo Chessa at >ccsds-spring2006 at asi.it . Please remember >that if you choose to change the password, you also must send the new >password in a separate e-mail to the same address. > >If you are unable to e-mail your identification information to ASI before >May 26th, 2006, please allow yourself extra time to be processed through >ISA security the first day of the meetings. ¯ CCSDS Meeting Registration To register for CCSDS meetings, please visit the main Spring 2006 Meetings information page located on the CCSDS web site at http://public.ccsds.org/meetings/2006Spring/2006Spring.aspx. You may visit this page regularly to access the latest meetings information for each scheduled day, agendas (as they become available), logistics information, and the list of registered participants (requires log in). Tech Support The registration system is optimized for following browsers: IBM/PC - Microsoft Internet Explorer 5.01 or later, plus the latest service packs - Netscape Navigator 6.2 or later - Firefox 1.0 or later MAC - Internet Explorer 5.2 for Mac OS X, plus the latest service pack - Netscape Navigator 6.2 or later - Firefox 1.0 or later - Mozilla 1.7 or later UNIX - Netscape Navigator 6.2 for UNIX or later - Firefox 1.0 or later If you experience technical difficulty completing your registration, please contact Brian Oliver at brian.oliver at btas.com. If you need to make changes to your registration information once you have registered through the system, please contact Marco Bovo at marco.bovo at btas.com for assistance. If you have general questions or need access to the CCSDS logo suite, please contact Penelope Walz at penelope.walz at btas.com. Thank you for your participation. Best regards, The CCSDS Secretariat Support Team Penelope W. Walz The Consultative Committee for Space Data Systems (CCSDS) CCSDS Secretariat – Public Affairs Mobile - +1 571 235 1625 (best contact / voicemail) E-mail - penelope.walz at btas.com Explore CCSDS at http://www.ccsds.org -------------- next part -------------- A non-text attachment was scrubbed... Name: ISA_Access_Info.doc Type: application/msword Size: 638976 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Tue Apr 4 17:42:54 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Tue, 04 Apr 2006 10:42:54 -0700 Subject: [Sls-slp] Fwd: [Cesg-all] Travel Guides to Rome, Maps and Hotel Information Message-ID: <6.2.0.14.2.20060404104143.02f59de8@mail.jpl.nasa.gov> For your information. Greg Kazz CCSDS Chairman SLS-SLP, SLS-HRU, SIS-IPO WGs >Date: Tue, 4 Apr 2006 12:56:11 -0400 >X-MS-Has-Attach: >X-MS-TNEF-Correlator: >Thread-Topic: Travel Guides to Rome, Maps and Hotel Information >Thread-Index: AcZYCKzyzCEaRlRbR96E9Sj2XixNrg== >From: "Walz Penelope \(BTAS\)" >To: , , > , , > , >Cc: >Subject: [Cesg-all] Travel Guides to Rome, Maps and Hotel Information >X-BeenThere: cesg-all at mailman.ccsds.org >X-Mailman-Version: 2.1.4 >List-Id: CCSDS-Engineering Steering Group-All >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: cesg-all-bounces at mailman.ccsds.org >X-Source-IP: m2.btas.com [66.194.184.76] >X-Source-Sender: cesg-all-bounces at mailman.ccsds.org >X-JPL-spam-score: 0.00% > >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C65809.41BE91FC" > >Dear CCSDS Community: > >When making your travel arrangements to attend the meetings this spring, >please remember that June is the beginning of the tourist season in >Rome. You are advised to make your reservations early since hotel rooms >and flights are already in short supply. For a list of hotels recommended >by our host agency ASI, please visit the CCSDS web site at >http://public.ccsds.org/meetings/2006Spring/2006SpringHotels.aspx >. > >In addition, I have included below a large collection of sites that you >might find interesting or helpful in planning various aspects of your trip >to Rome. > >¯ TOURIST INFO & MAPS >Roma Turismo (good interactive map): >http://www.romaturismo.com >Nerone - The Insider's Guide to Rome: >http://www.nerone.cc/ >Rome Guide: http://www.romeguide.it >Vatican City: http://www.vatican.va >CharmingRome.com: http://www.charmingrome.com >Roma Online: http://www.romaonline.net >Rome Italy Web and City Guide: >http://regional.searchbeat.com/rome.htm >Romexplorer - Guide to Rome: >http://www.romexplorer.com >Requesting Papal Event Tickets: >http://www.santasusanna.org/popeVatican/tickets.html >Rome and the disabled: http://www.coinsociale.it >Initaly.com: http://www.initaly.com >Vagabondo (the "independent” traveler's site): >http://www.vagabondo.net/Eng/Testohome.htm >Rome Metro Map: >http://www.alfanet.it/welcomeitaly/roma/bus_metro/mappametro.html > >¯ TRAIN, BUS AND SUBWAY TRAVEL >Euro railways: http://eurorailways.com >European railways and timetables: >http://www.railfaneurope.net/ >Ferrovie dello Stato: http://www.fs-on-line.com >Rome Bus and Metro site: http://www.atac.roma.it/ >Circumvesuviana stops and the timetable: >http://www.ininterland.it/circumvesuviana.htm >Eurodestination: >http://www.eurodestination.com > >¯ AIRPORTS >Aeroporti di Roma: http://www.adr.it >Aeroporti di Milano: >http://www.sea-aeroportimilano.it/ >Aeroporto di Firenze: >http://www.aeroporto.firenze.it/ >European Airports: >http://www.atlasnavigator.com/directory/apeuro.html >Directory of airports worldwide: >http://www.azfreight.com/links/azlinks1.htm > >Airport Shuttle: http://www.airportshuttle.it > >¯ ROME: HISTORY, ART & ARCHITECTURE >Rome in the footsteps of an XVIIIth century traveler: >http://www.romeartlover.it/ >Plan de Rome (scale model of Rome): >http://www.unicaen.fr/rome/index.php >Roma, History and Civilization of the eternal city: >http://www.citrag.it/roma/eng_home.htm >Baroque Rome in the etchings of Giuseppe Vasi: >http://members.tripod.com/romeartlover/index.html >History and Art in the coats of arms of the Popes: >http://members.tripod.com/romeartlover/Stemmi.html >Vasi's 1781 map of Rome: >http://members.tripod.com/romeartlover/Map.html >Waters of Rome: >http://jefferson.village.virginia.edu/waters/ >Rome Time Elevator: http://www.time-elevator.it >Images of Rome: >http://www.siba.fi/~kkoskim/rooma/pages/MAIN.HTM >Forma Urbis Romae (interactive monument map of Rome): >http://www.vatican.va/formaurbis/index_en.htm > >Ancient Rome: >Excavations of the forum of Trajan: >http://www.traiano.com/inglese/testi_html/home.htm >Ancient Roman Consular Roads: >http://www.iterconficere.net >Forum Romanum (exploring an ancient marketplace): >http://intranet.grundel.nl/thinkquest/ >Capitolium (Imperial Forums website): >http://www.capitolium.org > > >Best of luck in your travels, >Penelope > >Penelope W. Walz >The Consultative Committee for Space Data Systems (CCSDS) >CCSDS Secretariat – Public Affairs >Mobile - +1 571 235 1625 (best contact / voicemail) >E-mail - penelope.walz at btas.com >Explore CCSDS at http://www.ccsds.org > >_______________________________________________ >CESG-all mailing list >CESG-all at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/cesg-all From greg.j.kazz at jpl.nasa.gov Wed Apr 5 16:58:23 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Wed, 05 Apr 2006 09:58:23 -0700 Subject: [Sls-slp] New PDF version of Prox-1 GB Available Message-ID: <6.2.0.14.2.20060405095601.02f1b6b0@mail.jpl.nasa.gov> All, A PDF version of the Prox-1 GB is now available on the public folder within the CWE area of SLS-SLP. Please go to http://public.ccsds.org/sites/cwe/sls-slp/default.aspx to see and download it. I appreciate your comments on this green book. We will discuss them at our SLS-SLP meeting in Rome. thanks, Greg Kazz Chairman SLS-SLP WG From greg.j.kazz at jpl.nasa.gov Tue Apr 18 21:20:09 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Tue, 18 Apr 2006 14:20:09 -0700 Subject: [Sls-slp] Re: Encapsulation Service Message-ID: <6.2.0.14.2.20060418141711.03114df8@mail.jpl.nasa.gov> Bob, Please review my answers to your conditional acceptance of the Encapsulation Service to blue book status. I sent this reply on March 24 but I didn't hear back from you. I think this email should cover all of your concerns, but let me know. thanks, Greg Bob, Thanks for your comments. They have helped make the Encapsulation Service a better specification. My answers to your comments are in ** ** below. thanks, Greg At 03:05 PM 3/23/2006, Thomas Gannett wrote: >Greg: > >FYI: The CESG poll on encapsulation serve has received at least one >"Approve with Conditions" vote (from Durst). The conditions are below. > >TG > >APPROVE WITH CONDITIONS: 1 (33.33%) (Durst) > >In section 2.2, it is unclear what the conformance requirements >are. There are two protocols (Space Packet and Encapsulation Packet) >under a single service interface. Are both required for conformance? **Both protocols can be used to encapsulate other protocols. For example, CFDP can be encapsulated into space packets by using APID=2045 or into an Encapsulation packet by using PID = '110'. I need to know more about what you are expecting in terms of "conformance requirements". The encapsulation service specifies the inputs, what protocols are used to do the encapsulating, and references the Space Link Identifiers document, which supplies all of the IDs one needs in order to carry out the service.** >The document requires a SANA Implications section to address registered >APIDs and PIDs, and to define procedures to register new APIDs and PIDs. ** All of the IDs used by the Encapsulation Service are defined in the Space Link Identifiers spec. This is true for all of the link layer protocols. Therefore, it is the Space Link Identifiers book that requires a SANA implication section, not Encap. service. APIDs and PIDs are defined in the Space Link Identifiers book which is referenced in section 2.3 ** >The document requires a security implications section. ** I will work with Howie on how to accomplish this ** >Section 3.3.2.2: It is unclear to me whether and how a user of the >service is expected to know the correct GVCID and PVN to use. Are these >statically assigned? Assigned on a per-mission basis? What are the >implications on interoperability? ** GVCID = SCID + VCID. SCID is statically assigned. VCID is an enterprise or project managed parameter. CCSDS recognizes certain PVNs. All of these IDs are defined and their values are listed (if not a managed parameter) in the Space Link Identifiers spec. For things like PVN it's very static. For APIDs, an enterprise has to really manage these across the enterprise in order for interoperability to happen. Global enterprise APIDs begin to happen in these cases. ** >Section 4.1, item b) the APID "shall be one of the reserved APIDs" >defined in reference [8]. Are there guidelines or further restrictions on >how a particular APID is chosen? Does interoperability depend on this >choice? In Table 5-2 of reference [8], there appear to be two degrees of >"reserved" -- reserved and assigned to a particular protocol, and reserved >but unassigned. Are any of these fair game? Or was it intended that >these be drawn from the 2040-2044 range? ** Again APIDs are a managed parameter by an enterprise except for the ones defined in the CCSDS Space Link Identifiers book. There are no further restrictions except the ones managed by the enterprise. Yes, interoperability is an issue for the management of those apids. It is intended that 2040-2044 be used for encapsulation by space packets. ** >Section 4.2.2.1, item g -- this is a poorly worded summary of section >4.2.2.8. Recommend rewording to "Packet Length (0, 1, 2, or 4 octets) -- >See Figure 4-2. ** Agreed. It will be changed to Packet Length (0, 1, 2, or 4 octets). ** >Section 4.2.2.3 -- "The value '110'..." does this require a RID against >135.0-B-2 (or whatever)? ** The PID value '110" needs to be added to Space Link Identifiers blue book via a new pink sheet ** >Section 4.2.2.6 -- "The extended protocol IDs..." I didn't see this in >reference [8]. Does it require a RID? ** A new table called "Extended Protocol IDs" needs to be added to the Space Link Identifiers blue book via the new pink sheet. ** >As a note to the secretariat, I'd suggest that we add an Annex for red >books that require modifications to other documents that consolidates >and summarizes those external dependencies. ** I agree ** From durst at mitre.org Wed Apr 19 14:28:21 2006 From: durst at mitre.org (Durst, Robert C.) Date: Wed, 19 Apr 2006 10:28:21 -0400 Subject: [Sls-slp] RE: Encapsulation Service Message-ID: <3B660B4ACB06BE488E3938F95115E4DEC3ADF7@IMCSRV4.MITRE.ORG> Greg et al, Apologies for the late response. Here are my thoughts on this: >>APPROVE WITH CONDITIONS: 1 (33.33%) (Durst) >> >>In section 2.2, it is unclear what the conformance requirements >>are. There are two protocols (Space Packet and Encapsulation Packet) >>under a single service interface. Are both required for conformance? > >**Both protocols can be used to encapsulate other protocols. >For example, >CFDP can be encapsulated into space packets by using APID=2045 >or into an >Encapsulation packet by using PID = '110'. I need to know more >about what >you are expecting in terms of "conformance requirements". The >encapsulation >service specifies the inputs, what protocols are used to do the >encapsulating, and references the Space Link Identifiers >document, which >supplies all of the IDs one needs in order to carry out the service.** The conformance requirements I am asking about are whether an implementation is "conformant" if it only implements one of these two protocols (SPP or Encapsulation Packet). If so, please say so. If not, please explain how you ensure interoperability between two conformant applications that invoke this service (when, for example, one is hosted on a node that implements SPP and the other is hosted on a node that implements only Encapsulation). >>The document requires a SANA Implications section to address >registered >>APIDs and PIDs, and to define procedures to register new >APIDs and PIDs. > >** All of the IDs used by the Encapsulation Service are defined in the >Space Link Identifiers spec. This is true for all of the link layer >protocols. Therefore, it is the Space Link Identifiers book >that requires a >SANA implication section, not Encap. service. APIDs and PIDs >are defined >in the Space Link Identifiers book which is referenced in >section 2.3 ** OK. Does the Space Link Identifiers book have such a section? My comment will be successfully resolved if either of these documents has a SANA section. >>The document requires a security implications section. > >** I will work with Howie on how to accomplish this ** OK. When added, this comment will be resolved. >>Section 3.3.2.2: It is unclear to me whether and how a user of the >>service is expected to know the correct GVCID and PVN to use. > Are these >>statically assigned? Assigned on a per-mission basis? What are the >>implications on interoperability? > >** GVCID = SCID + VCID. SCID is statically assigned. VCID is >an enterprise >or project managed parameter. CCSDS recognizes certain PVNs. >All of these >IDs are defined and their values are listed (if not a managed >parameter) in >the Space Link Identifiers spec. For things like PVN it's very >static. For >APIDs, an enterprise has to really manage these across the >enterprise in >order for interoperability to happen. Global enterprise APIDs begin to >happen in these cases. ** This explanation is helpful. I know that the book is normative, rather than informative, but it would be nice to have this explained in there. >>Section 4.1, item b) the APID "shall be one of the reserved APIDs" >>defined in reference [8]. Are there guidelines or further >restrictions on >>how a particular APID is chosen? Does interoperability >depend on this >>choice? In Table 5-2 of reference [8], there appear to be >two degrees of >>"reserved" -- reserved and assigned to a particular protocol, >and reserved >>but unassigned. Are any of these fair game? Or was it intended that >>these be drawn from the 2040-2044 range? > >** Again APIDs are a managed parameter by an enterprise except >for the ones >defined in the CCSDS Space Link Identifiers book. There are no further >restrictions except the ones managed by the enterprise. Yes, >interoperability is an issue for the management of those apids. It is >intended that 2040-2044 be used for encapsulation by space packets. ** Could you please clarify these points in the document? I think that it would be useful to summarize the "managed parameters" somewhere, to make it clear specifically what bilateral agreements are required to ensure interoperability. This may be part of the "lore" within the CCSDS community, but if we want other folks to use this, making it clear what needs to be agreed upon out-of-band seems important. >>Section 4.2.2.1, item g -- this is a poorly worded summary of section >>4.2.2.8. Recommend rewording to "Packet Length (0, 1, 2, or >4 octets) -- >>See Figure 4-2. > >** Agreed. It will be changed to Packet Length (0, 1, 2, or 4 >octets). ** Thanks. >>Section 4.2.2.3 -- "The value '110'..." does this require a >RID against >>135.0-B-2 (or whatever)? > >** The PID value '110" needs to be added to Space Link >Identifiers blue >book via a new pink sheet ** OK, thanks. >>Section 4.2.2.6 -- "The extended protocol IDs..." I didn't >see this in >>reference [8]. Does it require a RID? > >** A new table called "Extended Protocol IDs" needs to be added to the >Space Link Identifiers blue book via the new pink sheet. ** OK. >>As a note to the secretariat, I'd suggest that we add an >Annex for red >>books that require modifications to other documents that consolidates >>and summarizes those external dependencies. ** I agree ** Perhaps also another annex that summarizes the "managed parameters" that the protocol specifies that must be agreed among peers in order to ensure interoperability? Thanks, and again, sorry for the delay. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Apr 19 18:22:18 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Wed, 19 Apr 2006 11:22:18 -0700 Subject: [Sls-slp] RE: Encapsulation Service In-Reply-To: <3B660B4ACB06BE488E3938F95115E4DEC3ADF7@IMCSRV4.MITRE.ORG> References: <3B660B4ACB06BE488E3938F95115E4DEC3ADF7@IMCSRV4.MITRE.ORG> Message-ID: <6.2.0.14.2.20060419111011.03111d30@mail.jpl.nasa.gov> Bob, My comments in ** ** below. thanks, Greg At 07:28 AM 4/19/2006, Durst, Robert C. wrote: > > >Greg et al, > >Apologies for the late response. Here are my thoughts on this: > > >>APPROVE WITH CONDITIONS: 1 (33.33%) (Durst) > >> > >>In section 2.2, it is unclear what the conformance requirements > >>are. There are two protocols (Space Packet and Encapsulation Packet) > >>under a single service interface. Are both required for conformance? > > > >**Both protocols can be used to encapsulate other protocols. > >For example, > >CFDP can be encapsulated into space packets by using APID=2045 > >or into an > >Encapsulation packet by using PID = '110'. I need to know more > >about what > >you are expecting in terms of "conformance requirements". The > >encapsulation > >service specifies the inputs, what protocols are used to do the > >encapsulating, and references the Space Link Identifiers > >document, which > >supplies all of the IDs one needs in order to carry out the service.** > >The conformance requirements I am asking about are whether an >implementation is "conformant" if it only implements one of these >two protocols (SPP or Encapsulation Packet). If so, please say so. >If not, please explain how you ensure interoperability between two >conformant applications that invoke this service (when, for example, >one is hosted on a node that implements SPP and the other is hosted >on a node that implements only Encapsulation). ** An implementation is conformant if it only implements one of these two protocols. I will modify the document to say this explicitly. ** > >>The document requires a SANA Implications section to address > >registered > >>APIDs and PIDs, and to define procedures to register new > >APIDs and PIDs. > > > >** All of the IDs used by the Encapsulation Service are defined in the > >Space Link Identifiers spec. This is true for all of the link layer > >protocols. Therefore, it is the Space Link Identifiers book > >that requires a > >SANA implication section, not Encap. service. APIDs and PIDs > >are defined > >in the Space Link Identifiers book which is referenced in > >section 2.3 ** > >OK. Does the Space Link Identifiers book have such a section? My >comment will be successfully resolved if either of these documents has a >SANA section. ** I will add it to the Space Link Identifiers book ** > >>The document requires a security implications section. > > > >** I will work with Howie on how to accomplish this ** > >OK. When added, this comment will be resolved. > > >>Section 3.3.2.2: It is unclear to me whether and how a user of the > >>service is expected to know the correct GVCID and PVN to use. > > Are these > >>statically assigned? Assigned on a per-mission basis? What are the > >>implications on interoperability? > > > >** GVCID = SCID + VCID. SCID is statically assigned. VCID is > >an enterprise > >or project managed parameter. CCSDS recognizes certain PVNs. > >All of these > >IDs are defined and their values are listed (if not a managed > >parameter) in > >the Space Link Identifiers spec. For things like PVN it's very > >static. For > >APIDs, an enterprise has to really manage these across the > >enterprise in > >order for interoperability to happen. Global enterprise APIDs begin to > >happen in these cases. ** > >This explanation is helpful. I know that the book is normative, rather >than informative, but it would be nice to have this explained in there. ** OK, I will see if I can weave these explanation in without being wordy ** > >>Section 4.1, item b) the APID "shall be one of the reserved APIDs" > >>defined in reference [8]. Are there guidelines or further > >restrictions on > >>how a particular APID is chosen? Does interoperability > >depend on this > >>choice? In Table 5-2 of reference [8], there appear to be > >two degrees of > >>"reserved" -- reserved and assigned to a particular protocol, > >and reserved > >>but unassigned. Are any of these fair game? Or was it intended that > >>these be drawn from the 2040-2044 range? > > > >** Again APIDs are a managed parameter by an enterprise except > >for the ones > >defined in the CCSDS Space Link Identifiers book. There are no further > >restrictions except the ones managed by the enterprise. Yes, > >interoperability is an issue for the management of those apids. It is > >intended that 2040-2044 be used for encapsulation by space packets. ** > >Could you please clarify these points in the document? ** OK ** >I think that it would be useful to summarize the "managed parameters" >somewhere, to make it clear specifically what bilateral agreements are >required to ensure interoperability. This may be part of the "lore" >within the CCSDS community, but if we want other folks to use this, making >it clear what needs to be agreed upon out-of-band seems important. > > >>Section 4.2.2.1, item g -- this is a poorly worded summary of section > >>4.2.2.8. Recommend rewording to "Packet Length (0, 1, 2, or > >4 octets) -- > >>See Figure 4-2. > > > >** Agreed. It will be changed to Packet Length (0, 1, 2, or 4 > >octets). ** > >Thanks. > > >>Section 4.2.2.3 -- "The value '110'..." does this require a > >RID against > >>135.0-B-2 (or whatever)? > > > >** The PID value '110" needs to be added to Space Link > >Identifiers blue > >book via a new pink sheet ** > >OK, thanks. > > >>Section 4.2.2.6 -- "The extended protocol IDs..." I didn't > >see this in > >>reference [8]. Does it require a RID? > > > >** A new table called "Extended Protocol IDs" needs to be added to the > >Space Link Identifiers blue book via the new pink sheet. ** > >OK. > > >>As a note to the secretariat, I'd suggest that we add an > >Annex for red > >>books that require modifications to other documents that consolidates > >>and summarizes those external dependencies. ** I agree ** > >Perhaps also another annex that summarizes the "managed parameters" that >the protocol specifies that must be agreed among peers in order to ensure >interoperability? ** OK, I will list the documents that Encapsulation Service affects and which parts (tables etc) are affected i.e., when a change is made. ** >Thanks, and again, sorry for the delay. > >Bob From greg.j.kazz at jpl.nasa.gov Wed Apr 19 19:50:34 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Wed, 19 Apr 2006 12:50:34 -0700 Subject: [Sls-slp] Finishing up on Encapsulation Service Message-ID: <6.2.0.14.2.20060419120612.03156a60@mail.jpl.nasa.gov> Tom, Here are the specific additions that Bob Durst wanted: 1) Section 2.2 In paragraph 2: A data unit supplied by the service user is encapsulated unchanged into a Space Packet or an Encapsulation Packet an no more than one data unit is encapsulated into a single packet. An implementation is conformant if it implements either the Space Packet or the Encapsulation Packet i.e., both are not required. 2) Section 3.3.2.2 and 3.3.3.2 To each of these sections add the following: Note: The management and where applicable defined values of the GVCID, PVN, and EPI fields in these primatives are defined in reference [8] reference[8] is the Space Link Identifiers Blue book 3) Section 4.1 item b) the Application Process Identifier (APID) shall be chosen from one of the reserved APIDs in the 2040 to 2044 range documented in reference [8]. 4) Section 4.2.2.1, item g It will be changed to Packet Length (0,1,2, or 4 octets). 5) Section 4.2.2.3 PID = '110' was added to the Space Link Identifiers pink sheet 6) Section 4.2.2.6 Extended Protocol IDs table was added to the space link Identifiers pink sheet 7) The managed parameters that the Encapsulation Service cares about are already listed in Section 5 of this document. What's missing is the controlling document, which needs to be added. We need two separate tables; One table if the Space Packet is used: Table 5-1 the other table 5-2, if the encapsulation packet is used. The new 3rd Column is called "Defined in" Table 5-1 Managed parameters for Encapsulation Service (Space Packet used) minimum data unit length is undefined maximum data unit length is defined in the Space Packet Protocol document valid packet version numbers is defined in the Space Link Protocol document valid protocol identifiers doesn't apply Table 5-2 Managed parameters for Encapsulation Service (Encapsulation Packet used) - minimum data unit length is defined in the Encapsulation Service document - maximum data unit length is defined in the Encapsulation Service document - valid packet version numbers is defined in the Space Link Identifiers document - valid apids does not apply - valid protocol identifiers is defined in the Space link Identifiers document All of this can be put into the same structure that Takahiro defined in the old table 5-1 but with the addition of the new column. thanks, Greg From greg.j.kazz at jpl.nasa.gov Wed Apr 19 20:36:51 2006 From: greg.j.kazz at jpl.nasa.gov (Greg Kazz) Date: Wed, 19 Apr 2006 13:36:51 -0700 Subject: [Sls-slp] RE: Encapsulation Service In-Reply-To: <3B660B4ACB06BE488E3938F95115E4DEC3AEC5@IMCSRV4.MITRE.ORG> References: <3B660B4ACB06BE488E3938F95115E4DEC3AEC5@IMCSRV4.MITRE.ORG> Message-ID: <6.2.0.14.2.20060419132710.0327a2f8@mail.jpl.nasa.gov> At 01:08 PM 4/19/2006, Durst, Robert C. wrote: >While this is probably the pragmatic approach, the implication of this is >that two implementors can provide the same CCSDS service in a way that is >not, and cannot be configured to be, interoperable. I find this >disturbing. This possibility at least needs to be noted, and added to >the list of parameters that are managed among implementors. This seems >like a rather serious flaw to me. I would much rather see a requirement >to implement both and an option to use either on a per-mission >basis. Failing that, I'd like to see a Protocol Implementation >Conformance Statement developed and made mandatory, so that there is no >ambiguity about what an implementor has implemented. Bob, Actually it is already a managed parameter. It's the PVN , i.e., packet version number in the Space Link Identifers blue book. It tells the receiver how to interpret the packet, i.e., how to find the length field, in order to extract it and assemble it. Encapsulation Packets have a unique PVN, so do Space Packets and they are distinct. So CCSDS has provided a mechanism for space agencies to be interoperable. But that doesn't proclude some hypothetical rogue space agency who "gets there first" who only chooses to support bit streams instead of CCSDS recognized packet version numbers. ____________________________________________________________________________________ >>I think that it would be useful to summarize the "managed parameters" >>somewhere, to make it clear specifically what bilateral >agreements are >>required to ensure interoperability. This may be part of the "lore" >>within the CCSDS community, but if we want other folks to use >this, making >>it clear what needs to be agreed upon out-of-band seems important. Didn't see any comment on this (but then, my comment didn't require any). Any thoughts on an annex to summarize these? I think we are between messages. You are probably reading that second message now. Actually Yamada has already captured the managed parameters in Table 5-1 of the Encapsulation Packet service, but he didn' t reference the controlling document for each parameter and more cleanly deliniate what applies when one use Space packets vs Encapsulation packets. Greg From durst at mitre.org Wed Apr 19 20:08:58 2006 From: durst at mitre.org (Durst, Robert C.) Date: Wed, 19 Apr 2006 16:08:58 -0400 Subject: [Sls-slp] RE: Encapsulation Service Message-ID: <3B660B4ACB06BE488E3938F95115E4DEC3AEC5@IMCSRV4.MITRE.ORG> >> >>In section 2.2, it is unclear what the conformance requirements >> >>are. There are two protocols (Space Packet and >Encapsulation Packet) >> >>under a single service interface. Are both required for >conformance? >> > >> >**Both protocols can be used to encapsulate other protocols. >> >For example, >> >CFDP can be encapsulated into space packets by using APID=2045 >> >or into an >> >Encapsulation packet by using PID = '110'. I need to know more >> >about what >> >you are expecting in terms of "conformance requirements". The >> >encapsulation >> >service specifies the inputs, what protocols are used to do the >> >encapsulating, and references the Space Link Identifiers >> >document, which >> >supplies all of the IDs one needs in order to carry out the >service.** >> >>The conformance requirements I am asking about are whether an >>implementation is "conformant" if it only implements one of these >>two protocols (SPP or Encapsulation Packet). If so, please say so. >>If not, please explain how you ensure interoperability between two >>conformant applications that invoke this service (when, for example, >>one is hosted on a node that implements SPP and the other is hosted >>on a node that implements only Encapsulation). > > >** An implementation is conformant if it only implements one >of these two >protocols. I will modify the document to say this explicitly. ** While this is probably the pragmatic approach, the implication of this is that two implementors can provide the same CCSDS service in a way that is not, and cannot be configured to be, interoperable. I find this disturbing. This possibility at least needs to be noted, and added to the list of parameters that are managed among implementors. This seems like a rather serious flaw to me. I would much rather see a requirement to implement both and an option to use either on a per-mission basis. Failing that, I'd like to see a Protocol Implementation Conformance Statement developed and made mandatory, so that there is no ambiguity about what an implementor has implemented. >> >>The document requires a SANA Implications section to address >> >registered >> >>APIDs and PIDs, and to define procedures to register new >> >APIDs and PIDs. >> > >> >** All of the IDs used by the Encapsulation Service are >defined in the >> >Space Link Identifiers spec. This is true for all of the link layer >> >protocols. Therefore, it is the Space Link Identifiers book >> >that requires a >> >SANA implication section, not Encap. service. APIDs and PIDs >> >are defined >> >in the Space Link Identifiers book which is referenced in >> >section 2.3 ** >> >>OK. Does the Space Link Identifiers book have such a section? My >>comment will be successfully resolved if either of these >documents has a >>SANA section. > >** I will add it to the Space Link Identifiers book ** OK, thanks. >> > >> >** GVCID = SCID + VCID. SCID is statically assigned. VCID is >> >an enterprise >> >or project managed parameter. CCSDS recognizes certain PVNs. >> >All of these >> >IDs are defined and their values are listed (if not a managed >> >parameter) in >> >the Space Link Identifiers spec. For things like PVN it's very >> >static. For >> >APIDs, an enterprise has to really manage these across the >> >enterprise in >> >order for interoperability to happen. Global enterprise >APIDs begin to >> >happen in these cases. ** >> >>This explanation is helpful. I know that the book is >normative, rather >>than informative, but it would be nice to have this explained >in there. > > >** OK, I will see if I can weave these explanation in without >being wordy ** Thanks. >> >>Section 4.1, item b) the APID "shall be one of the reserved APIDs" >> >>defined in reference [8]. Are there guidelines or further >> >restrictions on >> >>how a particular APID is chosen? Does interoperability >> >depend on this >> >>choice? In Table 5-2 of reference [8], there appear to be >> >two degrees of >> >>"reserved" -- reserved and assigned to a particular protocol, >> >and reserved >> >>but unassigned. Are any of these fair game? Or was it >intended that >> >>these be drawn from the 2040-2044 range? >> > >> >** Again APIDs are a managed parameter by an enterprise except >> >for the ones >> >defined in the CCSDS Space Link Identifiers book. There are >no further >> >restrictions except the ones managed by the enterprise. Yes, >> >interoperability is an issue for the management of those >apids. It is >> >intended that 2040-2044 be used for encapsulation by space >packets. ** >> >>Could you please clarify these points in the document? > >** OK ** Thanks. >>I think that it would be useful to summarize the "managed parameters" >>somewhere, to make it clear specifically what bilateral >agreements are >>required to ensure interoperability. This may be part of the "lore" >>within the CCSDS community, but if we want other folks to use >this, making >>it clear what needs to be agreed upon out-of-band seems important. Didn't see any comment on this (but then, my comment didn't require any). Any thoughts on an annex to summarize these? -------------- next part -------------- An HTML attachment was scrubbed... URL: From durst at mitre.org Wed Apr 19 20:40:12 2006 From: durst at mitre.org (Durst, Robert C.) Date: Wed, 19 Apr 2006 16:40:12 -0400 Subject: [Sls-slp] RE: Encapsulation Service Message-ID: <3B660B4ACB06BE488E3938F95115E4DEC3AEE1@IMCSRV4.MITRE.ORG> >>While this is probably the pragmatic approach, the >implication of this is >>that two implementors can provide the same CCSDS service in a >way that is >>not, and cannot be configured to be, interoperable. I find this >>disturbing. This possibility at least needs to be noted, >and added to >>the list of parameters that are managed among implementors. >This seems >>like a rather serious flaw to me. I would much rather see a >requirement >>to implement both and an option to use either on a per-mission >>basis. Failing that, I'd like to see a Protocol Implementation >>Conformance Statement developed and made mandatory, so that >there is no >>ambiguity about what an implementor has implemented. > > >Bob, > >Actually it is already a managed parameter. It's the PVN , >i.e., packet >version number in the Space Link Identifers blue book. It tells the >receiver how to interpret the packet, i.e., how to find the >length field, >in order to extract it and assemble it. Encapsulation Packets >have a unique >PVN, so do Space Packets and they are distinct. > >So CCSDS has provided a mechanism for space agencies to be >interoperable. >But that doesn't proclude some hypothetical rogue space agency >who "gets >there first" who only chooses to support bit streams instead of CCSDS >recognized packet version numbers. > OK, that covers my concern. > > >>I think that it would be useful to summarize the "managed >parameters" > >>somewhere, to make it clear specifically what bilateral > >agreements are > >>required to ensure interoperability. This may be part of the "lore" > >>within the CCSDS community, but if we want other folks to use > >this, making > >>it clear what needs to be agreed upon out-of-band seems important. > >Didn't see any comment on this (but then, my comment didn't require >any). Any thoughts on an annex to summarize these? > >I think we are between messages. You are probably reading that second >message now. Actually Yamada has already captured the managed >parameters in >Table 5-1 of the Encapsulation Packet service, but he didn' t >reference the >controlling document for each parameter and more cleanly >deliniate what >applies when one use Space packets vs Encapsulation packets. > Ah, OK. I believe that this fully covers my concerns. Thanks to you, Takahiro, and Tom. Durst