1 / 30

NR-KPP Training Brief

daniel_millan
Download Presentation

NR-KPP Training Brief

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. 1

    2. 2

    3. 3 Net - Centric Definition

    4. 4 Exploitation of advancing technology that moves from an application centric to a data centric paradigm – an information environment comprised of interoperable computing and communication components. Net - Centric

    5. 5 Features of Net Centricity Reach – in terms of space-time where distance is not a factor. Time is the dominant limitation in success. Richness – the total set of expertise, information, and/or capabilities that can be brought to bear, within a unit of time, to effect a decision or an action subsequent to a decision. Agility – the number of effective adaptations that can be accomplished per unit of time. Assurance – achieving expected levels of operational and systems performance within a specified context, including and adversarial force in a specified timeframe.

    6. 6 The Push and Pull of the GIG

    7. 7 Data Sharing Net-centricity requires optimized data sharing among all users and systems Concept of shared spaces is the foundation of data sharing Various technologies, services, and concepts enable optimized data sharing Shared spaces within NC environment are mechanisms that provide storage of/access to data for users within bounded network space Enterprise-shared space refers to stored data that accessible by all users within or across security domains on the GIG A shared space provides virtual or physical access to any number of data assets (e.g., catalogs, websites, registries, document storage, and databases) Any user, system, or application that posts data uses shared space

    8. 8 Community of Interest (COI) Used to describe a collaborative group of users who exchange information in support of shared missions, business processes, and objectives Support users across the enterprise by Promoting data posting, Establishing shared space and Creating catalogs in which users and applications can advertise their data assets through associated metadata Four types of COIs Contingency and Crisis Operations Expedient Functional Expedient Cross-Functional Routine - Continuing Entities Institutional Functional Institutional Cross-Functional

    9. 9 Problem: IER Scalability As new systems are added to the GIG, more one to one system interchanges (IERs) must developed and tracked. Adding new systems multiplies this problem because existing systems must develop additional interfaces (IERs) as well. Growing numbers of systems interfaces mean growing numbers of IERs and growing complexity (i.e.: IERs don’t scale). In the example depicted Using 10 systems you can see the potential for having to come up with 90 various interfaces for the systems. I will now discuss our solution to this dilemma.As new systems are added to the GIG, more one to one system interchanges (IERs) must developed and tracked. Adding new systems multiplies this problem because existing systems must develop additional interfaces (IERs) as well. Growing numbers of systems interfaces mean growing numbers of IERs and growing complexity (i.e.: IERs don’t scale). In the example depicted Using 10 systems you can see the potential for having to come up with 90 various interfaces for the systems. I will now discuss our solution to this dilemma.

    10. 10 Solution: The Net-Ready Approach The Net Ready approach focuses on a one-to-many. In this approach Net Ready systems just need to plug into the the Network. NET READINESS provides common capabilities to: Task, post, process, use, store, manage and protect information resources on demand for warriors, policy makers, and support personnel Facilitate information sharing across systems It supports: Entire DoD and Intelligence Community (IC) Conventional and Nuclear Warfighting Business units (e.g., FMMP) It provides programmatic features “Fast Track” Concept development and OSD/JS/Service/Agency Coordination Deals with transition from Common Operating Environment (COE) Systems that plug into to the Network will exchange common data through a set of common enterprise services and interfaces which allow for flexible and dynamic specification of data producers and consumers and data routing (i.e.: Scales easily) and all transparent to the users. The Network-Ready approach will encompass: Technical Standards as the “bedrock” (for basic, “bit-level” interoperability), Configuration Management of the implementation of those standards via the regulation of Key Interface Points (KIPs) (for inter-system and platform interoperability), Standard Tactics, Techniques and Procedures (TTPs) for connection and use of the network (for operational network-level interoperability) and to determine network load. And as you note the potential interfaces that systems will have to deal with is 1 – that is 1 interface to “The Network”The Net Ready approach focuses on a one-to-many. In this approach Net Ready systems just need to plug into the the Network. NET READINESS provides common capabilities to: Task, post, process, use, store, manage and protect information resources on demand for warriors, policy makers, and support personnel Facilitate information sharing across systems It supports: Entire DoD and Intelligence Community (IC) Conventional and Nuclear Warfighting Business units (e.g., FMMP) It provides programmatic features “Fast Track” Concept development and OSD/JS/Service/Agency Coordination Deals with transition from Common Operating Environment (COE) Systems that plug into to the Network will exchange common data through a set of common enterprise services and interfaces which allow for flexible and dynamic specification of data producers and consumers and data routing (i.e.: Scales easily) and all transparent to the users. The Network-Ready approach will encompass: Technical Standards as the “bedrock” (for basic, “bit-level” interoperability), Configuration Management of the implementation of those standards via the regulation of Key Interface Points (KIPs) (for inter-system and platform interoperability), Standard Tactics, Techniques and Procedures (TTPs) for connection and use of the network (for operational network-level interoperability) and to determine network load. And as you note the potential interfaces that systems will have to deal with is 1 – that is 1 interface to “The Network”

    11. 11 Global Information Grid Globally interconnected, end-to-end set of information capabilities, associated processes, and personnel for collecting, processing, storing, disseminating, and managing information on demand to warfighters, policy makers, and support personnel. Includes all owned and leased communications and computing systems and services, software (including applications), data, security services, and other associated services necessary to achieve Information Superiority.  Any system, equipment, software, or service that meets one or more of the following criteria: Transmits information to, receive information from, routes information among, or interchanges information among other equipment, software, and services Provides retention, organization, visualization, information assurance, or disposition of data, information, and/or knowledge received from or transmitted to other equipment, software, and services

    12. 12 Global Information Grid

    13. 13 GIG Enterprise Services Net Centric Private Data COI Data Enterprise Data Enabling Concepts Data Tagging Sharing Searching Retrieving Bandwidth Enhancements Fusion Capabilities

    14. 14

    15. 15 Net-Centric Data Strategy This is a pictorial representation of how the different types of users will operate under a net-centric data management approach. Consumers, producers and developers all belong to Communities of Interest (COIs) that are focused on managing specific data sources. Consumers use community and enterprise wide search capabilities and catalogs to see what data is available. Producers use community catalogs and shared space to post the data they have. Developers of systems can use community metadata registries to structure and format data for reuse and interoperability. Stovepipe systems may continue and provide value, but are now visible and accessible. The services available on the network are either enterprise services (e.g., NCES) or developed and offered at the community level. System developers are encouraged to offer services that allow users and applications to further exploit data assets. For example, a developer may offer a service that allows a user to query a relational database for specific content rather than requiring the user to understand how to develop an application that can search the database. In effect, the developer is creating an access service that “exposes” the information within the database. Community catalogs also contain service “metadata” that defines the capabilities of the service, the necessary inputs to use the service, and a description of what the service provides. Users can then assess services based on their ability to meet their information needs. This is a pictorial representation of how the different types of users will operate under a net-centric data management approach. Consumers, producers and developers all belong to Communities of Interest (COIs) that are focused on managing specific data sources. Consumers use community and enterprise wide search capabilities and catalogs to see what data is available. Producers use community catalogs and shared space to post the data they have. Developers of systems can use community metadata registries to structure and format data for reuse and interoperability. Stovepipe systems may continue and provide value, but are now visible and accessible. The services available on the network are either enterprise services (e.g., NCES) or developed and offered at the community level. System developers are encouraged to offer services that allow users and applications to further exploit data assets. For example, a developer may offer a service that allows a user to query a relational database for specific content rather than requiring the user to understand how to develop an application that can search the database. In effect, the developer is creating an access service that “exposes” the information within the database. Community catalogs also contain service “metadata” that defines the capabilities of the service, the necessary inputs to use the service, and a description of what the service provides. Users can then assess services based on their ability to meet their information needs.

    16. 16 How GES/NCES Works

    17. 17 How NCES Works (cont)

    18. 18 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management (ESM) integrated throughout the model with various activities

    19. 19 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management (ESM) integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    20. 20 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    21. 21 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    22. 22 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    23. 23 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    24. 24 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    25. 25 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    26. 26 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    27. 27 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    28. 28 “Core” Net-Centric Services Nine core services will be provided by the enterprise as common services available to all users All nine services are represented in the NCOW RM Seven can be mapped directly to activities in the model Security and Enterprise Systems Management integrated throughout the model with various activities Core Services User Assistant Service Collaboration Service Mediations Services Application Service Discovery Service Messaging Service Storage Service Security Service ESM Service

    29. 29 Breaking the Code

    30. 30 Full Spectrum Analysis

    31. 31 Net Ready Performance Parameters NR-KPP developed to assess net-ready attributes and information assurance required for both the technical exchange of information and the end-to-end operational effectiveness of that exchange Replaces the Interoperability KPP Incorporates net-centric concepts for achieving Information Technology (IT) and national Security System (NSS) interoperability and supportability Assists Program Managers, the test community, and Milestone Decision Authorities in assessing and evaluating IT and NSS interoperability Consists of measurable and testable characteristics and/or performance metrics required for the timely, accurate, and complete exchange and use of information to satisfy information needs for a given capability

    32. 32 Net Ready KPP Statement

    33. 33 NR-KPP Elements Net Centric Operations and Warfare Reference Model (NCOW RM) Target viewpoint of the GIG Supporting Integrated Architecture Products Assess information exchange and use for a given capability Minimum architecture products required: AV-1; OV-2, OV-4, OV-5, and OV-6C; SV-4, SV-5, SV-6; and TV-1 Information Assurance (IA) policies and procedures Demonstrate achievement of IA within GIG integrating and supporting evolution to net-centric ops and warfare Key Interface Profiles Approach for managing interoperability across the GIG based on configuration control of key interfaces

    34. 34 Net-Ready KPP

    35. 35 Net-Centric Operations Warfare Reference Model (NCOW RM) NCOW RM describes activities required to use, operate, and manage the net-centric enterprise information environment Describes a selected set of key standards that will be needed as the NCOW capabilities of the GIG become realized.

    36. 36 Represents the target viewpoint of the DoD GIG Objective end state is a service oriented, inter-networked, information infrastructure in which users request and receive services that enable operational capabilities across the range of: Military Ops DoD Business Operations Department wide Enterprise Management Operations

    37. 37 Reference Model Version 1.0 Content Approved Dec 03

    38. 38 Why Build a Reference Model? Provide Program Managers (the target audience) acquisition guidance on what to make contractually binding beyond the Joint Technical Arch (JTA) Provide immediate utility without time-consuming analysis of the DoD Enterprise Architecture (GIG Architecture Versions 1 and 2) Overcome difficulty of relating and applying a broad Enterprise Architecture to specific programs Provide common net-centric architectural constructs congruent with the DoDAF Establish a common language and taxonomy for NCOW concepts Demonstrate and promote the TPPU Vision Focus the GIG Arch compliance requirement Support evolution of the DoD Architecture Framework and the JTA

    39. 39 Activity Decomposition

    40. 40 Activity Decomposition of NCOW RM

    41. 41 A1 Interact With Net-Centric Services

    42. 42 A2 Perform Net-Centric User/Entity Services

    43. 43 A31 Provide Core Services

    44. 44 A31 Provide Core Services

    45. 45 A31 Provide Core Services

    46. 46 A31 Provide Core Services

    47. 47 A31 Provide Core Services

    48. 48 A32 Provide COI Services

    49. 49 NCOW RM Target Technical View (Technical Areas by Core IT Category) The Target Technical View (TTV) identifies emerging standards - protocols, frameworks, and advanced technologies - needed to support DoD’s net-centric goals. TTV addresses both near and long term emerging standards TTV supports identification of net-centric enabling technology This TTV contains a set of emerging standards and advanced technologies grouped according to core information technology categories: Information Processing Information Transfer Information Modeling, Metadata, and Information Exchange Human Computer Interface Information Security Policy-Based Services Other Information Technologies The Target Technical View (TTV) identifies emerging standards - protocols, frameworks, and advanced technologies - needed to support DoD’s net-centric goals. TTV addresses both near and long term emerging standards TTV supports identification of net-centric enabling technology This TTV contains a set of emerging standards and advanced technologies grouped according to core information technology categories: Information Processing Information Transfer Information Modeling, Metadata, and Information Exchange Human Computer Interface Information Security Policy-Based Services Other Information Technologies

    50. 50 Domains - Functions

    51. 51 NCOW RM Technical View

    52. 52 GIG Architecture Compliance Architecture products comply with Architecture Framework product definitions and purposes Architecture data conform to the CADM IT/NSS standards derived from the DoD JTA (or presents case for new or unique standards as necessary Conforms to the GIG Net-Centric Operations and Warfare Reference Model: Uses Reference Model definitions and vocabulary Incorporates Reference Model OV capabilities and services in the materiel solution Net-centric SOA Strategy Net-centric Data Strategy Net-centric Information Assurance Strategy Incorporates Reference Model TV IT/NSS standards in the TV products developed for the materiel solution

    53. 53 Integrated Architecture for Determining NR-KPP

    54. 54 Supporting Integrated Architecture Products

    55. 55 OV-2 Operational Node Connectivity

    56. 56 OV-4

    57. 57 OV-5 Operational Activity Model

    58. 58 Operational Event-Trace Description (OV-6c) – UML-type Template

    59. 59 SV-4 (first example)

    60. 60 SV-5 Operational Activity to System Function

    61. 61 SV-6 Systems Data Exchange Matrix

    62. 62 Architecture Analysis Focus on Architecture and Standards. First order analysis - identifying capability gaps, shortfalls and duplications. Second order analysis - identifies interoperability requirements. Architecture Tasks Primary focus must be on Architecture and Standards. ·        First order analysis - identifying capability gaps, shortfalls and duplications. •Once a first order of analysis identifies capability gaps and deficiencies, a decision process follows to evaluate what to do about it. •Where there are capability gaps, a new system needs to be developed to meet the requirement. •Where there are capability deficiencies, existing systems need to be improved or modified to meet the requirement. •If there are capability duplications, a follow-on question needs to be addressed to determine if the redundancy is necessary. There may be circumstances where it is strongly desired to maintain secondary and even tertiary capability. In these cases, maintain the redundant systems. However, when system redundancy is identified that is not necessary, the less capable systems should be deleted. •Finally, if the analysis identifies systems that have no required capability based on the first order analysis, they should be eliminated.   • Second order analysis, which identifies interoperability requirements. Tasks and capabilities are grouped into operational nodes. System interfaces required within nodes and between nodes are mapped out. • The second order analysis provides the data required to conduct analysis of interoperability issues. The architecture shows which system must be interoperable both within operational nodes and which system connect separate operational nodes. • If there is no system that performs a required function (capability gap), then the interoperability requirements become key design criteria in the proposed solution, • For legacy systems, the first question that should be resolved through the first order analysis is whether the system is even needed. If a system does not support a capability need in the architecture, there is no need to proceed with interoperability analysis, it should simply be cut. •That leaves the family of legacy systems that support required capabilities. These systems must be examined to see if they are interoperable with other systems linked inside it’s node and to connect between nodes, if applicable. •They key to this part of the analysis is that every system does not have to be interoperable with everything else. Only key systems need interoperability as defined in the operational node connectivity diagram and the source for these interoperability standards is in the technical architecture.   .              [g1]Architecture development and assessment should be an evolutionary process. The C4ISR framework shows a staggering list of architecture products, but it is not necessary to complete them all before meaningful analysis can begin. Architecture Tasks Primary focus must be on Architecture and Standards. ·        First order analysis - identifying capability gaps, shortfalls and duplications. •Once a first order of analysis identifies capability gaps and deficiencies, a decision process follows to evaluate what to do about it. •Where there are capability gaps, a new system needs to be developed to meet the requirement. •Where there are capability deficiencies, existing systems need to be improved or modified to meet the requirement. •If there are capability duplications, a follow-on question needs to be addressed to determine if the redundancy is necessary. There may be circumstances where it is strongly desired to maintain secondary and even tertiary capability. In these cases, maintain the redundant systems. However, when system redundancy is identified that is not necessary, the less capable systems should be deleted. •Finally, if the analysis identifies systems that have no required capability based on the first order analysis, they should be eliminated.   • Second order analysis, which identifies interoperability requirements. Tasks and capabilities are grouped into operational nodes. System interfaces required within nodes and between nodes are mapped out. • The second order analysis provides the data required to conduct analysis of interoperability issues. The architecture shows which system must be interoperable both within operational nodes and which system connect separate operational nodes. • If there is no system that performs a required function (capability gap), then the interoperability requirements become key design criteria in the proposed solution, • For legacy systems, the first question that should be resolved through the first order analysis is whether the system is even needed. If a system does not support a capability need in the architecture, there is no need to proceed with interoperability analysis, it should simply be cut. •That leaves the family of legacy systems that support required capabilities. These systems must be examined to see if they are interoperable with other systems linked inside it’s node and to connect between nodes, if applicable. •They key to this part of the analysis is that every system does not have to be interoperable with everything else. Only key systems need interoperability as defined in the operational node connectivity diagram and the source for these interoperability standards is in the technical architecture.   .              [g1]Architecture development and assessment should be an evolutionary process. The C4ISR framework shows a staggering list of architecture products, but it is not necessary to complete them all before meaningful analysis can begin.

    63. 63 Information Assurance (DITSCAP*) Availability Integrity Authentication Confidentiality Non-repudiation

    64. 64 DoD Information Technology Security Certification and Accreditation Process The DITSCAP is composed of four phases: Definition, Verification, Validation, and Post Accreditation. (See figure E3-1.) Phase 1, Definition, is focused on understanding the mission, environment, and architecture to determine the security requirements and level of effort necessary to achieve accreditation. The objective of phase 1 is to agree on the intended system mission, environment, architecture, security requirements, certification schedule, level of effort, and resources required. Phase 2, Verification, verifies the evolving or modified system's compliance with the information agreed on in the SSAA. The objective of phase 2 is to produce a fully integrated system ready for certification testing. Phase 3, Validation, validates compliance of the fully integrated system with the information stated in the SSAA. The objective of phase 3 is to produce the required evidence to support the DAA in making an informed decision to grant approval to operate the system; e.g., accreditation. Phases 1, 2, and 3 are the DITSCAP process engine. Those phases are repeated as often as necessary to produce an accredited system. Phase 4, Post Accreditation, includes those activities necessary for the continuing operation of the accredited IT system in its computing environment and to address the changing threats a system faces through its life-cycle. Phase 4 starts after the system has been certified and accredited for operations. The objectives of phase 4 are to ensure secure system management, operation, and maintenance to preserve an acceptable level of residual risk. DODI 5200.40, December 30, 97 The DITSCAP is composed of four phases: Definition, Verification, Validation, and Post Accreditation. (See figure E3-1.) Phase 1, Definition, is focused on understanding the mission, environment, and architecture to determine the security requirements and level of effort necessary to achieve accreditation. The objective of phase 1 is to agree on the intended system mission, environment, architecture, security requirements, certification schedule, level of effort, and resources required. Phase 2, Verification, verifies the evolving or modified system's compliance with the information agreed on in the SSAA. The objective of phase 2 is to produce a fully integrated system ready for certification testing. Phase 3, Validation, validates compliance of the fully integrated system with the information stated in the SSAA. The objective of phase 3 is to produce the required evidence to support the DAA in making an informed decision to grant approval to operate the system; e.g., accreditation. Phases 1, 2, and 3 are the DITSCAP process engine. Those phases are repeated as often as necessary to produce an accredited system. Phase 4, Post Accreditation, includes those activities necessary for the continuing operation of the accredited IT system in its computing environment and to address the changing threats a system faces through its life-cycle. Phase 4 starts after the system has been certified and accredited for operations. The objectives of phase 4 are to ensure secure system management, operation, and maintenance to preserve an acceptable level of residual risk. DODI 5200.40, December 30, 97

    65. 65 DITSCAP C&A – Phase 1 Document the system: mission environment, and architecture Identify the threat Define the levels of effort Identify the certification authority (CA) and the Designated Approving Authority (DAA), & document the necessary security requirements for Certification and Accreditation (C&A) Outputs - A documented agreement, between the program manager, the DAA, the CA, and the user representative of the approach and The results of the phase 1 activities

    66. 66 Management Responsibilities by DITSCAP Phase

    67. 67 Management Responsibilities by DITSCAP Phase

    68. 68 Why KIPs? The KIP concept provides organizations and system builders a relatively small number of carefully managed interfaces to converge on. This brings order, visibility, and stability to these important interfaces Frees the parties involved to innovate on either side of the interface.

    69. 69 KIP Interface Approach Interface-oriented approach is: - More manageable. Easier to supervise, maintain, understand, & enforce. Focused on seams, where issues most likely to arise. - Less reliant on one-size-fits-all solutions. Interfaces have smaller scope it is easier to gain consensus on a set of standards tight enough to ensure interoperability. - More legacy-tolerant. Does not always assume or require changes to internals of participating systems. - Less brittle (more adaptable) in face of change. System owners can change internal implementations with less fear of unintended consequences for others, so long as interfaces remain compliant. - Easier to evolve. Systems free to incorporate & adapt to new technology & requirements, so long as they remain compliant with relatively stable interface

    70. 70 The 17 Key Interfaces

    71. 71 KIP Analysis Logical Networks to DISN Transport Backbone Does your network connect to DISN Backbone? Space to Terrestrial Does your ground terminal utilize or require access to DOD SATCOM programs such as DSCS MILSTAR FLTSAT UFO MUOS Polar EHF GPS GBS INMARSAT Wideband etc? STEP and TELEPORT Does your ground terminal interface with/connect with STEP/TELEPORT systems?

    72. 72 KIP Analysis JTF to Coalition Does your program or system interface with/connect the JTF to coalition forces? JTF Component to JTF Headquarters Does your program or system interface/connect the JTF Component to the JTF Headquarters? Joint Interconnection Service Does your organization connect the NIPRNET to Internet? DISN Service Delivery Point Does your base, camp, post, station, unit or organization connect to the DISN? Secure Enclave Service Delivery Point Does your system or program interface with or connect a Secure Enclave local area network to DISN service delivery point? Client to Server Does your workstation publish, utilize or require access to data residing in DOD/NCES/GES servers? End System to PKI Do your workstation and applications utilize or interface with utilize DOD Public Key Information?

    73. 73 KIP Analysis Information Servers to IDM Infrastructure Does your information server (collaboration, discovery, mediation, security, application, messaging, etc) require access to NCES/GES Infrastructure? IDM to Distribution Infrastructure Does your network management system and communications system requires access to NCES/GES? Management Systems to Managed Systems Does your system for personal and local computing manage the local network infrastructure Routers WAPs Switches Hubs Firewalls Gateways IDS Servers, and Terminal devices Desktop computers Printers Wireless terminals?

    74. 74 KIP Analysis Management Systems to (Integrated) Managed Systems Does your management system interface with DOD GNOSC, RNOSC? Includes NIPRNET NOC, GSSC, SIPRNET NOC, DSN NOC, DRSN NOC? Applications Server to Database Server Does your web or application server require access to NCES/GES database server(s)? Applications to Shared Data Does your application require access to shared data residing in NCES/GES infrastructure? Application to COE/NCES/GES Does your application require access to COE/NCES/GES services?

    75. 75 KIPs to NCES/GES

    76. 76 Space to Terrestrial Space to Terrestrial – connects Satellites to Ground Terminals DISN Traditionally, SATCOM has consisted of geo-synchronous satellites and large ground terminals, each purpose-built for a specific satellite constellation. This approach simplifies the space segment at the expense of the ground segment. Specifically, ground terminals tend to be large, powerful, and incapable of on the move operation. Also, in the absence of on-board switching and satellite cross links, the existing architecture often forces communications along multiple SATCOM hops (introducing unacceptable latency and consuming still more SATCOM bandwidth). Increasingly, the DOD has become interested in more advanced satellites with capabilities such as: on-board switching/routing, store & forward capabilities, - satellite cross-links, smaller earth terminals, preferably capable of on the move operation; and fewer terminal variants (ideally, same multi-band terminal would communicate with multiple constellations). Although these features are certainly desirable, they increase the complexity of the interface between space and ground segments. Specifically, interface specifications will no longer be limited to physical and (possibly) link layers. Instead, future satellites will have network, transport, and possibly application layer interfaces as well. So, it is important to immediately start defining these interfaces, hopefully in a way that retains flexibility and as much simplicity as is practical in the space segment. And this KIP should be standardized across constellations. Otherwise, ground users will be forced to carry multiple terminal types. More importantly, network designers and SATCOM users will have difficulty integrating overly diverse SATCOM interfaces with the rest of their architectures. Space to Terrestrial – connects Satellites to Ground Terminals DISN Traditionally, SATCOM has consisted of geo-synchronous satellites and large ground terminals, each purpose-built for a specific satellite constellation. This approach simplifies the space segment at the expense of the ground segment. Specifically, ground terminals tend to be large, powerful, and incapable of on the move operation. Also, in the absence of on-board switching and satellite cross links, the existing architecture often forces communications along multiple SATCOM hops (introducing unacceptable latency and consuming still more SATCOM bandwidth). Increasingly, the DOD has become interested in more advanced satellites with capabilities such as: on-board switching/routing, store & forward capabilities, - satellite cross-links, smaller earth terminals, preferably capable of on the move operation; and fewer terminal variants (ideally, same multi-band terminal would communicate with multiple constellations). Although these features are certainly desirable, they increase the complexity of the interface between space and ground segments. Specifically, interface specifications will no longer be limited to physical and (possibly) link layers. Instead, future satellites will have network, transport, and possibly application layer interfaces as well. So, it is important to immediately start defining these interfaces, hopefully in a way that retains flexibility and as much simplicity as is practical in the space segment. And this KIP should be standardized across constellations. Otherwise, ground users will be forced to carry multiple terminal types. More importantly, network designers and SATCOM users will have difficulty integrating overly diverse SATCOM interfaces with the rest of their architectures.

    77. 77

    78. 78 JTF Component to JTF Headquarters JTF Component to JTF Headquarters – connects JTF Component & JTF HQ systems This is one of the more obvious Key Interface Profiles (KIPs), in that every JTF will clearly require internetworking between the JTF headquarters and each component (whether Service or functional). Less obvious is the fact that the same interface specification can probably also serve for inter-component interfaces (e.g. ARFOR to MARFOR or NAVFOR to AFFOR). By carefully designing and specifying this KIP, Service architects can converge on implementations that allow virtually any reasonable task organization. In other words, it won't matter which Service CJTF comes from, what the composition of JTF components might be, or who equips the JTF headquarters--the inter-network interfaces will be largely the same.   JTF Component to JTF Headquarters – connects JTF Component & JTF HQ systems This is one of the more obvious Key Interface Profiles (KIPs), in that every JTF will clearly require internetworking between the JTF headquarters and each component (whether Service or functional). Less obvious is the fact that the same interface specification can probably also serve for inter-component interfaces (e.g. ARFOR to MARFOR or NAVFOR to AFFOR). By carefully designing and specifying this KIP, Service architects can converge on implementations that allow virtually any reasonable task organization. In other words, it won't matter which Service CJTF comes from, what the composition of JTF components might be, or who equips the JTF headquarters--the inter-network interfaces will be largely the same.  

    79. 79 STEP/TELEPORT

    80. 80 Joint Interconnection Service

    81. 81 DISN/MAN Service Delivery Node (SDN)

    82. 82

    83. 83 End System to PKI

    84. 84

    85. 85 Management Systems to Managed System

    86. 86 Information Servers to IDM Infrastructure Information Servers to IDM Infrastructure  IDM infrastructure is tasked with managing the distribution of information from numerous information servers. It would not be logical to negotiate custom interfaces for every information server. Therefore, this KIP should be used to converge all information servers on a common way of interfacing to IDM. IDM to Distribution Infrastructure  Many communications systems will ultimately carry the information distributed by IDM. The key interface point is a vehicle for standardizing the interface between IDM and those communications systems. The most important aspect of this KIP is the interface between IDM and network management systems. This allows IDM to, for example, sense network and link states (e.g. congestion) and respond accordingly.Information Servers to IDM Infrastructure  IDM infrastructure is tasked with managing the distribution of information from numerous information servers. It would not be logical to negotiate custom interfaces for every information server. Therefore, this KIP should be used to converge all information servers on a common way of interfacing to IDM. IDM to Distribution Infrastructure  Many communications systems will ultimately carry the information distributed by IDM. The key interface point is a vehicle for standardizing the interface between IDM and those communications systems. The most important aspect of this KIP is the interface between IDM and network management systems. This allows IDM to, for example, sense network and link states (e.g. congestion) and respond accordingly.

    87. 87 IDM to Distribution Infrastructure Information Servers to IDM Infrastructure  IDM infrastructure is tasked with managing the distribution of information from numerous information servers. It would not be logical to negotiate custom interfaces for every information server. Therefore, this KIP should be used to converge all information servers on a common way of interfacing to IDM. IDM to Distribution Infrastructure  Many communications systems will ultimately carry the information distributed by IDM. The key interface point is a vehicle for standardizing the interface between IDM and those communications systems. The most important aspect of this KIP is the interface between IDM and network management systems. This allows IDM to, for example, sense network and link states (e.g. congestion) and respond accordingly.Information Servers to IDM Infrastructure  IDM infrastructure is tasked with managing the distribution of information from numerous information servers. It would not be logical to negotiate custom interfaces for every information server. Therefore, this KIP should be used to converge all information servers on a common way of interfacing to IDM. IDM to Distribution Infrastructure  Many communications systems will ultimately carry the information distributed by IDM. The key interface point is a vehicle for standardizing the interface between IDM and those communications systems. The most important aspect of this KIP is the interface between IDM and network management systems. This allows IDM to, for example, sense network and link states (e.g. congestion) and respond accordingly.

    88. 88 Application Server to Shared Data Applications to Shared Data   This Key Interface Profile (KIP) is important because it facilitates separation of mission specific applications from their underlying data. Thus, it will become easier to insulate database implementations from requirements volatility at the user end. And application developers can focus on application logic and the user interface, rather than database design and development (or data collection and distribution) when existing databases meet the application's requirements. Finally, increased standardization at this interface will make it easier to migrate application databases into the shared data infrastructure for joint use (and configuration management) when they prove broadly useful (even those for which a joint interface requirement was not initially anticipated)Applications to Shared Data   This Key Interface Profile (KIP) is important because it facilitates separation of mission specific applications from their underlying data. Thus, it will become easier to insulate database implementations from requirements volatility at the user end. And application developers can focus on application logic and the user interface, rather than database design and development (or data collection and distribution) when existing databases meet the application's requirements. Finally, increased standardization at this interface will make it easier to migrate application databases into the shared data infrastructure for joint use (and configuration management) when they prove broadly useful (even those for which a joint interface requirement was not initially anticipated)

    89. 89 Application Server to Database Server

    90. 90 Client to Server

    91. 91 Application Server to Shared Data

    92. 92 Summary By improving information exchange for all authorized users, Net Centric services will: increase efficiency enhance interoperability in joint environment provide all users with gained benefits in speed, accuracy, and networked information capabilities prevent unauthorized disclosure of information The NR-KPP assess net-ready attributes required for both the technical exchange of information and the end-to-end operational effectiveness of that exchange.

    93. 93 Contacts

More Related