NEN Design Consultation

1
NEN Design Consultation
November 2004

• Technical Policy, Delivery and Standards

2
Introduction and Aims

• Agenda
• Bectas Strategic Aims
• Building a National Educational Network
• NEN Design Approach
• Highlights
• Outcomes

3
Bectas Strategic Aims

• improve learning and teaching through the
  effective and embedded use of ICT
• increase the number of educational organisations
  making effective, innovative and sustainable use
  of ICT
• improve the availability and use of high quality
  educational content
• develop a coherent, sustainable and dependable
  ICT infrastructure for education
• continuously improve Becta's ability to deliver

4
develop a coherent, sustainable and dependable
ICT infrastructure for education

• Becta Infrastructure teams
• Develop Policies
• Produce guidance
• Define standards based specifications
• Commercial suppliers to education
• Create best value products and services
• Delivery
• Other Stakeholders (RBCs, LEA and LA)
• Integrate the delivery of services across sectors
• Ensure joined up working

5
Building a National Educational Network

• Developing a national framework of standards
• WAN services
• Institutional networks
• Application and information services
• Need for standardisation
• To be able to access services and optimise
  performance
• To cover end-to-end approach of delivery of
  applications
• Need to integrate with applications providing
  access to network services

6
Building a National Educational Network

• Portfolio
• Building models and promoting Standards
• Project Brief
• Co-ordination and development
• Activities
• Develop a national framework of standards for WAN
  services
• Co-Produce standards framework with key
  stakeholders and industry partners

7
NEN Design Approach

• Consultative input
• Document composition
• RBC and LEA visits
• Produce section drafts
• Review process
• Wider consultation and review
• Re draft and issue
• Formal process to be defined for all new policy
  and standards documents

8
Highlights

• Purpose of NEN
• Secure
• Reliable
• Interoperability
• Support next generation applications
• Equality of access to services
• NEN Design Document
• A design model to meet these objectives

• Audience
• RBC technical staff
• LEA/LA
• Integrators/ISP
• Design Model
• Can be tailored to meet local needs
• Modular Approach
• NEN Backbone interconnect
• RBC Layer
• Aggregation Layer
• Access Layer

Based on an integrated Network with appropriate
domains of responsibility
9
Outcomes

• Use scenarios
• Operational issues
• Re-purposing
• Additional topics (if any)
• Any barriers to the document being used?
• How would these be overcome?
• Identify potential risks how these can be
  mitigated against?
• Quality - how is the document to be updated and
  how frequently?

10
Designing a NEN

• A top-down design approach the top of the
  stack is driven by application layer
  requirements
• Scalable network design to accomodate changing
  network usage and service demands
• Balancing priorities, performing trade-offs and
  addressing a broad range of technical issues at
  both a general and detailed level
• Overall goal is to achieve predictability and
  consistency in performance, resilience and
  scalability

11
Regional Multilayer Design Model
12
Regional Multilayer Design Model

• RBCs to provide an integrated regional network
  down to the Access layer, with appropriate
  domains of responsibility
• Modular approach each layer has a specific
  role
• A Backbone layer providing optimised, highly
  resilient and high performance RBC interconnects
• An RBC layer providing optimised, resilient and
  high performance Aggregation layer interconnects,
  security, Internet access and application/network
  services
• An Aggregation layer providing School
  connectivity, security, traffic management and
  application/network services
• An Access layer that connects end devices at
  schools, libraries etc
• Hosting/Server Farms can be facilitated at an
  appropriate layer as required
• Easier to grow, understand and troubleshoot the
  network
• Load balancing and redundancy applied
  appropriately as required
• Follows consistent and deterministic traffic
  pattern

13
Regional Multilayer Design Model

• Incorporates balance of both Layer 2 and Layer 3
  technology, leveraging the strength of both
• Utilises IGP for benefits such as load balancing,
  fast convergence, scalabilty and control
• Uses Layer 3 intelligence at control points, such
  as, Aggregation and RBC layer to enforce access
  control, QoS and classify traffic
• Key decisions regarding security and the
  prioritisation of traffic are made at the School,
  Aggregation and RBC layers

14
Regional Multilayer Design Model

• Resilient Server Farm deployed at the RBC layer
• LEAs may also provide localised server farms for
  similar purposes
• Server Farms designed to provide the correct
  levels of redundancy, scalability and security
• Server Farms are implemented as high-capacity
  building blocks attached to the regional
  backbone

15
Regional Multilayer Design IP Addressing

• IP Addressing design must be planned, controlled,
  coherent, scalable and sumarisable where required
• Unique curriculum IP range within an RBC
• Unique Admin IP range within an Aggregation layer
  (if deployed as a separate network)
• 1022 curriculum IP addresses per school
  PCs/VC/Multimedia services
• Admin IP addresses - 126 per primary and 254
  per secondary school
• The curriculum network should use the private RFC
  1918 10.0.0.0 (255.0.0.0) address range
• The administration network should use the private
  RFC 1918 172.16.0.0 172.31.255.255 address
  range
• Where only a single network is deployed within a
  school, the network should use the private RFC
  1918 10.0.0.0 (255.0.0.0) address range
• security implications must be fully understood
  with additional measures in place to protect
  against breach

16
Regional Multilayer Design IP Addressing

• WAN links will use IP addresses from the
  curriculum network address range
• Network Address Translation (NAT) should be used
  to communicate with external untrusted networks
• Any services that an RBC/LEA/School wish to make
  available over the Internet or to other RBCs
  should have public IP addresses
• IP address ranges should be summarised at the
  Aggregation routers

17
Regional Multilayer Design DNS

• Schools and Local Authority will be operating
  primarily using private internal (not Internet
  routable) address space
• Internal DNS service used to keep track of
  private internal addresses
• Internal DNS service will only have visibility
  within either the school, Local Authority or RBC
  and use a non Internet domain name (e.g.
  schoolname.local)
• DNS management and administration catered for by
  either
• some schools managing their own DNS servers
• the organisation having managed service
  responsibility, in some cases the LEA or even the
  RBC supplier
• Public facing DNS (such as Email and Web
  addresses) will be administered by the
  organisation managing Internet access, which
  could be the LEA, RBC or ISP depending on
  contractual arrangements

18
Regional Multilayer Design IGP Routing

• Open Shortest Path First (OSPF) is the
  recommended IGP to be deployed for each of the
  regional networks within the NEN

19
Regional Multilayer Design IGP Routing

• RBC areas will be designated as Area 0 the
  backbone area
• All Aggregation layer areas will directly attach
  to the RBC backbone area and act as Area Border
  Routers
• School routers will not participate in any
  topology change recalculations as they are
  designated Stub Areas
• Autonomous System Boundary Routers will act as
  gateways (redistribution) between OSPF and BGP
  within an RBC region

20
Regional Multilayer Design EGP Routing

• Border Gateway Protocol (BGP) will be deployed as
  the EGP for peering connectivity into the NEN
  backbone

21
Regional Multilayer Design Security

• Security systems should support British and
  International standards for network/information
  security (BS 7799  ISO 17799)
• A security policy covering usage policy terms and
  conditions must be present, sponsored, endorsed
  and reviewed regularly
• For an RBC/LEA, usage policy breaks down into 4
  main areas general, school, partner and
  administrator acceptable use policies
• A specific policy statement should be formulated
  to cover home access, indicating requirements and
  responsibilities for users, schools and the
  RBC/LEA as network providers

22
Regional Multilayer Design Security

• Prior to any new development or procurement by
  authorities or schools, consideration should be
  given to the security policy
• RBCs will implement security policy across the
  regional network and the core and will also
  provide best practice guides and advice to
  schools
• It is the RBCs role to prevent external security
  breaches reaching the school and to stop any
  internal school security breaches affecting other
  users
• Detection, prevention and associated Incident
  reporting must be based on the layer at which the
  incident occurs (RBC, Aggregation, School) and
  the level of penetration

23
Regional Multilayer Design Security

• Firewalls deployed at the RBC protecting
  connections to the Internet and the National
  Interconnect into the NEN backbone
• Firewalls deployed at each Aggregation area
  connection to an external untrusted network
• Intrusion detection systems deployed in Server
  Farms and at untrusted external connections

24
Regional Multilayer Design Security
25
Regional Multilayer Design Security

• Application Level Gateways deployed as required
  to control the exchange of data between a secure
  and a non-secure network according to the network
  security policy
• Content filtering educational policy and
  configuration policy, decided by management and
  technical undertaking respectively
• Integrated content filtering solutions are vital
  to ensure that the content delivered to schools
  is safe
• Detailed monitoring regimes will need to be
  driven by the RBCs, LEAs and schools who have
  operational responsibility for managing their
  respective content access

26
Regional Multilayer Design Security

• All anti-virus software definition files should
  be automatically updated regularly
• Active and up to date anti-virus systems and
  definition files must be in place across each
  element of the network, achieved by either
• RBCs providing a region wide anti-virus license
• each LEA within an RBC ensuring that all of its
  schools have anti-virus software installed on all
  workstations and that virus definitions are
  automatically updated with the LEA providing the
  license and ensuring its annual renewal

27
Regional Multilayer Design Security

• A maximum level of security must be implemented
  for system devices and operation, by
• Limiting and controlling physical access to
  servers, routers, switches, appliances and
  network devices.
• Protecting the Network Elements e.g. turn off
  any unused or unnecessary services, use logging
  services to track access and configuration
  changes etc
• Environmental conditions - ensuring a controlled
  environment
• Designing the IP Network - following sound IP
  network design principles
• Configuration templates should be created to
  stipulate configuration requirements for all
  devices before connection on to the network
• Where maintenance is conducted remotely over the
  Internet, this should be facilitated through
  encrypted tunnels / VPN connections

28
Regional Multilayer Design Multicast

• Multicasting is a technique for delivering
  information to clients in a one-to-many fashion,
  conserving network bandwidth
• It is important that all the equipment, from the
  source, router, switch, to the listeners
  (receivers) support the chosen protocols
• It is important that guidelines exist on the
  choice of equipment when making a purchase.
• It is important to ensure that the source and the
  listener support IGMPv2
• Switches should have features like IGMP snooping
  to ensure that traffic is only forwarded to ports
  with registered members attached, although there
  may be other end stations in the same VLAN
  connected to other ports
• Routers should support Protocol Independent
  Multicast (PIM)

29
Regional Multilayer Design Multicast

• PIM-SM with Anycast RP is the recommended
  Multicast routing protocol within each of the
  different RBCs, associated Aggregation layer and
  Schools
• RPs must be correctly scaled for performance and
  optimally positioned between sources and
  listeners
• Anycast RP supports multiple RPs per Multicast
  group, providing a more scalable and
  fault-tolerant system
• MSDP will be used between each pair of RPs to
  allow each RP to share the load for source
  registration and give the ability to act as hot
  backup routers for each other

30
Regional Multilayer Design Multicast

• The recommended guidelines for IP Multicast
  within a regional RBC network are summarised
  below
• IP Multicast must be designed to scale streaming
  applications
• Administratively Scoped addresses should be used
  to differentiate Multicast applications by type
  and bandwidth
• LAN switches should support IGMP snooping
• Protocol Independent Multicast-Sparse Mode
  (PIM-SM) should be enabled at the RBC and
  Aggregation layers
• Anycast RP should be used for high availability
  and load balancing at the RBC and Aggregation
  layer (as required)
• RPs must be correctly scaled for performance and
  optimally positioned between sources and
  listeners
• IP Multicast boundaries should be used to control
  distribution of Multicast streams

31
Regional Multilayer Design Multicast

• Multicasting between regional RBC Networks
• Each RBC peering point with the National
  Educational Network backbone must support the
  transmission of Multicast data and in turn, each
  RBC regional network should be able to forward
  Multicast data to its downstream routers
• Multicast routing on the National Educational
  Network (NEN) backbone should use Protocol
  Independent Multicast-Sparse Mode (PIM-SM) and
  each RBC NEN interconnect router should be
  configured to transport both multicast data and
  routing information to the regional networks it
  connects
• Use of core backbone routers as the Rendezvous
  Points (RPs) or RBC NEN interconnect routers as
  Rendezvous Points must be supported. Multicast
  Source Discovery Protocol (MSDP) peering between
  the core backbone routers and the RBC NEN
  interconnect routers must be supported. This will
  enable exchange of Multicast source and group
  state information between the regional network
  and the NEN backbone
• As it is most likely that SuperJANET is used to
  interconnect RBC regional networks, RBCs should
  consult and adopt the SuperJANET Multicast
  address allocation scheme for intra-region
  Multicast deployment

32
Regional Multilayer Design Multicast

• There is no single best way to allocate
  Multicast addresses for use in all regional
  networks
• Each regional network and its responsible parties
  need to take their own unique requirements into
  account, and thus design the best addressing
  policy
• There are two ranges of private addresses that
  can be allocated within a regional addressing
  scheme (RFC 2365) - Site Local Scope and
  Organisational Local Scope
• A Multicast security policy must exist that
  defines which Multicast groups and corresponding
  UDP ports that are permitted to be relayed across
  the firewall

33
Regional Multilayer Design QoS

• To be effective, QoS must be implemented on an
  end-to-end basis, which in a National Educational
  Network (NEN) means local school campus, LEAs,
  RBCs and the NEN backbone
• Service Level Specifications (SLS) and Agreements
  need to be established covering all the domains
  in order to achieve end-to-end operation
• For end-to-end QoS, classification needs to be
  application specific
• Applications that will need standards for QoS
  include
• Voice over IP (VoIP)
• Video Conferencing
• Streaming Media

34
Regional Multilayer Design QoS

• Recommendation is for traffic to be identified
  and marked (with DSCP values) as close to its
  source as possible
• Traffic Shaping and Policing also used within
  certain network conditions to control ingress and
  egress traffic
• Where Firewalls are traversed, Application
  Gateways required to retain QoS
• Intra RBC standards need to be based on specific
  application need

35
Regional Multilayer Design Network Management

• Network Management is undertaken at the RBC layer
  within a trusted network deployed at each of the
  RBC regional networks
• In the case of opt-out LEAs, Network Management
  is undertaken at the opt-out LEA layer
• The Network Management Systems (NMS) should
• Facilitate the configuration, monitoring and
  troubleshooting of network devices within the
  regional trusted network
• Provide visibility into network behaviour and
  identify performance bottlenecks that can impact
  short and long-term performance trends
• Offer sophisticated configuration tools to
  optimise bandwidth and utilisation across
  broadband connections in the network

36
Regional Multilayer Design Network Management

• Network Management Applications
• Required
• Applications to manage and monitor
• LAN and WAN network infrastructure
• Security
• Firewalls
• Application and system management for key servers
  and applications in server farms
• Optional
• Applications to manage and monitor different
  technology areas, if deployed
• Quality of Service
• IP Telephony and VoIP
• Virtual Private Networks
• Multicast

37
Regional Multilayer Design Network Management

• The following are considered key design elements
  for a network management system solution
• Proactive Fault and Performance Management
• Device Management Tools
• Topology Maps
• Configuration Manager
• Real-time Traffic Monitor
• Auditing
• Access Accounting and Authorisation (AAA)
• Secure Shell (SSH) Communication
• Simple Network Management Protocol (SNMP)
• In-Band / Out of Band Management
• NTP Server
• Help Desk Integration
• Service Level Agreements (SLAs)
• Service Level Management

38
NEN Design Consultation
November 2004

• Technical Policy, Delivery and Standards