- Title
- FMN Spiral 5 Standards Profile
Subprofiles
Status
- FMN Spiral 5 Standards Profile
- Business Support Standards Profiles
- Geospatial Standards Profiles
- Information Management Standards Profiles
- Communication and Collaboration Standards Profiles
- Informal Messaging Standards Profiles
- Calendaring and Scheduling Standards Profiles
- Text-based Collaboration Standards Profiles
- Video-based Collaboration Standards Profiles
- Audio-based Collaboration Standards Profiles
- Media-based Collaboration Standards Profiles
- COI-Enabling Standards Profiles
- COI-Specific Standards Profiles
- Command and Control Standards Profiles
- Intelligence and ISR Standards Profiles
- CIS Support Standards Profiles
- SMC Process Implementation Profile
- SMC Process Implementation Profile for Enabling Processes
- SMC Process Implementation Profile for Change Management
- SMC Process Implementation Profile for Service Catalogue Management
- SMC Process Implementation Profile for Incident Management
- SMC Process Implementation Profile for Request Fulfilment
- SMC Process Implementation Profile for Event Management
- SMC Process Implementation Profile for Problem Management
- SMC Process Implementation Profile for Service Asset and Configuration Management
- SMC Process Implementation Profile for Service Level Management
- SMC Process Implementation Profile for Access Management
- SMC Process Implementation Profile for Service Request Catalogue Management
- SMC API Design and Conformance Profile
- SMC Process Implementation Profile
- Federated Fires profiles
- Communications Access Standards Profiles
- Inter-Autonomous Systems Multicast Signaling Profile
- Inter-Autonomous Systems Routing Profile
- Traffic Flow Confidentiality Protection Profile
- Inter-Autonomous Systems Multicast Source Discovery Profile
- IPv4 Generic Routing Encapsulation Profile
- NMCD Information Exchange Service Profile
- IPv6 Generic Routing Encapsulation Profile
- Communications Transport Standards Profiles
- Infrastructure Standards Profiles
- Platform Standards Profiles
- Database Platform Standards Profiles
- Web Platform Standards Profiles
- Metadata Labelling Profile
- Web Authentication Profile
- Structured Data Profile
- Web Content Profile
- Web Feeds Profile
- Web Platform Profile
- Web Service Messaging Profile
- OAuth 2.0 Authorization Server Bootstrap Profile
- SAML 2.0 Bootstrap Profile
- Security Token Services Profile
- OAuth 2.0 Assertion Grant Profile
- SAML 2.0 Assertion Profile
- JSON Web Token Assertion Profile
- OAuth 2.0 Access Token Profile
- Secure REST-based Request Response Profile
- SOAP-Based Request Response Profile
- REST-Based Request Response Profile
- Direct Notification Publish Subscribe Profile
- Brokered Notification Publish Subscribe Profile
- Secure SOAP-based Request Response Profile
- Communications Transmission Standards Profiles
- Business Support Standards Profiles
FMN Spiral 5 Standards Profile
Business Support Standards Profiles
Geospatial Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Geospatial Data Exchange Profile The Geospatial Data Exchange Profile provides standards and guidance in support of Geospatial Web Services to produce and exchange geospatial data between different participants using standardized exchange formats. These datasets will be loaded into specialized geospatial information systems (GIS) and published via standardized Geospatial Web Services. |
||
Geospatial Services, Technical Services, Text-based Communication Services |
Mandatory Exchange of Digital Raster Data
Mandatory Exchange of Digital Vector Data
Mandatory This ESRI Technical Paper describes XML schemas for the Geodatabase in order to enable exchange of digital geospatial data. In contrary to the ESRI Arc Geodatabase (File-based), this document is freely available to the public and does not require vendor-specific licenses. Mandatory Exchange of Digital Elevation Data |
Vector data has to be accompanied with a clear description (UML model or text file) of the data schema and fields which are to be based on AGeoP-11. |
Geospatial Web Feeds Profile The Geospatial Web Feeds Profile provides standards and guidance for in support of Geospatial Web Services to deliver geospatial content to web sites and to user agents, including the encoding of location as part of web feeds. |
||
Web Hosting Services |
Mandatory GeoRSS Simple encoding for "georss:point", "georss:line", "georss:polygon", "georss:box". Mandatory GML subset for point "gml:Point", line "gml:LineString", polygon "gml:Polygon", and box "gml:Envelope". In Atom feeds, location shall be specified using Atom 1.0's official extension mechanism in combination with the GeoRSS GML Profile 1.0 whereby a "georss:where" element is added as a child of the <entry> element. |
Geography Markup Language (GML) allows to specify a coordinate reference system (CRS) other than WGS84 decimal degrees (lat/long). If there is a need to express geography in a CRS other than WGS84, it is recommended to specify the geographic object multiple times, one in WGS84 and the others in your other desired CRSs. |
Web Feature Service Profile The Web Feature Service Profile provides standards and guidance for in support of Geospatial Web Services to provide a standardized interface for geodata provision in a defined format over a network connection. |
||
Geospatial Web Feature Services |
Mandatory |
The OGC® Web Feature Service 2.0 Interface Standard – With Corrigendum is the normative reference (document) that specifies how Web Feature Services shall be implemented. Note that the version number of this document is 2.0.2Further implementation guidance can be found in DGIWG 122, Defence Profile of OGC’s Web Feature Service 2.0 v.2.0.1, 28 November 2017.For testing compliancy of WFS service requests several options exist
|
Web Map Service Profile The Web Map Service Profile provides standards and guidance in support of Geospatial Web Services to provide a standardized interface for geodata provision in a defined format over a network connection. |
||
Geospatial Web Map Services |
Mandatory |
Technical solution is based on the OGC WMS specification, further profiled in the harmonized 'FMN Spiral 5 Service Interface Profile for WMS and WMTS'. |
Web Map Tile Service Profile The Web Map Tile Service Profile provides standards and guidance in support of Geospatial Web Services to provide a standardized protocol for serving pre-rendered georeferenced map tiles over the Internet. |
||
Geospatial Web Map Tile Services |
Mandatory |
Technical solution is based on the OGC WMTS specification, further profiled in the harmonized 'FMN Spiral 5 Service Interface Profile for WMS and WMTS'. |
GeoPackage Profile GeoPackage is an open standard developed and maintained by the Open Geospatial Consortium (OGC). It provides for a single container to hold all geospatial data types (vector, raster, and elevation) and is able to support not only the physical transfer of geospatial data but also to directly publish the data as services. It is light-weight enough that it can be employed in mobile devices requiring geospatial data content and is able to support geospatial data exchange in a Degraded/Denied, Disrupted, Intermittent, and Limited (bandwidth) (DDIL) environment. OGC GeoPackage is supported by a wide variety of commercial and open source software applications. |
||
Geospatial Services |
Mandatory |
Technical solution is based on the OGC GeoPackage specification, further profiled in DGIWG-126 specification.Annex A of the DGIWG GeoPackage Profile provides test suite for conformance to both the mandatory OGC GeoPackage standard elements as well as all mandatory and optional profilings and extensions defined in the DGIWG Profile. |
Geospatial Metadata Profile The Geospatial Metadata Profile identifies metadata for geospatial datasets, series, services, tiles, documents, products and non-geographic datasets. |
||
Geospatial Services |
Mandatory |
Information Management Standards Profiles
Formal Messaging Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Formatted Messages for Maritime Profile The Formatted Messages Profile for Maritime provides the standard for formatted messages that are typically used in Maritime operations in support of Maritime Situational Awareness (MSA), tasking and reporting. These formatted messages may be used as payload/attachment in combination with various transport mechanisms such as informal messaging (email), text collaboration (chat) or simply with ACP-127 headers. |
||
C3 Taxonomy |
Mandatory NATO Message Text Formats—Purpose and Method of Use NATO message text consists of standardized messages that are both man- and machine-readable. The formats of these messages are laid out in the NATO Message Catalogue (APP-11) and are generally referred to as MTF messages.Purpose -- MTF messages may be used:To convey operational instructions or intentions.To pass operational information to tactical commanders at sea.To pass operational information between component commanders and subordinate units.To report operational information between commanders and from subordinate to higher formations.To notify organizations of impending and actual operations of units engaged in maritime warfare.Method of Use -- MTF messages are to be used as shown in Table 2-15. Detailed instructions of the structures and method of completion are contained in APP-11. Some of these messages have not yet been incorporated into FORMETS and their structures are found in Chapter 6 of APP-11. Relevant Allied publications are to be consulted for direction on content to be included.Ships and aircraft joining a force are to be in receipt of all relevant messages pertaining to the operation in sufficient time before joining a force, to allow the commander and operational staff to make sufficient plans and provisions that they can join the force without further orders. |
Affiliates will take implementation guidance of Maritime related MTFs from Table B-15, Chapter 2 of MTP-01(H)(1). |
Formatted Messages for Air Profile The Formatted Messages Profile for Air provides the standard for formatted messages that are typically used in Air operations in support of the air processesAir TaskingandAirspace Control. These formatted messages may be used as payload/attachment in combination with various transport mechanisms. |
||
C3 Taxonomy |
Mandatory NATO message text consists of standardized messages that are both man- and machine-readable, constructed in accordance with ADatP-3 and maintained in a catalogue. In this case legacy versions of these Message Text Formats (MTFs) from Baseline 11, specified in APP-4/8/9 are still used by Affiliates as is the case for the ATO and ACO during the Spiral 5 Preferred phase. PurposeMTF messages may be used: To convey operational instructions or intentions.To pass operational information to tactical commanders.To pass operational information between component commanders and subordinate units.To report operational information between commanders and from subordinate to higher formations.To notify organizations of impending and actual operations of units engaged in multiple forms of warfare. Method of UseDetailed instructions of the structures and method of completion for the messages from ADatP-3 Baseline 11 are contained in APP-4/8/9 . Commanders should be cognizant of the relevant Allied publications to be consulted for direction on content to be included. |
To support the procedures of Air Tasking and Execution the following version of messages should be implemented
|
Communication and Collaboration Standards Profiles
Informal Messaging Standards Profiles
Calendaring and Scheduling Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Calendaring Exchange Profile The Calendaring Exchange Profile provides standards and guidance for the exchange meeting requests, free/busy information as well as calendar sharing implemented by common user access (CUA) software. The focus of this profile is on the exchange of the aforementioned information items and does not cover other typical features found in collaboration software. |
||
Calendaring and Scheduling Services, Informal Messaging Services, Web Hosting Services |
Mandatory |
RFC 5545 is required in order to allow a vendor independent representation and exchange of calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol.RFC 5546 defines the scheduling methods that permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling.RFC 6047 defines how calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped and transported over SMTP. Authentication, Authorization and Confidentiality with S/MIME (section 2.2 of RFC 6047) is not applicable for this profile. |
Text-based Collaboration Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Text-based Collaboration Chatroom Profile The Text-based Collaboration Managed Chatroom Profile provides standards and guidance to host moderated, password-protected and member-only chatrooms to support strongly controlled persistent near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations. In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. |
||
Text-based Communication Services |
Mandatory XMPP Services hosting the shared chatrooms must comply with the following additional extensions.
|
|
Text-based Collaboration Core Profile The Text-based Collaboration Core Profile provides standards and guidance to establish a basic near-real time text-based group collaboration capability (chat) for time critical reporting and decision making in military operations. |
||
Metadata Repository Services, Technical Services, Text-based Communication Services |
Mandatory The following standards are the base IETF protocols for interoperability of chat services.
Mandatory The following standards are required to achieve compliance for an XMPP Server and an XMPP Client dependent upon the categorisation of presenting a core or advanced instant messaging service interface.
|
|
Text-based Collaboration Data Forms Profile The Text-based Collaboration Forms Profile provides standards and guidance to use (define, discover, fetch and submit) the data forms for use by XMPP entities. |
||
Metadata Repository Services, Text-based Communication Services |
Mandatory
|
|
Text-based Collaboration Tactical Profile The Text-based Collaboration Tactical Profile provides guidance and standards to support the exchange of chat messages between mission participants at the tactical level. |
||
Text-based Communication Services |
Mandatory |
The current proposal (Sep 21) is to up-issue STANAG 4677 to include a Chat Extension message to support the exchange of Chat messages at the tactical level. |
Text-based Collaboration Publish-Subscribe Profile The Text-based Collaboration Publish-Subscribe Profile provide standards and guidance in support of Text-based Collaboration Publish-Subscribe Services. |
||
Text-based Communication Services |
Mandatory
|
|
Text-based Collaboration Information Discovery Profile The Text-based Collaboration Information Discovery Profile provides standards and guidance to support Information Discovery about XMPP entities. |
||
Text-based Communication Services |
Mandatory |
Video-based Collaboration Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Video-based Collaboration Profile The Video-based Collaboration Profile provides standards and guidance for the implementation and configuration of video teleconferencing (VTC) systems and services in a federated mission network. |
||
Audio-based Communication Services, Video-based Communication Services |
Mandatory The following standards are required for audio coding in VTC.
Conditional Use of the BFCP is conditional to that VTC conferencing services are used with the shared content like presentations and/or screen sharing, whose control needs to be shared among participants. Mandatory The following standards are required for video coding in VTC. |
It Is recommended that dynamic port ranges are constrained to a limited and agreed number. This is an activity that needs to be performed at the mission planning stage. Different vendors have different limitations on fixed ports. However, common ground can always be found.As a minimum G.722.1 is to be used. Others are exceptions and need to be agreed by the mission network's administrative authority for video calls. |
Audio-based Collaboration Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Audio-based Collaboration Profile The Audio-based Collaboration Profile provides standards and guidance for the implementation of an interoperable voice system (telephony) on federated mission networks. |
||
Audio-based Communication Services, Video-based Communication Services |
Mandatory The following standards are used for audio protocols.
|
Voice over IP (VoIP) refers to unprotected voice communication services running on unclassified IP networks e.g. conventional IP telephony. Voice over Secure IP (VoSIP) refers to non-protected voice service running on a classified IP networks. Depending on the security classification of a FMN instance, VoIP or VoSIP is mandatory.If a member choses to use network agnostic Secure Voice services in addition to VoSIP, then SCIP specifications as defined for audio-based collaboration services (end-to-end protected voice) shall be used.The voice sampling interval is 40ms. |
IP Access to Half Duplex Radio Networks for Tactical Voice The Tactical Voice Information Exchange profile provides standards in order to establish voice communications between tactical units that are connected via coalition waveforms. This profile covers the voice client interface (MELPe 2400/RTP/UDP/IP) as well as the RTP payload format for MELPe frames. |
||
C3 Taxonomy |
Mandatory This standard specifies the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder.
Mandatory This standard provides a waveform-agnostic interoperability specification for the interconnection of IP networks of one nation to half-duplex radio networks of another nation. As such, it specifies the voice client interface (MELPe 2400/RTP/UDP/IP) as well as the access to a radio device. Conditional |
From the elements that are mentioned in AComP-5634, at least the following must be applied
|
Media-based Collaboration Standards Profiles
Call Media Encoding Profile
Secure Voice Profile
Service | Standard | Implementation Guidance |
---|---|---|
SCIP PPK Profile In the context of secure communications, PPK is the Pre-Placed Key, which is a symmetric encryption key, pre-positioned in a cryptographic unit. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network. |
||
C3 Taxonomy |
Conditional When PPK is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.
|
|
SCIP X.509 Profile The X.509 standard is used in cryptography to define the format of public key certificates, which are used in many Internet protocols. One example is the use in Transport Layer Security (TLS) / Secure Sockets Layer (SSL), which is the basis for HTTPS, the secure protocol for browsing the web. Public key certificates are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. Besides the format for certificates themselves, X.509 specifies certificate revocation lists as a means to distribute information about certificates that are no longer valid, and a certification path validation algorithm, which allows for certificates to be signed by intermediate Certificate Authority (CA) certificates, which are in turn signed by other certificates, eventually reaching a trust anchor. Note: SCIP is depending on the FIPS 186-2 Digital Signature Standard. This standard is superseded by FIPS 186-4, which is the applicable standard in the Service Instructions for Digital Certificates. FIPS 186-2 is only allowed within the confinement of SCIP-based secure voice solutions on the mission network. |
||
C3 Taxonomy |
Conditional When X.509 is applied for the Secure Communications Interoperability Protocol (SCIP), the following standards need to be followed.
|
|
Secure Voice Profile The Secure Voice Profile provides standards and guidance for the facilitation of secure telephony and other protected audio-based collaboration on federated mission networks. |
||
C3 Taxonomy |
Mandatory SCIP Signaling Plan and Negotiation.
Mandatory SCIP Network Standards for operation over VoIP Real-time Transport Protocol (RTP).
Conditional SCIP Network Standards for operation over other network types.
Mandatory SCIP Secure Applications. |
AComP-5068 Secure Communications Interoperability Protocol (SCIP) Edition A Version 1provides further guidance for the implementation of SCIP specifications. |
Unified Audio and Video Profile
Service | Standard | Implementation Guidance |
---|---|---|
IPSec-based Media Infrastructure Security Profile The IPSec-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Internet Protocol Security (IPSec). |
||
Audio-based Communication Services, Video-based Communication Services |
Conditional Securing the media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.
|
|
Media Streaming Profile The Media Streaming Profile provides standards used to stream media across the mission network. |
||
Audio-based Communication Services, Video-based Communication Services |
Mandatory |
|
Priority and Pre-emption Profile The Priority and Pre-emption Profile provides standards are used to execute priority and pre-emption service with the Session Initiation protocol (SIP). |
||
Audio-based Communication Services, Video-based Communication Services |
Mandatory |
|
SRTP-based Media Infrastructure Security Profile The SRTP-based Media Infrastructure Security Profile provides security standards that are used for security of media infrastructure based on Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP). |
||
Audio-based Communication Services, Video-based Communication Services |
Conditional Securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. For this specific method, the following standard apply.
|
Note that securing the MN Media infrastructure can be done in several ways and that the selection of the appropriate method is to be done during the mission planning. |
Session Initiation and Control Profile The Session Initiation and Control Profile provides standards used for session initiation and control. |
||
Audio-based Communication Services, Video-based Communication Services |
Mandatory The following standards are used for regular Session Initiation Protocol (SIP) support..
Mandatory The following standards define the Session Initiation Protocol (SIP) and Real-time Transport Protocol (RTP) support for conferencing.
|
COI-Enabling Standards Profiles
Situational Awareness Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Ground-to-Air Information Exchange Profile The Ground-to-Air Information Exchange Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16. |
||
Mediation Services, Track Management Services, Wired Transmission Services, Wireless LOS Mobile Transmission Services |
Mandatory |
Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP). |
Ground-to-Air Situational Awareness Profile The Ground-to-Air (G2A) Situational Awareness Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks over Link 16. |
||
Mediation Services, Track Management Services |
Mandatory |
ADatP-37 Edition A Version 1Messages exchanged according to the exchange mechanisms described in ADatP-37(A) shall comply with the J-series message schema defined STANAG 5516, Tactical Data Exchange – Link 16 and STANAG 5518, Interoperability Standard for Joint Range Extension Application Protocol (JREAP).ADatP-36 Edition A Version 2Messages exchanged according to the exchange mechanisms described in ADatP-36(A)(2) shall comply with the Message Text Format (FFI MTF) schema incorporated in APP-11.IP1 is the preferred protocol for FMN Spiral 5. Where needed, the other ADatP-36(A)(2) protocols (IP2 or WSMP 1.3.2) may be used if the situation requires this. The version of WSMP to be used in FMN Spiral 5 is version 1.3.2. This version is explicitly stated as is it is recognized that ADatP-36(A)(2) does not unambiguously state a version of WSMP to be used.ADatP-36 Edition B Version 1Messages exchanged according to the exchange mechanisms described in ADatP-36(B)(1) shall comply with the Message Text Format (FFI MTF) schema incorporated in ADatP-36(B)(1) Standard Related Document (SRD)1.IP1 is the preferred protocol for FMN Spiral 5.Note that the IP1 of the ADatP-36(A)(2) and of the ADatP-36(B)(1) arenot interoperable. In case both the version need to coexist it is needed the presence of an FFT proxy service as adapter. |
Overlay Distribution Profile The Overlay Distribution Profile covers the standards for overlays and (military) symbology that identify locations on the surface of the planet. These overlays are employed when disseminating recognized domain or functional pictures and related picture elements between different communities of interest in a federated mission network environment, as well as sharing with partners operating outside of the Operational Network. |
||
Overlay Services, Recognized Picture Services, Text-based Communication Services |
Mandatory The minimum conformance level for Spiral 5 is defined as: File-based and NVG Request/Response Protocol;All symbolized content;With timing information;With operationally relevant extended data. Mandatory Refer to the latest NVG APP-6(D)(1) Bindings for Implementation Guidance. This isNVG APP-6(D)(1) Bindings v1.3at the time of publication. |
All presentation services shall render tracks, tactical graphics, and battlespace objects using the defined symbology standards. |
KML Distribution Profile The KML Distribution Profile covers the standards for exchange of KML symbols between different communities of interest in a federated mission network environment, as well as sharing with partners operating outside of the Operational Network. |
||
Recognized Picture Services |
Conditional If an Affiliate has the requirement to share (export/import) with participants, entities and organizations outside of the Mission Network, then it is to support exchange via KML. When exporting KML files that reference external resources, KML Zipped (KMZ) must be used and all relevant referenced external resources must be included in the KMZ structure as relative references. The references to these files can be found in the href attribute of several KML elements. To enable cross domain exchange and long-term preservation relative references must be used for those resources that are included in the KMZ structure. As many Earth Viewers only work with legacy PKZIP 2.x format for KMZ, .zip folders shall be created in accordance withhttps://www.pkware.com/documents/APPNOTE/APPNOTE-2.0.txt |
Operations Information Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Friendly Force Tracking Profile The Friendly Force Tracking Profile provides standards and guidance to support the exchange of Friendly Force Tracking information within a coalition network or a federation of networks. |
||
Mediation Services, Situational Awareness Services, Track Distribution Services, Track Management Services |
Mandatory
Conditional |
'''ADatP-36 Edition A Version 2Messages exchanged according to the exchange mechanisms described in ADatP-36(A)(2) shall comply with the Message Text Format (FFI MTF) schema incorporated in APP-11.IP1 is the preferred protocol for FMN Spiral 5. Where needed, the other ADatP-36(A)(2) protocols (IP2 or WSMP) may be used if the situation requires this. The version of WSMP to be used in FMN Spiral 5 is version 1.3.2. This version is explicitly stated as is it is recognized that ADatP-36(A)(2) does not unambiguously state a version of WSMP to be used.'''ADatP-36 Edition B Version 1 (conditional)Messages exchanged according to the exchange mechanisms described in ADatP-36(B)(1) shall comply with the Message Text Format (FFI MTF) schema incorporated in ADatP-36(B)(1) Standard Related Document (SRD)1.IP1 is the preferred protocol for FMN Spiral 5. |
Tactical Message Distribution Profile The Tactical Message Distribution Profile provides standards and guidance to support the exchange of selected messages between Tactical Data Link networks and IP based federation of networks. |
||
Overlay Services, Tactical Messaging Access Services |
Mandatory The JREAP Standard enables TDL data to be transmitted over digital media and networks not originally designed for tactical data exchange. JREAP consists of three different protocols: A, B and C. For implementation in FMN only JREAP-C 'Encapsulation over Internet Protocol (IP)' which enables TDL data to be transmitted over an IP network must be used. Refer to Appendix E of the standard for an overview of which messages are MANDATORY for implementation. Whenever there is a common reference clock in the JREAP network, one that is available to all nodes, it should be used. In instances when there is no reference clock available, then Round Trip Time (RTT) should be utilized. With a common time reference, all JREAP-C gateways have a simple way to synchronize and measure delays between JREAP-C nodes by looking at the time of transmission inside the incoming messages. In instances where nodes do not have a common time reference, JREAP-C offers RTT message to measure delays between gateways. These messages measure the RTT between nodes. Each node can state which time reference it will support, and which is its preferred protocol. Inherent within the standard is the ability to select either method Mandatory The "Minimum Link-16 Message Profile", as described in the FMN Spiral 5 Service Interface Profile for RAP Data, defines the minimum set of data elements that are required to be available for operational or technical reasons so that correctly formatted technical message can be generated to establish the COP in a federated environment. The implementation of the following message types of ATDLP-5.16 is MANDATORY and refers to Appendix A of the standard for the detailed requirement of receive or transmit support, also based on the role of the MNP: Precise Participant Location and Identification (PPLI) MessagesJ2.0 Indirect Interface Unit PPLIJ2.2 Air PPLIJ2.3 Surface (Maritime) PPLIJ2.4 Subsurface (Maritime) PPLIJ2.5 Land (Ground) Point PPLIJ2.6 Land (Ground) Track PPLISurveillance MessagesJ3.0 Reference PointJ3.1 Emergency PointJ3.2 Air Track messageJ3.3 Surface (Maritime) TrackJ3.4 Subsurface (Maritime) TrackJ3.5 Land (Ground) Point/TrackJ3.7 Electronic Warfare Product Information For MNPs that are contributing to Shared Situational Awareness production, the following messages should be supported to maximize the ability to share tactical data: J7 Information ManagementJ9 Weapons Coordination and ManagementJ10 Weapons Coordination and ManagementJ12 ControlJ13 Platform and System StatusJ15 Threat WarningJ17 Miscellaneous More recent editions of this standard may be implemented for operational use but ATDLP-5.16 is the minimum to guarantee Link 16 tactical message distribution. Mandatory |
JREAP is designed to support operations using Link 16 over most communication media (JRE media) including forwarding TDL data over satellite communication links, however, for implementation in FMN only JREAP-C Encapsulation over IP is to be used. It supports UDP Unicast, UDP multicast, and TCP. |
COI-Specific Standards Profiles
Command and Control Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
MIP4 Profile The Land C2 Information MIP4 Profile provides standards and guidance to support the exchange of Command and Control information within a coalition network or a federation of networks. |
||
Land Domain Services, Order of Battle Services, Situational Awareness Services |
Mandatory |
The MIP4 profile should be used primarily for the exchange of Battlespace Objects (BSOs); this profile is not intended to support high volume, high frequency updates such as Friendly Force Tracking (FFT). Nor is it intended to support the exchange of data over tactical bearers (with limited capacity and intermittent availability).The MIP interoperability specification comprises both a mandatory technical interface specification as well as implementation guidance documents, and is available on the MIP website (https //www.mip-interop.org). The minimum iteration for MIP4 implementation is MIP4.4 (and MIP4.4 is the basis for the capabilities covered in the spiral). However, as the MIP4 specification supports inter-version compatibility, later iterations of MIP4 (i.e. MIP4.4+) are expected to remain interoperable with MIP4.4.The suite of guidance documents includes the MIP Operating Procedures (MOP), which provides technical procedures for configuration/operation of MIP 4.4 interfaces in a coalition environment. |
Land Tactical C2 Information Exchange Profile The Land Tactical C2 Information Exchange Profile provides standards and guidance with regard to a core set of Command and Control information and also on how to exchange XML messages within a coalition tactical environment with mobile units. |
||
Situational Awareness Services |
Mandatory
Mandatory AEP-76 is to be used for direct C2 Data Exchange between coalition units at the Mobile Tactical Edge, where a shared interoperability network is in place built upon the loaned radio concept. The data model of AEP-76 is based on variant of MIP 3.1 XML messages extended to support APP-6(D) symbology. The following messages of the messages defined in Volume II are mandatory for federating JDSS in coalition operations: JDSSDM 1.2 Presence Message ExtensionJDSSDM 1.2 Identification Message ExtensionJDSSDM 1.2 Contact/Sighting Message ExtensionJDSSDM 1.1 Sketch MessageJDSSDM 1.1 GenInfo MessageJDSSDM 1.1 Receipt MessageJDSSDM 1.2 Overlay Message ExtensionJDSSDM 1.1 Casualty Evacuation Request Message (Request Message Body only)JDSSDM 1.2 Chatrooms Message ExtensionJDSSDM 1.2 Chat Message Extension Mandatory The JDSS Gateway shall use JDSSDM 1.2 exclusive mode configuration as defined by Business Rule BACK010. |
Developers may useAEP-76 Ed A V3 XML Schema Definitionsfor implementing JDSS. |
Maritime C2 Information Exchange Profile The Maritime C2 Information Exchange Profile provides standards and guidance to support the exchange of the Recognized Maritime Picture (RMP) information within a coalition network or a federation of networks. |
||
Recognized Maritime Picture Services |
Mandatory Conditional For conditional use, coupled with the AIS line from OTH-T GOLD Baseline 2007. |
The implementation of the following message types is mandatory
|
MIP 4/JDSSDM Mediation Profile The MIP 4/JDSSDM Mediation Profile provides standards and guidance on non-friendly observed reported Battlespace Objects information exchange between TACCIS and OPCIS. |
||
Mediation Services, Situational Awareness Services |
Mandatory
|
|
NVG/JDSSDM Mediation Profile The NVG/JDSSDM Mediation Profile provides standards and guidance on overlays exchange between TACCIS and OPCIS. |
||
Mediation Services |
Mandatory
|
|
XMPP/JDSSDM Mediation Profile The XMPP/JDSSDM Mediation Profile provides standards and guidance on text based information exchange between TACCIS and OPCIS. |
||
Mediation Services, Situational Awareness Services, Text-based Communication Services |
Mandatory |
|
ADatP-36/JDSSDM Mediation Profile The ADatP-36/JDSSDM Mediation Profile provides standards and guidance on self reporting FFT exchange between TACCIS and OPCIS. |
||
Mediation Services |
Mandatory
|
Intelligence and ISR Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
ISR Library Interface Profile The ISR Library Interface is the standard interface for querying and accessing heterogeneous product libraries maintained by various nations. |
||
Intelligence and ISR Functional Services |
Mandatory The following NATO standards provide the specification as well as business rules for interoperability of ISR libraries. Mandatory The following NATO standards are mandated for interoperability of ISR library products.
Mandatory The Basic Image Interchange Format (BIIF) is mandated for interoperability of ISR libraries.
Mandatory Implementation of JC3IEDM (STANAG 5525) in the context of the ISR Library Interface Profile is limited to the definition of unique keys that could be used to unambiguously refer to an external information object that is modelled in accordance with JC3IEDM. Note that AEDP-17 refers to the metadata attribute “JC3IEDMIdentifier” on page G-15, but to “identifierJC3IEDM” on page G-79. The correct attribute to use is “identifierJC3IEDM”. Mandatory The following international standards are mandated for interoperability of ISR libraries. |
To ensure optimization of network resources the ISR Library Interface services work best with a unicast address space.AEDP-17 defines four interfaces
|
ISR Streaming Profile The ISR streaming services architecture defined by AEDP-18 covers the ISR enterprise wide sharing and management of streaming data, i.e. data generated by sensors and which is periodically updated. The ISR Streaming Services Standard mandates support for streams of one or more of the data types: Ground Moving Target Indicator (GMTI),Motion imagery,Link 16. The supported datatype(s) of the ISR Streaming Services are required information in the Joining instructions. |
||
ISR Exploitation Services, Intelligence and ISR Functional Services |
Mandatory Mandatory Implementation mandates that one or more of the following standards be implemented:
|
The operational processes facilitated by the ISR Streaming architecture are described in detail in the Procedural Instructions for JISR and Intelligence Products which is based on AIntP-16 (IRM&CM procedures) and AIntP-14 (JISR procedures). |
Intelligence BsO Synchronization The Intelligence BsO Synchronization Interface is the standard interface for querying, accessing, and updating shared intelligence battlespace objects maintained across various nations. |
||
Intelligence Analysis Services |
Mandatory The establishment of an exchange format, a common set of data standards and a prescriptive set of business rules forms the basis of the AIntP-03 standard. |
The ability to implement the AIntP-03 standard requires both sender and recipient to have fully adopted the structures and data standards set out in AIntP-3(C). Whether this requirement subsequently influences the structure of the parties’ national intelligence databases is a matter of national policy. |
CIS Support Standards Profiles
SMC Process Implementation Profile
SMC Process Implementation Profile for Enabling Processes
Service | Standard | Implementation Guidance |
---|---|---|
SMC Process Implementation Profile for Party Management The Party Management, leveraging the TM Forum Party Management API, enables the exchange of federated Parties between Mission Network Participants. |
||
Business Support SMC Services |
Mandatory |
|
SMC Process Implementation Profile for Geographic Location Management The Geographic Location Management, leveraging the - TM Forum Geographic Address Management API, - Tm Forum Geographic Site Management API, - Tm Forum Location Management enables the exchange of federated Locations between Mission Network Participants. |
||
Business Support SMC Services |
Mandatory |
|
SMC Process Implementation Profile for Activity Management Description The Activity Management, leveraging the TM Forum Process Flow Management API, enables the exchange of federated Service Tasks between Mission Network Participants. |
||
Business Support SMC Services |
Mandatory |
Federated Fires profiles
Service | Standard | Implementation Guidance |
---|---|---|
Kinetic Indirect Fire Support Information Exchange profile The Kinetic Indirect Fire Support Information Exchange profile provides standards and guidance to plan, prepare and execute kinetic fires missions, in support of Land maneuver forces, within a coalition network or a federation of networks. |
||
C3 Taxonomy |
Mandatory |
Contact NATO ICGIF IER Panel Chair about ASCA-012 CTIDP.========Digital Fire Control Systems must be qualified to guarantee a sufficient level of interoperability. Upon necessary Information Assurance objectives, Dependability of digital fire control systems (DFCS) is the most critical objective to reach, in order to ensure a fast, constant, reliable and safe Fire Support service to maneuver units.For now and the purpose of indirect kinetic fire support, and in accordance with STANAG-2245 and STANAG-2432 (AArtyP-03), be a Full or Associated ASCA Member is the stipulated way for an Affiliate to ensure such an aim. No fees are required; the main requirement is to demonstrate an effective interoperability with DFCSs of the Community, coached by one of the Full Member.After be sponsored, nation implements ASCA-012 CTIDP, coached by its sponsoring nation, and demonstrates interoperability with at least two Full ASCA Members.
|
Communications Access Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Inter-Autonomous Systems Multicast Signaling Profile The Inter-Autonomous Systems Multicast Signaling Profile provides standards and guidance for multicast group signalling between inter-autonomous systems. |
||
C3 Taxonomy |
Mandatory Service providers with their own multicast capability shall implement Rendezvous Point (RP) and provide signalling between their network segments supporting the following IP multicast signalling standards. |
|
Inter-Autonomous Systems Routing Profile The Inter-Autonomous Systems Routing Profile provides standards and guidance for routing between inter-autonomous systems. The best current practice for the Border Gateway Protocol (BGP) based network routing operations and security is described in RFC 7454 "BGP Operations and Security". Deployment guidance with regards to the application of BGP in the Internet is described in RFC 1772 "Application of the Border Gateway Protocol in the Internet". |
||
Audio-based Communication Services, Packet Routing Services, Video-based Communication Services |
Mandatory The following standards apply for all IP interconnections.
Conditional Additionally, the following standards apply for use of communities, extended communities and 32-bit extended communities for traffic engineering purposes.
Mandatory The following standard is added to improve security of BGP peering Mandatory The following standards are added to improve BGP resilience through faster detection of network failures |
BGP sessions must be authenticated, through a TCP message authentication code (MAC) using a one-way hash function (MD5), as described in RFC 4271 A Border Gateway Protocol 4 (BGP-4). |
Traffic Flow Confidentiality Protection Profile The Traffic Flow Confidentiality Protection Profile provides standards and guidance for implementing IPSEC based protection for data traffic. |
||
Authentication Services, Communications Security Services, Transport Cryptography Services |
Mandatory These are standards to implement protection profiles needed for IPSec.
|
|
Inter-Autonomous Systems Multicast Source Discovery Profile The Inter-Autonomous Systems Multicast Source Discovery Profile provides standards and guidance for multicast group source active signalling between inter-autonomous systems. |
||
C3 Taxonomy |
Conditional Service providers with their own multicast capability shall provide signalling between their Rendezvous Point (RP) supporting the following IP multicast source discovery standards. |
|
IPv4 Generic Routing Encapsulation Profile The Routing Encapsulation Profile provides standards and guidance for generic routing encapsulation functions over network interfaces both in PCN and in Information Domain network interconnection points (NIPs), in this case based on Internet Protocol version 4 (IPv4). |
||
Packet-based Broadcast Services, Packet-based Transport Services |
Conditional Standards for GRE tunneling in IPv4 Conditional Key and sequence number extension for GRE |
|
NMCD Information Exchange Service Profile The NMCD Information Exchange uses RESTCONF-like exchange semantics to distribute Protected Core PCSOP information throughout the NMCD federation. |
||
Web Hosting Services, Web Platform Services |
Mandatory NMCD IES uses a subset of the RESTCONF protocol to exchange information between peering NMCD IESes. Mandatory NMCD IES client discovers the resource root endpoint of the RESTCONF protocol using the Web Host Metadata standard. Mandatory |
|
IPv6 Generic Routing Encapsulation Profile The Routing Encapsulation Profile provides standards and guidance for generic routing encapsulation functions over network interfaces both in PCN and in Information Domain network interconnection points (NIPs), in this case based on Internet Protocol version 6 (IPv6). |
||
Packet-based Transport Services |
ERROR Standards for GRE tunneling in IPv6 Conditional Key and sequence number extension for GRE |
Communications Transport Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
IP Quality of Service Profile The IP Quality of Service Profile provides standards and guidance to establish and control an agreed level of performance for Internet Protocol (IP) services in federated networks. |
||
Packet-based Broadcast Services, Packet-based Transport Services |
Mandatory The following normative standard shall apply for IP Quality of Service (QoS). |
|
Inter-Autonomous Systems IP Communications Security Profile The Inter-Autonomous Systems IP Communications Security Profile provides standards and guidance for communications security for transporting IP packets between federated mission network interconnections and in general over the whole Mission Network. |
||
Communications Security Services |
Conditional In missions where no NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected with technical structures by mutual agreement made during the mission planning phase. Conditional In missions where NATO information products are carried over the mission network, the MISSION SECRET (MS) communications infrastructure is protected at minimum with NAMILCOM approved Type-B crypto devices. |
|
Inter-Autonomous Systems IP Transport Profile The Inter-Autonomous Systems IP Transport Profile provides standards and guidance for Edge Transport Services between autonomous systems, using the Internet Protocol (IP) over point-to-point ethernet links on optical fibre. |
||
Frame-based Access Services, Packet-based Access Services, Transport Services |
Mandatory Section 3 - Clause 38 - 1000BASE-LX, nominal transmit wavelength 1310nm. Mandatory The use of LC-connectors is required for network interconnections inside shelters (or inside other conditioned infrastructure).
Conditional Physical connectors for harsh environments
Mandatory |
Use 1 Gb/s ethernet over single-mode optical fibre (SMF). |
Interface Auto-Configuration Profile The Interface Auto-Configuration Profile provides standards and guidance for support of the Routing Information Protocol (RIPv2 and RIPng) to expand the amount of useful information carried in RIP messages for the exploitation of auto-configurations over NIP-G and PCN-compliant interfaces, and for the inclusion of a measure of control. |
||
C3 Taxonomy |
Mandatory |
The auto-configuration is a highly recommended feature for the desired flexibility, maintainability and survivability in communications systems configuration. Nevertheless, there is always an option to follow a manual configuration process. This implies that auto-configuration in itself is not mandatory; when applied, the listed standards are mandatory. |
IPv6 Transport Services Profile Implementation guidance for the implementation of standards for transport service based on Internet Protocol version 6 (IPv6). |
||
Packet-based Access Services, Packet-based Broadcast Services, Packet-based Transport Services, Transport Services |
ERROR Standards for Internet Protocol version 6 (IPv6) and Internet Control Message Protocol for IPv6 (ICMPv6).
ERROR For automatic detection of the maximum transmission unit (MTU) between end-points. It is strongly recommended that IPv6 nodes implement Path MTU Discovery, in order to discover and take advantage of path MTUs greater than 1280 octets. ERROR Standards for Internet Protocol version 6 (IPv6) neighbor discovery over link level network. ERROR These standard are used for point-to-point interconnections between network devices. ERROR Standards for IPv6 address allocation scheme utilizing reserved address space for Unique Local IPv6 Unicast Addresses. It should be noted that actual allocation policy is not following the RFC, but co-ordinated policy. Also prefix that is used is from the non-defined area of ULA addresses. ERROR Standards for IPv6 Anycast address assignment. These standards need to be taken account when assigning IPv6 addresses on systems. ERROR Standard for understanding different options to generate IPv6 addresses. |
|
IP Access to Tactical Radio This profile described the standards for IP access to a tactical radio. It contains the IP requirements of STANAG 5634 and STANAG 4677. This includes at least the following standards: UDP, IPv4 unicast and multicast, including IP addressing standards, IGMPv3, ICMP, DSCP. |
||
IPv4 Routed Access Services, Packet-based Broadcast Services, Packet-based Transport Services |
Mandatory IP access to Half-Duplex Radio. This Profile only concerns the IP-access part of the standard. Not, the RTP/voice-part. Mandatory IP Network Access requirements for JDSS Conditional |
|
IPv4 Transport Services Profile Implementation guidance for the implementation of standards for transport service based on Internet Protocol version 4 (IPv4). |
||
Edge Services, Packet-based Access Services, Packet-based Broadcast Services, Packet-based Transport Services, Transport Services |
Mandatory Standards for Internet Protocol version 4 (IPv4). Mandatory Standards for Internet Protocol version 4 (IPv4) over Ethernet.
Mandatory For automatic detection of the maximum transmission unit (MTU) between end-points. |
|
NINE ISPEC NINE ISPEC - NETWORKING AND INFORMATION INFRASTRUCTURE (NII) INTERNET PROTOCOL (IP) NETWORK ENCRYPTOR – INTEROPERABILITY SPECIFICATION, will serve as a basis and allows manufacturers from different nations to develop and produce interoperable IPsec devices to be used in federated IP network environments such as the Federated Mission Networking (FMN). |
||
Communications Security Services |
Mandatory |
AComP-4787 Ed1 contains several sections out of which following form basis for interoperability in the context of FMN SP5
|
Infrastructure Standards Profiles
Infrastructure Security Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Certificates Exchange Profile The Certificates Exchange Profile specifies the use of public standards for exchange of digital certificates. |
||
Digital Certificate Services, Technical Services |
Mandatory The PEM format with base64-encoded data shall be used to exchange Certificates, Certificate Revocation Lists (CRLs), and Certification Requests. |
The PEM format with base64-encoded data shall be used to exchange Certificates, Certificate Revocation Lists (CRLs), and Certification Requests.Single requests shall be supported, stacked requests may be supported (caveat coordinate with the PKI Service Provider). |
Cryptographic Algorithms Profile The Cryptographic Algorithms Profile specifies the use of public standards for cryptographic algorithm interoperability to protect IT systems. |
||
Digital Certificate Services, Technical Services |
Mandatory
|
The following algorithms and parameters are to be used to support specific functions
|
Digital Certificate Profile The Digital Certificate Profile provides standards and guidance in support of a Public Key Infrastructure (PKI) on federated mission networks. |
||
Digital Certificate Services, Technical Services |
Mandatory Mandatory CRLs may be provided at multiple endpoints. The addresses of these endpoints shall be provided in digital certificates through X.509 certificate extensions such as Authority Information Access (AIA) and CRL distribution point (CDP). Each CA shall provide CRLs over HTTP. Clients must support this protocol. Mandatory The Online Certificate Status Protocol (OCSP) capability is mandatory for PKI Service providers. The addresses of OCSP endpoints shall be provided in digital certificates through X.509 certificate extensions such as Authority Information Access (AIA). Clients might support this protocol. |
The version of the encoded public key certificate shall be version 3. The version of the encoded certificate revocation list (CRL) shall be version 2.Further mandatory guidance for the issued digital certificates is provided in the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2, with the following allowed deviations
|
Transport Layer Security Fallback Profile This profile provides detailed information, guidance, and standardsto be used for the usage of Transport Layer Security version 1.2 (TLS 1.2) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers. |
||
Directory Services, Informal Messaging Services, Technical Services, Text-based Communication Services, Web Hosting Services |
Mandatory TLS extensions Mandatory extensions: Section 3 - Server Name Indication Extension Disallowed extensions: Section 7 - Truncated HMAC Mandatory Session Hash and Extended Master Secret Extension Mandatory Negotiated Finite Field Diffie-Hellman Ephemeral Parameters Required curves: secp256p1secp384p1 Mandatory Supported Elliptic Curves extension. Required extensions: Section 5.1/5.2 - Supported Point Formats Required curves: secp256r1secp384r1 Mandatory TLS 1.2 compression SHALL be disabled with the use of the "null" compression method. Mandatory TLS 1.2 base standards. Mandatory extensions: Section 7.4.1.4.1 - Signature Algorithms
Mandatory Transport Layer Security (TLS) Renegotiation Indication Extension Renegotiation shall only be initiated by the server.Implementation shall be compliant with RFC 9325. |
Certificate validation
|
Transport Layer Security Profile This profile provides detailed information, guidance, and standards to be used for the usage of Transport Layer Security version 1.3 (TLS 1.3) protocol to provide authentication, confidentiality and integrity services for protecting the communication between service providers and consumers. |
||
Directory Services, Informal Messaging Services, Technical Services, Text-based Communication Services, Web Hosting Services |
Mandatory Base standard |
Certificate validation
|
Digital Certificate Validation (OCSP) Profile The Digital Certificate Validation (OCSP) Profile provides standards and guidance in support of a digital certificate validation based on OCSP. |
||
Digital Certificate Services |
Mandatory The Online Certificate Status Protocol (OCSP) capability is mandatory for PKI Service providers. Clients might support this protocol. |
The addresses of OCSP endpoints shall be provided in digital certificates through Authority Information Access (AIA) extension.Further mandatory guidance on the implementation and usage of OCSP Signing Certificates is provided in the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2, with the following allowed deviations
|
Digital Certificate Validation (CRL) Profile The Digital Certificate Validation (CRL) Profile provides standards and guidance in support of a digital certificate validation based on CRL. |
||
Digital Certificate Services |
Candidate concat('Service profile ', $pr.title,' does not refer to any standard.') |
CRLs may be provided at multiple locations, these are to be provided in digital certificates through the cRLDistributionPoints extension. Each CA is to provide CRLs over HTTP. Clients must support this protocol.The version of the encoded certificate revocation list (CRL) shall be version 2. |
Infrastructure Networking Standards Profiles
Domain Naming Profile
Service | Standard | Implementation Guidance |
---|---|---|
Secure Domain Naming Profile The Secure Domain Naming Profile provides standards and guidance to support the hierarchical distributed name system with a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality. These extensions are combined in the Domain Name System Security Extensions (DNSSEC), a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. |
||
C3 Taxonomy |
Mandatory
|
Only the following security algorithms shall be used
|
Zone Transfer Profile The Zone Transfer Profile provides standards and guidance to support zone synchronization in the hierarchical distributed name system for authoritative name servers of federated mission network ing. |
||
C3 Taxonomy |
Mandatory
Mandatory Mandatory message digest algorithm is hmac-sha384. |
|
Anycast DNS Profile The Anycast DNS Profile provides standards and guidance for operating an Authoritative Name Service on an anycast address. |
||
Packet-based Access Services |
Mandatory DNS operation on shared unicast address Mandatory Operation of anycast services |
|
Generic Domain Naming Profile The Generic Domain Naming Profile provides base standards and guidance to support the hierarchical distributed name system for computers, services, or any resource connected to a federated mission network. |
||
C3 Taxonomy |
Mandatory Additional types and bigger payloads
Mandatory Base standards |
|
IPv6 Domain Naming Profile The IPv6 Domain Naming Profile contains additions to the base Domain Name System standards, which enable the usage of the Domain Name System in the context of the Internet Protocol, version 6. |
||
C3 Taxonomy |
ERROR DNS Extensions for IP version 6 ERROR Address Selection |
Time Synchronization Profile
Service | Standard | Implementation Guidance |
---|---|---|
Peer Time Synchronization Profile The Symmetric Peer Profile provides standards and guidance to support the symmetric synchronization of time servers on the same NTP stratum level across a network or a federation of networks. |
||
Distributed Time Services |
Mandatory Protocol modes 1 and 2 |
|
Federation Time Synchronization Profile The Client/Server Synchronization Profile provides standards and guidance to support the synchronization of clients and servers across a network or a federation of networks and the safeguard of the accurate use of timestamps. |
||
Distributed Time Services |
Mandatory Protocol modes 3 and 4 |
Stratum 1 servers must implement IPv4 so that they can be used as time servers for IPv4-based mission networks. |
Infrastructure Processing Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Virtual Appliance Interchange Profile The Virtual Appliance Interchange Profile provides standards and guidance to support the Virtualized Processing Services to exchange virtual appliances between different host platforms. |
||
Technical Services, Virtualized Processing Services |
Conditional OVF format shall be used as exchange format. Mandatory File format for virtual hard disk drives, which the service consumer has to be able to provide. |
To ensure optimization of the exchange of virtual appliances, the following guidelines should be observed.The environment should be prepared for optimal implementation of a virtual machine (VM).
|
Platform Standards Profiles
Database Platform Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Directory Data Exchange Profile The Directory Data Exchange Profile provides standards and guidance in support of a mechanism used to connect to, search, and modify Internet directories on the basis of the Lightweight Directory Access Protocol (LDAP). |
||
Directory Services |
Mandatory
|
|
Directory Data Structure Profile The Directory Data Structure Profile provides standards and guidance in support of the definition of the namespace of a federated mission network on the basis of the Lightweight Directory Access Protocol (LDAP). The Directory Data Structure Profile facilitate the need to share contact information across all participants of a federation, in order to support improved collaboration and communication, for example through the sharing of a Global Address List (GAL) for email addresses. |
||
Directory Services |
Mandatory |
The central DIT schema, for sharing GAL information, shall support the IETF standards for 'inetOrgPerson' LDAP Object Class.The Directory Data Synchronization Services shall be able to exchange inetOrgPerson object class with mandatory Common Name (cn) and Surname (sn) attributes.Based on the specific mission network's requirements, the list of exchanged attributes for a particular mission network might be extended by Service Management Authority (SMA) during the planning process. The table in section 4.3 provides mandatory and optional specific guidance of such attributes within a federation context. The attributes refer back to those attributes as defined in ACP 133 Supp-1(C). The table in section 4.4 contains standard attributes. |
Web Platform Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Metadata Labelling Profile Metadata Labelling Profile describes how to apply standard confidentiality metadata to common protocols and file formats. |
||
Direct Messaging Services, Informal Messaging Services, Metadata Repository Services, Technical Services, Text-based Communication Services, Web Hosting Services |
Mandatory The Allied Data Publication and associated binding profiles describe the syntax and mechanisms for applying Confidentiality Metadata. |
The structure of the binding is defined in ADatP-4778.The labelling values shall be based on the security policy defined for the mission. |
Web Authentication Profile The Web Authentication Profile provides standards and guidance in support of principal authentication and exchange of authenticated principal's identity attributes between Mission Network Participants. |
||
Security Token Services, Web Hosting Services |
Mandatory
|
Identity providers must support the following components of the SAML 2.0 specification
|
Structured Data Profile The Structured Data Profile provides standards and guidance for the structuring of web content on federated mission networks. |
||
Web Hosting Services |
Mandatory General formatting of information for sharing or exchange.
|
XML shall be used for data exchange to satisfy those Information Exchange Requirements (IERs) within a FMN mission network instance that are not addressed by a specific information exchange standard. XML schemas and namespaces are required for all XML documents. |
Web Content Profile The Web Content Profile provides standards and guidance for the processing, sharing and presentation of web content on federated mission networks. Web presentation services must be based on a fundamental set of basic and widely understood protocols, such as those listed below. These recommendations are intended to improve the experience of Web applications and to make information and services available to users irrespective of their device and Web browser. However, it does not mean that exactly the same information is available in an identical representation across all devices: the context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Some services and information are more suitable for and targeted at particular user contexts. While services may be most appropriately experienced in one context or another, it is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations. |
||
Web Hosting Services |
Mandatory Providing a common style sheet language for describing presentation semantics (that is, the look and formatting) of documents written in markup languages like HTML.
Mandatory Publishing information including text, multi-media, hyperlink features, scripting languages and style sheets on the network. |
To enable the use of web applications by the widest possible audience, web applications shall be device independent and shall be based on HTML5 standards and criteria for the development, delivery and consumption of web applications and dynamic websites. HTML5 contains new features for attributes and behaviors, plus a large set of associated technologies such as CSS 3 and JavaScript that allows more diverse and powerful Web sites and applications.Web applications will not require any browser plug-ins on the client side as some organizations or end user devices do not allow the use of Java Applets or proprietary extensions such as Silverlight (Microsoft), Flash (Adobe) or Quick Time (Apple). Implementers shall use open standard based solutions (HTML5 / CSS3) instead.These requirements are mandatory for all web content consumers (browsers) and are optional for web content providers. It is expected that in the future FMN Spiral Specifications they will also become mandatory for the web content providers. |
Web Feeds Profile The Web Feeds Profile provides standards and guidance for the delivery of content to feed aggregators (web sites as well as directly to user agents). |
||
Web Hosting Services |
Mandatory Web content providers must support at least one of the two standards (RSS and/or Atom).
Mandatory Receivers of web content such as news aggregators or user agents must support both the RSS and the ATOM standard. |
RSS and Atom documents should reference related OpenSearch description documents via the Atom 1.0 link element, as specified in Section 4.2.7 of RFC 4287.The rel attribute of the link element should contain the value search when referring to OpenSearch description documents. This relationship value is pending IANA registration. The reuse of the Atom link element is recommended in the context of other syndication formats that do natively support comparable functionality.The following restrictions apply
|
Web Platform Profile The Web Platform Profile provides standards and guidance to enable web technology on federated mission networks. |
||
Web Hosting Services |
Mandatory |
HTTP MAY (only) be used as the transport protocol for CRL and AIA exchange between all service providers and consumers (unsecured HTTP traffic). HTTP traffic shall use port 80 by default.HTTPS MUST be used as the transport protocol between all service providers and consumers to ensure confidentiality requirements (secured HTTP traffic). HTTPS traffic shall use port 443 by default. |
Web Service Messaging Profile The Web Service Messaging Profile (WSMP) defines a set of service profiles to exchange a wide range of XML-based messages. WSMP is extensible and may be used by any Community of Interest (COI). It is based on publicly available standards and defines a generic message exchange profile based on the Request/Response (RR) and the Publish/Subscribe (PubSub) Message Exchange Pattern (MEP). WSMP is platform independent and can be profiled for different wire protocols such as SOAP. Other protocols like REST, JMS, AMQP, and WEBSocket will be profiled later. This profile is intended for software developers to implement interoperable "WSMP services" and "WSMP clients". |
||
Mediation Services, Track Distribution Services, Track Management Services |
Mandatory |
To enable plug-and-play interoperability a pre-defined minimum set of topics referenced and shared by multiple communities of interest is recommended. This TopicNamespace is included in Annex A Information Products - Detailed Definitions to the Procedural Instructions for Situational Awareness.If needed, WSMP may be used for FFT MTF exchange as an alternative to IP1.The version of the WSMP Standard used with MIP4-IES (Version 4.3) is WSMP 1.3.2. |
OAuth 2.0 Authorization Server Bootstrap Profile OAuth 2.0 Authorization Server Bootstrap Profile provides standards and guidance on how OAuth 2.0 Clients can obtain the necessary information required to interact with an OAuth 2.0 Authorization Server. |
||
Direct Messaging Services, Security Token Services, Technical Services |
Mandatory |
The OAuth 2.0 Authorization Server Metadata is retrieved from a well-known location.Alternatively, OAuth 2.0 Clients can configure some or all of this information in an out-of-band manner.As a minimum the OAuth 2.0 Authorization Server Metadata is recommended to contain the issuer, token_endpoint, jwks_uri and grant_types_supported fields. |
SAML 2.0 Bootstrap Profile The SAML 2.0 Bootstrap profile is based on the SAML2.0 standard. |
||
Direct Messaging Services, Security Token Services, Technical Services |
Mandatory |
|
Security Token Services Profile The Security Token Services Profile supports the exchange of SAML 2.0 assertions to support federated Identity and Access Management. |
||
Direct Messaging Services, Security Token Services |
Mandatory Mandatory |
How the SAML 2.0 Token has been retrieved from the local STS to be used at the federated STS is not a federation issue.The operations that are specified here are the minimal operations that SHALL be implemented by the STS in order to support the exchange of SAML Security Tokens between federation partners. Other operations that are defined by the relevant specification MAY be implemented by the STS in accordance with those specifications.Issue -- Based on the credential provided/proven in the request, a new token is issued, possibly with new proof information.
|
OAuth 2.0 Assertion Grant Profile The OAuth 2.0 Assertion Grant Profile supports the exchange of SAML 2.0 or JWT assertions for Access Tokens to be used to access federated protected resources (i.e. REST-based web services) |
||
Direct Messaging Services, Security Token Services |
Mandatory
Mandatory |
A federated Authorization Server supports this profile by providing a Security Token Service Endpoint (HTTP collection resource identified by the request URI) for a Client to make a request to exchange a Security Token (SAML or JWT assertion) from its own domain for a new Security Token (Access Token) that can be used to support chaining web services and access to federated protected resources.How the Client receives a SAML or JWT assertion is out of scope for this profile.The SAML assertion, if used, shall be compliant with the structure specified in the SIP for Middleware.The JWT assertion, if used, shall be compliant with the structure specified in the SIP for Middleware.When complying with this profile the Client must set the fields of its assertion grant token requests as follows
|
SAML 2.0 Assertion Profile The SAML 2.0 Assertion Profile facilitates interoperability for distributing Claims, structured in SAML 2.0, between federated entities. |
||
Direct Messaging Services, Security Token Services |
Mandatory |
The list of Claims to be provided in the SAML assertions has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Middleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support SAML assertions. |
JSON Web Token Assertion Profile The JSON Web Token Assertion Profile facilitates interoperability for distributing Claims, structured as a JWT assertion, between federated entities. |
||
Direct Messaging Services, Security Token Services |
Mandatory |
The list of Claims to be provided in the JWT assertion has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Middleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that JSON Web Tokens. |
OAuth 2.0 Access Token Profile The OAuth 2.0 Access Token Profile facilitates interoperability for distributing Claims, structured as a JWT bearer Access Token, between federated entities. |
||
Direct Messaging Services, Security Token Services |
Mandatory |
The list of Claims to be provided in the JWT access token has to be defined for each federation context and may differ from federation to federation.The recommendations in the Service Interface Profile (SIP) for Midleware are intended to give directives, along with clarifications and amendments on the use of mandatory and recommended requirements to be implemented by the services that support OAuth 2.0 Access Tokens in JSON Web Token format. |
Secure REST-based Request Response Profile The Secure REST-based Request Response profile supports consistent and compliant use of the uniform interface offered by HTTP for accessing a federated protected resource (REST-based Web Service). The Client makes a protected access request to the Resource Server (authority part referred to within the request URI) presenting the Access Token in the Header of the HTTP request. If the Access Token is successfully validated the Resource Server processes the authorized request and the result is returned to the Client. |
||
Direct Messaging Services, Technical Services |
Mandatory |
The Access Token is encoded in the HTTP Authorization entity-header by the Client.The auth-scheme parameter for the HTTP Authorization entity-header is specified to indicate the type of Access TokenAs a minimum for complying with this profile, the auth-scheme parameter value for the HTTP Authorization Header is Bearer.Note If supporting the OAuth 2.0 DPoP Profile the auth-scheme parameter value is DPoP).Note If supporting the OAuth 2.0 HTTP Message Signatures Profile the auth-scheme parameter value is PoP).In the cases where a Client receives a 401 status error code, that Client SHALL request an Access Token from the Authorization Server as specified in PRF-139 OAuth 2.0 Assertion Grant Profile. |
SOAP-Based Request Response Profile The SOAP-Based Request Response Profile defines the standard interface for sending a SOAP Message from a Consumer to a Provider and returning the results. The profile covers only the call from a Consumer to the Provider using SOAP, and the response from the Provider. This details the structuring of the Message. |
||
Direct Messaging Services, Technical Services |
Mandatory |
Providers must reject unsupported versions of SOAP.Upon request, Providers are to make available to authorized Consumers a Web Service Description Language (WSDL) describing the service interface. |
REST-Based Request Response Profile The REST-Based Request Response Profile provides the implementation details for REST-based Request-Response Message Exchange Pattern (MEP). The profile covers only the call from a Consumer to the Provider using HTTP, and the response from the Provider. |
||
Direct Messaging Services, Technical Services |
Mandatory
Mandatory Mandatory Mandatory
Conditional Conditional |
When a Consumer asks a Provider for a resource, the Provider is expected to respond with the best possible representation for that resource, given the Consumer's preferences.This profile places no constraints on the type of data that can be exchanged between Consumers and Providers in the body of an HTTP Message request or response. However, it is recommended that XML or JSON be used as the MIME media type exchanged between Consumers and Providers in the body of an HTTP Message request or response.HTTP requests from the Consumers using the HTTP verbs GET, HEAD, PUT and DELETE are honoured as idempotent requests by the Provider.Create, Read, Update and Delete (CRUD) are the main operations used when dealing with information in persistent storage.While REST/HTTP has similar operations, the correspondence with CRUD is not a direct one-to-one match, specifically for the Create and Update methods, but also due to the granularity of HTTP resources.REST offers generic uniform HTTP interface methods (HTTP verbs RFC 7231 (IETF)]) that apply to the request URI entity which is the URI specified on the HTTP request.It is RECOMMENDED that RESTful web services use the prescribed HTTP verbs for Create, Read, Update and Delete (CRUD) operations as specified in below
|
Direct Notification Publish Subscribe Profile This profile provides provides standards and guidance for Publish-Subscribe components (Producer, Subscription Manager and Consumer) based on WS-BaseNotification. |
||
Direct Messaging Services, Technical Services |
Mandatory Mandatory |
|
Brokered Notification Publish Subscribe Profile The Brokered Notification Publish Subscribe Profile provides standards and guidance based on WS-BrokeredNotification. |
||
Direct Messaging Services, Message Brokering Services, Technical Services |
Mandatory Mandatory |
In a brokered environment it is possible to generate a situation, where notifications may circulate in a set of brokers. This behaviour has to be solved with organizational methods if no additional features are added to a brokered environment. |
Secure SOAP-based Request Response Profile The Request-Response Message Exchange Pattern (MEP) involves a consumer sending a request message to a provider, which receives and processes the request, ultimately returning a message in response. The Secure SOAP-based Request Response profile provides the key elements of security infrastructure required to implement uniform, consistent, interoperable and effective protection of the resources exposed by partners in a federated environment. |
||
Direct Messaging Services, Technical Services |
Mandatory
|
The recommendations provided in the Service Interface Profile (SIP) Securing SOAP-based Request-Response Web Services are intended to give directives, along with clarifications and amendments on the use of securing SOAP-based Request-Response web services. |
Communications Transmission Standards Profiles
Wireless NB BLOS Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF) Phase 1 edition 1 This profile specifies the interoperability and performance characteristics of terminal equipment that will operate over NATO or national UHF satellite systems. |
||
Wireless BLOS Mobile Narrowband Transmission Services |
Mandatory Digital Interoperability Between UHF Satellite Communications Terminals - Integrated Waveform (IWF). |
Wireless NB LOS Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
NATO Narrowband waveform for VHF/UHF Radios edition 1 The Narrowband Waveform (NBWF) provides ground–ground interoperability over air between troops/platforms of different nations at the tactical battlefield using the military VHF and UHF band (30 - 500 MHz). |
||
Wireless LOS Mobile Narrowband Transmission Services |
Mandatory NBWF - HEAD STANAG Mandatory NBWF - Physical Layer Mandatory NBWF - Link Layer Mandatory NBWF - Network Layer |
For FMN Spiral 5, NATO Narrowband Waveform Profile A shall be implemented according to Annex G of AComP 5630, i.e. one-hop voice and data wireless communication using PHY modes N1 and NR. Other PHY modes and profiles are optional. |
SATURN Waveform edition 4 A narrow-band waveform with Fast Frequency Hopping EPM Mode for UHF Radio. A/G/A use, typically used voice-only. |
||
Wireless LOS Mobile Narrowband Transmission Services |
Mandatory SATURN - a fast frequency hopping EPM mode for UHF radio. AComP-4372 EDITION A |
A/G/A use, typically used voice-only. |
Wireless WB LOS Standards Profiles
Service | Standard | Implementation Guidance |
---|---|---|
NATO HDRWF (ESSOR) Standards Profile edition 1 NATO HDRWF (ESSOR) is a wideband waveform standard originated from the EU ESSOR program and community. |
||
Wireless LOS Mobile Wideband Transmission Services |
Mandatory Technical standard of the ESSOR HDRWF waveform (OC1) |