G.9. Communication Services

411. Communications Services interconnect systems and mechanisms for the opaque transfer of selected data between or among access points, in accordance with agreed quality parameters and without change in the form or content of the data as sent and received. Internet Protocol (IP) technology is the enabler of adaptive and flexible connectivity. Its connectionless structure, with its logical connectivity, provides scalability and manageability and is also future-proof by insulating services above from the diverse transport technologies below.

412. FMN instances are using a converged IP network applying open standards and industry best practices. For Milestone 1 of the FMN architecture the interconnection between Mission Network Elements (MNE) also referred to as autonomous systems will be based on IPv4. However, the next evolution (FMN Milestone 2) will be based on IPv6 for interconnecting autonomous systems. Therefore all new equipment, services and applications must support a dual IPv4/IPv6 stack implementation.

413. The Communication Services standards of the FMN Profile have been developed based on existing STANAGs such as 5067, 4637, 4640, 4643 and 4644, existing commercial standards used in communications systems and the lessons learned from implementing and operating the Afghanistan Mission Network.

G.9.1. Edge Transport Services

414. The interconnection between Mission Network Elements is based on STANAG 5067 enhanced with a non-tactical connector and optional 1Gb/s Ethernet. STANAG 5067 provides additional implementation, security and management guidance. Depending on the classification level of the Mission Network dedicated transmission security (crypto) equipment might be used.

Table G.2. Edge Transport Services and Communications Equipment Standards
ID:Services/Purpose Standard Implementation Guidance
1.1:Edge Transport Services between autonomous systems

(IP over point-to-point Ethernet links on optical fibre)

ISO/IEC 11801: 2002-09, Information technology –Generic cabling for customer premises, Clause 9. Single-mode optical fibre OS1 wavelength 1310nm.

ITU-T G.652 (11/2009), Characteristics of a single-mode optical fibre and cable. (9/125μm)

IEC 61754-20: 2012(E), Fibre optic interconnecting devices and passive components - Fibre optic connector interfaces - Part 20: Type LC connector family. LC-duplex single-mode connector.

IEEE Std 802.3-2013, Standard for Ethernet- Section 5 - Clause 58 - 1000BASE-LX10, Nominal transmit wavelength 1310nm.

IPv4 over Ethernet (Mandatory): IETF STD 37: 1982 / IETF RFC 826: 1982, An Ethernet Address Resolution Protocol.

IPv6 over Ethernet (Optional): (M) IETF RFC 4861: 2007, Neighbor Discovery for IP version 6 (IPv6)

Use 1Gb/s Ethernet over Single-mode optical fibre (SMF).
1.2:Edge Transport Services between autonomous systems ­ (time-division multiplexing wide area network)

Mandatory: Fractional E1 (Nx64kbit/s) conformant with:

  • ITU-T G.703 (11/2001), Physical/electrical characteristics of hierarchical digital interfaces.

  • ITU-T G.704 (10/1998), Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s hierarchical levels.

  • IETF STD 51: 1994, Point-to-point Protocol (PPP).

Recommended: Full E1 (2.048 Mbit/s) conformant with

  • ITU-T G.703 (11/2001), Physical/electrical characteristics of hierarchical digital interfaces.

  • IETF RFC1994: 1996, PPP Challenge Handshake Authentication Protocol (CHAP).

IPv4:

  • (O) IETF RFC 3544: 2003, IP header compression over PPP. ()

IPv6 (Optional):

  • (M) IETF RFC 5072: 2007, IP Version 6 over PPP.

  • (M) IETF RFC 4861: 2007, Neighbor Discovery for IP version 6 (IPv6).

  • (O) IETF RFC5172: 2008, Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol. ()

This interconnection is based on STANAG 5067, Standard for interconnection of IPv4 networks at Mission Secret and Unclassified Security Levels. STANAG 5067 provides additional implementation, security and management guidance.

Combined with TRANSEC crypto or other forms of link protection, CHAP (IETF RFC 1994) is not required. Otherwise, CHAP is recommended.
2:Inter-Autonomous System (AS) routing

Mandatory: Border Gateway Protocol V4

  • IETF RFC 1997: 1996, BGP Communities Attribute.

  • IETF RFC 4271: 2006, A Border Gateway Protocol 4 (BGP-4).

  • IETF RFC 4760: 2007, Multiprotocol Extensions for BGP-4.

  • IETF RFC 5492: 2009, Capabilities Advertisement with BGP-4.

Recommended (32-bit autonomous system numbers):

  • IETF RFC 6793: 2012, BGP Support for Four-Octet Autonomous System (AS) Number Space.

  • IETF RFC 4360: 2006, BGP Extended Communities Attribute.

  • IETF RFC 5668: 2009, 4-Octet AS Specific BGP Extended Community.

Optional for IPv6:

  • IETF RFC 2545: 1999, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing.

BGP deployment guidance in IETF RFC 1772: 1995, Application of the Border Gateway Protocol in the Internet.

BGP sessions must be authenticated, through a TCP message authentication code (MAC) using a one-way hash function (MD5), as described in IETF RFC 4271.

3:Inter-Autonomous System (AS) multicast routing

IPv4 (Mandatory):

  • IETF RFC 3618: 2003, Multicast Source Discovery Protocol (MSDP).()

  • IETF RFC 3376: 2002, Internet Group Management Protocol, Version 3 (IGMPv3).

  • IETF RFC 4601, Protocol Independent Multicast version 2 (PIMv2) Sparse Mode (SM).

  • IETF RFC 4760 “Multiprotocol Extensions for BGP (MBGP)”

Optional:

  • IETF RFC 4604: 2006, Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast.

Note on IPv6: No standard solution for IPv6 multicast routing has yet been widely accepted. More research and experimentation is required in this area.

 
4:unicast routing Mandatory:

- Classless Inter Domain Routing (IETF RFC 4632)

  
5:multicast routing Mandatory:

­ IETF RFC 1112: 1989, Host Extensions for IP Multicasting.

IETF RFC 2908: 2000, The Internet Multicast Address Allocation Architecture

­ IETF RFC 3171: 2001, IANA Guidelines for IPv4 Multicast Address Assignments.

­ IETF RFC 2365: 1998, Administratively Scoped IP Multicast.

  


Table G.3. Communication IA Services Standards
ID:Services/Purpose Standard Implementation Guidance
1:Information Assurance during Transmission Conditional:

ACP 176 NATO SUPP 1 (NC)

 ACP 176 NATO SUPP 1 (NC) provides configuration settings necessary to ensure interoperability when different cryptographic devices (e.g. KIV-7/KG84/BID1650) are employed together.
2:Provide communications security over the network above the Transport Layer ­ Mandatory:

IETF RFC 5246: 2008, Transport Layer Security (TLS) Protocol Version 1.2.

  


G.9.2. Communications Access Services

415. Communications Access Services provide end-to-end connectivity of communications or computing devices. Communications Access Services can be interfaced directly to Transmission Services (e.g. in the case of personal communications systems) or to Transport Services, which in turn interact with Transmission Services for the actual physical transport. Communications Access Services correspond to customer-facing communications services. As such, they can also be referred to as Subscriber Services, or Customer-Edge (CE) Services.

416. With respect to the implementation scope of FMN Milestone 1, the following standards for Packet-based Communications Access services apply:

Table G.4. Packet-based Communications Access Services Standards
ID:Services/Purpose Standard Implementation Guidance
1:Host-to-host transport services Mandatory:

Conditional (not to be used with IP encryption): IETF RFC 3168: 2001, The Addition of Explicit Congestion Notification (ECN) to IP.

Despite IETF RFC 793 is updated by IETF RFC 3168, ECN cannot be used in the FMN in parallel to the deployment of IP encryption.
2:host-to-host datagram services Internet Protocol (Mandatory):

  • IETF RFC 791: 1981, Internet Protocol.

  • IETF RFC 792: 1981, Internet Control Message Protocol.

  • IETF RFC 919: 1994, Broadcasting Internet Datagrams.

  • IETF RFC 922: 1984, Broadcasting Internet Datagrams in the Presence of Subnets.

  • IETF RFC 950: 1985, Internet Standard Subnetting Procedure.

  • IETF RFC 1112: 1989, Host Extensions for IP Multicasting.

  • IETF RFC 1812: 1995, Requirements for IP Version 4 Routers.

  • IETF RFC 2644: 1999, Changing the Default for Directed Broadcasts in Routers.

Internet Protocol version 6 (Recommended):

  • IETF RFC 2460: 1998, Internet Protocol, Version 6 (IPv6) Specification.

  • IETF RFC 3810: 2004, Multicast Listener Discovery Version 2 (MLDv2) for IPv6.

  • IETF RFC 4291: 2006, IP Version 6 Addressing Architecture.

  • IETF RFC 4443: 2006, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.

  • IETF RFC 4861: 2007, Neighbor Discovery for IP version 6 (IPv6).

  • IETF RFC 5095: 2007, Deprecation of Type 0 Routing Headers in IPv6.

  • IETF RFC 6724: 2012, Default Address Selection for Internet Protocol Version 6 (IPv6).

IP networking. Accommodate both IPv4 and IPv6 addressing. To accommodate IP crypto tunnelling within autonomous systems and avoid packet fragmentation maximum transmission unit (MTU) and maximum segment size (MSS) settings have to be harmonised between MNEs[a].
3:Differentiated host-to-host datagram services

(IP Quality of Service)

 Mandatory:

  • IETF RFC 2474: 1998, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.

    • updated by IETF RFC 3260: 2002, New Terminology and Clarifications for DiffServ.

    • Conditional: updated by IETF RFC 3168: 2001, The Addition of Explicit Congestion Notification (ECN) to IP.

  • IETF RFC 4594: 2006, Configuration Guidelines for DiffServ Service Classes.

  • ITU-T Y.1540 (03/2011), Internet protocol data communication service – IP packet transfer and availability performance parameters.

  • ITU-T Y.1541 (12/2011), Network performance objectives for IP-based services.

  • ITU-T Y.1542 (06/2010), Framework for achieving end-to-end IP performance objectives.

  • ITU-T M.2301 (07/2002), Performance objectives and procedures for provisioning and maintenance of IP-based networks .

  • ITU-T J.241 (04/2005), Quality of service ranking and measurement methods for digital video services delivered over broadband IP networks.

Utilize Quality of Service capabilities of the network (Diffserve, no military precedence on IP)

[a] For current mission networks in support of ISAF, RSM, NRF 15 and NRF 16: MTU set to 1300 bytes, MSS set to 1260 bytes. Emerging in 2016 (e.g. NRF 17) in preparation for IPv6 it is planned to transition to MTU 1280/MSS 1240.