RFC 2391
Load Sharing using IP Network Address Translation (LSNAT)
RFC 2391: Load Sharing using IP Network Address Translation (LSNAT) 💖
okay bestie, this one is a Network Working Group doc, and it's giving "we figured out how to share the load across servers without anyone changing their setup" 🫶
- Author 1: P. Srisuresh, from Lucent Technologies 🎀
- Author 2: D. Gan, from Juniper Networks, Inc. 🎀
- Category: Informational 🌸 (it provides information for the Internet community, it's not a standard)
- Date: August 1998 📅
- Obsoletes / Updates: the header doesn't list anything it obsoletes or updates ✨
Status of this Memo ✨
This memo is informational for the Internet community. It is not an Internet standard of any kind, and it's free to distribute with no limits 💅
Copyright Notice 🌈
Copyright (C) The Internet Society (1998). All Rights Reserved.
Preface 🎀
okay so this doc takes the address translation idea from RFC 1631 and mixes it with real-time load sharing algorithms to create Load Share Network Address Translators (or, simply, LSNATs) 🦋 LSNATs can quietly take load off one server and spread it across a whole pool of servers, no drama, totally transparent 👑
Abstract 🌸
Network Address Translators (NATs) change IP addresses inside a datagram while they route it, and the end nodes never notice 🙈 NATs have traditionally been used so private network domains can talk to global networks with as few as one globally unique IP address. In this doc, we level up NATs with a load sharing feature, so session load gets spread across a pool of servers instead of being sent to one lonely server 😭 That's a win for service providers and sysadmins alike, since servers keep getting more sessions and they need to scale 💜
1. Introduction ✨
Okay so, NATs (or just "NATs") were originally used to connect private network domains to globally unique public IP networks 🧚 Apps start in the private domain, and the NAT quietly translates the datagrams for those apps in either direction. This doc mixes that transparent address translation with real-time load sharing algorithms to create Load Share Network Address Translators 🔥
Load sharing (or load balancing) is not a new problem at all, it goes back years 🍓 People tried lots of techniques. Some were super ad hoc and platform specific, and some were clever schemes that reorder DNS resource records. REF [11] uses a DNS zone transfer program on name servers to periodically shuffle the order of resource records for server nodes, based on a pre-determined load balancing algorithm. The catch? Those reordering periods can be very large, on the order of minutes, and they don't reflect real-time load changes on the servers 😬 Also, that approach assumes every host in the server pool has equal capability to offer all services, and that's often not the case 💀 Sometimes you also only need load balancing for a few specific services. The load share approach in this doc tackles both of those concerns, and it doesn't need any changes to clients or servers. Plus it can be tailored to individual services or to all services 🫶
For the rest of this doc, we'll call NAT routers that provide load sharing support LSNATs 🦋 Unlike traditional NATs, LSNATs aren't limited to operating between private and public domain routing realms. They also work inside a single routing realm and still provide load sharing 💅
Load sharing becomes necessary when a single server can't keep up with a growing number of sessions at the same time 😭 Spreading that load across multiple servers boosts responsiveness and scales nicely with session load. Popular apps that can flood servers include web browsers, remote login, file transfer, and mail 📬
When a client tries to reach a server through an LSNAT router, the router picks a node in the server pool based on a load share algorithm, then redirects the request to that node 🧚 LSNATs don't put any restrictions on how the nodes in a server pool are organized or rearranged. Nodes can be replaced, new nodes can be added, and others can be in transition 🌸 All of those changes can be hidden from client nodes, because the LSNAT router becomes the focal point for change management 👑
Now the not-so-fun part: LSNATs have limitations 😩 First, all requests and responses for a session between a client and server have to be routed through the same LSNAT router, which the doc describes as "mandatory" 🙈 Because of that, the recommendation is to run LSNATs on a single border router into the stub domain where the server pool lives. That way, all traffic going to the servers from outside clients, and all traffic going back, has to pass through the LSNAT border router 🦋 Later on, the doc covers a special LSNAT setup that gets around this topological constraint on the server pool, so stay tuned 👀
Second limitation: LSNATs can't switch loads between hosts in the middle of a session. That's because LSNATs measure load at the granularity of sessions. Once a session is assigned to a host, it can't move to a different host until that session ends 🔥
Other limitations of NATs, as outlined in REF [1], also apply to LSNATs 💀
As with traditional NATs, LSNATs take away the end-to-end significance of an IP address 😭 The big upside, though, is that LSNATs can be installed without changing any clients or servers 💖
2. Terminology and concepts used 🎀
2.1. TU ports, Server ports, Client ports 🦋
For the rest of this doc, we'll refer to the TCP/UDP ports associated with an IP address simply as "TU ports" 🧚
Most TCP/IP hosts use TU port range 0-1023 for servers listening for incoming connections. Clients trying to start a connection usually pick a TU port in the range of 1024-65535 🌸 That said, this convention isn't universal and isn't always followed. Client nodes can start connections using a TU port number in the range of 0-1023, and some applications listen on TU port numbers in the range of 1024-65535 🙈
A complete list of TU port services can be found in REF [2] 📚 The TU ports servers use to listen for incoming connections are called "Server Ports", and the TU ports clients use to start a connection to a server are called "Client Ports" ✨
2.2. Session flow vs. Packet flow 💅
Connection or session flows are different from packet flows 🌈 A session flow shows the direction a session was initiated in, relative to a network port. A packet flow is the direction a packet traversed, relative to a network port 🦋 A session flow is uniquely identified by the direction the first packet of that session traveled 👑
Take a telnet session as an example. It has packet flows in both directions. Outbound telnet packets carry the client's terminal keystrokes, and inbound telnet packets carry screen displays from the telnet server 💻 So doing address translation for a telnet session means translating the incoming packets and the outgoing packets that belong to that session 😭
Packets belonging to a TCP/UDP session are uniquely identified by this tuple: (source IP address, source TU port, target IP address, target TU port) 🎀 ICMP sessions that match queries and responses using a query id are uniquely identified by (source IP address, ICMP Query Identifier, target IP address) 🫶 For lack of well-known ways to tell them apart, all other types of sessions get lumped together and told apart by (source IP address, IP protocol, target IP address) 🙈
2.3. Start of session for TCP, UDP and others 🔥
The first packet of every TCP session is trying to establish a session, and it carries connection startup info 🧚 You can recognize it by the SYN bit being set and the ACK bit being absent in the TCP flags 🌸 Every TCP packet except that first one must have the ACK bit set 💅
The first packet of every session, whether TCP, UDP, an ICMP query session, or anything else, is trying to establish a session 💖 But there's no deterministic way to recognize where a UDP session or any other non-TCP session starts 😩
Start of session really matters for NATs, because a state describing the translation parameters gets established at the start of the session 🦋 Packets for the session can't be translated unless the NAT has set up that state at the start of the session 👑
2.4. End of session for TCP, UDP and others 😭
A TCP session is over when FIN has been acknowledged by both halves of the session, or when either half receives the RST bit in the TCP flags field 🌈 If one session partner sets the RST bit, you can safely assume the session has terminated within a short period (say, a couple of seconds) 🔥
Every other kind of session has no deterministic way to tell when it ends, unless you know the application protocol 💀 People use lots of heuristic approaches to end sessions. You can assume TCP sessions that haven't been used for say, 24 hours, and non-TCP sessions that haven't been used for say, 1 minute, are terminated 🙈 Often this assumption works, but sometimes it doesn't 😬 These idle period timeouts can vary a lot across the board, and they may be user configurable 🎀
Another option is to timestamp sessions, keep them around for as long as possible, and retire the longest idle session when it becomes necessary 🧚
2.5. Basic Network Address Translation (Basic NAT) 🌸
Basic NAT lets hosts in a private network domain access hosts in the external network transparently 🦋 A block of external addresses is set aside to translate the addresses of private hosts, as those private hosts start sessions to applications in the external domain 💖 Once the NAT device binds an external address to a specific private address, that binding stays in place for all later sessions from the same private host 👑 The binding can be ended when there are no sessions left using it ✨
2.6. Network Address Port Translation (NAPT) 💅
Network Address Port Translation (NAPT) lets hosts in a private network domain access hosts in the external network at the same time, transparently, using a single registered address 🌈 It works by multiplexing the transport layer identifiers of private hosts onto the transport identifiers of that one external address 🔥 Because of that, NAPT only supports applications based on TCP and UDP 😭 ICMP query based applications are supported too, since the ICMP header carries a query identifier that's used to correlate responses with requests 🧚 Any other session type, other than TCP, UDP, and ICMP query types, is simply not permitted from local nodes served by a NAPT router 🙈💀
2.7. Load share ✨
okay so bestie, load sharing here means spreading session load across a cluster of servers that are functionally similar or the same 💅. Every node in the cluster can handle a client session equally well, with no noticeable difference in what it can do 🫶. Once a node is picked to service a session, that session is stuck with that node until it ends 🔒. Sessions are not allowed to hop between nodes partway through 🙅♀️.
Load sharing can apply to all services, as long as every host in the server cluster can carry out all of them 🌈. It can also be limited to one or more specific services and skip the rest 🎀.
Also, "session load" (used in the load share context) is NOT the same thing as "system load" 🙈. System load is the CPU, memory, and other resource usage on a host. Different vibes, different meaning, periodt 💜.
3. Overview of Load sharing 🦋
okay this part is giving comparison energy ✨. Both traditional NATs and LSNATs do address translation and give end nodes transparent connectivity, but they're different in a few key ways 👑.
Traditional NATs start translations on outbound sessions. They either bind a private address to a global address (that's basic NAT), or they bind a tuple of private address and transport identifier (like a TCP/UDP port or an ICPM query ID) to a tuple of global address and transport identifier 🧚.
LSNATs flip it and start translations on inbound sessions 🔄. Each session, represented by a tuple like (client address, client TU port, virtual server address, server TU port), gets bound to one of the server pool nodes. The node is picked using a real-time load-share algorithm ⚡. A virtual server address is a globally unique IP address that stands for a physical server or a group of servers offering similar or the same functionality 🫧.
For the remainder of this document, we'll just call traditional NATs "NATs" 💖. We'll only talk about LSNATs in the load share context, and we won't imply any traditional NAT functionality for them 🌸.
LSNATs are not limited to private and public routing realms 🌍. They can also run inside a single routing realm that uses globally unique IP addresses, or between private and public network domains, whatever's easiest 💅. The only real requirement is that the server pool is confined to a stub domain, reachable by clients outside the domain through a single LSNAT border router 🚪. BUT, as you'll see later, this topology limit on the server pool can be overcome in certain configurations 🙌.
Here's how Load Share NAT works, step by step 🧠. A client tries to reach a server using the server virtual address. The LSNAT router quietly redirects that request to one of the hosts in the server pool, picked with a real-time load sharing algorithm 🎯. One client can start multiple sessions, and each one could land on a different host depending on how the load is balanced across the server pool at that moment ⚖️. If you only want load sharing for a few specific services, you can configure the LSNAT to restrict load sharing to just those services 🎀.
Now the one limitation 🚧: if the virtual server address is the same as the interface address of an LSNAT router, then server applications on that router (such as telnet) must be disabled for external access on that address. So using an address the LSNAT router owns as the virtual server address comes with that catch 😬.
Load share NAT also helps during individual server upgrades 🛠️. Say a server needs an upgrade. It gets statically mapped to a backup server on the inbound side. After that mapping, any new session requests aimed at the original server get redirected by LSNAT to the backup server 🔁. As an extension, you can also statically map a specific TU port service on one server to a backup server 🍓.
We'll walk through LSNAT operation in the subsections below, covering (a) servers confined to a stub domain and belonging to a globally unique address space shared by clients, (b) servers confined to a private address space stub domain, and (c) servers not restrained by any topological limitations 🧚♀️.
3.1 Operation of LSNAT in a globally unique address space 🌐
Here we're looking at LSNAT in a globally unique address space 💫. The border router with LSNAT enabled on the WAN link does the load sharing and address translations for inbound sessions 🌟. Outbound sessions from hosts in the server pool are NOT subject to any translation, since every node already has a globally unique IP address 🫶.
In the example, servers S1 (172.85.0.1), S2 (172.85.0.2), and S3 (172.85.0.3) form a server pool confined to a stub domain 🏠. LSNAT on the border router is enabled on the WAN link, so the virtual server address S (172.87.0.100) maps to the server pool made up of S1, S2, and S3 🎀. When client 198.76.29.7 starts an HTTP session to virtual server S, the LSNAT router checks the load on the server pool hosts and picks a host, say S1, to handle the request 👀. The transparent address and TU port translations the LSNAT router performs are shown as you follow the down arrow line ⬇️. IP packets on the return path go through similar address translation 🔙.
Now say another client, 198.23.47.2, starts a telnet session to the same virtual server S 📞. The LSNAT would decide host S3 is a better choice for this session, since S1 is already busy with a session, so it redirects the session to S3 🔀. That second redirection path is drawn with colons ::: 🌈. This keeps going the same way for any number of sessions 🔁✨.
Notice what's NOT happening here: no changes are needed on clients or servers 🙌. All the configuration and mapping only lives on the LSNAT router 💅.
\ | /
+---------------+
|Backbone Router|
+---------------+
WAN |
|
Stub domain border .......|.........
|
{s=198.76.29.7, 2745, v | {s=198.23.47.2, 3200,
d=172.87.0.100, 80 } v | d=172.87.0.100, 23 }
v +------------------+ :
v |Border Router with| :
v |LSNAT enabled on | :
v |WAN interface | :
v +------------------+ :
v | :
v | LAN :
------v----------------------:---
{s=198.76.29.7, 2745, v | | |:{s=198.23.47.2, 3200,
d=172.85.0.1, 80 } | | | d=172.85.0.3, 23 }
+--+ +--+ +--+
|S1| |S2| |S3|
|--| |--| |--|
/____\ /____\ /____\
172.85.0.1 172.85.0.2 172.85.0.3
Figure 1: Operation of LSNAT in Globally unique address space3.2. Operation of LSNAT in conjunction with a private network 🏡
This section shows LSNAT working together with NAT on the same router 🤝. The NAT config is required for translating outbound sessions, and it can be either Basic NAT or NAPT 💖. The illustration below assumes NAPT on the outbound side and LSNAT on the inbound side over the WAN link 🎀.
Picture an organization with a private IP network and a WAN link to a backbone router 🏢. The private network's stub router gets a globally valid address on the WAN link 🌍. The remaining nodes in the organization have IP addresses that only mean something locally 🏠. The border router is NAPT configured on the outbound side, so it allows access to external hosts using that single registered IP address ✨.
The organization also has servers S1 (10.0.0.1), S2 (10.0.0.2), and S3 (10.0.0.3) that form a pool providing inbound access to external clients 📥. This works because LSNAT is enabled on the WAN link of the border router, so the virtual server address S (198.76.28.4) maps to the server pool made up of S1, S2, and S3 🫧. When external client 198.76.29.7 starts an HTTP session to virtual server S, the LSNAT router checks the load on the server pool hosts and picks a host, say S1, to handle the request 👀. The transparent address and TU port translations done by the LSNAT router are shown as you follow the down arrow line ⬇️. IP packets on the return path get similar address translation 🔙.
Then client 198.23.47.2 starts a telnet session to the same address 📞. The LSNAT decides host S3 is a better choice for this session, since S1 is already busy, so it redirects the session to S3 🔀. That second redirection path is drawn with colons ::: 🌈. And it keeps going the same way for any number of sessions 🔁.
\ | /
+---------------+
|Backbone Router|
+---------------+
WAN |
|
Stub domain border ........|.........
|
{s=198.76.29.7, 2745, v | {s=198.23.47.2, 3200,
d=198.76.28.4, 80 }v | :d=198.76.28.4, 23 }
v+-------------------+:
v|Border Router with |:
v| LSNAT and NAPT |:
v|enabled on WAN link|:
v+-------------------+:
v | :
v | LAN :
------v---------------------:------
{s=198.76.29.7, 2745, v | | | : {s=198.23.47.2, 3200,
d=10.0.0.1, 80 } | | | d=10.0.0.3, 23 }
+--+ +--+ +--+
|S1| |S2| |S3|
|--| |--| |--|
/____\ /____\ /____\
10.0.0.1 10.0.0.2 10.0.0.3
Figure 2: Operation of LSNAT, in coexistence with NAPTOnce again, no changes are needed on clients or servers 🙌. The translation is completely transparent to end nodes 🫶. Address mapping on the LSNAT handles load sharing and address translation for inbound sessions 📥. Sessions outbound from hosts in the server pool are subject to NAPT 📤. And yes, NAT and LSNAT happily co-exist on the same router 💜✨.
3.3. Load Sharing with no topological restraints on servers ✨
okay so this section is about setting up load sharing on a router WITHOUT boxing your servers into a specific spot in the network 🧚 the trick is that the virtual server address is owned by the load-sharing router itself. like, it's literally the same address as one of the router's interfaces 💅 we're calling this Load Share Network Address Port Translation (LS-NAPT) to tell it apart from LSNAT. routers doing this are LS-NAPT routers, or just LS-NAPTs 🦋
in an LSNAT router, an inbound TCP/UDP session gets identified by (client address, client TU port, virtual server address, service port), and it's translated into (client address, client TU port, selected server address, service port). the translation happens on every datagram in that session, in both directions 🔁
an LS-NAPT router is a whole different energy 😭 it translates the same session into (virtual server address, virtual server TU port, selected server, service port). see, the LS-NAPT router swaps the client address and TU port for the virtual server's address and TU port, which is the same as one of its own interface addresses. because of that, datagrams from clients AND servers are forced to use the router's address as the destination, so they're guaranteed to pass through the LS-NAPT router 🫶 which means the servers don't need any topological constraints at all 🙌
let's look at figure 3 in section 3.1. imagine the load-sharing router isn't just a border router, it can be any kind of router 🌸 say the virtual server address S (172.87.0.100) is the same as the WAN link address, and LS-NAPT is turned on on the WAN interface. figure 3 shows how the new router is set up.
when a client at 198.76.29.7 starts an HTTP session to S (the WAN interface address), the LS-NAPT router checks the load on the hosts in the server pool and picks one, say S1, to handle it. the destination address gets translated to S1 (172.85.0.1). the original client address and TU port get swapped for the WAN link's address and TU port. so the destination address, source address and source TU port all get translated by the time the packet reaches S1, which you can spot on the down-arrow path ⬇️ return packets go through similar translations 💖
then a second client at 198.23.47.2 opens a telnet session to the same virtual server address S, and the router load-shares it over to S3. this packet gets LS-NAPT translated too, same as the first client's. you can follow the data path and the translations along the colon line 👀 this keeps going for however many sessions come in. the translations on datagrams in either direction are completely transparent to the end nodes 🎀
\ | /
+---------------+
| Router |
+---------------+
WAN |
|
|
{s=198.76.29.7, 2745, v | {s=198.23.47.2, 3200,
d=198.76.28.4, 80 }v | 198.76.28.4 :d=198.76.28.4, 23 }
v +----------------+ :
v | A Router with | :
v | LS-NAPT enabled| :
v | on WAN link | :
v +----------------+ :
v | :
v LAN | :
------v---------------------:------
{s=198.76.28.4, 7001, v| | |:{s=198.76.28.4,7002,
d=172.85.0.1, 80 } | | | d=172.85.0.3, 23 }
+--+ +--+ +--+
|S1| |S2| |S3|
|--| |--| |--|
/____\ /____\ /____\
172.85.0.1 172.85.0.2 172.85.0.3Figure 3: LS-NAPT configuration on a router
okay so the bit that makes it click 🧠 datagrams from clients AND servers are all sent to the router's WAN interface address as their destination, so they all have to go through the router. with that guarantee in place, the servers no longer have to live inside a stub domain, and LSNAT doesn't have to be turned on only at the border router to that stub domain 💅
the LS-NAPT setup has more translations going on, so it's more complex than the LSNAT setups from the earlier sections 😭 but it's worth it, I promise. first, it breaks down the restraints on server topology 🙌 second, it scales with bandwidth expansion for client access. even if a service provider only has one link for clients today, LS-NAPT lets them add more links later and keep the same load-share service on the new links too 📈
it's not all sunshine though 🥲 server applications (like telnet) on the router box would have to be disabled for the interface address that's been assigned as the virtual server address. load sharing would only work for TCP and UDP applications. the max number of concurrent sessions is limited by the max number of TCP/UDP client ports on that same address. if ports 0-1023 are set aside as well-known service ports, that leaves a max of 63K TCP client ports and 63K UDP client ports on the LS-NAPT router to talk to each load-share server. so the LS-NAPT router can't concurrently support more than (63K * count of Load-share servers) TCP sessions and (63K * count of Load-share servers) UDP sessions. the math checks out, sadly 💀
4.0. Translation phases of a session in LSNAT router. 🧚
just like regular NATs, LSNATs have to keep an eye on three phases of address translation 👀
4.1. Session binding: 🔗
session binding is the phase where an incoming session gets linked to the address of a host in the server pool 💖 that link sets the translation parameters for every datagram after it in the same session. for addresses with static mapping, the binding happens at startup. otherwise, each incoming session gets dynamically bound to a different host using a load sharing algorithm 🎀
4.2. Address lookup and translation: 🔍
once session binding is set up for a connection, every packet that belongs to that connection gets checked with a session lookup for translation purposes 🫶
for outbound packets in a session, the source IP address (and the source TU port, if it's a TCP/UDP session) and related fields (like the IP, TCP, UDP and ICMP header checksums) get translated. for inbound packets in a session, the destination IP address (and the destination TU port, if it's a TCP/UDP session) and related fields (like the IP, TCP, UDP and ICMP header checksums) get translated 🦋
the header and payload changes made to IP datagrams under LSNAT are exactly the same as the ones for traditional NATs, described in section 5.0 of REF [1]. so, bestie, go read REF [1] for the full packet translation process 📚
4.3. Session unbinding: 🌙
session unbinding is the phase where a server node is no longer responsible for the session. usually, that happens when the end of the session is detected. like we said in the terminology section, figuring out when a session has ended isn't always easy 🙈
5. Load share algorithms 🎰
there are lots of algorithms out there for picking a host from a server pool to handle a new session ✨ load distribution mainly depends on (a) the cost of getting to the network a server sits on, plus the load on the network interface used to reach it, and (b) the server's resource availability and system load. there are all kinds of policies you can use to spread sessions across a server pool 🌈
for simplicity, we're going to look at two types of algorithms, based on how close the server nodes are to the LSNAT router. the higher the cost of reaching a server, the farther away it's assumed to be 🧭 the first kind assumes all server pool members are at equal or nearly equal distance from the LSNAT router. so the load can be spread based only on resource availability or system load on the remote servers, and network access cost doesn't matter here 💅 the second kind assumes all server pool members have equal resource availability, so the choice comes down to how close each server is. in other words, this kind uses algorithms that take the cost of network access into account 👑
5.1. Local Load share algorithms ✨
Okay so, ideally the selector would know the exact real-time resources and system load of every host in the server pool 🧠, and then it could just pick the one with the most unused capacity. Obvious choice, right? 💅 But that is literally so hard to pull off, ngl.
We're looking at two kinds of heuristic approaches to track session load on pool members 🔍. The first kind is where the load share selector keeps an eye on system load for each server in a non-intrusive way 🫥. The second kind is where the members actively join the chat with the selector and tell it what load capacity they have 📣.
Here are the most common selection algorithms in the non-intrusive category 🦋:
- Round-Robin algorithm This is the simplest scheme 🎀. A host gets picked on a round robin basis, without any regard to how loaded it is.
- Least Load first algorithm This is an upgrade from round-robin 🙌. The host with the least number of sessions bound to it gets to service a new session. It's not without caveats though 🙃. Each session is assumed to be as resource consuming as any other session, no matter what type of service it represents, and all hosts in the server pool are assumed to be equally resourceful.
- Least traffic first algorithm Even better, you could measure system load by tracking the packet count or byte count directed from or to each member host over a period of time 📊. Packet count isn't the same as system load, but it's a reasonable approximation, so it's giving "good enough" 👌.
- Least Weighted Load first approach This one is an enhancement to the first two 💜. It lets administrators assign weights to sessions, based on likely resource consumption estimates of each session type, and weights to hosts based on resource availability 🍓.
The sum of all session loads by weight assigned to a server, divided by the weight of that server, gets evaluated to pick the server with the least weighted load for each new session. Let's do an example, bestie 🧚. FTP sessions get 5 times the weight (5x) of a telnet session (x), and server S3 is 3 times as resourceful as server S1. Say S1 has 1 FTP session and 1 telnet session, while S3 has 2 FTP sessions and 5 telnet sessions. When a new telnet session needs assignment, the weighted load on S3 comes out to (2*5x+5*x)/3 = 5x, and the load on S1 comes out to (1*5x+1*x) = 6x. S3 is smaller, so S3 wins the new telnet session 👑.
- Ping to find the most responsive host Up until now, the LSNAT has been figuring out a member host's capacity using heuristic approaches only 🤔. In reality, you can't predict system capacity from a remote spot without actually interacting with the member hosts 🙈. So a prudent move would be to periodically ping member hosts and measure the response time to figure out how busy they really are ⏱️. Then you use that response time together with the heuristics to pick the host that's most appropriate for the new session 💖.
In the active category, we bring the individual member hosts into the resource utilization monitoring process 🫶. An agent software on each node would notify the monitoring agent about its resource availability. Clearly, this means every member node has to run an application program, and that program should not consume significant resources by itself 💅. This strategy of involving member hosts in system load monitoring is likely to yield the most optimal results in the selection process 🌈.
5.2. Distributed Load share algorithms 🌍
When server nodes are spread out geographically and the cost to reach them varies a lot, the load share selector could use that info when picking a server for a new session 🗺️. To do this, the load share selector would need to consult the routing tables maintained by routing protocols such as RIP and OSPF, so it can find the cost of accessing a server 🧭.
All of the algorithms below are the non-intrusive kind, where the server nodes don't actively take part in telling the load share selector about their load capacity 🫥.
- Weighted Least Load first algorithm The selection criteria are based on (a) the cost of access to the server, and (b) the number of sessions assigned to the server 💸. The product of cost and session load for each server gets evaluated, and the server with the least weighted load gets picked for each new session. Say the cost of accessing server S1 is twice as much as the cost of server S2. In that case, S1 will be assigned twice as much load as S2 during distribution 🙃. When a server isn't accessible because of a network failure, its cost of access is set to infinity, so no more load can be assigned to it 💀.
- Weighted Least traffic first algorithm This is an improvement over the previous one 🔥. The idea is to measure network load by tracking packet count or byte count directed from or to each member host over a period of time. Again, packet count isn't the same as system load, but it's a reasonable approximation 👍. So the product of cost and traffic load (over a fixed duration) gets evaluated for each server, and the server with the least weighted traffic load gets selected for each new session 🎀.
6. Dead host detection 💀
As sessions get assigned to hosts, it's super important to detect whether the hosts are still alive 🫀. Otherwise, sessions could just get black-holed into a dead host 😭. There are lots of heuristic approaches. Sending pings periodically is one way to check liveness 🏓. Another approach is to track datagrams originating from a member host in response to new session assignments 👀. If no response is detected in a few seconds, declare the server dead and do not assign new sessions to that host 🙅♀️. The server can be checked again later, after a long pause (say, on the order of a few minutes), by periodically reassigning new sessions and monitoring response times, and so on 🔁.
7. Miscellaneous 📜
The IETF has been notified of potential intellectual Property Rights (IPR) issues with the technology described in this document 🚨. Interested people are asked to look at the IETF web page (http://www.ietf.org) under the Intellectual property Rights Notices section for the current info 🔍.
8. Security Considerations 🚨
All security considerations associated with NAT routers, described in REF [1] are applicable to LSNAT routers as well. 😱 Basically, if the NAT router has security issues, so does the LSNAT router. No escape, bestie 💀🔒
REFERENCES 📚
- [1] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html - [3] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
- [4] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
- [5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
- [6] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
- [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
- [8] Postel, J., "Internet Control Message (ICMP) Specification", STD 5, RFC 792, September 1981.
- [9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
- [10] Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
- [11] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
Authors' Addresses 🎀
Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Voice: (925) 737-2153
Fax: (925) 737-2110
EMail: suresh@ra.lucent.com
Der-hwa Gan
Juniper Networks, Inc.
385 Ravensdale Drive.
Mountain View, CA 94043
U.S.A.
Voice: (650) 526-8074
Fax: (650) 526-8001
EMail: dhg@juniper.netFull Copyright Statement 🌸
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🌍
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💖
📦 where this page comes from
- ietf: rfc2391 1998-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms