RFC 979

Network Working Group Title Block ✨

Okay bestie, first things first 🎀 this RFC is by Andrew G. Malis from BBN Communications Corp., and it dropped in March 1986 as RFC 979. It's titled PSN END-TO-END FUNCTIONAL SPECIFICATION 💅 It doesn't obsolete or update anything, so it's a fresh start 🌸

Status of this Memo

Okay so this memo is an updated version of BBN Report 5775, "End-to-End Functional Specification" 🦋 It got updated to reflect changes since that report was written, and it's being shared in this form to give info to the ARPA-Internet community about this work 🧚 The changes described here will affect AHIP (1822 LH/DH/HDH) and X.25 hosts directly connected to BBNCC PSNs 🔥

If you want to know when this version of the PSN software (Release 7.0) gets deployed in the ARPANET and the MILNET, you can ask DCA 💜 And distribution of this memo is unlimited, so share away 🫶

---

1. Introduction ✨

Okay so this memo has the functional spec for the new BBNCC PSN End-to-End (EE) protocol and module 💖 (PSN stands for Packet Switch node, which used to be called the IMP 🍓) The EE module is the part of the PSN code that keeps EE connections alive so data gets delivered reliably across the network, and it also handles the packet level (level 3) stuff with the hosts 🎀 The EE protocol is the peer protocol EE modules use to create, maintain, and close connections 🫶

The new EE exists to fix a bunch of deficiencies in the old EE, boost its performance and throughput, and make the PSN better equipped for its current and future host population 🚀

The initial version of the new EE is shipping in PSN Release 7.0 ✨ Both old and new EEs live in the PSN code, but each PSN can only run one of them at a time (not both!) 🙈 The Network Operations Center (NOC) can switch individual PSNs, or the whole network, between old and new EEs 👑 When the old EE is running, PSN 7.0 acts exactly like PSN 6.0, so the differences in this memo don't apply 💅 And hosts on PSNs running the old EE can't interoperate with hosts on PSNs running the new EE 😭

After this intro there are two more sections 🌈 Section two covers the motivation and goals behind the new EE project 🦋

Section three has the new EE's functional spec ⭐ It covers the services for the different host types the PSN supports, the addressing capabilities, the functionality the peer protocol needs, and the performance goals for the new EE 💜

Two terminology notes before we go on 🍓 In this doc, the units of info sent from one host to another are called "messages", and the units those messages get chopped into for transmission through the subnetwork are called "subnet packets" or just "packets" 🎀 This is different from X.25's terminology, because X.25 "packets" are actually messages 😭 Also, in this report "AHIP" refers to the ARPANET Host-IMP Protocol, described in BBN Report 1822, "Specifications for the Interconnection of a Host and an IMP" 🧚

2. Motivation ✨

Okay so the old EE was built almost a decade ago, back in the early days of packet switching 🦋 This part of the PSN stayed stable for eight years, but the environment it runs in changed a LOT 💅 When the old EE was made, it was only used in one network, the ARPANET 🌸 Now there are tons of PSN-based networks, and some of them are grouped into internets 🌈 AHIP used to be the only host interface protocol, with NCP sitting on top of it 🍓 X.25 use is growing fast now, and TCP/IP has replaced NCP 🔥

This section talks about why the new EE needs more flexibility and higher limits than the old one, and lists the goals this new design should hit 💖

2.1. Benefits of a New EE 🎀

Network growth and the changing environment make better performance, meaning more PSN throughput, a big goal for the new EE 🚀 The new EE cuts protocol traffic overhead, so it uses network line bandwidth and transit PSN processing power more efficiently ✨

The new EE gives a set of network transport services that work for both the AHIP and X.25 host interfaces 🫶 The old EE was highly optimized for, and tightly tied to, the AHIP host interface, so it couldn't do that 😭

The new EE has an adjustable window facility, instead of the old EE's fixed window of eight outstanding messages between any host pair 💅 The old EE applied that limit to all traffic between two hosts, and it had no concept of multiple independent channels or connections between them 🙈 The new EE allows that 🦋 A network with satellite trunking, which means long delays, is an example where the new window facility boosts the EE throughput you can actually get 🛰️ TACs and gateways are another example where the old fixed window was a bottleneck 😭 All of the traffic between a host and a TAC or gateway used the same EE connection and was stuck with the eight-outstanding-messages limit, even when several users' traffic flows were involved 💀 With the new EE, that restriction is gone 👑

Supportability is another reason to rewrite the EE software ✨ The new EE can use more modern programming practices, like layering and modularity, which weren't as well understood when the old EE was first designed 🌈 Those techniques make the EE easier to support and enhance 🎀

Finally, the new EE adds a bunch of new features so the PSN can offer services that are more closely tuned to what customers need for their apps 💖 These include new addressing capabilities, precedence levels, end-to-end data integrity checks, and monitoring and control capabilities 🔥

2.2. Goals for the New EE 💜

The new EE's X.25 support is way better than the old EE's 🧚 One part of that improvement is at least halving the amount of per-message EE protocol overhead 🍓 Another part is unifying the different storage allocation mechanisms the old EE and X.25 modules used, since data moving between them used to get copied from one structure type to another 💅

The new EE tries, as much as possible, to present a non-blocking interface to the hosts 🌸 If a host floods the PSN with traffic, the PSN eventually has to block it, but that should happen less often than it does now 🦋

In the old EE, all the hosts compete for the same pool of resources 😭 In the new EE, fairness is enforced in resource allocation among different hosts, through per-host minimum allocations for buffers and connection blocks as part of a general buffer management system 👑 This makes sure no host can be completely "shut out" of service by another host at its PSN 🫶

The EE supports four precedence levels and, optionally (on a per-network basis), preemption features 🌈

Addressing capabilities now include hunt groups 🎀

Instead of a fixed window of eight outstanding messages between any host pair, the maximum window size on an EE connection is configurable up to 127 💖 The EE also lets host pairs set up multiple connections, each with its own independent window ✨

The old EE relies on destination buffer reservation, which means subnet packets can get lost if an intermediate node goes down 💀 The new EE uses source buffering with retransmission to give more reliable service 🛡️

The new EE has a duplex peer protocol, so acknowledgments can be piggybacked on reverse traffic to cut protocol overhead 🔥 When there's no reverse traffic, acknowledgments get aggregated and sent together 🍓

The end result of all this is end-to-end software with better performance, supportability, and functionality 👑

---

3. End-to-End Functionality 💅

This section has the new EE's functional spec 🦋 It covers the services provided to the different host types the new EE supports, the addressing capabilities it offers, the functionality the peer protocol requires, the performance goals for the new EE, the EE's network management spec, and provisions for testing and debugging 🧚

3.1. Network Layer Services 🌸

The most important part of designing any new system is figuring out its external functionality 🎀 For the new EE, that means the network layer services and interfaces the hosts see 💜

3.1.1. Common Functionality ✨

The next three sections list the details for the new EE's support of the X.25, AHIP, and Interoperable network layer services 🫶 To keep things brief, though, some extra functionality that all three services get is listed right here 🌈

• 🔥 To check data integrity as packets cross the network, the old EE relies on a trunk-level, hardware/firmware-generated, per-packet CRC code (16 or 24 bits, depending on which PSN-PSN trunk protocol is in use) plus a software-generated per-packet 16-bit checksum 🧚 Neither of these is an end-to-end check, since they only check PSN-to-PSN 😭 For the new EE, the software checksum has been extended into an optional 32-bit end-to-end checksum, and the per-packet software checksum has been reduced to a parity bit 💖

The network admin now gets to choose what matters most: efficient use of network trunks (because the per-packet headers are smaller), or strong data integrity checks 👑

Hosts that need strong data integrity checking can request, in their configuration, that all messages originating from them include a 32-bit per-message end-to-end checksum 🛡️ This checksum is computed in the source PSN, ignored by tandem PSNs along the path, and checked in the destination PSN 🍓 If the checksum doesn't check out, the EE's regular source retransmission facilities are used to get the message resent 🦋

• 🌸 The old EE's access control mechanism lets you define 15 separate communities of interest, and it uses an unnecessarily complicated algorithm to decide which communities can talk to each other 🙈 This is being expanded to allow 32 communities of interest, up from the old limit of 15 💅 The feature that let hosts communicate with a community without actually being a member of it has been removed, because nobody ever used it 💀
• The addressing capabilities of the PSN have been improved by the new EE. 💖 In addition to continuing to support the old EE's logical addressing facility, hunt groups (for both AHIP and X.25 hosts) have been added. These are described further in Section 3.2.
• Connection block preemption is supported on a configurable per-network basis. 🔥 If a network is configured to use connection block preemption, then lower-precedence connections can be closed by the PSN, if necessary, in order to maintain configured reserves of PSN resources for higher-precedence connections.
• The new EE supports congestion control and improved resource allocation policies which ensure fairness and graceful degradation of service under extreme load. ✨ Certain resources can be prereserved to each host port, and each port can also be limited in its use of shared resources. This ensures that no host can be totally shut out from PSN resources by the actions of other hosts at the same PSN. 🫶 In addition, each PSN is sensitive to congestion in both of the PSNs at the endpoints of each connection, and it can exert backpressure (flow control) on hosts, as necessary, to prevent congestion. Main character energy, no notes. 👑

3.1.2. X.25 🦋

Okay so the new EE's X.25 service is a glow-up compared to what the old EE had. 💅 The following paragraphs summarize the X.25 support in the new EE:

• The new EE provides both DDN Standard and Basic X.25 service, as described in BBN Reports 5476, "DDN X.25 Host Interface Specification," and 5500, "C/30 PSN X.25 Interface Specification," respectively. ✨ In addition, the description of DDN Standard Service, Version 2, is found in Section 3.1.4 of this document.
• All data packets and call requests are source-buffered in the source PSN to provide a better level of reliability for network traffic. 🛡️ This should keep the network from issuing a reset on an open connection as a result of a lost packet in the subnet or any other occasional subnetwork failure. Except in cases of extreme network or node congestion, recovery from lost subnet packets is automatic and transparent to the end user or host. Honestly iconic. 😭
• Both local and end-to-end significance for host window advancement (based upon the D bit from the host) are planned, but only end-to-end significance is included in the initial release (the old EE did not include local significance). 🌸 The D bit is passed through the network transparently.

3.1.3. AHIP 🎀

Another service provided by the new EE is defined in BBN Report 1822, "Specifications for the Interconnection of a Host and an IMP", as amended by Report 5506, "The ARPANET 1822L Host Access Protocol". 📚 This ARPANET Host-IMP Protocol (AHIP) service is supported in a backwards-compatible manner by the new EE. Since this is a BBNCC-private protocol, the new EE can improve the service to better match its current uses (the AHIP protocol was first designed over twelve years ago). 🧚 The main changes to AHIP are to remove the absolute eight-message-in-flight restriction for connection-based traffic, and to improve the PSN's "datagram" support for non-connection-based traffic. Glow up era. 💜

For this new support, datagram service is planned (for PSN Release 8.0) to include fragmentation and reassembly by the network, but without requiring the network overhead used by connections, and without the reliability, message sequencing, and duplicate detection that connections provide. 🌈 However, "destination dead" indications will be provided to the source host where possible and appropriate.

With the new EE, hosts are also able to create multiple connections between host pairs by using the 8-bit "handling type" field to specify up to 256 different connections. 🍓 The field is divided into high-order bits that specify the connection's precedence, and low-order bits that distinguish between multiple connections at the same precedence level. Since the new EE is using four precedence levels, the handling type field is used to specify 64 different connections at each of the four precedence levels. Math ate. 🔥

AHIP connections will continue to be implicitly created and automatically torn down after a configurable period (nominally three minutes) of inactivity, or because of connection block contention. ⭐

To summarize the new end-to-end's AHIP support:

• The old EE's AHIP services are supported in a backwards-compatible manner (except where listed below).
• The old EE's uncontrolled (subtype 3) message service will be replaced, in PSN Release 8.0, by the datagram service mentioned above. 💀 This service will provide fragmentation and reassembly, so that there is no special restriction on the size of datagrams; will not insure that messages are delivered in order or unduplicated, or provide a delivery confirmation; will notify the source host if the destination host or PSN is dead; will not require the connection block overhead associated with connections; and may lose messages in the subnet, without notification to the source host, in the event of subnet congestion or component failures. This service could be useful for applications that do not need the absolute reliability or sequentiality of connections and therefore wish to avoid their associated overhead. 🙈

Datagrams are not supported by the new EE in PSN Release 7.0.

• Connections no longer have the old EE's "eight messages in flight" restriction, and a pair of hosts can be connected with up to 256 simultaneous implicit connections. 🦋 In addition, multiple precedence levels are supported.
• The new EE supports interoperability between AHIP and X.25 hosts (see Section 3.1.4 for further details). 🫶
• AHIP local, distant, and HDH (both message and packet mode) hosts are supported. The new EE does not support VDH hosts. VHA and 32-bit leaders are supported. 🌸
• Packet-mode HDH has been extended to allow longer packet data frames (see BBN Report 1822, Appendix J, for a description of the HDH protocol). 🍓 Middle packet frames can now contain up to 128 octets of data, rather than the previous 126 (although there must still be an even number of octets per frame). Last packet frames can now contain up to 127 octets of data, rather than the previous 125, and the number of octets need not be even. However, the maximum total message size is still 1007 data octets. The PSN uses these new packet frame size limits when sending packet frames to packet-mode HDH hosts unless the host is configured to allow only 126-octet frames. In addition, there are restrictions on packet-mode HDH when interoperating with DDN Standard X.25 hosts; these restrictions are discussed in Section 3.1.4. 🧚

3.1.4. Interoperability (DDN Standard X.25) 🌈

One of the main goals of the new EE is to provide interoperability between AHIP and X.25 hosts. 💖 On the surface, this may appear difficult, since the two host access protocols have little in common: X.25 presents a connection-oriented interface with explicit windowing, while AHIP presents a reliable datagram-oriented interface with implicit flow control. However, they both have the same underlying functionality: they allow the hosts to submit and receive messages, and they both provide a reliable and sequenced delivery service. Opposites, but make it make sense. 🤍

The key to interoperability is the fact that in the new EE, both X.25 and AHIP connections use the same underlying protocols and constructs. ✨ The new EE has AHIP and X.25 Level 3 modules that translate between the specific host protocols and the EE mechanisms. Since these Level 3 host modules share a common interface with the EE, the fact that the two hosts on either side of an EE connection are not using the same access protocol is largely hidden. 🫧

As a result, the new EE supports basic interoperability. 🎀 However, there are some special cases that need to be mapped from one protocol to the other, or just not supported because no mapping exists. For example, AHIP has no analogue of X.25's Interrupt packet, while X.25 does not support an unreliable datagram service such as AHIP's subtype 3 messages. For each of these cases, the recommendations of BBN Report 5476, "DDN X.25 Host Interface Specification," have been followed. 📖

The interoperable service provided by the new EE is called DDN Standard Service, Version 2. Standard Service, Version 1, is defined in BBN Reports 5760, "Preliminary Interoperable Software Design," and 5900 Revision 1, "Supplement to BBN Report Nos. 5476 and 5760".

The major differences between Versions 1 and 2 are:

• Version 2 offers improved performance over Version 1. 🚀
• The EE now provides four precedence levels. Therefore, the four precedence levels allowed in the DDN-private Call Precedence Negotiation are mapped directly to subnet precedence levels, instead of being collapsed into two subnet precedence levels as in Version 1. 👑
• On an interoperable connection, the X.25 protocol ID in an X.25-originated message is translated to an AHIP link number (the upper eight bits of the message-ID field) using a lookup table. Version 1 supports only the IP protocol ID and corresponding link number of 155 (decimal). Version 2 allows new values to be added to the lookup table. At present, IP is the only protocol supported. In addition, the AHIP link number is also used to distinguish one connection from another. This guarantees that when an AHIP host is sending messages to an X.25 host, messages using different link numbers come into the X.25 host on different X.25 connections. 🔑 Lowkey the most important bit, bestie. 🫶
• Since a "translation module" is no longer needed in the PSN, interoperable connections now have end-to-end significance 💖, with a direct match between X.25 RRs and AHIP RFNMs ✨. This keeps the meaning of the RFNM from Report 1822 🫶. Release 7.0 only offers end-to-end significance, but the D bit is passed through transparently on Standard Service connections between two X.25 hosts 🎀.
• Up to 256 simultaneous connections are supported between host pairs that use the same addresses and precedence levels 🌈. Version 1 only supported one of these 😭.

The following Version 1 services are not offered by Version 2 🙈:

• Permanent Virtual Circuits.
• X.25 protocol bypass (a BBN-private service).

Okay, there were some spicy debates about Report 5760 💅, so three things need a mention. First, for DDN Standard Service, Version 1, acknowledgments have local significance only, and the D bit must be set to 0 in the call request 🍓. In DDN Standard Service, Version 2, only end-to-end significance is provided, as mentioned above ✨. For backwards compatibility with Version 1, the D bit can be set to 0 or 1 in a call, but hosts are advised that only end-to-end significance is provided in Version 2 💜.

Second, non-standard Default Precedence is not supported by either Standard Service Version 1 or Version 2 🙅. Support for this facility in Version 1 was withdrawn at the request of DCA 💀.

Third, although DTEs are allowed to request maximum packet sizes of 16, 32, and 64 octets, the DCE always negotiates up to 128 octets 🧚, as per Section 6.12 ("Flow Control Parameter Negotiation") of the CCITT 1984 X.25 Recommendation 📚. This is true of both Version 1 and Version 2 👑. Since IP and TCP are required when Standard Service is in use, this is a reasonable restriction (due to the length of IP and TCP headers) 🫶.

One issue must be raised about interoperability between X.25 and packet-mode HDH hosts ⭐. To interoperate efficiently, packet-mode HDH hosts should completely fill their middle packet frames with 128 octets of data 🌸. Packet-mode HDH hosts that send or require receiving middle packet frames with less than 128 octets of data can still interoperate with X.25 hosts, but at a greater expense of PSN CPU resources per message 😮‍💨.

---

3.2. Addressing 🎀

The old EE supports two forms of host addressing for both AHIP and X.25 hosts, physical and logical 🌷.

Physical addressing means identifying a host port by the combination of its PSN number and the port number on that PSN 📍. Logical addressing lets an arbitrary 16-bit "name" refer to a list of one or more host ports 🦋. The EE tries to open a connection to one of the ports in the list according to the criterion chosen for that name: first reachable in the ordered list, closest port (in terms of routing delay), or round-robin load sharing 🔁.

For the new EE, logical addressing is supported on an explicit per-connection basis 💅: all logical-to-physical address translations take place in the source PSN when a connection is established ✨. Once this translation has happened, all data messages on the connection are sent to the same physical address 💌.

Hunt groups are now supported for both X.25 and AHIP hosts too 🎉. This new capability lets host ports on a destination PSN be combined into a "hunt group" 🧺. The ports share the same group identifier, and incoming connections are evenly spread over the ports in the group ⚖️. This is different from logical addressing's load sharing 🙃: there, all name translations take place in the source PSN, the different ports can be on any number of PSNs, and the load sharing is on a per-source-PSN basis. By contrast, all of the host ports in a hunt group are on the same PSN 🏠, the group-to-port resolution takes place in the destination PSN 🎯, and the load sharing of incoming connections can be guaranteed over the ports by the destination PSN 💯. For X.25, hunt groups comply with Section 6.24 of the 1984 X.25 Recommendation 📖. Note that Called Line Address Modification is not supported 🚫.

---

3.3. Protocol Functionality 🦋

The EE peer protocol runs between EE modules in PSNs on either end of an EE connection 🔗. This protocol and its mechanisms have to perform the following functions 👑:

• Provide full duplex connections (the old EE provides simplex connections, and any two-way traffic, such as that generated by TCP, requires two subnet connections) ↔️.
• Open a connection and optionally send a full message's worth of data as part of the open request (the old EE requires a separate opening sequence in each direction before data can flow) 🚪.
• Reliably send connection-oriented messages, properly fragmented/reassembled and sequenced 📦.
• Close (clear) a connection (normally, or in a "clean-up" mode after a host or PSN dies) 🧹.
• Reset a connection (like the X.25 reset procedure) 🔄.
• Be able to send a limited amount of out-of-band traffic associated with a connection (like the X.25 interrupt) 🚨.
• Use source buffering with message retransmission (after a timeout) to insure delivery (the old EE depends on destination buffer preallocation, which adds protocol overhead and cannot recover from lost packets in the subnet) 🛟.
• Use an internal connection window of up to 127 messages 🪟.
• Support two types of ACKs, Internal ACKs (IACKs) and External ACKs (EACKs), which are further described following this list 💬
• Have an inactivity timer for each connection. For AHIP and Standard X.25, the connection is closed if the timer fires. For Basic X.25, the EE uses an internal Hello/I-Heard-You sequence with the PSN on the other end of the connection to check if the other end's host or PSN is still alive. If not, then the connection is closed ⏰.
• Be able to gracefully handle resource shortages and avoid reassembly lockup problems 🧘.

As mentioned above, the protocol supports two types of acknowledgments, IACKs and EACKs 💜. Both types of ACKs apply to messages only; individual packets are not acknowledged 📨. Since windowing is being used, one ACK can acknowledge more than one message 🪟✨.

IACKs cancel the retransmission timer and free source buffering 🧽. They are sent when a message has been completely reassembled and delivered from the EE to either the AHIP or X.25 level 3 module 📬. This lets the EE avoid unnecessary message retransmissions, and speeds up freeing source buffering when destination hosts are slow to accept messages or, in the case of X.25, slow to advance the PSN's window to the destination 🐢. (X.25 does not specify any time limit for a host to acknowledge that it received a message 🫠.)

EACKs advance the end-to-end window and cause one or more end-to-end X.25 RRs or AHIP RFNMs to be sent to the source host 🚀. An EACK is sent when an X.25 host acknowledges a message, or when an AHIP host actually receives it 💌.

Both types of ACKs are piggybacked, if possible, on reverse traffic to the source PSN (for any connection) 🐷. Whenever a packet is sent to another PSN, it is filled to the maximum allowed subnetwork packet size with any outstanding ACKs waiting to be sent to that PSN 🧩. After a configurable period, all outstanding ACKs for the same PSN are aggregated together and sent ⏳. Succeeding ACKs for the same connection can be combined into one, and EACKs can be used to imply that a message is being IACKed as well (if the destination host is speedy enough when receiving or acknowledging messages to allow IACKs and EACKs to be combined) 🏎️.

The ACK aggregation timer works together with the source buffering retransmission timer like this 🕰️: whenever a message is sent from a host on one PSN to a host on a second PSN, an IACK is sent back to the first PSN when the message has been completely reassembled by the destination EE 📥, and an EACK is sent when it has been delivered (and perhaps ACKed) by the destination host 📤. The IACK must make it back to the source PSN within the limits of the retransmission timer, or unnecessary retransmissions could be sent across the network 🚧. This limits the ACK aggregation timer to being shorter than the source buffering retransmission timer ⚠️.

If the destination host is quick enough when accepting traffic from its PSN (with respect to the ACK aggregation timer), the EACK can be combined with the IACK, and only the EACK would be sent 🤝. If the destination host is even quicker, multiple IACKs and EACKs could be combined into one EACK ⚡. In the best case, if there is a steady stream of traffic going between the two PSNs in both directions (but not necessarily over the same connection or even between the same pairs of hosts in each direction), then all of the IACKs and EACKs could be piggybacked on data packets 🥳 and cause no additional network packets beyond the data packets already required to send the data messages across the network 🌟. In the worst case, though, such as when there is only a one-way flow from a source PSN to a destination PSN and the destination host is very slow to accept the messages from the network, each data message could result in separate IACKs and EACKs being sent back to the source PSN in individual packets 😩. Even so, the IACKs may cause additional packets to cross the network, but they are still less expensive than the source retransmissions they are used to prevent, and they also free up valuable source buffering space 💅✨.

---

3.4. Performance and Capacity Goals 🔥

Performance and capacity goals for the new EE include 🎯:

• Throughput: The AHIP host-host and host-trunk maximum throughput (in packets/second) will be at least as good as at present, and should improve for those situations that currently entail traffic limitations based upon the old EE's underlying protocol 🚄. The current X.25 intrasite host-host and host-trunk throughput will each improve by at least 50% 📈. The store-and-forward throughput for the new EE's X.25-based traffic will improve by at least 100% 💯.
• Connections: The new EE will support at least 500 simultaneous connections per PSN, and will be able to handle at least 50% more call setups per second than at present 📞✨.
• Buffering: The EE will have at least 400 packet buffers available to source-buffer and/or reassemble messages 🧠🫧.
• Network size 🌸: okay bestie, so the EE protocol and module will use data structure and message field sizes big enough to support at least up to 255 hosts per PSN and 1023 PSNs per network (however, other PSN protocols and modules presently constrain these figures to 63 hosts per PSN and 253 PSNs per network) 💅✨
• Other 🦋: the EE will support four message precedence levels and a maximum message length of 1024 bytes 💖 For logical addressing, the EE will support at least 1024 logical names and at least 2048 address mappings per network 🎀🌈