Summary of IOAG-11 IOAG-11 June18, 2007 Cebreros, Spain Adrian Hooke (NASA) and Nestor Peccia (ESA) CCSDS Technical Liaisons

2 Contents 1.Summary of highlights of IOAG-11 2.CCSDS Liaison Report to IOAG-11 3.JAXA, NASA, ESA Service Architecture Proposals

3 IOAG-11 AGENDA

4 Manfred Warhaut will relinquish the IOAG Chairmanship; Klaus-Juergen Schulz replaces him ISRO (S.K. Shivakumar) admitted as the 7 th. Member of the IOAG Continued progress on Agency deployment of SLE Closed-out all IOAG-8 Resolutions to CCSDS and opened a more limited IOAG-11 set to move forward Resonance on approach towards Service Architecture: JAXA, ESA and NASA presentations IOAG will maintain a core Cross Support Service Catalog Agreement to establish new “IOAG Space Internetworking Strategy Group” (2-year horizon) Co-chairs: Paolo Maldari/ESA and John Rush/NASA Strong opinions from ESA, CNES, BNSC and JAXA about non- standard IP encapsulation using serial HDLC stream Need for supplementary information re: NASA Coding, Modulation and Link Protocols (CMLP) study IOAG-11 HIGHLIGHTS

5 2. CCSDS Liaison Report to IOAG

6 (Res 8.5.1)REQUEST FOR A FRAMEWORK FOR CROSS- SUPPORT SERVICE ARCHITECTURE (Res 8.5.1)REQUEST FOR A FRAMEWORK FOR A CROSS- SUPPORT SERVICES CATALOG (Res 8.1.1)URGENT NEED FOR A SLE MANAGEMENT SERVICES RECOMMENDATION (Res 8.4.1) ADVICE ON CROSS-SUPPORT TRANSFER SERVICES WORKING GROUP CHARTER (Res 8.3.1) ADVICE FOR SIMPLIFICATION OF RF & MOD. RECOMMENDATIONS (Res 8.7.1) REQUEST FOR A HIGH RATE COMMANDING RECOMMENDATION (Res 8.8.1) REQUEST FOR A DELTA DOR RECOMMENDATION (Res 8.2.1)CCSDS STRATEGIC PLAN: SUGGESTED MODIFICATIONS IOAG-08 RESOLUTIONS

7 (8.1.1 and 8.4.1) CCSDS Cross Support Services Area

8 Jan 2007 Jul 2007Jan 2008 Concept of Operations (Green Book) Jul 2008 Interoperations/Demo Track Document Production Track (8.1.1) Service Management Working Group (SMWG): Current Plan of Major Activities SMWG Intermediate SLE SM Red 2 Production Red2 XML schema CCSDS Fall DSN Red-1 Compliant Prototype JAXA Red-1Compliant Prototype ESA Red-1 Compliant Prototype Red2 Agency review CCSDS Spring CCSDS Winter Red 2 Conceptual Analysis Red-2 Red-1 Specific Analysis of Ranging & Radiometric SM Key ActivityDate Updated, completed Conceptual Analyses for committed Red-2 production, updates June 07 Intermediate Meeting (Red-2 production check, adjustments) June 07 Detailed analysis for management of Ranging, Radiometric Services Oct 07 Operations Concept Green Book Oct 07 Red-2 (Submission to Secretariat) Dec 07 XML Schema Update (Red-2 Compliance) Jan 08 Prototype Interoperations (Red-1 Compliant) Apr 07– Apr 08 Inclusion of management of ranging and radiometric service is unlikely for Red-2. Per IOAG resolution 8.1.1, deferment of the inclusion of management of this service is preferred over a delay in production of Red-2.. Current targeted Red-2 book does provide support for management of these services via its allowance for bilaterally defined service configuration profiles and bilaterally defined event sequences.

9 Service Management Recommendation Red-2 1 st Priority Current projection for submission of Red-2 to secretariat is now December 2007 (was September 2007) ~40% of overall work required for Red-2 completed - Excluding ranging, radiometric service management Marginal resources: production mostly being done by NASA W3C XmlSchema2 nd Priority OK; Schema updates to be sequenced after Red-2 updates At least two independently developed interoperable prototypes 2 nd Priority Prototype activities are underway JPL: prototype ready to support inter- operations as of April 2007 ESA: current status indicates interoperations starting ~October JAXA: current status indicates interoperations starting ~September Green (Concept) Book 3 rd Priority Current projection is that basic Green Book will be available in time for Red-2 Review Very slim production resources from BNSC Insufficient resources for producing advance use cases in document Best Practices Book4 th Priority No resources available (8.1.1) Service Management Working Group (SMWG): Summary Status

10 Work is in progress in the SLS RFM Working Group: CCSDS (401) recommendations A and B are both being reworked:  Pink sheets will be available for CCSDS Agency review in November 2007 Simultaneously, an update of the Green Book (413) is in progress to reflect the changes in 401:  The Green Book will be submitted to CESG/CMC for approval in November 2007 (8.3.1) RF & Modulation Simplifications

11 (8.7.1) High Rate Uplink The HRU Working Group met in Colorado Spring in January 2007 but could not identify any substantive mission requirements: Neither ESA (Aurora) nor NASA (Constellation) were able to share their mission scenarios associated with high rate uplinks Accordingly, the HRU Working Group sent a request (April 2007) to the IOAG agencies asking for assistance in the assembly of a set of definitive requirements: Until such mission scenarios and requirements are assembled, the CCSDS HRU Working Group cannot move forward. IOAG assistance is urgently solicited.

12 (8.8.1) Delta DOR The revised Delta- DOR Operations (draft Green Book) is ready for review by the CESG. The plan is to publish the Green Book in the 2 nd. half of 2007

13 (8.2.1) CCSDS Strategic Plan The main comments of the IOAG are paraphrased as follows: 1. The Plan should be more than just a vision: a major driver is the development of a long term architecture for cross support services. 2. There are no clear connections to the forward-looking plans of the various space agencies 3. Planning for standards infusion is not covered well 4. Member agencies are not engaged in the infusion of each new recommendation 5. It is unclear how CCSDS Area objectives and goals are ascertained The CCSDS Strategic and Operating Plans have to be read together. Both have to be reworked (not only considering IOAG comments, but also internal CCSDS discussions)

14 (8.2.1) CCSDS Strategic Plan CCSDS agrees that the Strategic Plan should be updated according to Comment 1 Comment 2 should be discussed with the IOAG. Sometimes the forward looking future of the Agencies is vague, or concentrates in only one domain (e.g., Exploration but not Earth Observation) CCSDS agrees that the Strategic Plan should be updated to reflect Comment 3. However, the IOAG needs to engage in the infusion process and needs to provide regular input to CCSDS. CCSDS feels that no Strategic Plan will guarantee the infusion of a new recommendation within an Agency (consider, for example, the CFDP). Comment 4 should be considered in the response to Comment 3. CCSDS agrees that the Strategic and Operating Plans should be updated to reflect Comment 5: however, the IOAG needs to supply a user input 1. The Plan should be more than just a vision: a major driver is the development of a long term architecture for cross support services. 2. There are no clear connections to the forward-looking plans of the various space agencies 3. Planning for standards infusion is not covered well 4. Member agencies are not engaged in the infusion of each new recommendation 5. It is unclear how CCSDS Area objectives and goals are ascertained

15 An Emerging Issue: An Emerging Issue: Evolution towards Space Internetworking There is an emerging consensus that space missions will desire to evolve towards a networked (multi-hop) model of operations: There is general agreement that the Internet Protocol (IP) suite will work in short- delay, richly connected space communications environments. There is general agreement that the emerging Disruption Tolerant Networking (DTN) protocol suite is needed for many space communications environments where the IP suite will not work well, or will not work at all. There is no current consensus as to how to achieve this evolution. The major issues include: Where to terminate the space link protocol (i.e., where on the ground the routed IP or DTN operations begin) Whether IP is the ubiquitous long-term choice of networking protocol. How IP will be transferred over the space link using current CCSDS standards (DTN is not an issue as it is being designed-into the CCSDS suite). How to provide the most general cross-support solution. The current IP proposals focus on “IP-over-AOS”. ESA spacecraft do not support AOS and therefore ESA spacecraft running IP will require cross-support of CCSDS-standard IP packet insertion in conventional TM/TC. These issues involve implementation choices in ground infrastructure. They are therefore issues that the IOAG will soon need to address.

16 3. Service Architecture Proposals: JAXANASAESA

CROSS SUPPORT SERVICE ARCHITECTURE Takahiro Yamada (JAXA/ISAS) 19 June 2007 JAXA

18 Purpose of This Presentation Review the contents of the Cross Support Service Architecture document developed as the response to the following action item assigned to JAXA at IOAG-10. Action Item 6: Develop a framework showing high level cross- support architecture containing organizational, administrative, and functional features of services for cross- support services. As the response to action item 6, we distributed to the IOAG members a document that described a framework of cross support service architecture at the end of December Since we did not receive any negative comments on the framework document, we proceeded to develop a document that defines the cross support service architecture (IOAG XXX.0-W-1.0), and distributed it to the IOAG members at the beginning of June JAXA

19 Cross Support Service Architecture The cross support service architecture expands the conventional “service-provider/service-user” model to include both space and ground users. The scope of the architecture is limited to four views: Service View Physical View Communications View Enterprise View Cross Support Service System (Service provider) Space Services Ground Services Space Service Users Ground Service Users JAXA

20 Simple Configuration A cross support service element has two interfaces (or two sets of interfaces). The interface (or the set of interfaces) closer to the space user element is called the space side interface The interface (or the set of interfaces) closer to the ground user element is called the ground side interface CSSE S1 Ground User Element Space User Element Space side interface of CSSE 1 Ground side interface of CSSE 1 JAXA

21 Cascaded Configuration There are cases in which a space user element and a ground user element are supported by two or more CSSEs. This figure shows such an example, in which a space user element (a spacecraft) and a ground user element (a spacecraft control center) are supported by CSSE1 (a data relay satellite) and CSSE2 (a ground terminal for the data relay satellite). CSSE 2 CSSE 1 Ground User Element Space User Element Space side interface of CSSE 1 Space side interface of CSSE 2 Ground side interface of CSSE 1 Ground side interface of CSSE 2 JAXA

22 Examples of Service View JAXA

23 Service Management JAXA

24 JAXA View: Basic Cross Support Services Cross Support Service Type Basic Cross Support Service Forward Delivery Services Forward Bitstream Delivery Service Forward CLTU Delivery Service Forward Packet Delivery Service Forward File Delivery Service Return Delivery Services Return Bitstream Delivery Service Return Frame Delivery Service Return Packet Delivery Service Return File Delivery Service Cross Support Service Type Basic Cross Support Service Tracking Services Radio Metric Data Service Delta-DOR Service Orbit Determination Service Time Service Spacecraft Time Correlation Service Voice and Video Services Voice Service Video Service Note: 1.IP service is not viewed necessary for the IOAG cross support purposes other than that for communications in close proximity. 2.The method of “bit stream encapsulation” of the IP over HDLC frame over AOS frame, as suggested by NASA, is not recommended for IOAG cross support purpose. JAXA

25 An Example of Physical View JAXA

26 An Example of Communications View JAXA

27 An Example of Enterprise View JAXA

28 Procedure for Cross Support Service Agreement 1.Each member Agency must specify (1) policies and conditions for providing cross support services, (2) documents used for agreement on cross support services and establishment of cross support interfaces, and (3) pricing information. This information should be documented in a Service Catalogue. 2.If the supported Agency can meet the policies and conditions specified by the supporting Agency, the supported Agency submits necessary documents to request services to the supporting Agency. 3.Both Agencies jointly generate documents specified by the supporting Agency, which must be completed and signed off by the dates agreed upon by both Agencies. (A template for service agreement documents is given on the next pages.) 4.Both Agencies must agree on the types of tests necessary for verifying the cross support interfaces and conduct the tests according to the schedule agreed upon by both Agencies. JAXA

29 Template for Service Agreement Document Number : mmmm SERVICE AGREEMENT BETWEEN AGENCY_X AND AGENC_Y FOR PROJECT_Z Date: YYYY-MM-DD Version: n.m Supporting Agency Point of Contact: Name: FirstName SurName Supported Agency Point of Contact: Name: FirstName SurName JAXA

30 Next Steps Cross Support Service Architecture June 2007JAXA distributed the draft document. July-August 2007 IOAG members review the document and provide agency specific attribute tables. September 2007 JAXA distributes the final document. Cross Support Service Catalogues October- December 2007 Using the CSSA document, IOAG members generate service catalogues that describe services they can provide. JAXA

Space Communications and Navigation Office NASA’s Concept: “International Space Communications and Navigation Network Service Architecture” IOAG-11 June19, 2007 Cebreros, Spain NASA Consolidated Network Services Team Space Communications and Navigation Office NASA Headquarters NASA

32 Background : NASA’s Space Communications Architecture Working Group (SCAWG) Fresh look at NASA’s overall space communications and navigation infrastructure Created the “NASA Space Communications and Navigation Architecture - Recommendations for ”: NASA

33 NASA Space Communications Architecture: where next? What concept unites all of these views into a cohesive, consolidated “network of networks”? NASA

34 Mission User Mission User Space Communication and Navigation Services NASA’s Concept: provide “any-to-any” services … NASA

35 Mission User Mission User International Space Communications and Navigation Service Infrastructure … via an International Service Infrastructure … NASA

36 30 October 2015 International Space Communications and Navigation Service Infrastructure Space Mission User Space Mission User Space Mission User Space Mission User … offering standard service interfaces Source: Mario Merri/Mike Kearney Standard Services Standard Services Standard Services Standard Services Standard Services NASA

37 There are multiple phases involved with providing space communications and navigation services Mission User DiscoverCapabilities NegotiateSupport ProvideServices Mission Formulation Phase Mission Design Phase Mission Operations Phase NASA

38 Options Provide Select ServiceProvider Mission User User/provider negotiations involve the selection and refinement of service options NASA

39 Mission User DiscoverCapabilities NegotiateSupport ProvideServices Mission Formulation Mission Design Mission Operations Service Catalog Provide Select Service Capability Provider Mission User Service Agreements Provide Select Service Package Provider Mission User Configuration Profiles Provide Select Service Provider Mission User Activities across all Phases should follow a principle of successive refinement NASA

40 Mission User Service Provider Mission Formulation Phase: d iscover available services; certify and register authorized users SM I/F Service Management Interface Service Discovery Functions Service Discovery Activities Mission Formulation Manager SM I/F Service Catalog Mission “M” user browses the service catalog to determine which available network providers may potentially be available to support. User decides to explore potential support arrangements example: Mission “M” user requests authority to enter exploratory support discussions. Users x, y and z are validated and authorized to negotiate during formulation phase example: (Background administrative negotiation) NASA

41 Mission User Service Provider Service Negotiation Activities Config Profile DB Service Negotiation Functions Config Profile DB Service Agreement DB Service Agreement DB Mission Formulation Manager Network Engineering Network Integration Manager Mission Design Phase: negotiate service agreement; create configuration profiles SM I/F SM I/F Service Catalog Service Management Interface (Background administrative negotiation) “Service Agreement: per Service Package M23, SN will support Mission “M” with one S-band forward link at 8kbps or 16 kbps; one S-band return link with data rate in the 10 kbps – 2 Mbps range; and one-way or two-way Doppler tracking” example: “Service Package M23, Configuration Profile C : provide Mission “M” with S-band forward link at 8kbps, S-band return link with data rate = 1 Mbps, and one-way Doppler tracking service” example: NASA

42 Mission User Service Provider Service Providing Resources Service Users Provider Scheduling and Execution Functions Network scheduling SM I/F SM I/F Mission scheduling Mission planning Equipment configuration, control, monitoring Config Profile DB Service Agreement DB Config Profile DB Service Agreement DB Service Utilization Interface Mission Planning, Scheduling and Execution Functions Mission Operations Phase: Provide Services “Provide a contiguous Telemetry, Telecommand and Raw Radiometric data acquisition pass for Mission “M”, per Service Package M23 and using configuration profile C with Station “S67”, between 15:00 and 15:45 Z on ” 1. Raw Radiometric service 2. Forward CLTU telecommand service 3. Return All Frames telemetry service FDF example: Service Management Interface Mission Planning Manager Mission User Station S67 NASA

43 NASA’s Proposed Approach Consolidate NASA’s three current mission support networks around the organizing principle of a service-based architecture, that builds upon significant current international investment in “SLE” Coordinate the development of that service-based architecture with other IOAG agencies to ensure future interoperability - NASA proposes that its networks should be a component of an international space communications and navigation service infrastructure Evolve this international infrastructure by progressively exposing increasingly richer suites of services for cross support - Participating Agencies will agree to implement a common, evolving catalog of agreed Cross Support Transfer Services - Supported by common, evolving Cross Support Service Management systems Expand the scope of the international infrastructure to embrace new capabilities as needs emerge - Support of the Mission Design and Mission Formulation phases Provision of new network capabilities, e.g., - Lunar and Mars relays - Space internetworking NASA

44 NASA’s Initial Scope Primary Initial Scope Initially focus on expanding NASA’s service infrastructure based on what we have today – Earth-based networks Basic communications and tracking services Consolidation of services in the Mission Operations Phase NASA

45 Current state of the art for standard capabilities DiscoverCapabilities NegotiateSupport ProvideServices Mission Formulation Phase Mission Design Phase Mission Operations Phase Mission User Full specification of basic “SLE” data transfer services Full specification of basic “SLE” data transfer services Growing deployment community Growing deployment community Service Management nearing initial Standard Service Management nearing initial Standard Prototypes under test Prototypes under test Generalization and expansion into “Cross Support Transfer Services”, including Radiometric and Monitoring Generalization and expansion into “Cross Support Transfer Services”, including Radiometric and Monitoring Service Management defines Configuration Profiles to specify fixed or alternative mission parameters Service Management defines Configuration Profiles to specify fixed or alternative mission parameters Service Management defines some content of Service Agreements Service Management defines some content of Service Agreements But no process for negotiating that content But no process for negotiating that content No uniform way to: No uniform way to: obtain knowledge of network capabilities obtain knowledge of network capabilities describe network services. describe network services. negotiate or document mission support negotiate or document mission support Key:ExistsEmerging Does not exist NASA

46 DiscoverCapabilities NegotiateSupport ProvideServices Mission Formulation Phase Mission Design Phase Mission Operations Phase Mission User Cross Support Transfer Services (CSTS) and Cross Support Service Management (CSSM) standards complete – Cross Support Transfer Services (CSTS) and Cross Support Service Management (CSSM) standards complete – Ready for widespread deployment and operational use across international networks Ready for widespread deployment and operational use across international networks Expansion to Lunar and Mars Relays and internetworked operations Expansion to Lunar and Mars Relays and internetworked operations Fully standardized process defined for negotiating network support via Service Agreements Fully standardized process defined for negotiating network support via Service Agreements XML-based Service Agreements and Configuration Profiles defined and ready for operational use XML-based Service Agreements and Configuration Profiles defined and ready for operational use Expansion to Lunar and Mars Relays and internetworked operations Expansion to Lunar and Mars Relays and internetworked operations Fully standardized process defined for initial negotiation of network support Fully standardized process defined for initial negotiation of network support Internationally agreed Cross support Service Catalog defined and ready for operational use, providing access to uniformly-described service offerings of Agency networks Internationally agreed Cross support Service Catalog defined and ready for operational use, providing access to uniformly-described service offerings of Agency networks Expansion to Lunar and Mars Relays and internetworked operations Expansion to Lunar and Mars Relays and internetworked operations Goal for standard capabilities Key:ExistsEmerging Does not exist NASA

47 Service Provider Service Provision Mission User Service Users First Step - Mission Operations Phase: initial Earth-Based “Service Set” Mission User Service Utilization Interface SU I/F SU I/F SM I/F SM I/F Service Management Interface Service Production Positioning & Timing Services Radiometric Services Return Data Delivery Services Forward Data Delivery Services NASA

48 Initial Service Set: Earth-Based Return and Forward Forward data delivery services: Forward File (CFDP) Forward Space Packet Internetworking Forward CLTU (TC Frame, AOS Frame,octet-stream) Forward Bitstream Return data delivery services: Return File (CFDP) Return Space Packet Internetworking Return All Frames; Return Channel Frames Return Unframed Telemetry Return Bitstream Radiometric services: Raw radio metric data Validated radio metric Delta-DOR Position &Timing services: Position Determination Time Determination (Clock Correlation, Time distribution) NASA

49 Initial Service Set - service data unit view: Earth-Based Return and Forward Physical Space Packet Link Network CLTU Application File Internetworking Packet Transport FORWARD Space Packet All Frames Channel Frames Link Internetworking Packet Network Transport File Application Unframed Telemetry RETURN Raw Radiometric Bit-stream Delta-DOR Physical Validated Radiometric Service Provision Service Production Radiometric NASA

50 Physical Space Packet Link Network CLTU Application File Internetworking Packet Transport FORWARD Space Packet All Frames Channel Frames Link Internetworking Packet Network Transport File Application Unframed Telemetry RETURN Raw Radiometric Bit-stream Delta-DOR Physical Validated Radiometric Position Time Pos & Time Service Provision Service Production Radiometric Initial Service Set - service data unit view: Earth-Based Return and Forward NASA

51 DSN SN GN Current capability Planned Upgrade Proposed addition No planned service Deprecated Local standard Current Standard Service Set mapping to NASA Networks: Earth-Based Return and Forward Forward data delivery services: Forward File (CFDP) Forward Space Packet Internetworking Forward CLTU (TC Frame, octet stream) Forward Bitstream* Return data delivery services: Return File (CFDP) Return Space Packet Internetworking Return All Frames; Return Channel Frames Return Unframed Telemetry Return Bitstream* Radiometric services: Raw radio metric data Validated radio metric Delta-DOR Positioning &Timing services: Position Determination Time Determination (Clock Correlation, Time distribution) Source: Mike Kearney * Deprecated DSN services; provided only to legacy missions ** “GN” has been renamed “NEN” L L L LLL L LLL L L L LLL LLL ** NASA

52 Anticipated Service Set mapping to NASA Networks: Earth-Based Return and Forward Forward data delivery services: Forward File (CFDP) Forward Space Packet Internetworking Forward CLTU (TC Frame, AOS Frame, octet-stream) Forward Bitstream* Return data delivery services: Return File (CFDP) Return Space Packet Internetworking Return All Frames; Return Channel Frames Return Unframed Telemetry Return Bitstream* Radiometric services: Raw radio metric data Validated radio metric Delta-DOR Positioning &Timing services: Position Determination Time Determination (Clock Correlation, Time distribution) Source: Mike Kearney DSN SN GN L L L L LL Current capability Planned Upgrade Proposed addition No planned service Deprecated Local standard L ** * Deprecated DSN services; provided only to legacy missions ** “GN” has been renamed “NEN” NASA

53 NASA recommends that: IOAG/CCSDS should jointly focus on accelerated development of the Cross Support Service Architecture, with a view towards creating three new CCSDS Recommendations: CCSDS Recommended Practice: Cross Support Service Architecture CCSDS Recommended Standard: Cross Support Service Catalogs CCSDS Recommended Standard: Cross Support Service Agreements IOAG/CCSDS should continue to push towards rapid completion of the current SLE Service Management Blue Book, and towards accelerated development of the generic Cross Support Transfer Services and Cross Support Service Management standards CCSDS should be asked to issue a communiqué to IOAG, detailing progress made on the Cross Support Service Architecture, and related standards, at the completion of the CCSDS Fall 2007 technical meeting IOAG should consider forming a working committee to: Explore how to create and maintain the international IOAG Cross Support Service Catalog: - Provide a guide to services exposed for inter-agency use within CCSDS-compliant agencies - Indicate to CCSDS-compliant agencies where infrastructure development is needed Coordinate the international prototyping and interoperability testing of specific services and their associated service management capabilities Proposed Next Steps NASA

54 ESA Service Architecture ESA

IOAG-11: Draft Resolutions affecting CCSDS IOAG-11 June20, 2007 Cebreros, Spain

56 (Res 8.5.1)REQUEST FOR A FRAMEWORK FOR CROSS- SUPPORT SERVICE ARCHITECTURE (Res 8.5.1)REQUEST FOR A FRAMEWORK FOR A CROSS-SUPPORT SERVICES CATALOG New Resolution IOAG IOAG resolves to retire Resolution and agrees to provide future guidance to CCSDS with respect to the desired Cross Support Service Architecture and Cross Support Service Catalog. IOAG thanks JAXA for assuming leadership of this work and resolves to ask JAXA to work with CCSDS to continue to develop the architecture. IOAG also resolves to create and maintain an agreed inter-Agency cross support catalog. Actions: 1.Update the Cross Support Service Architecture to reflect presentations made by ESA and NASA at IOAG-11 and circulate to the IOAG and CCSDS for review and comment. Assigned to: JAXA (Yamada). Due date: Issue-1 by 01 December Create a baseline IOAG service catalog, indicating the “core” services that all Agencies agree to cross support and a phasing plan that indicates when cross support new services will be added by Agencies in the future, and obtain IOAG and CCSDS review and comment. ESA (Hell). Due date: Issue-1 by 14 September IOAG-11 DRAFT RESOLUTIONS

57 ( Res 8.1.1)URGENT NEED FOR A SLE MANAGEMENT SERVICES RECOMMENDATION (Res 8.4.1) ADVICE ON CROSS-SUPPORT TRANSFER SERVICES WORKING GROUP CHARTER New Resolution IOAG IOAG resolves to retire Resolutions and and notes its satisfaction with current CCSDS progress in developing standards for Cross Support Service Management and Cross Support Transfer Services. IOAG further resolves to ask CCSDS to report progress with a view towards finalizing a CCSDS Recommended Standard (“Blue Book”) for Service Management by the end of CY2008 Action: Provide IOAG with interim status reports relative to the IOAG goal of a Service Management Blue Book by the end of CY2008. Assigned to: CCSDS Liaison (Hooke). Due dates: October 2007; May 2008; October IOAG-11 DRAFT RESOLUTIONS

58 (Res 8.3.1) ADVICE FOR SIMPLIFICATION OF RF & MOD. RECOMMENDATIONS New Resolution IOAG IOAG resolves to retire Resolution and notes its satisfaction with current CCSDS progress in simplification of CCSDS (401) recommendations A and B. IOAG further resolves to ask CCSDS to report progress with a view towards finalizing CCSDS 401 (2.4.17A/B) as Recommended Standards (“Blue Books”) by the Spring of CY2008 Action: Provide IOAG with interim status reports relative to IOAG goal of finalizing the simplification of CCSDS RF & Modulation Recommendations CCSDS A/B by the Spring of CY2008. Assigned to: CCSDS Liaison (Hooke). Due dates: October 2007; May IOAG-11 DRAFT RESOLUTIONS

59 (Res 8.7.1) REQUEST FOR A HIGH RATE COMMANDING RECOMMENDATION New Resolution IOAG IOAG resolves that no requirements for future high rate uplinks are currently foreseen and therefore resolves to withdraw Resolution Action: notify CCSDS of IOAG decision to withdraw Resolution Assigned to: CCSDS Liaison (Hooke). Due dates: June IOAG-11 DRAFT RESOLUTIONS

60 (Res 8.8.1) REQUEST FOR A DELTA DOR RECOMMENDATION New Resolution IOAG IOAG notes its satisfaction with current CCSDS progress in standardization of Delta-DOR and therefore resolves to retire Resolution IOAG further resolves to ask CCSDS to report progress on a regular basis. Action: Provide IOAG with interim status reports relative to status of Delta-DOR standardization. Assigned to: CCSDS Liaison (Peccia). Due dates: June 2007; October 2007; May IOAG-11 DRAFT RESOLUTIONS

61 (Res 8.2.1)CCSDS STRATEGIC PLAN: SUGGESTED MODIFICATIONS New Resolution IOAG IOAG notes that CCSDS intends to update its Strategic Plan and resolves to supply CCSDS with the new IOAG Cross Support Services Catalog and IOAG Standards Infusion Matrix as a contribution towards that update. IOAG further resolves to retire Resolution and asks CCSDS to report progress on the new CCSDS Strategic Plan on a regular basis. Action: 1.Provide CCSDS with the IOAG Cross Support Services Catalog and IOAG Standards Infusion Matrix. Assigned to: Hell. Due date: 01 Dec Provide IOAG with interim status reports relative to status of the CCSDS Strategic Plan update Assigned to: CCSDS Liaison (Peccia). Due dates: June 2007; October 2007; May IOAG-11 DRAFT RESOLUTIONS

62 DRAFT IOAG-11 RESOLUTION New Resolution IOAG The IOAG takes note of indications from NASA that the transmission of IP datagrams across CCSDS space links has been proposed in a mode whereby the IP datagrams are encapsulated within a private serial bitstream. This operational mode is also currently being considered as an implementation option in the "IP-over-CCSDS Links" Draft Recommended Practice (CCSDS R-2 IP). The IOAG does not endorse this option and it will not be cross- supported. Such an implementation is a private Agency matter and should not be documented by CCSDS. For future cross- support purposes, IP should be implemented using the existing CCSDS mechanisms of encapsulation or direct IP multiplexing.

63 IOAG-11 RESOLUTION New Resolution IOAG