1 / 16

Abstract Modeling of Service Package Result Components

Abstract Modeling of Service Package Result Components. 31 March – 3 April 2014 Noordwijkerhout, Netherlands John Pietras Global Science and Technology, Inc., Greenbelt, MD, USA. Purpose of This Analysis/Presentation.

sugar
Télécharger la présentation

Abstract Modeling of Service Package Result Components

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Abstract Modeling of Service Package Result Components 31 March – 3 April 2014 Noordwijkerhout, Netherlands John Pietras Global Science and Technology, Inc., Greenbelt, MD, USA

  2. Purpose of This Analysis/Presentation • To fulfill CSSMWG Action Item #2013-1031-04: “Create an abstract model of service package result components”

  3. Purpose Of the Service Package Result • Identifies the Functional Resource instances and the connections among them that comprise the Service Package Result • Implicitly identifies the SCCS services that have been scheduled • Specifies the values of the configuration parameters of those Functional Resource instances • Used to confirm settings • Used to specify exact configurations/values when the flexibilities of the Service Package Request allowed multiple possible configurations/settings • Contains the Functional Resource Name of each Functional Resource in the Service Package • Needed to identify the sources of monitored parameter values and event notifications (and the targets of future real-time control directives) • Contains the time(s) at which the services will be available • Identifies the “locations” at which the services will be available • ESLT aperture locations • Network addresses • Documents the provenance of the Service Package • Closes the loop on Service Package Requests • Useful for Service Accounting purposes • Other forms of Service Package “result”?

  4. Three Kinds of Service Package Results • SLS Service Package Result • Schedules the space link resources and real-time transfer services for moving data across those space links • Expansion of B-1 SLS Service Package Result • Retrieval Service Package • Schedules/configures the return data transfer services and associated production processes for retrieving data from an ESLT data store duringor after the SLS that generated that data • Expansion of B-1 Retrieval Service Package Result • Forward Offline Service Package • Schedules/configures the forward transfer services and associated production processes for moving data into an ESLT data store before the SLS is available • New • More kinds?

  5. Components of the SLS Service Package Result • Identification • Unique and unambiguous • In Blue-1, this was the same as the ID of the Service Package Request • Not so simple in all situations, e.g., a single Recurrent Service Package Request can spawn multiple Service Package Results • Provenance • Same Service Package ID can be associated with multiple versions of the Service Package Request, e.g., when a Service Package is replaced • B-1 Service Package Results relies on Document Exchange Protocol (DEP) sequence numbers to keep provenance straight • A more explicit and non-DEP-dependent method should be explored • Identification and provenance could be combined in an appropriately constructed naming scheme • SLS Functional Resources • Instances • Start/stop times • Groupings (e.g., scenarios) • External relationships/constraints (maybe?)

  6. SLS Service Package Functional Resource Instances (1 of 4) • Grouped by Functional Group (FG) • (Space Link) Physical Channel FRs • Sync and Channel Coding FRs • Space Data Link Protocol FRs • SLS Data Delivery Production FRs • Data Delivery Transfer Service Maps • Offline Data Delivery Production FRs • Data Sinks • Data Delivery Transfer Service FRs • FRs within a FG specialization are related by containment; FRs in different FG specializations are related by Service Access Point (SAP)/Accessor port pairs

  7. SLS Service Package Functional Resource Instances (2 of 4)

  8. SLS Service Package Functional Resource Instances (3 of 4)

  9. SLS Service Package Functional Resource Instances (4 of 4) • At least 2 versions of each FR type in an SLS Service Package • Terse • Just enough information to tell the user what all of the Functional Resource Names are • Verbose • Contains all of the configuration parameters and their initial values

  10. Start/Stop Times • In Blue-1 Service Package Result, containment determined the start/stop times of production functionality • Classes without start/stop times inherited them from their containing classes • Assumption: all start/stop times will continue to be expressed as absolute times • No need to express relative or conditional times • Some options for expression of start/stop times • Every FG instance • Unambiguous but full of opportunities for inconsistencies • Implied containment • Inheritance through SAP/Accessor ports pairs • Some sort of “wrapper” around configurations • May limit extensibility • External Start/Stop time component that references every FR under its purview

  11. Groupings • Grouping by Configuration Profile • Configuration Profiles are used to identify the requested services/functional resources in the Service Package Request, but the Service Package Result does not necessarily have to reflect the organization of those profiles • SCCS-SM B-1 uses references to Configuration Profiles to minimize content of the Service Package Result • Space Communication Service Profile • Space Link Carrier Profile • In extensible Service Package Result, every FR instance must be individually identified to provide the FR Name • No need to group FRs by the configuration profile that triggered them • Grouping by scenario • No identification of scenario inherent in FRs • Possible approaches are similar to those for grouping by start/stop times • Scenario should be optional – many providers don’t intend to use it • Grouping by ESLT/relay satellite • Inherent in the identification of the specific aperture(s) that are used • Other kinds of groupings?

  12. External Relationships/Constraints • Coupling the Service Package to external events or entities • E.g., Service Packages across multiple Provider CSSSes for 3-way tracking, D-DOR services • Could imply some communication among Provide CSSSes • Would it apply to a whole Service Package or just a subset? • If the whole SP, then it could be handled as identification and/or provenance

  13. Components of the Retrieval Service Package Result • Identification • Provenance (?) • No current use for this in the Retrieval Service Package • Retrieval Functional Resources • Instances • Start/stop times • Groupings • External relationships/constraints (?) • Assumption: return DTN services across the terrestrial WAN will require no scheduling in the User CSSS – Provider CSSS Service Package sense • There may be some coordination with the SSP ISP, but that’s a different Information Entity

  14. Retrieval Functional Resources • In Blue-1, a Retrieval Service Package consists of one retrieval transfer service instance and a reference to one antenna • Equates antenna with data store • Next version needs to be more flexibly defined • Multiple transfer service instances per Retrieval Service Package • Allows access to groups of users for the period of the service package – supportive of a common playback mode of operation • Scheduling of CS File Transfer service files? • More flexible way of identifying the data stores that the Service Package accesses, e.g.: • Named data store at a ground terminal • Named data store for the whole Provider CSSS • Data store used by a specified SLS Service Package • Use case analysis should be done • External coupling • Need to be able to share complete-mode CSTSes with SLS Service Packages • Current plan is to do this with TS maps, but something else may be required • Is there any need to monitor a Retrieval Service Package?

  15. Forward Offline Service Package Result • No precedent in Blue-1 • So far, only identified possible use is for Forward File service • Is it even needed for that? Hard to say since the service hasn’t been defined yet • No other transfer service-based forward services in Service Catalog 1 or 2 • Assumption: forward DTN services across the terrestrial WAN will require no scheduling in the User CSSS – Provider CSSS Service Package sense • There may be some coordination with the SSP ISP, but that’s a different Information Entity • Is there any need to monitor a Forward Offline Service Package?

  16. Concluding Thoughts Inspired (at the Last Minute) by the Previous Material • Requiring Provision Management to supply the Functional Resource Names in the Service Package Result is a potential burden to users • Motivation for requiring PM to do so was the possibility of the same configuration profile being used repeatedly in the same Service Package • E.g., when the Provider CSSS satisfies a request for a single space link by splitting it up across multiple handovers in the same Service Package Result • Allowing multiple Service Package Results to be provided in response to a single Service Package Request could possibly eliminate this possible redundant use of configuration profile FR instances • Multiple results for a single request is already on the table for recurrent requests • Extended identification and provenance information would support traceability back to the source request • Propose to investigate this simplification over the next 6 months

More Related