Guidance

PSN network architecture

Published 27 October 2015

Overview of the PSN

The Public Services Network creates the effect of a single network across UK government, delivered through multiple service providers. The PSN network consists of the Government Conveyance Network (GCN), Direct Network Service Provider (DNSP) networks and other PSN networks.

The GCN connects the PSN together. It exists to allow customers to reach services from any service provider on any network by ensuring that the customer’s network provider only needs to connect to a single entity, the GCN, to guarantee delivery of their data to services in other networks, rather than being forced to connect to every possible network operator. This opens up the marketplace for services on government networks.

Where traffic needs to pass between different DNSPs, eg if a user is accessing a service not on their own DNSP, then it will traverse the GCN. The GCN is the only place where traffic can pass between different DNSPs, and only DNSPs may connect to the GCN.

There are some other networks on the PSN that are not DNSPs. These networks must connect to and pass traffic to a DNSP, and not to any other PSN network. Service Providers (SPs) and customers use the GCN through DNSPs, but no direct connection to the GCN will be permitted for any entity unless they become DNSPs in their own right.

PSN Protected and PSN Assured

A number of PSN providers offer a shared IPsec encrypted overlay. This is referred to as the PSN Protected network. The individual provider Encryption Domains (EDs) are connected in a fully meshed manner via the Inter-Provider Encryption Domain (IPED).

The underlying non-encrypted network outside of PSN Protected is PSN Assured. As well as carrying unencrypted traffic, PSN Assured may also carry traffic encrypted both at the network and application layers, according to customer needs.

Obligation CAS.1: mandatory for GCNSPs, DNSPs and other network services

All network services must be assured through CAS(T) - ‘CESG Assured Service (Telecoms)’ certification scheme for telecommunications services.

From January or April 2020, the National Cyber Security Centre will no longer renew CAS(T) certificates.

To deliver networking services for PSN your organisation must submit:

  • an existing CAS(T) or ISO27001 certificate
  • a scope
  • service orientated architecture (SoA) plans

You will need to continue with surveillance audits on your current CAS(T) certification if it’s due for renewal before January 2020.

After this date your CAS(T) certificate will remain valid for PSN assurance purposes until the certificate expires, providing you complete your annual return to us, including your annual ITHC. Before your CAS(T) certificate has expired you will need to work with UKAS accredited certification provider to ensure continuous assurance of your PSN services.

Obligation NNI.24: mandatory for GCNSPs, DNSPs and other network services

All service providers must apply suitable mechanisms to ensure that PSN components are adequately dimensioned to support the expected (current and forecast) levels of traffic.

GCN - conceptual architecture

The GCN is a resilient, high-availability transit architecture connecting a number of pre-agreed locations in the UK. The GCN is provided by four network service providers (BT, Level 3 Communications, Virgin Media and Vodafone) at their own risk, under the Deed of Undertakings. Although GCN customers (DNSPs) are free to choose their individual GCN provider, the GCN as a whole behaves as a single service.

Any GCN Service Provider (GCNSP) who is also a DNSP adheres to a set of fairness provisions (in the Deed of Undertakings), which dictate ethical walls between the parts of the organisation which act as the GCNSP and DNSP.

Within the GCN connectivity model, there are:

  • GCN to GCN interconnects, known as the Point of Interconnect (PoI), which GCN providers require for ‘full mesh’ connectivity to the core
  • GCN to DNSP interconnects which are needed at the Point of Connection (PoC) to enable DNSPs to connect to the GCN

A group of physical Points of Connection (PoC) from different providers is called a Virtual Point of Connection (VPoC). A VPoC is a restricted geographic environment that spans a 25 kilometers radius from the respective VPoC centre. The choice of available VPoCs provides appropriate resilience and geographical diversity for DNSPs.

This diagram shows how PSN is delivered over the GCN, to DNSPs, other PSN networks and then to customer and service end points. The PSN DiffServ region covers all of the GCN, DNSP and other network services.

An overview of the Public Services Network architecture. This diagram shows how PSN is delivered over the GCN, to DNSPs, other PSN networks and then to customer and service end points. The PSN DiffServ region covers all of the GCN, DNSP and other network services.

Obligation COM.41: mandatory for DNSPs

A DNSP network must allow traffic with any direct connection it has with any PSN customer or PSN service provider to transit across the GCN, subject to any access restrictions imposed by the PSN customer or PSN service provider.

Obligation COM.42: mandatory for GCNSPs, DNSPs and other network services

A PSN service offering network services must allow traffic with any direct connection it has with any PSN customer or PSN service provider to transit to a DNSP network, subject to any access restrictions imposed by the PSN customer or PSN service provider.

Obligation GCNSP.2: mandatory for GCNSPs

GCNSPs must facilitate GCN peering requests from any DNSP.

Obligation GCN.5: mandatory for GCNSPs

GCNSPs must provide full and resilient mesh connectivity to all other participating GCNSPs.

Obligation GCN.6: mandatory for GCNSPs

GCNSPs must provide connectivity services of sufficient capacity to meet the network performance requirements forecasted by DNSPs and GCNSPs.

Obligation GCN.8: mandatory for GCNSPs

GCNSPs must provide PoCs for DNSP peering with the GCN.

Obligation GCN.9: mandatory for GCNSPs

GCNSPs must provide a PoC at a minimum of 75% of the PSN VPoC locations. Each GCNSP must:

  • declare a list of VPoC locations at which they will provide a PoC:
  • only make changes to the declared list of VPoC locations in agreement with the PSN team
  • complete the provision of a GCN service at any of the declared VPoC locations within 120 days of receipt of an order from a DNSP, if required within this timescale by the DNSP

Obligation GCN.12: mandatory for GCNSPs

GCNSPs should have a defined policy and technology roadmap for the support of IPv6 in the event of HMG customer demand.

Traffic traversing the GCN

Obligation GCN.20: mandatory for GCNSPs

Service providers must ensure that a network connection across the PSN spanning the GCN will traverse either 1 GCNSP or 2 GCNSPs with the path being either:

  • PoC to PoC for a traverse of a single GCNSPs
  • Poc to PoI to PoC for traverse of 2 GCNSPs

Under normal circumstances a maximum of 2 GCNSPs will be involved in routing between 2 POCs. In exceptional circumstances, special arrangement may be implemented on request in conjunction with GCNSPs.

Any routes not permitted must be reported to the PSN team with details of the start and finish times. In the event of a failure of a GCN service that would cause traffic to traverse 2 PoIs, the GCNSPs that are not responsible for the failure cannot be held accountable for the potential impact. GCNSPs that were not responsible for the failure can exclude the period from their GCN performance and quality of service reports.

PSN availability

PSN customers need evidence that the minimum network availability from their customer connection point across their DNSP to services on other DNSPs is sufficient, so that they can be confident of their ability to access the business services they need.

The PSN operates as an assured network service end-to-end, with formal assurance provided by certification of network services under the CESG Assured Service – Telecoms (CAS-T) scheme. In the context of PSN, the term ‘service’ refers to a specific service type instance.

CAS(T) gives us a minimum of 99.95% availability for each individual supplier’s network on PSN (excluding customer access tail circuits). However, the PSN customer depends on several suppliers in a serial chain, so additional measures are built into PSN to maintain the CAS(T) level of availability end-to-end.

A typical end-to-end service type instance may be a combination of one or more service slices, for example a Domain Name System (DNS) service instance; whereby a stub resolver such as a desktop PC may use a connectivity ‘access slice’, ‘MPLS network slice’ and ‘DNS service slice’.

Customers and service providers agree specific availability metrics and associated Service Level Agreements (SLAs) applicable to PSN access connectivity during consultation or procurement of services. The service availability metrics agreed may be above the availability figures presented here. These figures define the ‘minimum’ acceptable availability for use in the PSN.

Obligation AVA.1: mandatory for GCNSPs and DNSPs

The PSN network - provided by a combination of any two DNSPs Provider Edge end-points and the GCN, but excluding other network service slices and customer access tail circuits - must provide a minimum availability of 99.95% measured over 1 month, and have the capability (should a customer require it) to provide an availability of 99.999%, measured over 1 month.

Obligation AVA.2: mandatory for GCNSPs

Each GCNSPsPoC must achieve a minimum service availability of 99.95% measured over 1 month.

Obligation AVA.3: mandatory for DNSPs

The DNSP as a component service slice, measured between any two DNSP Provider Edge end-points, but excluding customer access tail circuits, must provide a minimum service availability of 99.98% measured over 1 month.

Obligation AVA.4: mandatory for GCNSPs

The GCN as a whole, measured between the point of demarcation with one DNSP and the point of demarcation with any other DNSP, must be designed to meet an availability target of 99.98% measured over 1 month. To avoid planned maintenance affecting availability, this target assumes:

  • either that each DNSP connects to two PoCs from a single GCN service provider
  • or - in the case where a DNSP connects to PoCs from different GCN service providers - the DNSP is responsible for ensuring that the GCN service providers in question have coordinated their maintenance schedules such that planned PoC outages do not coincide

GCN service providers must provide reports to the PSN team showing the actual availability achieved. These reports must include an explanation for any sustained instances where the target availability is not met.

Missing the availability target is not a PSN compliance issue. The availability target exists to provide an indication to customers of what can be expected in the absence of any additional SLA.

Obligation AVA.5: mandatory for DNSPs

Each DNSP must connect to the GCN using at least two geographically separated PoCs.

PSN Network infrastructure timing

Obligation TIM.1: mandatory for GCNSPs, DNSPs and other network services

All PSN network services must synchronize network infrastructure timing from a stratum 0 clock source such as Global Positioning Systems (GPS).

Obligation TIM.2: mandatory for GCNSPs, DNSPs and other network services

Network Infrastructure timing must be disseminated to all PSN networking infrastructure using industry standard methods such as the Network Time Protocol (NTP).

Multiprotocol Label Switching (MPLS) options

Obligation NNI.30: mandatory for GCNSPs, DNSPs and other network services

All service providers must use MPLS Inter-AS option A for their PoC and PoI interconnects.

NNI facilities, equipment and security for PoC and PoI interconnects

All devices forming part of the NNI interconnect are housed at the respective service provider premises unless agreed co-location services are sought.

Obligation NNI.3: mandatory for GCNSPs and DNSPs

Service provider facilities must be physically secured with access only being granted to approved and suitably screened staff.

Obligation NNI.4: mandatory for GCNSPs and DNSPs

In all cases, GCNSPs must control the entire infrastructure to actual cable/fibre or patch-panel hand-off at the DNSP or third-party GCNSP location.

Each GCNSP should provision all cabling to the associated termination point. From this point, cabling should be provided via direct patching between peers in a point-to-point fashion. This does not require any further devices, such as switches, to be placed in-line between connections.

Obligation NNI.6: mandatory for GCNSPs and DNSPs

Each service provider must ensure adequate labelling of all NNI devices to current standards so that equipment may be easily identifiable in the event of any issues.

Obligation NNI.7: mandatory for GCNSPs and DNSPs

All NNI interconnects must employ monitoring mechanisms to ensure that any link failure is reported in a timely fashion. This failure must be immediately reported into the relevant management platform with an associated alert condition.

NNI Virtual Local Area Network (VLAN) and IP allocation for PoC and PoI interconnects

Obligation NNI.8: mandatory for GCNSPs and DNSPs

VLANs must be allocated from existing GCNSP and DNSP provider pools.

Obligation NNI.9: mandatory for GCNSPs and DNSPs

All service providers must provision NNI interconnects using point-to-point /30 IP addressing presented on physical or logical sub-interfaces.

Routing protocols - peering, AS numbering and AS path

Obligation NNI.10: mandatory for GCNSPs and DNSPs

Physical or sub-interfaces must be used for peering in all cases.

Obligation NNI.11: mandatory for GCNSPs, DNSPs and other network services

All service providers must only use public AS numbers assigned from their own allocations.

Obligation NNI.12: mandatory for GCNSPs, DNSPs and other network services

Any AS path manipulation (such as AS-Override, SoO and AS prepend values) must be performed at the edge of the network via the client facing PE device. No other manipulation of the AS path is expected.

Obligation NNI.13: mandatory for GCNSPs and DNSPs

All service providers must provide a statement of current AS 32bit capability as well as a roadmap to deliver this capability.

Routing protocols - BGP timers, authentication and prefix limits

Obligation NNI.14: mandatory for GCNSPs and DNSPs

All service providers must support standard BGP timers, namely a keepalive of 60 and a holddown of 180. Any change to these values must be agreed between parties for use at the NNI.

Obligation NNI.15: mandatory for GCNSPs and DNSPs

The service provider must provide authentication of the BGP session at the NNI.

Obligation NNI.16: mandatory for GCNSPs and DNSPs

All service providers must apply a maximum value of 5000 to the allowed BGP prefix count. However, any such value will be scaled based on government demand without enforcing any limitation on the consumer.

Routing protocols - community attribute support

Obligation NNI.17: mandatory for GCNSPs and DNSPs

All service providers must support community values at the NNI point.

Routing protocols - filtering

Each service provider must commit to applying the correct filters to limit communication to the required Virtual Private Network (VPN) resource only. For example, PE devices should allow direct ICMP and BGP peering traffic only.

MPLS Virtual Private Networks (VPNs) in use on the PSN

The PSN shared services VPN is a linked set of provider MPLS VPNs connected via NNIs. The VPN that spans the GCN containing shared customer traffic is called PSN_Service. Each DNSPs connects a shared VPN to PSN_Service, and every other PSN network connects a shared VPN to its DNSP’s shared VPN.

Obligation NNI.32: mandatory for GCNSPs, DNSPs and other network services

A PSN network service must provide access to the PSN shared services VPN, and may also provide a customer with access to a number of other MPLS VPNs, including private and shared VPNs.

If a customer chooses a PSN network service to be configured such that it does not have access to the PSN shared services VPN, then this configuration must be called a non-connected PSN network service. The service provider must be able to enable access to the PSN shared services VPN simply and quickly, so any non-connected PSN network service must be a configuration variant of a compliant and operational PSN network service, and not a separate service.

MPLS Virtual Private Networks (VPNs) in use on the GCN

VPNs that transit the GCN are a finite resource that must be managed. There are two types of VPN that transit GCN:

  • the steady state predefined set
  • special request closed user group

The maximum manageable number of GCN transit VPNs is 70, made up of:

  • PSN predefined VPNs = 5,
  • special request VPNs = 65 Maximum

Organisations may submit requests for GCN VPNs to the PSN team, who will confirm the business need, on behalf of government, for a new VPN to the GCN service providers. The GCNSPs will consider the supporting contracts and where the traffic is routed, and decide which of them will implement new VPN. A special request VPN does not have to be supported by all GCNSPs.

Obligation NNI.29: mandatory for GCNSPs

Service providers must implement this steady state predefined set of 5 GCN-spanning VPNs:

Name ID Purpose
PSN_Service 701 used for all PSN customer traffic, both for PSN Assured and PSN Protected
PSN_Reserve1 702 Temporarily used for the provision of the Vodafone GCF Secure Internet Gateway Service to Public Sector organisations during their transition to PSN*
PSN_Performance 703 Service provider performance measurement VPN**
PSN_Test 704 VPN for service test traffic**
PSN_Reserve2 705 pre-provisioned but use not defined

*Note that PSN_Reserve1 will revert back to its previous Purpose (‘Pre-Provisioned but use not defined’) once all customers have transitioned off the Vodafone GCF Secure Internet Gateway Service.

**Note that these VPNs do not need to propagate beyond the GCN.

Obligation NNI.31: mandatory for GCNSPs

Service providers must inform the PSN team of any VPN crossing the GCN, and avoid using an ID for their VPN that is already in use. The PSN team will maintain and publish a list of all VPNs crossing the GCN.