160 likes | 233 Views
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.
E N D
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 • To fulfill CSSMWG Action Item #2013-1031-04: “Create an abstract model of service package result components”
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”?
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?
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?)
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
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
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
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?
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
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
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?
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?
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