1. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 1 CSTS Charter & SLE Toolkit Status 11 April 2005 Y.Doat

2. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 2 Contents A.CSTS Charter B.Available documentation C.SLE Tool Kit Environment D.Association E.Operations F.Service Specialization G.Summary of questions

3. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 3 CSTS Charter - Goals 1.Tool Kit Recommendation derived from SLE; 2.Guidelines for new service specification based on Tool Kit; 3.Prototype based on a dummy service; 4.RUFT and Radiometric Recommendations; 5.SLE API Proxy Recommendation: Internet to SLE Protocol; 6.SLE API best practices; 7.Maintenance of existing SLE books.

4. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 4 CSTS Charter - Planning Spring 2005 913.1 914.0 914.1 914.2 915.x 916.x ISP Recommendation (RB); API Core Specifications (MB); Summary of Concept & Rationale (GB); API Programmer’s Guide (GB); API Supplements for RAF, RCF, ROCF (MB), API Supplements for CLTU, FSP (MB). Autumn 2005 Tool Kit Draft Recommendation Spring 2006 Prototype demonstration RUFT & Radiometric Draft Recommendation

5. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 5 Available Documentation (so far) ESA SLE Toolkit – Commonality Analysis – Technical Note JAXA: Cross Support Generic Service Part 1: Toolkit NASA: Working documents

6. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 6 SLE API Implementation Tool Kit SLE Toolkit Environment Where do we stand? TCP/IP API Proxy API AssociationAPI Operation Derived Service User/Provider Application API Proxy (Based on ISP) Also called ‘data type.

7. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 7 ESA/JAXA: Association: –Bind –Unbind –Peer-Abort Association NASA: Association: –Bind –Unbind –Peer-Abort

8. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 8 List of Operations ESA/JAXA Start Stop Transfer-Data Status-Report Schedule-Status-Report Sync-Notify Async-Notify Get-Parameter Invoke-Directive Throw-Event ESA/JAXANASA Start Stop Transfer-Data Confirmed Transfer-Data Unconfirmed Transfer-Data Status-Report Schedule-Status-ReportCovered by SET Sync-NotifyEvent-Notify Async-Notify Get-Parameter Set-Parameter Invoke-Directive Throw-Event

9. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 9 Operation: THROW-EVENT “The user shall invoke the FSP-THROW-EVENT operation in order to cause the provider to forward to SLE Complex Management an event that requires management action” [FSP] Question : Do we want to keep a dedicated operation for interactions between Data Transfer and SLE Management? Note: In Toulouse we agreed to keep all existing operations.

10. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 10 Operation: INVOKE-DIRECTIVE “The user shall invoke the FSP-INVOKE-DIRECTIVE operation to invoke the TC directives as necessary in order to (re-)establish the commanding capability ” [FSP] Question: Do we want to keep this operation clearly targeting TC? Do we see such a need for other services? Note: In Toulouse we agreed to keep all existing operations.

11. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 11 New operation: SET NASA propose to add a SET operation covering among others SCHEDULE-STATUS-REPORT. Question: Do we accept new operations? What other operations would be required?

12. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 12 Operations: Confirmed & Unconfirmed TRANSFER-DATA NASA propose a CONFIRMED-TRANSFER-DATA and an UNCONFIRMED-TRANSFER-DATA. Forward and Return TRANSFER-DATA do not have the same meaning: –Forward: Transfer-data, provider to confirm, provider to use async- notification if problem –Return: Transfer-data is used to deliver only the data Question: Do we need to have distinct operations for confirmed and unconfirmed PDU? Can we call them TRANSFER-DATA & DELIVER-DATA?

13. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 13 Operations Format All operations are made of: Header –Invoke identifier; –… Data: –Common Data (if any); –Opaque Data.

14. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 14 Operations : Common types Two alternatives: 1.All SLE Types made available by the tool kit. In case a specialized service would need a new type it would use the OPAQUE Type facility. E.g.: CommonType ::= CHOICE { [1] SleTypeA,[2] SleTypeB,[3] OpaqueType – Octet String } 2.Only OPAQUE Type made available by the tool kit. Each specialized service declares its own types. E.g: CommonType ::= OpaqueType – Octet String Question: Which alternative do we select? Discuss pros & cons.

15. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 15 Service Specialisation Forward common RAF ROCF RCF CLTU FSP Return common RUFT COMMON (Abstract) TrackingMonitoring… Common Type: Common (e.g. invoke- Id.) Opaque Common-type Opaque Common-Type: Radiometric Opaque Common- Type: Monitoring Opaque Common-Type: Common Return Opaque Return-Type Opaque Return- Type: RUFT Types

16. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 16 Summary of questions 1.Do we freeze the set of operations or do we allow extensibility? I.e. define all operations at top level or Derived service may define additional operation. 2.THROW-EVENT & INVOKE-DIRECTIVE: Keep or disregard? 3.Do we accept new operations at top level: SET, …? 4.Do we merge SYNC-NOTIFY & ASYNC-NOTIFY into one operation? 5.Confirmed and unconfirmed TRANSFER-DATA or TRANSFER-DATA & DELIVER-DATA? 6.Common types: All identified SLE types in Tool Kit or leave freedom to new services?

17. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 17 Summary of Questions 7. Procedure approach ? Interdependency between operations; Mandatory/Optional behaviour. E.g.: –BIND / UNBIND / PEER-ABORT; –If Transfer-Data is required one must implement Start and Stop. On Stop reception: Forward:clear buffer; Return:stop Transfer-Data. –Throw-event implies an asynchronous notification. –Schedule-status-report implies Status-Report. –Get-parameter.

18. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 18 Summary of questions 8. Allow bi-directional operations ? Do we allow all operations to be bi-directional? E.g: –Bi-directional DELIVER-DATA. We know the behaviour (procedure) associated with this operation in Return services. What would it be in Forward services? –Bi-directional TRANSFER-DATA. We know the behaviour (procedure) associated with this operation in Forward services. What would it be in Return services –Bi-directional notification ?

19. SLE Toolkit 18 April 2005 Athens, Greece CSTS - 19 Summary of Questions 9. Layered or Abstract Approach ? Layered approach: –Define set of operations; –Specify services provided by layer using a set of operations (API); –The toolkit is a layer that does not impose application behavior. Abstract Service: –Specify set of operations; –Specify end-to-end => the abstract service imposes application behavior implying interoperability. –The toolkit is the abstract service.