2. Fabrics, Prefixes, Subnetting and Summarisation

Overview

It is important for an organization designing an IP broadcast facility to adequately plan and manage the IP addresses of their infrastructure. This document describes the technical details behind the example LVN IPAM structure and provides information on how to understand: 

• The purpose of IP prefixes and assigning them to the network fabrics
• Subnetting IP prefixes — the process of dividing a large pool of addresses (a prefix) into smaller, more manageable subnetworks (subnets)
• The purpose of summarization
  • Easy to understand, predict and configure routes to networks by using route summarization
    • Reducing the number of networks/routes a switch advertises to its neighbor

By following the LVN IPAM example guidelines, customers may allocate IP addresses, allowing for:

• An individual facility to add capacity/horizontally increase in scale in the future
• The planning of multiple facilities to transition from legacy baseband to IP infrastructure
• The inter-connectivity of sites and facilities (e.g. studio-to-studio, studio-to-truck, truck-to-truck, etc.)
• The transition from non-SDN controlled Streaming Media network(s) to SDN controlled Streaming Media network(s) while also allowing for:
  • L3-PIM Leaf switches
  • vsmShare

This document is applicable for AIS and MIS integrations.

IP Prefixes

IP Prefixes are used to create an aggregation or pool of IPv4 or IPv6 addresses for the various networks that make up an IP broadcast facility. The network address and subnet mask are expressed in CIDR notation. Currently, Lawo makes use of the IPv4 addressing system. The table below illustrates how a pool of IP addresses (a prefix) can be allocated to multiple fabrics at a parent level:

Example Parent IP Prefixes

Once parent level IP prefixes have been established, the pool of addresses can be divided or 'subnetted' into child prefixes for further designation:

Example Child IP Prefixes

This process can be repeated in order to create further child prefix subnets, for example allocating specific address spaces per Studio/OB Truck:

Summarisable Routes

Lawo encourages the use of IP prefixes for all fabrics that can be easily summarized. Route summarization is a method to reduce multiple routing table entries by using a single statement. It is often used for representing IPv4 address prefixes. Below is an example statement that could be configured on a Broadcast Control / Management switch so that HOME can access devices attached to all switches in the streaming media networks via in-band communication:

Example Use-case of Summarized Routes

ip route 10.1.128.0 255.255.255.0 10.1.224.2

ip route 10.1.128.0 255.255.252.0 10.1.224.2

ip route 10.1.129.0 255.255.255.0 10.1.224.2

ip route 10.2.160.0 255.255.252.0 10.1.225.2

ip route 10.1.130.0 255.255.255.0 10.1.224.2

ip route 10.1.131.0 255.255.255.0 10.1.224.2

ip route 10.1.160.0 255.255.255.0 10.1.225.2

ip route 10.1.161.0 255.255.255.0 10.1.225.2

ip route 10.1.162.0 255.255.255.0 10.1.225.2

ip route 10.1.163.0 255.255.255.0 10.1.225.2

Route Summarization

Summarisation is often employed to make routing tables smaller, in addition to the redistribution of routes between routing protocols such as BGP and OSPF. It is also easier to manipulate these routes using route-maps, prefix-list, access-list, etc., for granular control/tuning, e.g. on a Purple switch, block BLUE multicasts from egressing links to RED switches. Additionally, making multicast streams summarizable based on essence types makes it easier to:

• Identify streams during troubleshooting
• Configure multicast boundaries
• Configure PIM Rendezvous Points (RPs) based on different multicast ranges
• Configure flow policies when using SDN Controllers

Base Network Addressing

The Base network refers to the physical network infrastructure that forms the foundation which the remaining networks are built on:

• e.g. the physical switches and hardware that make up the Broadcast Control / Management, Streaming Media networks and PTP/NTP infrastructure forwarding packets based on IPv4 addresses and routing protocols
• The BASE-NET is the specific IP prefix allocated for assigning the physical PTP GMC interfaces, switch hardware and uplink interfaces with IP addresses

The subsequent networks are logically configured alongside the physical BASE-NET:

• e.g. the Broadcast Control / Management and Streaming Media networks
• The BCAST-CTRL-NET, RED-MEDIA-NET, BLUE-MEDIA-NET and PURPLE-MEDIA-NET are the specific IP prefixes allocated for assigning the end point devices network interfaces with IP addresses

Provisioning and implementing an IP prefixes for Base network enables the customer to implement technologies such as virtualization and virtual private networks (VPNs) in the future. Technologies such as Virtual Extensible LAN (VXLAN) can enable devices to span a Layer 2 network across remote networks via the Underlay. This can be particularly useful when intercom systems (which typically do not work well in a Layer 3 routed network) are required to be in the same Layer 2 network, but are located in geographically different facilities.

Loopback Addressing

A loopback interface is a virtual, logical interface that is always in an 'up' or active state and does not depend on a physical port. It is assigned a single /32 IP address and is commonly used for network stability, management, and routing purposes. A switch can be configured to have multiple loopback interfaces.

Loopback Addressing

Loopback interfaces in the Base network are assigned an IP address with a /32 subnet mask:

• e.g.
  • 10.1.224.1/32
  • 10.1.224.2/32
  • 10.1.224.3/32
  • etc.

Uplink Addressing (point-to-point)

Uplink interfaces are physical ports designated for interconnecting switches together. They are typically assigned the second available IP address from a /30 subnet, the first available IP address is assigned to the switch interface. A switch will typically have multiple uplink interfaces connected.

Uplink Addressing

Uplink interfaces in the Base network are assigned an IP address with a /30 subnet mask:

• e.g.
  • 10.1.224.65/30
  • 10.1.224.69/30
  • 10.1.224.73/30
  • etc.

/31 Uplink Addressing

While /31 masks can also be used, this should be avoided if 'dynamic stagebox' addressing via DHCP is desired by the customer

Broadcast Control / Management Network Addressing

Lawo recommends to logically segment the IP prefix assigned to the BCAST-CTRL fabric by using VLANs paired with subnets to:

VLANs

• ✅ Reduce the size of the failure domain
  • e.g. the number of devices that will be affected in the event of network disruption
• ✅ Reduce the size of the broadcast domain and improve efficiency
• ✅ Improve network performance and security

There is no single 'best practice' for allocating VLANs in a Broadcast Control / Management fabric, however there are two good viewpoints to be aware of:

• A VLAN per device type
  • This method subnets the IP address range assigned to the Broadcast Control / Management fabric and makes networks and VLANs based on the devices by type: 
    • VLAN 11: HOME servers
    • VLAN 12: vsmStudio servers
    • VLAN 13: vsmStudio control panels
    • VLAN 14: .edge blades
    • VLAN 15: HOME Apps servers
    • VLAN 16: A__UHD Cores
    • VLAN 17: Power Cores
    • VLAN 18: A__line devices
    • VLAN 19: Audio consoles
    • VLAN 20: Radio consoles

• A VLAN per location/application
  • This method subnets the IP address range assigned to the Broadcast Control / Management fabric and makes networks and VLANs based on the devices that a grouped by their application or location — e.g.
    • VLAN 11: Studio A (audio): A__UHD Cores, XCS servers, A__line devices, mc² consoles

Customers can also choose to use elements of both approaches in their designs. 

Resource Sharing

The 'VLAN per location/application' method is particularly applicable to audio infrastructure customers who wish to make use of Lawo's resource sharing feature, whereby A__UHD Cores and XCS servers can be logically paired together to provide multiple virtual mixing facilities

Below is a list of best practices to consider when designing a VLAN structure for the Broadcast Control / Management fabric:

BCAST-CTRL LVN Recommendations

• ✅ In Layer 2 Spine-Leaf Broadcast Control / Management networks, configure the BCAST-CTRL spine switches to be the Spanning-Tree Protocol primary/root bridge for each BCAST-CTRL VLAN
• ✅ Configure the first/lowest IP address in a given BCAST-CTRL subnet as the VLANs gateway address (IGMP Snooping querier election is based on 'lowest IP address wins')
  • Typically assigned to a Switch Virtual Interface (SVI)
• ✅ Reserve the first three IP addresses in each BCAST-CTRL VLAN/subnet when using switches that implement MLAG or vPC pairing for routing redundancy protocols
• ✅ Configure an IGMP Snooping querier on each BCAST-CTRL VLAN to control multicast discovery mechanisms
• ✅ Disable PTP on BCAST-CTRL access interfaces (Power Core does not like it)

It is common for customers to request the Broadcast Control / Management network connect to the corporate IT network, sometimes via a firewall. This should be achieved by employing static routes to the customer's network via L3 routed interfaces, however, L2 trunk/access ports can also be used.

Streaming Media Network Addressing

High Bandwidth e.g. SMPTE ST2110

The majority of LVNs employ the use of Layer 3 /30 routed interfaces for connecting endpoints to the Streaming Media fabrics. A /30 network comprises four IP addresses:

• Network address
• Host/endpoint address (switch interface)
• Host/endpoint address (device interface)
• Broadcast address

e.g.

The benefits of using this approach to managing IP addresses in Streaming Media networks are:

• LVNs use PIM (Protocol-Independent Multicast) to establish multicast communication between switches in the same Streaming Media fabric
• The switches are PIM neighbors and communicate over point-to-point links, a /30 subnet (2 usable IPs) is the most efficient way to allocate addresses
• /30 networks minimise wasted IP space compared to a larger subnets

• In a larger /24 subnet, multicast traffic may be received by unintended devices
  • A /30 ensures only the two directly connected devices participate in PIM and IGMP messaging

• A /30 subnet isolates multicast traffic between two devices
• Minimises exposure to multicast-related security vulnerabilities

Example Unicast IP Address Management

The start of this document alluded to using the following parent prefixes:

Base Network

For the Base network, a single /20 network provides a total of 4,096 addresses, more than enough capacity for a topology consisting of hundreds of switches/line cards across all fabrics, assuming:

• At least two loopback interfaces per switch
• Four uplink connections are used for connecting to other switches using routed interfaces with /30 networks, requiring four IP addresses per uplink
  • 26 IP addresses per Streaming Media switch

A physical topology with the capacity for 8 x /23 subnets could consist of:

• A maximum of two BCAST-CTRL-NET spine switches
  • BCAST-CTRL-NET leaf switches add more physical network capacity, but use L2 trunk uplinks which do not require IP addresses
• At least 61 individual RED-MEDIA-NET switches
• At least 61 individual BLUE-MEDIA-NET switches
• At least 10 individual PURPLE-MEDIA-NET switches
• A maximum of four PTP GMCs
• A minimum of two PTP Distribution switches

Indicative Available IP Addresses

4096 – 3440 = 656 available IP addresses 

Broadcast Control / Management Networks

For the Broadcast Control / Management network, a /17 parent prefix can be subnetted into 128 x /24 child prefixes:

A single /17 network provides a total of 32,768 addresses, which, as previously described, can be subnetted further and assigned to VLANs to logically segment the Broadcast Control / Management fabric and support thousands of devices.

Streaming Media Networks

For the streaming media fabrics, a /19 parent prefix can subnetted into 32 x /24 child prefixes:

Each /24 network can be subnetted into 64 x /30 networks (256/4 = 64):

This equates to the following endpoint capacity, per streaming media fabric:

Therefore, a single routing statement can provide access to an entire IP facility consisting of up to 2,048 streaming media endpoints per fabric:

ip route 10.1.128.0 255.255.224.0 10.224.2

ip route 10.1.160.0 255.255.224.0 10.1.225.2

A streaming media network consisting of up to 2,048 endpoints can accommodate large modern facilities. Below is an example of how the IP addresses could be allocated across Lawo product lines:

Summary 

By using a /16 prefix and appropriately subnetting, a customer has the capacity to build a small IP facility and scale it up to a large facility without the need to re-IP address any equipment.

• 1 x /17 prefix for the Broadcast Control / Management network
• 2 x /19 prefixes (one per Streaming Media fabric)
  • Providing capacity for up to 2,048 devices per streaming media fabric
• 1 x /20 prefix for a Purple network (if required)
• 1 x /20 prefix for the Base network
  • Supports at least 26 individual switches across all fabrics (BCAST-CTRL-NET Leaf switches do not explicitly require IP addresses for Loopback interfaces or uplinks)
    • 276 IP addresses required

Example Multicast IP Address Management

Lawo advises customers to use the 'Administratively Scoped' (private) multicast address range 239.0.0.0 - 239.255.255.255. This range is used for local multicast within an organization. The range can be subnetted into two equal ranges and provides over 8.3 million multicast addresses to each Streaming Media fabric:

However, please be aware of the regional differences between the use of automatic multicast address assignment to flows:

Regional Differences

• Customers in North America typically have a pre-existing IP schema that Lawo and other manufacturers must adhere to - therefore, automatic multicast addressing is not desirable
• Customers in the rest of the world typically do not have a pre-existing IP schema - therefore, manually assigning multicast addresses is not desirable

AIS Multicast Organization

MIS Multicast Organization

Oratio

Please note the Oratio service in HOME does not currently support address assignment that can be summarized. The size and complexity of a given project may influence the decision whether or not to use Oratio.

Should a customer wish to evolve a facility and integrate an SDN controller in the future, the example unicast and multicast LVN IPAM structure above is also compatible with Arista's MCS and Cisco's NDFC/NBM SDN controllers.

• Arista's MCS is directed to allocate bandwidth to individual flows via the Broadcast Controller — therefore, summarization for multicast ranges is not necessary
• Cisco's NBM/NDFC is configured to allocate bandwidth to individual flows — therefore, summarization for multicast ranges is not necessary

Considerations

A disadvantage to the example multicast organisation as described above, is when using bandwidth policies based on multicast address ranges:

• A change in standard, e.g. 3G to UHD, requires the flow multicast address to be changed
  • If the address is not changed (based on the example above), packets will be dropped due to the increase in bandwidth requirement for a UHD signal being processed through a 3G flow policy