Functional Overview
The Oracle Communications Subscriber-Aware Load Balancer (Subscriber-Aware Load Balancer) is a discrete network element that processes all SIP end-point signaling traffic entering the service provider network. The Subscriber-Aware Load Balancer is not necessarily the first network device to receive signaling traffic, as, depending on network topology, additional network components (for example, routers, network address translators, and so on) can lie between the end-point and the Subscriber-Aware Load Balancer.
Upon receipt of a SIP packet from an unknown source, the Subscriber-Aware Load Balancer uses a provisioned policy to select an appropriate next-hop SBC for traffic originated by that end-point. Subsequent packets from the same end-point are forwarded to the same SBC. The first packet, the one used to make the route decision, and all subsequent packets sent through the Subscriber-Aware Load Balancer to the next-hop SBC are encapsulated within an IP-in-IP format as defined in RFC 2003, IP Encapsulation within IP.
SBCs that participate in the load balancing-enabled deployment are enhanced by several capabilities. First, the SBC supports RFC 2003 tunnel for both packet transmission and reception. Second, the SBC periodically transmits health and performance data to the Subscriber-Aware Load Balancer; such information is evaluated and entered into the Subscriber-Aware Load Balancer’s route determination algorithm. Lastly, the SBC participates in any Subscriber-Aware Load Balancer-initiated rebalance operation, as described in the Rebalancing section. A group of SBCs, with the above-listed capabilities, that receive signaling traffic from the Subscriber-Aware Load Balancer, is referred to as a cluster.
The IP-in-IP encapsulation technique provides Subscriber-Aware Load Balancer transparency to the terminating SBC. That is, when an SBC receives an encapsulated packet via the Subscriber-Aware Load Balancer, it can discard the outer encapsulation leaving behind an identical packet as transmitted originally by the end-point. Visibility into the actual packet transmitted by the end-point is necessary to provide certain services in the SBC (for example, hosted NAT traversal, session-agent matching, and so on). A secondary goal achieved by using this encapsulation technique is that it provides a disassociation function between an SBC’s connected network and its SIP reachability. That is, an SBC can be assigned any IP address it wants from a network topology standpoint, yet still process SIP packets as though it were logically situated elsewhere at Layer 5. In a larger sense, the physicality of the SBC is no longer important; like-configured, logically identical SBCs can be spread all over the globe.