HSCN Supplier Workshop – 19th May 2016 Peering Discussion Chair: Kate Gill

Today’s Objectives Agree a mutually favourable technical approach for network interconnects Review the requirements / principles for HSCN’s preferred approach Document pros and cons Timescales required Agree a set of actions / tasks to take the solution forward with owners Documentation required Draw out any commercial issues for discussion this afternoon

HSCN requirements for network interconnects Provide a level playing field for all participating network providers Support routing “out of the box” across network endpoints and to national applications No need for major infrastructure changes to connect new suppliers or services Provide easiest and timely path for Transition Remove the need for a large core backbone as the bulk of applications and services are moved locally or to the internet Simple and effective fault diagnosis between supplier networks To provide centralised connectivity to other networks e.g. SWAN or Janet i.e. permit central interconnects to these services for all HSCN service providers

HSCN preferred approach How should peering work? As a private peering arrangement not reusing public Number of locations – 2 and where Principle of how it works ie fibre under the floor as in same location or connection to this location Do we put internet into this location as well? Do we try and put filtering/monitoring in here? N3 connects via two reference connections in the same location – or as they are in the building a “special” bespoke service as it can also be fibre in the building Do we agree now it connects MPLS DNSP networks and can support PSN as well as ourselves? Sizing/capacity needed – is it as simple as 10Gb circuits will be plenty for all as a connection  - or do we need to actually think what traffic will be routed over it, for example to the TN which could get above this level (except it might not without internet)? Layer 2/3 traversal – someone needs to explain difference to me J Availability target? Resilience minimum at each exchange?  

Why We Favour Peering Simple, uncomplicated connectivity Flexibility (can rapidly deploy increased bandwidth) Rapid path to connectivity / interconnectivity Level playing field across suppliers Simplified end-to-end Service Assurance & fault diagnosis Best possible performance (traffic doesn’t have to span a core, could use route servers/route reflectors to ensure shortest path etc.) Use of established Peering Exchanges facilitates simplified Internet connectivity Allows other networks to connect to the peering e.g. Janet / SWAN

Peering - Technical challenges vs Core / Backbone Open for Discussion: Point to note – Current sum total of NHS circuits is >500Gb/s Can hosted services that require national access (e.g. Spine) connect to peering or would be better supported on a backbone providing wider dispersed PoPs. Note we think these could be connected to DLNs Is the peering option resilient enough for our purposes What technical challenges do you see with the preferred approach?

Other Discussion Points Availability & Performance – Acceptable targets? Capacity / Sizing – number of connections Who should run the peering infrastructure? Requirement for NSI cross service view Timescales to deliver – note HSCN needs this prior to April 17 with an ambition to be ready by Dec 16 Anything else? How should it be set-up and managed? Who should run the peering infrastructure? A peering specialist third party One of the DLN providers? NSI? Will there be an NSI cross service view of it What would we need to do to manage it – capacity/performance??

Conclusion Consensus on approach – review any issues or other proposals Review action list Commercial aspects for this afternoon

Future Discussions QoS, including IP Addressing Transition Network Diffserv architecture, Service class mapping and alignment, DSCP codepoints & Transparency. IP Addressing Making use of both RIPE and RFC1918 IP Address Management