RFC 1932
IP over ATM: A Framework Document
RFC 1932: IP over ATM: A Framework Document 💖
Okay bestie, this is RFC 1932, and it's titled "IP over ATM: A Framework Document" 🎀. It was published in April 1996 by the Network Working Group (the IETF crew) and it's classed as Informational 📚, so it's giving "here's some info," not a rulebook. The authors are R. Cole and D. Shur from AT&T Bell Laboratories, plus C. Villamizar from ANS 👑. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.
Status of This Memo 📜
This memo is here to provide information for the Internet community 🌸. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶.
Abstract 🌈
So the IP over ATM working group has been at this for several years and came up with a pretty diverse set of proposals, and some of them aren't being actively looked at anymore 💀. This doc sorts the ones the group cares most about into categories so everyone can focus 🔥. The goal is to clarify how the proposals differ, spot the features they share, and push everyone toward a smaller, more mutually compatible set of standards 💜. Basically, by classifying the ATM approaches and issues, it's hoped this document will help steer the working group's direction 🧚.
1. Introduction ✨
The IP over ATM Working Group of the Internet Engineering Task Force (IETF) is chartered to develop standards for routing and forwarding IP packets over ATM sub-networks 💅. This document gives a classification/taxonomy of IP over ATM options and issues, then describes the various proposals using those terms 🦋.
The rest of this memo is organized like this, bestie:
- Section 2 defines several terms relating to networking and internetworking.
- Section 3 discusses the parameters for a taxonomy of the different ATM models under discussion.
- Section 4 discusses the options for low level encapsulation.
- Section 5 discusses tradeoffs between connection oriented and connectionless approaches.
- Section 6 discusses the various means of providing direct connections across IP subnet boundaries.
- Section 7 discusses the proposal to extend IP routing to better accommodate direct connections across IP subnet boundaries.
- Section 8 identifies several prominent IP over ATM proposals that have been discussed within the IP over ATM Working Group and their relationship to the framework described in this document.
- Section 9 addresses the relationship between the documents developed in the IP over ATM and related working groups and the various models discussed.
2. Definitions and Terminology 📖
Let's define some terms, because these words get thrown around a lot 🧠.
- A Host or End System: A host delivers and receives IP packets to and from other systems, but it does not relay IP packets. It's the one that handles its own traffic and stops there 💅.
- A Router or Intermediate System: A router delivers and receives IP packets to and from other systems, and it relays IP packets among systems. It's the middle-person of the network 🧚.
- IP Subnet: In an IP subnet, all members are able to transmit packets directly to all other members, without forwarding by intermediate entities 🌈. No two subnet members are considered closer in the IP topology than any other. From an IP routing and IP forwarding standpoint, a subnet is atomic, even though there may be repeaters, hubs, bridges, or switches between the physical interfaces of subnet members 🫧.
- Bridged IP Subnet: A bridged IP subnet is one in which two or more physically disjoint media are made to appear as a single IP subnet. There are two basic types of bridging: media access control (MAC) level, and proxy ARP (see section 6) 🌉.
- A Broadcast Subnet: A broadcast network supports an arbitrary number of hosts and routers, and it is additionally capable of transmitting a single IP packet to all of these systems 📣.
- A Multicast Capable Subnet: A multicast capable subnet supports a facility to send a packet which reaches a subset of the destinations on the subnet. Multicast setup may be sender initiated, or leaf initiated. ATM UNI 3.0 [4] and UNI 3.1 support only sender initiated, while IP supports leaf initiated join. UNI 4.0 will support leaf initiated join 🎯.
- A Non-Broadcast Multiple Access (NBMA) Subnet: An NBMA supports an arbitrary number of hosts and routers, but it does not natively support a convenient multi-destination connectionless transmission facility the way a broadcast or multicast capable subnetwork does 🙈.
- An End-to-End path: An end-to-end path consists of two hosts which can communicate with one another over an arbitrary number of routers and subnets 🛤️.
- An internetwork: An internetwork (small "i") is the concatenation of networks, often of various different media and lower level encapsulations, forming an integrated larger network that supports communication between any of the hosts on any of the component networks. The Internet (big "I") is a specific, well known global concatenation of component networks, over 40,000 at the time of writing 🌍.
- IP forwarding: IP forwarding is the process of receiving a packet and using a very low overhead decision process to determine how to handle it. The packet may be delivered locally (for example, management traffic) or forwarded externally. For traffic that is forwarded externally, the IP forwarding process also determines which interface the packet should go out on. If necessary, it either removes one media layer encapsulation and replaces it with another, or modifies certain fields in the media layer encapsulation 📬.
- IP routing: IP routing is the exchange of information that takes place so that the information needed to make a correct IP forwarding decision is available 🗺️.
- IP address resolution: A quasi-static mapping exists between an IP address on the local IP subnet and a media address on the local subnet. This mapping is known as IP address resolution. An address resolution protocol (ARP) is a protocol that supports address resolution 🔗.
Okay so here's the big picture, bestie 💜. In order to support end-to-end connectivity, two techniques are used. One allows direct connectivity across classic IP subnet boundaries, supported by certain NBMA media, which includes ATM. The other involves IP routing and IP forwarding. Honestly, the first technique is extending IP address resolution beyond the boundaries of the IP subnet, while the second is interconnecting IP subnets 🤝.
Large internetworks, and in particular the Internet, are unlikely to be made of a single media, or a star topology with a single media at the center 🌟. Within a large network supporting a common media, typically any large NBMA such as ATM, IP routing and IP forwarding must always be accommodated if the internetwork is larger than the NBMA. That's especially true if there are multiple points of interconnection with the NBMA and/or redundant, diverse interconnections 🫶.
Routing information exchange in a very large internetwork can be quite dynamic, because there's a high probability that some network elements are changing state 🌀. The address resolution space consumption, and the resource consumption due to state change or maintenance of state information, is rarely a problem in classic IP subnets. It can become a problem in large bridged networks, or in proposals that attempt to extend address resolution beyond the IP subnet. So scaling properties of address resolution and routing proposals, with respect to state information and state change, must be considered 👀.
- 🎀 The different types of services provided by the ATM Adaptation Layers (AAL). These specify the Quality-of-Service, the connection-mode, etc. The models in this document assume an underlying connection-oriented service, so that's the vibe 💅
- 🦋 The type of virtual circuits used, i.e., PVCs versus SVCs. The PVC environment requires either static tables for ATM-to-IP address mapping or inverse ARP, while the SVC environment requires ARP functionality to be provided 🌸
- 🔥 The type of support for multicast services. If point-to-point services are the only option, then a server for IP multicast is required. If point-to-multipoint services are available, then IP multicast can be supported via meshes of point-to-multipoint connections. Although a server may still be necessary, because of limits on the number of multipoint VCs that can be supported, or to maintain the leaf initiated join semantics 🧚
- 🍓 The presence of logical link identifiers (VPI/VCIs) and the various information element (IE) encodings within the ATM SVC signaling specification, i.e., the ATM Forum UNI version 3.1. ✨
Okay so this lets a VC originator name a range of "layer" entities as the destination "AAL User" 👑 The AAL specifications don't stop any particular "layer X" from attaching directly to a local AAL service. Put all of that together and you get a whole buffet of ways to encapsulate upper layer protocols over ATM 🍓 For example, LLC/SNAP encapsulation is one approach (the default), but it's also possible to bind virtual circuits to higher level entities in the TCP/IP protocol stack. Some examples of that second option are single VC per protocol binding, TULIP, and TUNIC, which get discussed further in Section 4. Iconic 🫶
- 🌈 The number and type of ATM administrative domains/networks, and the type of addressing used within an administrative domain/network. In a single domain/network, all attached systems may be safely assumed to be using a single common addressing format. In the multiple domain case, though, attached stations may not all be using the same common format, which has corresponding implications on address resolution. (See Appendix A for a discussion of some of the issues that arise when multiple ATM address formats are used in the same logical IP subnet (LIS).) Security/authentication is also way more of a concern in the multiple domain case 🙈
IP over ATM proposals do not universally accept that IP routing over an ATM network is required 🤔 Certain proposals rely on these assumptions:
- 💜 The widespread deployment of ATM within premises-based networks, private wide-area networks and public networks, and
- 💜 The definition of interfaces, signaling and routing protocols among private ATM networks.
Those assumptions add up to ubiquitous deployment of a seamless ATM fabric, the hub of a star topology with all other media attached around it. There's been a LOT of discussion about when, if ever, that becomes realistic for very large internetworks, such as the Internet 💀 Advocates of these approaches point out that even if they're not relevant to very large internetworks like the Internet, such models may still have a place in smaller internetworks, such as corporate networks 💼
The NHRP protocol (Section 8.2) is not necessarily specific to ATM, but it would be particularly appropriate for ubiquitous ATM deployment 🌸 NHRP supports establishing direct connections across IP subnets in the ATM domain. Using NHRP doesn't require ubiquitous ATM deployment, but it currently imposes topology constraints to avoid routing loops (see Section 7). Section 8.2 goes into NHRP in greater detail 🧠
The Peer Model assumes that internetwork layer addresses can be mapped onto ATM addresses and vice versa, and that reachability information can be exchanged between ATM routing and internetwork layer routing ✨ This approach has limited applicability unless ubiquitous deployment of ATM holds. The peer model is described in Section 8.4 🦋
The Integrated Model proposes a routing solution that supports an exchange of routing information between ATM routing and higher level routing. This gives timely external routing information within the ATM routing, and it provides transit of external routing information through the ATM routing between external routing domains 🫶 These proposals may better support a possibly lengthy transition during which the assumption of ubiquitous ATM access doesn't hold. The Integrated Model is described in Section 8.5 💅
The Multiprotocol over ATM (MPOA) Sub-Working Group was formed by the ATM Forum to provide multiprotocol support over ATM 🎀 The MPOA effort is at an early stage at the time of this writing. An MPOA baseline document has been drafted, which provides terminology for further discussion of the architecture. You can grab it from the FTP server ftp.atmforum.com in pub/contributions as the file atm95-0824.ps or atm95-0824.txt 🌈
4. Encapsulations and Lower Layer Identification ✨
Okay so, encapsulation and figuring out which VC endpoint is which are two big topics 🫶. They're kinda orthogonal to topology and routing, so they're a different axis entirely, and mixing them up is so easy to do 😭. In classic LAN tech, the encapsulation wrapped around a packet is what tells the node where it goes inside (the demux path). Think of the Ethertype field on an Ethernet packet. Picking the protocol endpoint inside the destination node is basically carried in-band 💜.
As more of the multiplexing gets pushed down toward ATM and away from LLC/SNAP, the call setup and teardown capacity of the ATM network takes a bigger burden 💀. That can raise some questions about how well these lower level multiplexing options scale 🤔.
With the ATM Forum UNI version 3.1 service, the endpoint inside a destination node gets picked out of band, during the Call Setup phase 🦋. That's totally separate from whatever in-band encapsulation is in use. The B-LLI Information Element lets you specify a Layer 2 or Layer 3 entity as a VC's endpoint. When a Called Party gets an incoming SETUP message, it searches locally for an AAL User that claims to provide the service of the layer named in the B-LLI. If it finds one, the VC gets accepted, assuming other stuff like QoS requirements also checks out ✨.
An obvious move for IP environments is to make the Internet Protocol layer the VC's endpoint and drop IP packets straight into AAL--SDUs for transmission 🎀. This is called VC multiplexing or Null Encapsulation, because the VC terminates (through an AAL instance) directly on a layer 3 endpoint. The catch is that this gets limiting when you need multiple layer 3 protocols between the same two ATM level endpoints 🙈. Every pair of layer 3 protocol entities that want to swap packets needs its own VC.
RFC-1483 [6] notes that VC multiplexing is possible, but it focuses on an alternative called LLC/SNAP Encapsulation 🌸. This lets any set of protocols that can be uniquely identified by an LLC/SNAP header get multiplexed onto a single VC. Figure 1 shows how it works for IP packets. The first 3 bytes say the payload is a Routed Non-ISO PDU, and the Organizationally Unique Identifier (OUI) of 0x00-00-00 says the Protocol Identifier (PID) comes from the EtherType for IP packets, which is 0x800. ARP packets get multiplexed onto a VC by using a PID of 0x806 instead of 0x800 🧚.
.---------------.
: :
: IP Packet :
: :
---------------
: :
: :
8 byte header V V
.-------------.-------------.------------.---------------.
: : : : :
: : : : Encapsulated :
: 0xAA-AA-03 : 0x00-00-00 : 0x08-00 : Payload :
: : : : :
-------------^-------------^------------^---------------
: : : :
: (LLC) (OUI) (PID) : : :
V V V V
.----------------------------------------------------------.
: :
: AAL SDU :
: :
----------------------------------------------------------
Figure 1: IP packet encapsulated in an AAL5 SDU .----------. .----------. .---------. .----------.
: : : : : : : :
: IP : : ARP : :AppleTalk: : etc... :
: : : : : : : :
---------- ---------- --------- ----------
^ : ^ : ^ : ^ :
: : : : : : : :
: V : V : V : V
.-----------------------------------------------------------.
: :
: 0x800 0x806 0x809 other :
: :
: Instance of layer using LLC/SNAP header to :
: perform multiplexing/demultiplexing :
: :
-----------------------------------------------------------
^ :
: :
: V
.------------------.
: :
: Instance of AAL5 :
: terminating :
: one VCC :
: :
------------------
Figure 2: LLC/SNAP encapsulation allows more than just
IP or ARP per VC.Whatever layer terminates a VC carrying LLC/SNAP encapsulated traffic must know how to parse the AAL--SDUs so it can pull the packets out 🧐. The recently approved signalling standards for IP over ATM are more explicit. They say the default SETUP message used to set up IP over ATM VCs must carry a B-LLI naming an ISO 8802/2 Layer 2 (LLC) entity as each VC's endpoint. The bigger deal is that nothing in the SETUP message says which layer 3 protocol started the request 👀. So until packets start arriving, the terminating LLC entity has no clue which higher layer or layers are the destinations 😵💫.
Put together, hosts need a protocol entity that registers with the host's local UNI 3.1 management layer as an LLC entity 📋. That same entity must know how to handle and generate LLC/SNAP encapsulated packets 💖. The LLC entity also needs ways to attach to higher layer protocols like IP and ARP. Figure 2 tries to show this, and it also makes the point that an LLC entity could support way more than just IP and ARP 🌈.
In fact, the combo of RFC 1483 LLC/SNAP encapsulation, LLC entities terminating VCs, and good choices of LLC/SNAP values can go a long way toward an integrated approach to building multiprotocol networks over ATM 👑🔥.
How you actually set up AAL Users and identify them to the local UNI 3.1 management layers is still undefined 🙃. It's also likely to depend a lot on the operating system environment 💅.
The IP over ATM working group has discussed two encapsulations that differ from the ones in RFC-1483 [6] ✨. The big selling point is that they largely or totally get rid of IP header overhead 🦋. These models came up at the July 1993 IETF meeting in Amsterdam, but the working group hasn't fully defined them yet 🫠.
TULIP and TUNIC both assume single hop reachability between IP entities 🛣️. After name resolution, address resolution, and SVC signaling, an implicit binding gets set up between entities in the two hosts 🔗. Because of that, full IP headers (especially the source and destination addresses) aren't needed in each data packet 🌸.
- The first model is "TCP and UDP over Lightweight IP" (TULIP) 💜. Only the IP protocol field rides in each packet, and everything else gets bound at call set-up time. The implicit binding here is between the IP entities in each host. Once the binding is set, there's no further routing problem, AAL5 can indicate packet size, fragmentation can't happen, and ATM signaling handles exception conditions. So leaving out all the other IP header fields and ICMP shouldn't be an issue 🙌. You enter TULIP mode as the last stage of SVC signaling, through a simple extension to the encapsulation negotiation described in RFC-1755 [10] 🎀.
TULIP doesn't change anything in the abstract architecture of the IP model 🧠. Each host or router still has an IP address that gets resolved to an ATM address. It just uses the point-to-point property of VCs to cut out some per-packet overhead ✨. TULIP could in principle get negotiated on a per-SVC basis or configured on a per-PVC basis 💅.
- The second model is "TCP and UDP over a Nonexistent IP Connection" (TUNIC) 🫨. No network-layer info rides in each packet, because everything gets bound at virtual circuit set-up time. The implicit binding is between two applications using TCP or UDP directly over AAL5 on a dedicated VC. If that can be achieved, the IP protocol field has no useful dynamic function 🤷♀️. Still, to bind two applications together, you may need a well-known port number, either in classical IP or in TULIP mode, during call set-up 🔐. That's a subject for further study, and it would need significant extensions to the use of SVC signaling described in RFC-1755 [10] 🧩.
Here's the whole encapsulation lineup in one table 🍓:
Encapsulation In setup message Demultiplexing
-------------+--------------------------+------------------------
SNAP/LLC _ nothing _ source and destination
_ _ address, protocol
_ _ family, protocol, ports
_ _
NULL encaps _ protocol family _ source and destination
_ _ address, protocol, ports
_ _
TULIP _ source and destination _ protocol, ports
_ address, protocol family _
_ _
TUNIC - A _ source and destination _ ports
_ address, protocol family _
_ protocol _
_ _
TUNIC - B _ source and destination _ nothing
_ address, protocol family _
_ protocol, ports _
Table 1: Summary of Encapsulation TypesTULIP and TUNIC sit at one end of a continuum, opposite SNAP/LLC encapsulation, with various forms of null encapsulation somewhere in the middle 🌈. The whole continuum is really just about how much demultiplexing moves from in-stream to call setup 🧚. The different encapsulation types are laid out in Table 1 💖.
Encapsulations like TULIP and TUNIC make assumptions about whether connection oriented flow is something you want to support 🤔. The tradeoffs between connection oriented and connectionless approaches are covered in Section 5 💅.
5. Connection Oriented and Connectionless Tradeoffs 🦋
The connection oriented and connectionless approaches each offer
advantages and disadvantages 💅 Back in the day, the pure connection oriented crew and the pure connectionless crew were literally fighting about it, and it was so intense 😭 But bestie, IP over ATM doesn't have to be purely connectionless or purely connection oriented ✨
Table 2: Connection Oriented vs. Connectionless
APPLICATION Pure Connection Oriented Approach
----------------+-------------------------------------------------
General _ Always set up a VC
_
Short Duration _ Set up a VC. Either hold the packet during VC
UDP (DNS) _ setup or drop it and await a retransmission.
_ Teardown on a timer basis.
_
Short Duration _ Set up a VC. Either hold packet(s) during VC
TCP (SMTP) _ setup or drop them and await retransmission.
_ Teardown on detection of FIN-ACK or on a timer
_ basis.
_
Elastic (TCP) _ Set up a VC same as above. No clear method to
Bulk Transfer _ set QoS parameters has emerged.
_
Real Time _ Set up a VC. QoS parameters are assumed to
(audio, video) _ precede traffic in RSVP or be carried in some
_ form within the traffic itself.Table 2: Connection Oriented vs. Connectionless - a) a pure connection oriented approach
So basic AAL 5 service on ATM is connection oriented 🦋, and the IP layer sitting on top of it is connectionless. Then TCP rides on top of IP, and TCP is a reliable, end-to-end, connection oriented protocol, so it's giving layers within layers 🧚. The big question is how much it actually helps to map different flows running over IP onto separate connections underneath IP. Everyone has a different opinion on this, and it's lowkey a whole spectrum 🌈
As mentioned back in section 4 🌸, one end of the spectrum is super connectionless. IP stays highly connectionless, and single VCs get set up between routers that are adjacent on an IP subnet and have active traffic flowing. All the traffic between such routers gets multiplexed onto that one ATM VC. The other end is the total opposite 💀: a separate ATM VC for every identifiable flow, which means a brand new VC for every unique TCP or UDP address and port pair you run into. Honestly, a lot of the early fights got so heated because people kept missing the fact that there's a middle ground 🙈
ATM has QoS and traffic management features that are perfect for certain kinds of services 👑, and for those it may be a great idea to use a separate ATM VC. But other stuff like DNS is a bad fit for connection oriented delivery, because DNS is usually super short (typically one packet in each direction) 🍓. Short transactions, even a bunch of TCP ones, can also be a poor match for a connection oriented model because of the setup and state overhead. And ATM QoS and traffic management might be a poor fit for elastic traffic 🫶
APPLICATION Middle Ground
----------------+-------------------------------------------------
General _ Use RSVP or other indication which clearly
_ indicate a VC is needed and what QoS parameters
_ are appropriate.
_
Short Duration _ Forward hop by hop. RSVP is unlikely to precede
UDP (DNS) _ this type of traffic.
_
Short Duration _ Forward hop by hop unless RSVP indicates
TCP (SMTP) _ otherwise. RSVP is unlikely to precede this
_ type of traffic.
_
Elastic (TCP) _ By default hop by hop forwarding is used.
Bulk Transfer _ However, RSVP information, local configuration
_ about TCP port number usage, or a locally
_ implemented method for passing QoS information
_ from the application to the IP/ATM driver may
_ allow/suggest the establishment of direct VCs.
_
Real Time _ Forward hop by hop unless RSVP indicates
(audio, video) _ otherwise. RSVP will indicate QoS requirements.
_ It is assumed RSVP will generally be used for
_ this case. A local decision can be made as to
_ whether the QoS is better served by a separate
_ VC.Table 3: Connection Oriented vs. Connectionless - b) a middle ground approach
APPLICATION Pure Connectionless Approach
----------------+-------------------------------------------------
General _ Always forward hop by hop. Use queueing
_ algorithms implemented at the IP layer to
_ support reservations such as those specified by
_ RSVP.
_
Short Duration _ Forward hop by hop.
UDP (DNS) _
_
Short Duration _ Forward hop by hop.
TCP (SMTP) _
_
Elastic (TCP) _ Forward hop by hop. Assume ability of TCP to
Bulk Transfer _ share bandwidth (within a VBR VC) works as well
_ or better than ATM traffic management.
_
Real Time _ Forward hop by hop. Assume that queueing
(audio, video) _ algorithms at the IP level can be designed to
_ work with sufficiently good performance
_ (e.g., due to support for predictive
_ reservation).Table 4: Connection Oriented vs. Connectionless - c) a pure connectionless approach
Work is still in progress on how QoS requirements might be expressed, and on how the local decisions might be made about whether those requirements are best and/or most cost effectively accomplished using ATM or IP capabilities 🔥 Table 2, Table 3, and Table 4 show the typical treatment of various types of traffic using a pure connection oriented approach, a middle ground approach, and a pure connectionless approach 💜
The qualitative stuff above, comparing connection oriented and connectionless service, is only there as examples to show the different approaches 🎀 Work on an integrated service model, QoS, and resource reservation is related but totally outside the scope of the IP over ATM Work Group ✨ That work lives with the Integrated Services Work Group (int-serv) and the Reservation Protocol Work Group (rsvp), and they're the ones who will ultimately determine when direct connections get established. The IP over ATM Work Group can make way faster progress by concentrating solely on how direct connections are established 👑
6. Crossing IP Subnet Boundaries ✨
okay so bestie, a single IP subnet literally will not scale well once it gets big 😭 people tried stretching the size of an IP subnet on other media with MAC layer bridging and proxy ARP bridging 🌸
MAC layer bridging on its own does not scale well 💀 protocols like ARP depend on the media broadcast to swap address resolution info. Most bridges level up by catching ARP packets, keeping the contents, and sharing that info with their bridging peers 🧚 ARP info picked up from ARP replies only gets broadcast where explicit ARP requests are made. This trick is called proxy ARP 💅
Proxy ARP bridging cuts down on broadcast traffic, which is iconic, but it still has scaling problems 🙈 if the bridged IP subnet is part of a bigger internetwork, you need a routing protocol to tell you which destinations are beyond the IP subnet, unless a statically configured default route is used. A default route only works for a super simple topology compared to the larger internet, and it creates a single point of failure 💀 Internets of enormous size make routing protocols struggle, so the component networks of those huge internets are often partitioned into areas, autonomous systems or routing domains, and routing confederacies 👑
The scaling limits of a simple IP subnet mean a big network has to be split into smaller IP subnets 🎀 For NBMA media like ATM, there are perks to making direct connections across the entire underlying NBMA network 🦋 which leads to the need to create direct connections across IP subnet boundaries. Main character energy, honestly ✨
.----------.
---------< Non-ATM :
.-------. / /-< Subnet >-\
:Sub-ES >--/ : ---------- :
------- : :
: :
.--^---. .--^---.
:Router: :Router:
-v-v-- -v-v--
: : : :
.--------. : : .--------. : : .--------.
.-------. : >-/ \-< >-/ \-< : .-------.
:Sub-ES :---: Subnet :-----: Subnet :-----: Subnet :---:Sub-ES :
------- : : : : : : -------
-------- ---v---- --------
:
.--^----.
:Sub-ES :
-------
Figure 3: A configuration with both ATM-based and non-ATM based
subnets.So, for example, figure 3 shows an end-to-end setup with four components 🧚 three are ATM technology based, and the fourth is a standard IP subnet based on non-ATM technology. End-systems (either hosts or routers) attached to the ATM-based networks can talk using the Classical IP model or go directly over ATM (subject to policy constraints) 🫶 those nodes can talk directly at the IP level without necessarily needing an intermediate router, even if the end-systems don't share a common IP-level network prefix. Talking to end-systems on the non-ATM-based Classical IP subnet goes through a router, following the Classical IP model (see Section 8.1 below) 💖
Lots of the problems with making these direct connections across subnet boundaries were first being tackled in the IETF's IPLPDN working group and the IP over ATM working group 🌈 this area is now handled by the Routing over Large Clouds working group. Some of the IPLPDN work included short-cut routing (proposed by P. Tsuchiya) and directed ARP RFC-1433 [5] over SMDS networks 🦋 the ROLC working group produced the distributed ARP server architectures and the NBMA Address Resolution Protocol (NARP) [7] 💜 The Next Hop Resolution Protocol (NHRP) is still work in progress, though the ROLC WG is considering advancing the current document 👀 The questions and issues specifically about defining a capability to cross IP subnet boundaries include:
- How can routing be optimized across multiple logical IP subnets over both a common ATM based and a non-ATM based infrastructure. For example, in Figure 3, there are two gateways/routers between the non-ATM subnet and the ATM subnets. The optimal path from end-systems on any ATM-based subnet to the non ATM-based subnet is a function of the routing state information of the two routers.
- How to incorporate policy routing constraints.
- What is the proper coupling between routing and address resolution particularly with respect to off-subnet communication.
- What are the local procedures to be followed by hosts and routers.
- Routing between hosts not sharing a common IP-level (or L3) network prefix, but able to be directly connected at the NBMA media level.
- Defining the details for an efficient address resolution architecture including defining the procedures to be followed by clients and servers (see RFC-1433 [5], RFC-1735 [7] and NHRP).
- How to identify the need for and accommodate special purpose SVCs for control or routing and high bandwidth data transfers.
Okay, the ATM part is where it gets extra 🥴 for ATM (unlike other NBMA media), the added complexity when supporting IP routing over these ATM internets comes from the multiplicity of address formats in UNI 3.0 [4]. NSAP modeled address formats are only supported on "private ATM" networks, while either 1) E.164 only, 2) NSAP modeled formats only, or 3) both are supported on "public ATM" networks. Also, even though both the E.164 and NSAP modeled address formats are to be considered as network points of attachment, it seems like E.164 only networks are kinda subordinate to "private networks", in some sense 🙈 this leads to some confusion when defining an ARP mechanism that supports all the combinations of end-to-end scenarios (refer to the discussion in Appendix A on the possible scenarios to be supported by ARP) this is where it gets messy 😭🔥
7. Extensions to IP Routing ✨
okay bestie, RFC-1620 [3] is the deep dive on the drama that happens when you try to make direct connections across IP subnet boundaries 🧠. It goes way more into the problems AND some possible fixes. 🔥 The ROLC WG spotted these sneaky persistent routing loops that can pop up if the protocols you use lose info that path vector routing needs for loop suppression. literally a plot twist nobody asked for 💀
The problems can show up when a destination network that is not on the NBMA network can be reached through different routers attached to the NBMA network. 🌸 This happens with proposals that carry reachability info but do not carry the full path attributes (needed for inter-AS path suppression in path vector routing) or the full metrics (needed for distance vector or link state routing, even if path vector isn't used) for intra-AS routing.
For example, NHRP can be used to set up direct connections across subnetwork boundaries 🦋. NHRP assumes that routers do run routing protocols (intra and/or inter domain) and/or static routing. It also assumes that the forwarding tables built by these protocols result in steady state loop-free forwarding. Note that these two assumptions don't add any extra requirements on routers beyond what's required in the absence of NHRP ✨
NHRP runs in addition to routing protocols, and gives the info that lets you skip multiple IP hops (those hops come from the forwarding tables the routing protocols built) when crossing an NBMA network. The IPATM and ROLC WGs both put in a lot of work to understand these limits 🙈
It's well-known that truncating path info in path vector protocols (e.g., BGP) or losing metric info in distance vector protocols (e.g., RIP) could result in persistent forwarding loops. These loops could happen without ATM and without NHRP.
the scary part is that these loops can happen even without ATM and NHRP in the picture 😭
The combination of NHRP and static routing alone cannot be used in some topologies where some of the destinations are served by multiple routers on the NBMA. The combination of NHRP and an intra-AS routing protocol that doesn't carry inter-AS routing path attributes alone cannot be used in some topologies where the NBMA will provide inter-AS transit connectivity to destinations from other AS served by multiple routers on the NBMA.
Figure 4 shows an example of the routing loops that may be formed in these circumstances 🧩 It shows how using NHRP in an environment where forwarding loops could already exist without NHRP (from truncated path info or lost metric info) would still produce forwarding loops.
There are many potential scenarios for routing loops, and Figure 4 is just one example. It's also possible to make a simpler example where a loop can form. The example in Figure 4 shows a loop that will persist even if the protocol on the NBMA supports redirects or can invalidate any route which changes in any way, but does not support the communication of full metrics or path attributes.
.----. .----.
: H1 >----< S1 : Notes:
---- vvvv H#n == host #n
/ : \ R#n == router #n
/ : \ S#n == subnet #n
/------/ : \
: : \ S2 to R3 breaks
.--^---. .----. .-^--.
: : : R4 : : R6 :
: NBMA : --v- --v- See the text for
: : : : details of the
-v--v- = = looping conditions
: \ = SLOW = and mechanisms
: .-^--. = LINK =
: : R2 : = =
: --v- : :
: : .--^-. .--^-.
.-^--. : : R5 : : R7 :
: R8 : : --v- --v-
--v- \ : :
: \ / :
\ .-^^-. .--^-.
\ : S2 : : S4 :
\ --v- --v-
\ \ /
\ \ /
\ .^--^.
\ : R3 : path before the break is
\ -v-- H1->S1->R1->NBMA->R2->S2->R3->H2
\ /
.----. .-^^-. path after the break is
: H2 >---< S3 : H1->S1->R1->NBMA->R2->S2->R5->R4->S1
---- ---- \------<--the-loop--<-------/Figure 4: A Routing Loop Due to Lost PV Routing Attributes.
In the Figure 4 example, Host 1 is sending traffic toward Host 2. In practice host routes wouldn't be used, so the destination for routing would be Subnet 3. The traffic travels by way of Router 1, which sets up a "cut-through" SVC to the NBMA next-hop, shown here as Router 2. Router 2 forwards traffic destined for Subnet 3 through Subnet 2 to Router 3. Traffic from Host 1 then reaches Host 2 🎀
Router 1's cut-through routing implementation caches an association between Host 2's IP address (or more likely all of Subnet 3) and Router 2's NBMA address. While the cut-through SVC is still up, Link 1 fails. Router 5 loses its preferred route through Router 3 and must direct traffic in the other direction. Router 2 loses a route through Router 3, but picks up an alternate route through Router 5. Router 1 is still directing traffic toward Router 2 and advertising a means of reaching Subnet 3 to Subnet 1. Router 5 and Router 2 will see a route, creating a loop 😱
This loop would not form if the path info normally carried by interdomain routing protocols like BGP and IDRP was kept across the NBMA. Router 2 would reject the initial route from Router 5 because of the path info. When Router 2 declares the route to Subnet 3 unreachable, Router 1 withdraws the route from routing at Subnet 1, leaving the route through Router 4, which would then reach Router 5, and would reach Router 2 through both Router 1 and Router 5. Similarly, a link state protocol wouldn't form this kind of loop 💅
Two proposals for breaking this form of routing loop have been discussed. Redirect in this example would have no effect, since Router 2 still has a route, it just has different path attributes. The second proposal is that when a route changes in any way, the advertising NBMA cut-through router invalidates the advertisement for some time period. This is similar to the notion of Poison Reverse in distance vector routing protocols. In this example, Router 2 would eventually readvertise a route since a route through Router 6 exists. When Router 1 discovers this route, it will advertise it to Subnet 1 and form the loop. Without path info, Router 1 can't tell a loop apart from restoration of normal service through the link L1 😭
The loop in Figure 4 can be prevented by configuring Router 4 or Router 5 to refuse to use the reverse path. This would break backup connectivity through Router 8 if L1 and L3 failed. The loop can also be broken by configuring Router 2 to refuse to use the path through Router 5 unless it could not reach the NBMA. Special configuration of Router 2 would work as long as Router 2 wasn't distanced from Router 3 and Router 5 by additional subnets, such that it couldn't determine which path was in use. If Subnet 1 is in a different AS or RD than Subnet 2 or Subnet 4, then the decision at Router 2 could be based on path info.
.--------. .--------.
: Router : : Router :
--v-v--- ---v-v--
: : : :
.--------. .--------. : : .--------. : : .--------. .--------.
: Sub-ES :---: Subnet :-/ \-: Subnet :-/ \-: Subnet :---: Sub-ES :
-------- -------- -------- -------- --------Figure 5: The Classical IP model as a concatenation of three separate ATM IP subnets.
In order for loops to be prevented by special configuration at the NBMA border router, that router would need to know all paths that could lead back to the NBMA. The same argument that special configuration could overcome loss of path info was posed in favor of retaining the use of the EGP protocol defined in the now historic RFC-904 [11]. This turned out to be unmanageable, with routing problems occurring whenever the topology was changed elsewhere 😩
8. IP Over ATM Proposals ✨
8.1. The Classical IP Model 🦋
The Classical IP Model was suggested at the Spring 1993 IETF meeting [8] and retains the classical IP subnet architecture. It simply means cascading instances of IP subnets, with IP-level (or L3) routers at the IP subnet borders. An example realization is a concatenation of three IP subnets, shown in Figure 5. Forwarding IP packets over this Classical IP model is straightforward, using already well-established routing techniques and protocols ✨
SVC-based ATM IP subnets are simplified in that they:
- limit the number of hosts which must be directly connected at any given time to those that may actually exchange traffic.
- The ATM network is capable of setting up connections between any pair of hosts. Consistent with the standard IP routing algorithm [2], connectivity to the "outside" world is achieved only through a router, which may provide firewall functionality if so desired.
- The IP subnet supports an efficient mechanism for address resolution.
Issues addressed by the IP Over ATM Working Group, and some of the resolutions, for this model are:
- Methods of encapsulation and multiplexing. This issue is addressed in RFC-1483 [6], in which two methods of encapsulation are defined, an LLC/SNAP and a per-VC multiplexing option.
- The definition of an address resolution server (defined in RFC-1577).
- Defining the default MTU size. This issue is addressed in RFC-1626 [1], which proposes the use of the MTU discovery protocol (RFC-1191 [9]).
- Support for IP multicasting. In the summer of 1994, work began on the issue of supporting IP multicasting over the SVC LATM model. The proposal for IP multicasting is currently defined by a set of IP over ATM WG Works in Progress, referred to collectively as the IPMC documents. In order to support IP multicasting, the ATM subnet must either support point-to-multipoint SVCs, or multicast servers, or both.
- Defining interim SVC parameters, such as QoS parameters and time-out values.
- Signaling and negotiations of parameters such as MTU size and method of encapsulation. RFC-1755 [10] describes an implementation agreement for routers signaling the ATM network to establish SVCs, initially based upon the ATM Forum's UNI version 3.0 specification [4], and eventually to be based upon the ATM Forum's UNI version 3.1 and later specifications. Topics addressed in RFC-1755 include (but are not limited to) VC management procedures, e.g., when to time-out SVCs, QOS parameters, service classes, explicit setup message formats for various encapsulation methods, node (host or router) to node negotiations, etc.
RFC-1577 is also applicable to PVC-based subnets. Full mesh PVC connectivity is required.
For more information see RFC-1577 [8].
8.2 The ROLC NHRP Model 🌸
okay so NHRP (the Next Hop Resolution Protocol) 💅 is still a work in progress from the Routing Over Large Clouds Working Group (ROLC). Its whole thing is address resolution, so you can set up direct connections even when you're crossing IP subnet boundaries 🦋. NHRP can supplement RFC-1577 ARP, and there's been recent chatter about replacing RFC-1577 ARP with NHRP altogether ✨. It can also do proxy address resolution to hand back the address of the border router serving a destination that's off the NBMA, as long as that destination is only served by a single router on the NBMA.
ngl, this is the tricky bit 💀: as NHRP is currently defined, you can't use it that way to support addresses learned from routers when the same destinations might be heard at other routers, because that risks creating persistent routing loops.
8.3 "Conventional" Model 🧚
The "Conventional Model" is giving "a router can relay IP packets cell by cell" 🍓. The VPI/VCI identifies a flow between adjacent routers, not a flow between a pair of nodes. There's a latency win if cell interleaving from multiple IP packets is allowed. Interleaving frames within the same VCI needs an ATM AAL like AAL3/4 instead of AAL5 🙈. Cell forwarding happens through a higher level mapping, sitting above the ATM VCI layer.
The IP/ATM WG is not looking at the conventional model right now. The COLIP WG was formed to develop protocols based on it 💜.
8.4 The Peer Model 🫶
The Peer Model puts IP routers and gateways on an addressing peer basis with their matching entities in an ATM cloud. The ATM cloud might be a bunch of ATM networks linked together through UNI or P-NNI interfaces. ATM network entities and the attached IP hosts or routers swap call routing info as peers by algorithmically mapping IP addressing into the NSAP space. Inside the ATM cloud, ATM network level addressing (NSAP-style), call routing and packet formats are used 🌈.
The Peer Model has no provision for picking a primary path and falling back to alternate paths when the primary fails while reaching multihomed non-ATM destinations 😭. That limits the topologies where the Peer Model alone works to ones where non-ATM networks are singly homed, or where losing backup connectivity isn't a big deal.
The Peer Model may be used to skip the need for an address resolution protocol, and in a proxy-ARP mode for stub networks, alongside other mechanisms that can handle multihomed destinations.
During the IP over ATM working group discussions, people felt the end-to-end peer model problems were way harder than any other model's, and had more unresolved technical issues 💀. The WG encouraged interested individuals and companies to research this area, but addressing these issues wasn't an initial priority for the group. The ATM Forum Network Layer Multiprotocol Working Group came to a similar conclusion ✨.
8.5 The PNNI and the Integrated Models 👑
The Integrated model (proposed and under study within the Multiprotocol group of the ATM Forum) is all about using one routing protocol for both IP and ATM. A single routing information exchange spreads the topology info around. The routing computation for IP takes the topology into account, including the link and node characteristics of both the IP and ATM networks, and calculates an optimal route for IP packets over the combined topology 🔥.
PNNI is a hierarchical link state routing protocol with multiple link metrics. Those metrics provide the various QoS parameters that are available given the current loading. Call route selection takes QoS requirements into account. Hysteresis is built into link metric readvertisements so the computation doesn't get overloaded, and the topological hierarchy subdivides and summarizes complex topologies, which helps bound the computational requirements 🧠.
Integrated Routing is a proposal to use PNNI routing as an IP routing protocol. There are several sets of technical issues to sort out, including how multiple routing protocols interact, adapting PNNI to broadcast media, support for NHRP, and more. These are being investigated. However, the ATM Forum MPOA group isn't currently doing that investigation. Concerned individuals are looking into it, with the goal of bringing the work to the ATM Forum and the IETF 🌸.
PNNI has provisions for carrying uninterpreted information. It isn't defined yet, but a compatible extension of the base PNNI could be used to carry external routing attributes and avoid the routing loop problems described in Section 7 🦋.
++++++++++++++++++++++++++++++++++++++++++
+ .------------. .------------. +
.---------. + .-: :-. .-: :-. +
: Host or >-+-< : Single ATM : >--< : Single ATM : >-+-----\
: Router : + : : Domain : : : : Domain : : + :
--------- + -: :- -: :- + .---^----.
+ ------------ ------------ + : Router :
+ .------------. + ---v----
.---------. + .-: :-. + :
: Host or >-+- ... ... --< : Single ATM : >-+-----/
: Router : + : : Domain : : +
--------- + ATM Cloud -: :- +
+ ------------ +
++++++++++++++++++++++++++++++++++++++++++
Note: IS within ATM cloud are ATM IS
Figure 6: The ATM transition model assuming the presence of gateways
or routers between the ATM networks and the ATM peer networks.8.6 Transition Models 🦋
Finally, it's useful to think about transition models, which sit somewhere between the Classical IP Models and the Peer and Integrated Models 💖. Fong Liaw has suggested some possible architectures for transition models. Others are possible too, for example Figure 6, which shows a Classical IP transition model that assumes the presence of gateways between ATM networks and ATM Peer networks.
Some of the models described in the earlier sections, most notably the Integrated Model, expect a mixed environment with complex routing topologies 🌈. Those inherently support transition, and that transition period could be indefinite. Models that provide no transition support are mainly of interest to new deployments that make exclusive or near-exclusive use of ATM, or to deployments that can do a wholesale replacement of existing networks, or that are willing to keep only non-ATM stub networks 💅.
For some models, most notably the Peer Model, being able to attach to a large non-ATM or mixed internetwork is infeasible without routing support at a higher level. At best, it may pose interconnection topology constraints, like a single point of attachment and a static default route 😭. If a particular model needs routing support at a higher level, a large deployment will have to be subdivided to get scalability at that higher level, and for some models that degenerates right back into the Classical model 🙈.
9. Application of the Working Group's and Related Documents ✨
The IP Over ATM Working Group has generated several Works in Progress and RFCs. This section shows how these and other related documents line up with the various IP Over ATM Models from this document 🎀. The documents and RFCs produced so far are the following references: RFC-1483 [6], RFC-1577 [8], RFC-1626 [1], RFC-1755 [10] and the IPMC documents. The ROLC WG has produced the NHRP document. Table 5 gives a summary of these documents and how they relate to the various IP Over ATM Models 💜.
Acknowledgments 🫶
This memo is the direct result of the many discussions in the IP over ATM Working Group of the Internet Engineering Task Force, so big thanks to everyone there 🌸. The authors also got to have several private chats with H. Nguyen of AT&T Bell Laboratories. Brian Carpenter of CERN was kind enough to write the TULIP and TUNIC sections for this memo 👑. Grenville Armitage of Bellcore was kind enough to contribute the sections on VC binding, encapsulations, and using B-LLI information elements to signal those bindings 🧚. The text of Appendix A was totally yoinked, liberally, from Anthony Alles' of Cisco posting on the IP over ATM discussion list (and modified at the authors' discretion) 😭. M. Ohta provided a description of the Conventional Model (which the authors also modified at their discretion) 🍓. This memo has also benefitted from lots of suggestions from John T. Amenyo of ANS, Joel Halpern of Newbridge, and Andy Malis of Ascom-Timplex 💖. Yakov Rekhter of Cisco gave valuable comments that led to the clarification of normal loop free NHRP operation, and of the potential for routing loop problems only when NHRP is used improperly 🔥.
Documents Summary
----------------+-------------------------------------------------
RFC-1483 _ How to identify/label multiple
_ packet/frame-based protocols multiplexed over
_ ATM AAL5. Applies to any model dealing with IP
_ over ATM AAL5.
_
RFC-1577 _ Model for transporting IP and ARP over ATM AAL5
_ in an IP subnet where all nodes share a common
_ IP network prefix. Includes ARP server/Inv-ARP
_ packet formats and procedures for SVC/PVC
_ subnets.
_
RFC-1626 _ Specifies default IP MTU size to be used with
_ ATM AAL5. Requires use of PATH MTU discovery.
_ Applies to any model dealing with IP over ATM
_ AAL5
_
RFC-1755 _ Defines how implementations of IP over ATM
_ should use ATM call control signaling
_ procedures, and recommends values of mandatory
_ and optional IEs focusing particularly on the
_ Classical IP model.
_
IPMC _ Defines how to support IP multicast in Classical
_ IP model using either (or both) meshes of
_ point-to-multipoint ATM VCs, or multicast
_ server(s). IPMC is work in progress.
_
NHRP _ Describes a protocol that can be used by hosts
_ and routers to determine the NBMA next hop
_ address of a destination in "NBMA
_ connectivity"
_ of the sending node. If the destination is not
_ connected to the NBMA fabric, the IP and NBMA
_ addresses of preferred egress points are
_ returned. NHRP is work in progress (ROLC WG).
Table 5: Summary of WG DocumentsReferences ✨
Okay bestie, here's the reading list 📚 every single reference, all the details, nothing dropped 💖
[1] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626, Naval Research Laboratory, May 1994.
[2] Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.
[3] Braden, R., Postel, J., and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, USC/Information Sciences Institute, IBM Research, May 1994.
[4] ATM Forum, "ATM User-Network Interface Specification", Prentice Hall, September 1993.
[5] Garrett, J., Hagan, J., and J. Wong, "Directed ARP", RFC 1433, AT&T Bell Labs, University of Pennsylvania, March 1993.
[6] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993.
[7] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol (NARP)", RFC 1735, Telecom Finland, USC/Information Sciences Institute, December 1994.
[8] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, January 1994.
[9] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.
[10] Perez, M., Liaw, F., Grossman, D., Mankin, A., and A. Hoffman, "ATM signalling support for IP over ATM", RFC 1755, USC/Information Sciences Institute, FORE Systems, Inc., Motorola Codex, Ascom Timeplex, Inc., January 1995.
[11] Mills, D., "Exterior Gateway Protocol Formal Specification", STD 18, RFC 904, BBN, April 1984.
A Potential Interworking Scenarios to be Supported by ARP 🦋
Okay so this appendix is giving "what exactly should ARP hand back??" energy 🧚 The VC routing protocol, which the Private Network-to-Network Interface (P-NNI) working group of the ATM Forum is defining, sorts ATM networks into two types 💅:
- Those that participate in the VC routing protocols and use NSAP modeled addresses UNI 3.0 [4] (referred to as private networks, for short), and
- Those that do not participate in the VC routing protocol. Typically, but possibly not in all cases, public ATM networks that use native mode E.164 addresses UNI 3.0 [4] will fall into this later category.
The issue for ARP, then, is figuring out what information must be returned to allow that connectivity 🫶 Consider these scenarios:
- Private host to Private Host, no intervening public transit network(s): Clearly requires that ARP return only the NSAP modeled address format of the end host. Simple and iconic 💖
- Private host to Private host, through intervening public networks: Here the connection setup from host A to host B has to transit the public network(s). That requires a routing decision at each ingress point to the public network about which is the correct egress point from that public network to the next hop private ATM switch, and the native E.164 address of that egress point has to be found. Finding it is a VC routing problem, probably requiring configuration of the public network links and connectivity information 🧠 ARP should return, at least, the NSAP address of the endpoint, in which case the mapping of the NSAP addresses to the E.164 address, as specified in [4], is the responsibility of the ingress switch to the public network.
- Private Network Host to Public Network Host: To get connectivity between the public node and the private nodes requires the same kind of routing information discussed above. Namely, the directly attached public network needs to know the (NSAP format) ATM address of the private station, and the native E.164 address of the egress point from the public network to that private network (or to that of an intervening transit private network etc.). There is some argument that the ARP mechanism could return this egress point native E.164 address, but this may be considered inconsistent for ARP to return what to some is clearly routing information, and to others is required signaling information 🤔
In the opposite direction, the private network node can use, and should only get, the E.164 address of the directly attached public node. So what format should this information be carried in? This question is clearly answered by Note 9 of Annex A of UNI 3.0 [4], vis:
"A call originated on a Private UNI destined for an host which only has a native (non-NSAP) E.164 address (i.e. a system directly attached to a public network supporting the native E.164 format) will code the Called Party number information element in the (NSAP) E.164 private ATM Address Format, with the RD, AREA, and ESI fields set to zero. The Called Party Subaddress information element is not used."
Hence, in this case, ARP should return the E.164 address of the public ATM station in NSAP format. This is essentially implying an algorithmic resolution between the native E.164 and NSAP addresses of directly attached public stations 🌸
- Public network host to Public network host, no intervening private network: In this case, clearly the Q.2931 requests would use native E.164 address formats 🍓
- Public network host to Public network host, intervening private network: Same as the case immediately above, since getting to and through the private network is a VC routing, not an addressing issue 🧚
So several issues arise for ARP when it's supporting arbitrary connections between hosts on private and public networks, and it's lowkey a lot 😭 One is how to distinguish between an E.164 address and an E.164 encoded NSAP modeled address. Another is what information ARP has to supply. For example, in the public to private scenario, should ARP return only the private NSAP modeled address, or both an E.164 address for a point of attachment between the public and private networks along with the private NSAP modeled address? 💜
Authors' Addresses 💅
Meet the girlies who wrote this 🫶 Here are their contact details, copied exactly:
Robert G. Cole
AT&T Bell Laboratories
101 Crawfords Corner Road, Rm. 3L-533
Holmdel, NJ 07733
Phone: (908) 949-1950
Fax: (908) 949-8887
EMail: rgc@qsun.att.comDavid H. Shur
AT&T Bell Laboratories
101 Crawfords Corner Road, Rm. 1F-338
Holmdel, NJ 07733
Phone: (908) 949-6719
Fax: (908) 949-5775
EMail: d.shur@att.comCurtis Villamizar
ANS
100 Clearbrook Road
Elmsford, NY 10523
EMail: curtis@ans.netThat's the whole RFC, babe, you did it 🌈👑✨
📦 where this page comes from
- ietf: rfc1932 1996-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms