Title
FMN Spiral 5 Standards Profile

Reference document

Org
FMN
Pubnum
Date
2023-10-16
Version
Title
FMN Spiral 5 Specification

Subprofiles

Status

URI

History

Flag Date RFC Version
added 2023-12-01 15-023 15
UUID
e47373e7-dc3e-4b69-8899-2be8c5324f2a

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

  • both version strings 2.0.0 and 2.0.2 shall be accepted in the 'version' parameter of the corresponding WFS operations or in other parts of the web service metadata.
  • when using the version number negotiation mechanism both versions 2.0.0 and 2.0.2 may be requested, and compliance shall be tested by comparing with only the first two digits of the version number (i.e. any version string of the from 2.0.* shall be accepted).

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

  • Air Tasking Order to be implemented from ADatP-3 Baseline 11(F)(Future)-- The Air Tasking Order (ATO) is used to task offensive, defensive and support missions including surveillance and control assets in order to conduct both joint and single service air operations.
  • Airspace Control Order to be implemented from ADatP-3 Baseline 11(C)(Current)-- The Airspace Control Order (ACO) is used to provide specific detailed orders for airspace management and control from a higher command to subordinate units.

Communication and Collaboration Standards Profiles

Informal Messaging Standards Profiles

Service Standard Implementation Guidance

Content Encapsulation Profile

The Content Encapsulation Profile provides standards and guidance for content encapsulation within bodies of internet messages, following the Multipurpose Internet Mail Extensions (MIME) specification.

Informal Messaging Services,

Text-based Communication Services

Mandatory

MIME encapsulation.

Mandatory

Media and content types.

Informal Messaging Profile

The Informal Messaging Profile provides standards and guidance for settings of Simple Mail Transfer Protocol (SMTP).

Informal Messaging Services

Mandatory

These standards are mandated for interoperability of email services within the mission network.

TLS with mutual authentication is mandatory for all SMTP communications. Detailed TLS protocol requirements are specified in the 'Service Interface Profile for Transport Layer Security'.

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

  • 2.4 kbps MELPe encoded voice
  • VARC based half-duplex PTT control
  • UDP
  • RTP
  • IPv4
  • IP QoS
  • Admission Control and Service Identification functions

Media-based Collaboration Standards Profiles

Call Media Encoding Profile

Service Standard Implementation Guidance

VTC Services Audio and Video Encoding Profile

Standards profile for encoding of video teleconferencing services.

Audio-based Communication Services,

Video-based Communication Services

Mandatory

Voice Services Media Encoding Profile

Standards profile for encoding of voice services.

Audio-based Communication Services,

Video-based Communication Services

Mandatory

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

  • Enhanced Contact Report (XCTC);
  • Overlay Message (OVLY2, OVLY3);
The implementation of the following message types is mandatory for an RMP Manager, optional for Mission Network Participants
  • Area of Interest Filter (AOI);
  • FOTC Situation Report;
  • Group Track Message (GROUP);
  • Operator Note (OPNOTE);
  • PIM Track (PIMTRACK);
These messages can be used for other C2 functions.For interconnecting C2 Systems and their RMP Services, the implementation of the following transport protocol to share OTH-T GOLD messages is mandatory
  • TCP (connect, send, disconnect) - default port 2020
End-users that do not have RMP Applications MAY generate OTH-T GOLD messages manually and transmit them via eMail/SMTP.

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

  • STANAG 4559 NATO Standard ISR Library Interface,
  • Provider-consumer interface (seeISR Library Access Pattern) based on HTTP/HTTPS interface'
  • CSD-Publish services interface,
  • CSD-Query services interface.
The NATO Standard ISR Library interface is required for server-to-server interactions (i.e., federation) as well as client-to-server interactions.The HTTP/HTTPS interface is for transferring files between server and clients as well as remote file access.The Publish and Query are web service interfaces supporting only client to server interaction. Although AEDP-17 allows for the use of partially qualified attribute name for the queries (see AEDP-17 section B-3.10.3 Query validation), the use of fully qualified attribute names are recommended since some AEDP-17 implementations require such fully qualified attribute name and this will ensure an adequate mapping to the right attribute. This is particular important considering the extension required to support all information products specified within the Procedural Instructions for Intelligence and JISR.AEDP-17 Annex K provides further details on the ISR Library synchronization.Service provider must identify which interfaces/patterns they support as a part of the federation process.

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.

  • Full Members are committed to participate to all ASCA meetings and actively contribute to the Standard development;
  • Associated Members maintain their interoperability with Community DFCS and update their status and ASCA activities; this status is comparable to a simple user of the interface.

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

  • Core Specification
    • Threshold requirements considered Minimum Interoperability Requirements.
  • Gateway Extension
    • Understand that NINE devices for FMN are gateway devices.
  • Generic Discovery Client Extension
    • The initiation of the discovery process is required when a packet transmitted to a SA endpoint is marked as unreachable; this is foreseen in NINE Core as part of the “Peer NINE Reachability Detection”. The support of this feature is essential for devices since it ensures the reachability of the NINE endpoints.
  • Reachability Extension
    • NINE “Reachability” Extension defines the required mechanism to discover, maintain and advertise subnets of networks which are available at the PlainText interface (including through SAs) using routing protocols (like RIPv2 and RIPng).
  • Traffic Protection - Suite B Cryptography Core

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

  • ''' Root CA Certificates
    • Digest Algorithm SHA-256 or SHA-384 (Root CA certificates, which were signed using SHA-1 before 1 January 2016, may be used until 1 January 2025)
    • RSA modulus size (bits) 3072 or 4096
    • ECC Curve NIST P-256 or P-384
  • ''' Subordinate CA Certificates
    • Digest Algorithm SHA-256 or SHA-384
    • RSA modulus size (bits) 2048, 3072 or 4096
    • ECC Curve NIST P-256 or P-384
  • ''' Subscriber Certificates
    • Digest Algorithm SHA-256 or SHA-384
    • RSA modulus size (bits) 2048, 3072 or 4096
    • ECC Curve NIST P-256 or P-384
For further guidance on the implementation the AC/322-N(2020)0077 iTIF Certificate Profiles Version 1.2.2 shall also be considered.Even more guidance
  • A digital certificate service provider shall choose which combination of algorithm and keylength chain to build. The service portfolio may contain several parallel solutions.
  • You shall not mix key-algorithms in one CA/sub-CA chain.
  • A digital certificate service consumer shall support the full spectrum of possible combinations in algorithm and keylength.
  • During a mission instantiation, the service designer shall verify service consumer capabilities with regard to supported algorithms.

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

  • The ‘Authority Key Identifier’ (marked in iTIF as mandatory) MAY be used

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

  • Federated services that implement TLS shall perform certificate validation. Certificate validation shall include checking at least full certificate path validation, certificate validity period and certificate revocation status.
  • Federated services that implement TLS shall be able to check the revocation status of digital certificates through HTTP or OSCP endpoints.
  • If compliance and validation of Digital Certificates fail, TLS connections shall be terminated
Cipher suites
  • Implementations shall be configured to only use the following cipher suites
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Mandatory for RSA certificates)
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Optional)
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Mandatory for ECC certificates)
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Optional)
  • If no cipher suite could be negotiated, TLS connections shall be terminated.
Maximum lifetime and session termination
  • The upper limit for the lifetime of a TLS session shall not exceed 48 hours.
  • When the TLS connection is closed, ephemeral keys shall be securily deleted.
Disallowed standards and extensions
  • SSL version 2.0, version 3.0 and TLS version 1.0 or 1.1
  • The Heart Beat Extension (RFC 6520
  • Encrypt-then-MAC extension (RFC 7366)

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

  • Federated services that implement TLS shall perform certificate validation. Certificate validation shall include checking at least full certificate path validation, certificate validity period and certificate revocation status.
  • Federated services that implement TLS shall be able to check the revocation status of digital certificates through HTTP or OSCP endpoints.
  • If compliance and validation of Digital Certificates fail, TLS connections shall be terminated
Cryptographic algorithms and cipher suites
  • TLS_AES_128_GCM_SHA256 (mandatory)
  • TLS_AES_256_GCM_SHA384 (recommended)
  • TLS_CHACHA20_POLY1305_SHA256 (recommended)
  • If no cipher suite could be negotiated, TLS connections shall be terminated.
Maximum lifetime and session termination
  • The upper limit for the lifetime of a TLS session shall not exceed 48 hours.
  • When the TLS connection is closed, ephemeral keys shall be securely deleted.
Disallowed standards and extensions
  • SSL version 2.0, version 3.0 and TLS version 1.0, 1.1 or 1.2
  • The Heart Beat Extension (RFC 6520)

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

  • all applications and clients using OCSP responses should support responses signed with a certificate that has the Non-Repudiation bit set, especially in the case of signature-only certificates (where only this bit is set in KeyUsage).

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

    • RSASHA256,
    • RSASHA512,
    • ECDSAP256SHA256,
    • ECDSAP384SHA384.

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

    • Strip down the hardware as much as possible, by removing sound cards, USB controllers, CD-ROM and floppy drives, and para-virtualized devices;
    • Minimize the VMs’ HDD footprint to a minimum and use thin provisioning;
    • Unmount any removable devices before exporting to Open Virtualization Format (OVF);
    • Delete all snapshots;
    • Shutdown machine; and
    • Include a CRC Integrity Check.
    The platform should be able to support the following minimalistic set of hardware features
    • vCPU support minimal two vCPUs supported per VM
    • SCSI disk controller minimal two
    • Virtual SCSI harddisks and optical disk minimal eight
    • IDE nodes
    • Virtual IDE disks
    • Virtual IDE CD-ROMs
      • E1000 (Network Interface)
    • SVGA displays minimal one
    • Serial ports minimal one
    Note although OVF defines standard for virtual machine images, there still might be a slight differences how various vendors use it, thus some manual modifications of the OVF files might be necessary before their import.

    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

    • Profiles Web Browser SSO Profile and Single Logout Profile.
    • Bindings HTTP Redirect Binding and HTTP POST Binding.
    When making authentication requests<code><samlp AuthnRequest> </code>to Identity Providers, the requesting SP/RP must fulfill the following requirements
    • All Authentication Requests shall be signed.
    • HTTP-Redirectbinding shall be used for the transmission of Authentication Request messages.
    Authentication responses from an identity provider must fulfill the following requirements
    • HTTP-POSTbinding shall be used for the receipt of<code><samlp Response> </code>messages.
    • SAML Assertions shall contain a<code> <saml NameID> </code>element with the following format to enable Single Logout <code>urn oasis names tc SAML 2.0 nameid-format transient.</code>
    • All<code><saml Attribute></code>elements shall contain a NameFormat of<code>urn oasis names tc SAML 2.0 attrname-format uri </code>. Required attribute names are listed in the Context section.
    • <code> <ds KeyName> </code>element, specified in the XML Digital Signature Core specification [1], inside the<code> <ds KeyInfo> </code>element shall be left empty.
    • If encryption is used for SAML Response messages, the assertion element shall be encrypted as a whole. Encryption of only Attributes and/or NameID is not allowed for SAML Response messages. Thus, SAML Response messages shall contain a<code> <saml EncryptedAssertion> </code>element in case encryption is used.
    • For Single Logout request messages<code> <saml EncryptedID> </code>element shall not be used. Instead transient NameIDs shall be used to hide the user identity.
    In order to make web authentication more robust, implementations should allow five (5) minutes of clock skew in both directions when interpreting timestamps in SAML assertions.[1] XML Signature Syntax and Processing Version 2.0, W3C Working Group Note 23 July 2015,https //www.w3.org/TR/xmldsig-core2/#sec-KeyInfo

    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

    • The type attribute must contain the value application/opensearchdescription+xml.
    • The rel attribute must contain the value search.
    • The href attribute must contain a URI that resolves to an OpenSearch description document.
    • The title attribute may contain a human-readable plain text string describing the search engine.

    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.

    • Providers and Consumers SHALL use the following WS-Addressing actions to enable specific processing context to be conveyed to the recipient
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Issue
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal
    • Providers and Consumers SHALL use the following URI as a wst RequestType element
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    Renew -- A previously issued token with expiration is presented (and possibly proven) and the same token is returned with new expiration semantics.
    • Providers and Consumers SHALL use the following WS-Addressing actions to enable specific processing context to be conveyed to the recipient
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Renew
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/RenewFinal
    • Providers and Consumers SHALL use the following URI as a wst RequestType element
      • http //docs.oasis-open.org/ws-sx/ws-trust/200512/Renew

    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

      • If the Client is exchanging a SAML assertion for an Access Token the grant_type parameter value is urn ietf params oauth grant-type saml2-bearer and the assertion parameter value is the SAML assertion.
      • If the Client is exchanging a JWT assertion for an Access Token the grant_type parameter value is urn ietf params oauth grant-type JWT-bearer and the assertion parameter value is the JWT assertion.
      • The resource parameter must be used to indicate the federated service or protected resource where the resultant Access Token is intended to be used.
    The Authorization Server ensures that the assertion provided by the Client is valid and not expired.When complying with this profile the Authorization Server must set the fields of the assertion grant token response as follows
      • The access_token parameter value is the Access Token issued as part of the request.
      • The token_type parameter value is Bearer.
    Note If supporting the OAuth 2.0 DPoP Profile the token_type parameter value is DPoP. Note If supporting the OAuth 2.0 HTTP Message Signatures Profile token_type parameter value is PoP.The Access Token format may be compliant with the OAuth 2.0 Access Token Profile.

    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

    • Get Retrieves an information object identified by the request URI.
    • Put Creates a new information object identified by the request URI. (Updates an information object identified by the request URI. It is recommended that the update operation is a complete update of the information object identified by the request URI.)
    • Post Updates an information object identified by the request URI. (The request URI may create new additional information objects; update additional information objects; or perform a variety of create or updates of information objects.)
    • Patch Creates a partial update of an information object identified by the request URI. (Updates an information object identified by the request URI. It is recommended that the update operation includes a set of instructions or description of changes describing what needs to be modified in the information object identified by the request URI. The entire set of instructions are required to be applied atomically.)
    • Delete Deletes an information object identified by the request URI.
    • Head Retrieves the same HTTP header fields and HTTP status code as the GET HTTP verb without the representation of the information object identified by the request URI.
    • Options RESTful web services can use this HTTP verb to determine the list of HTTP verbs supported by the information object identified by the request URI.
    A fundamental axiom of the architecture of the World Wide Web is that URIs should be opaque to Consumers i.e. a Consumer should not need to pick apart a URI to determine what it means or what to do with it.Consumers must not be capable of gathering sensitive information about the information object or the Communications and Information System (CIS) containing the information object through aggregation techniques carried out on the URI.Where metadata about the resource needs to be conveyed, it must be done using the standard HTTP headers and the rest of the information a resource conveys is carried in the representation of the resource itself.In environments that typically have high latency and bandwidth constraints Consumers and Providers may support HTTP caching for the HTTP verbs GET, PUT and HEAD.Cached contents must be protected.Caching of sensitive information is prohibited. A Consumer shall indicate to all entities in the HTTP request/response chain that information shall not be cached by inserting the HTTP header cache-control with the additional directive of no-store. or no-cache. As such, information must not be cached when a HTTP request contains a HTTP Cache-Control Header field with the values no-store and no-cache.

    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)

    Last updated on Fri, 12 Apr 2024 12:37:50 UTC
    This page is work in progress