RFC 2098

Toshiba's Router Architecture Extensions for ATM : Overview 🎀

okay bestie, this is RFC 2098 🦋 It was written by Y. Katsube, K. Nagami and H. Esaki, all from the Toshiba R&D Center, and it dropped in February 1997. It's labelled Informational, so it's giving "here's some info" rather than "you must do this" 💅 It's part of the Network Working Group stuff, and it doesn't obsolete or update any other RFC, since none is listed in its header. 🌸

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 💜

Abstract 🌸

This memo describes a new internetworking architecture that makes better use of what ATM is good at 🔥 Normally, IP datagrams travel hop by hop through routers, but in this proposed architecture, datagram assembly/disassembly and IP header processing aren't necessarily done at every individual router. The star of the show is the "Cell Switch Router (CSR)" 👑, a new kind of internetworking equipment that has ATM cell switching abilities on top of normal IP datagram forwarding.

The vibe is that the architecture can give applications high-throughput, low-latency ATM pipes while keeping the current router-based internetworking concept 🧚 It also gives applications specific QoS and bandwidth by working with internetworking-level resource reservation protocols like RSVP ✨

1. Introduction 💖

The Internet is getting bigger in both size and traffic volume, and lots of newer applications need guaranteed bandwidth and QoS instead of best effort 😭 Those changes make the current hop-by-hop datagram forwarding paradigm feel inadequate, which is why people are speeding up their investigations into new internetworking architectures.

There are roughly two distinct approaches that could solve this. One is using ATM to carry IP datagrams. The other is revising IP to support a flow concept and resource reservation. Integrating or interworking these two approaches will be necessary if we want end hosts to get high throughput and QoS-guaranteed internetworking services over any datalink platform, not just ATM 🌈

The new internetworking architecture proposed in this draft is based on the "Cell Switch Router (CSR)", and it has the following properties 🦋

• It makes the best use of ATM's property while retaining current router-based internetworking and routing architecture.
• It takes into account interoperability with future IP that supports flow concept and resource reservations.

Section 2 of this draft explains the background and motivations behind our proposal 🎀 Section 3 gives an overview of the proposed internetworking architecture and several of its remarkable features ⭐ Section 4 discusses control architectures for CSR, which will need to be further investigated 🔍

2. Background and Motivation 🌷

It's considered that the current hop-by-hop best effort datagram forwarding paradigm won't be adequate for a future large-scale Internet that carries a huge amount of traffic with certain QoS requirements 💅 Two major schools of investigation can be seen in the IETF, and their main purpose is to improve the Internet's throughput and QoS. One is to use ATM technology as much as possible. The other is to introduce the concept of resource reservation and flow into IP ✨

1) Utilization of ATM 🦋

Basic properties of ATM, like the necessity of connection setup and the necessity of traffic contract, aren't necessarily a great fit for conventional IP datagram transmission 🙈 But ATM's excellent throughput and delay characteristics let us investigate how to realize IP datagram transmission over ATM. It's giving "worth a try" energy 🔥

A typical internetworking architecture is the "Classical IP Model" [RFC1577]. This model allows direct ATM connectivity only between nodes that share the same IP address prefix. IP datagrams should traverse routers whenever they go beyond IP subnet boundaries, even if their source and destination are in the same ATM cloud 💀 An ATMARP is introduced, and it isn't based on legacy datalink broadcast. Instead, it relies on centralized ATMARP servers. Still, this model doesn't require drastic changes to the legacy internetworking architectures when it comes to the IP datagram forwarding process 🌸 The problem is that it still has limited throughput and large latency compared with what ATM can do, because IP header processing happens at every router. This is going to get more critical when multimedia applications that need much larger bandwidth and lower latency become dominant in the near future 😭

Another internetworking architecture is the "NHRP (Next Hop Resolution Protocol) Model" [NHRP09]. This model aims to resolve the throughput and latency problems of the Classical IP Model and make the best use of ATM 🧚 ATM connections can be directly established from an ingress point to an egress point of an ATM cloud, even when they don't share the same IP address prefix. To make that work, the Next Hop Server [KAT95] is introduced. It can find the egress point of the ATM cloud nearest to a given destination and resolve its ATM address. There is a sort of query/response protocol between the server(s) and clients, and possibly between server and server too 👑 Once the ATM address of a desired egress point is resolved, the client sets up a direct ATM connection to that point through ATM signaling procedures [ATM3.1] 💖

Once a direct ATM connection has been set up this way, IP datagrams don't have to go through hop-by-hop IP processing. They can be transmitted over the direct ATM connection instead. So high throughput and low latency communications become possible even when they go beyond IP subnet boundaries 🌈 That said, having these direct ATM connections doesn't mean legacy routers that interconnect distinct ATM-based IP subnets are gone. Hop-by-hop IP datagram forwarding would still be required in cases like these 🙈

• When you want to transmit IP datagrams before a direct ATM connection from an ingress point to an egress point of the ATM cloud is established
• When you neither require a certain QoS nor transmit a large amount of IP datagrams for some communication
• When the direct ATM connection is not allowed by security or policy reasons

2) IP level resource reservation and flow support 💜

Apart from investigating specific datalink technologies like ATM, resource reservation technologies for desired IP-level flows have been studied and are still under discussion ✨ Typical examples are RSVP [RSVP13] and STII [RFC1819].

RSVP itself isn't a connection-oriented technology, since datagrams can be transmitted regardless of the result of the resource reservation process 🦋 Once a resource reservation process from a receiver (or receivers) to a sender (or senders) is successfully completed, RSVP-capable routers along the path of the flow reserve their resources for datagram forwarding according to the requested flow spec 🔥

STII is regarded as a connection-oriented IP. It requires a connection setup process from a sender to a receiver (or receivers) before any datagrams are transmitted 🎀 STII-capable routers along the path of the requested connection reserve their resources for datagram forwarding according to the flow spec 🌸

Neither RSVP nor STII restricts the underlying datalink networks, since their primary purpose is to let routers give each IP flow the desired forwarding quality by controlling their datagram scheduling rules 🧚 Since various datalink networks will coexist with ATM in the future, these IP-level resource reservation technologies would be necessary to provide an end-to-end IP flow with the desired bandwidth and QoS 👑

Taking this background into consideration, there are several issues we should be aware of, and they're what motivate our proposal 💅

• As of the time of writing, the ATM-specific internetworking architecture proposed does not take into account interoperability with IP-level resource reservation or connection setup protocols. In particular, operating RSVP in the NHRP-based ATM cloud seems to require much effort. RSVP is a soft-state, receiver-oriented protocol with multicast capability as a default, while ATM with NHRP is a hard-state, sender-oriented protocol that doesn't support multicast yet 💀
• Although RSVP- or STII-based routers will provide each IP flow with a desired bandwidth and QoS, they have some native throughput limitations. These come from the processor-based IP forwarding mechanism, compared with the hardware switching mechanism of ATM 😭

The main objective of our proposal is to resolve the issues above 🎀

The proposed internetworking architecture makes the best use of the property of ATM by extending legacy routers to handle future IP features, like flow support and resource reservation, with the help of ATM's cell switching capabilities 🦋

3. Internetworking Architecture Based On the Cell Switch Router (CSR) 🌈

3.1. Overview ✨

The Cell Switch Router (CSR) is a key network element of the proposed internetworking architecture 👑 The CSR provides cell switching functionality on top of conventional IP datagram forwarding. Communications with high throughput and low latency, which are native properties of ATM, become possible by using this cell switching functionality, even when the communications pass through IP subnetwork boundaries 🧚 In an ATM internet made of CSRs, VPI/VCI-based cell switching that bypasses datagram assembly/disassembly and IP header processing is possible at every CSR for communications that suit it (for example, communications that need a certain amount of bandwidth and QoS). At the same time, conventional hop-by-hop datagram forwarding based on the IP header is also possible at every CSR for other conventional communications 💖

By using these cell-level switching capabilities, the CSR can concatenate incoming and outgoing ATM VCs. The concatenation here is controlled outside the ATM cloud (the ATM control/management plane), unlike conventional ATM switch nodes 🙈 That's because the CSR is attached to ATM networks via an ATM-UNI instead of an NNI. By carrying out VPI/VCI concatenations at multiple CSRs one after another, you get ATM-level connectivity made of multiple ATM VCs. Each of those VCs connects adjacent CSRs (or a CSR and hosts/routers). We call this kind of ATM pipe an "ATM Bypass-pipe" 🌸 That's to tell it apart from an "ATM VCC (VC connection)", which is provided by a single ATM datalink cloud through ATM signaling 🔥

Example network configurations based on CSRs are shown in figure 1 🦋 An ATM datalink network may be a large cloud that accommodates multiple IP subnets X, Y and Z. Or, several distinct ATM datalinks may each accommodate a single IP subnet X, Y and Z, respectively. The latter configuration would be the most straightforward for discussing the CSR, but the CSR also applies to the former configuration 👑 On top of that, the CSR would be applicable as a router that interconnects multiple NHRP-based ATM clouds ⭐

Two different kinds of ATM VCs are defined between adjacent CSRs, or between a CSR and ATM-attached hosts/routers 🎀

1) Default-VC 🌷

It's a general-purpose VC used by any communications that select conventional hop-by-hop IP routed paths 💅 All incoming cells received from this VC are assembled into IP datagrams and handled based on their IP headers. VCs set up in the Classical IP Model are classified into this category 🧚

2) Dedicated-VC

okay so Dedicated-VCs are the VIP lane 💅 they get used by specific IP flows, and a flow gets picked out by any combo of stuff like the destination IP address/port, the source IP address/port, or the IPv6 flow label 🦋 Then they can get chained together with other Dedicated-VCs that carry the same flow, and that whole chain becomes an ATM Bypass-pipe for those flows 🎀

Ingress and egress nodes of a Bypass-pipe can be either CSRs or ATM-attached routers/hosts, as long as they all speak a Bypass-pipe control protocol. (we call those "Bypass-capable nodes" 🫶) The intermediate nodes, on the other hand, are gonna be CSRs, because they need to do cell switching AND speak the Bypass-pipe control protocol. no cap, it's a whole job 😭

The route for a Bypass-pipe just follows the IP routing info in each CSR 🗺️ So IP datagrams from source host or router X.1 to destination host or router Z.1 go over X.1 -> CSR1 -> CSR2 -> Z.1, whether the communication is hop-by-hop or on a Bypass-pipe ✨ The routes for the individual Dedicated-VCs that make up the Bypass-pipe X.1 --> Z.1 (X.1 -> CSR1, CSR1 -> CSR2, CSR2 -> Z.1) come from ATM routing protocols like PNNI [PNNI1.0], and they're totally independent of IP level routing. it's giving separation of concerns 👑

Here's how an IP datagram gets sent, step by step:

• The host/router X.1 checks an identifier on each IP datagram. That could be the "destination IP address (prefix)", the "source/destination IP address (prefix) pair", the "destination IP address and port", the "source IP address and Flow label (in IPv6)", and so on 🧚 Based on whichever identifier it uses, it figures out which VC the datagram should go out on.
• The CSR1/2 checks the VPI/VCI value of each incoming cell 👀 If the mapping from the incoming interface/VPI/VCI to an outgoing interface/VPI/VCI is in an ATM routing table, the cell gets forwarded straight to the specified interface through an ATM switch module ⚡ If the mapping isn't in the ATM routing table (or the table says the output interface is an IP module), the cell gets reassembled into an IP datagram and forwarded to an appropriate outgoing interface/VPI/VCI based on the datagram's identifier 💖

Check out the picture 🌈

        IP subnet X           IP subnet Y          IP subnet Z
  <---------------------> <-----------------> <--------------------->

  +-------+ Default  +-------+ Default   +-------+ Default  +-------+
  |       |     -VC  | CSR 1 |     -VC   | CSR 2 |     -VC  |       |
  | Host +=============+   +===============+   +=============+ Host |
  |  X.1 +-------------+++++---------------+++++-------------+  Z.1 |
  |      +-------------+++++---------------+++++-------------+      |
  |      +-------------+++++---------------+++++-------------+      |
  |       |Dedicated |       | Dedicated |       |Dedicated |       |
  +-------+     -VCs +-------+      -VCs +-------+     -VCs +-------+
         <--------------------------------------------------->
                             Bypass-pipe


         Figure 1  Internetworking Architecture based on CSR

---

3.2. Features

the main feature of the CSR-based internetworking architecture is basically the same as the NHRP-based one 🌸 they both give you direct ATM level connectivity across IP subnet boundaries. BUT there are some notable differences in the CSR version, and here they are 👇

1) Relationship between IP routing and ATM routing

okay so in the NHRP model, the egress point of the ATM network gets figured out first, during the next hop resolution phase, using IP level routing info 🧠 Then the actual route for an ATM-VC to that egress point gets picked during ATM connection setup, using ATM level routing info. Both kinds of routing info get calculated based on stuff like network topology and available bandwidth for the big ATM cloud 🌥️ ATM routing is based on PNNI phase1 [PNNI1.0], and IP routing is based on OSPF, BGP, IS-IS, etc. So we have to manage two different routing protocols over the big ATM cloud 😩 until Integtrated-PNNI [IPNNI96] shows up in the future. It takes both the ATM level metric and the IP level metric into account 🙌

In the CSR model, IP level routing picks the egress point of the ATM cloud, AND it also works out the inter-subnet level path to that point, including which CSRs it should pass through 🗺️ ATM level routing only figures out the intra-subnet level path for ATM-VCs (both Dedicated-VC and Default-VC), and only between adjacent nodes (CSRs or ATM-attached hosts/routers) 🎀 Since routing gets split up hierarchically into inter-subnet level (router level) and intra-subnet level (ATM SW level), ATM routing doesn't have to run all over the ATM cloud. It only runs inside each IP subnet, independent of the others. ✨ That means less information for the ATM routing protocol to handle 💅 But heads up, an end-to-end ATM path might not be as optimal as it is in the NHRP model, since in the CSR model the path has to go through routers at subnet boundaries 🥺

2) Dynamic routing and redundancy support

a CSR-based network can change routes for Bypass-pipes dynamically when the related IP level routing info changes 🦋 The Bypass-pipes affected by those routing changes don't have to be torn down or built again from scratch, because the intermediate CSRs related to the IP routing changes can just follow along and change routes for their Bypass-pipes on their own 🫶

Same deal when some error or outage happens in any ATM nodes/links/routers on a Bypass-pipe's route 🚧 The CSRs that notice those errors or outages change routes for the related Bypass-pipes by themselves. honestly, so iconic 👑

3) Interoperability with IP level resource reservation protocols in multicast environments

so the current NHRP spec only assumes NHRP gets used in unicast environments 🙈 That means multicast IP flows still have to be carried hop-by-hop with multicast routers. On top of that, making IP level resource reservation protocols like RSVP work over NHRP environments needs more investigation 🔍

The CSR-based internetworking architecture keeps subnet-by-subnet internetworking for any control protocol sequence 🌈 and it can provide multicast Bypass-pipes without needing any changes to IP multicast over ATM [IPMC96] or to multicast routing techniques. slay 💖 Also, since the CSR can handle RSVP messages (which get sent hop-by-hop), it can provide Bypass-pipes that satisfy QoS requirements through cooperation between RSVP and the Bypass-pipe control protocol ⭐

---

4. Control Architecture for CSR

okay so this section talks through a bunch of issues with the control architecture for the CSR 🧚

4.1. Network Reference Model

to help you follow along with this section, we're assuming the following network reference model 🍓 Source hosts S1 and S2, and destination hosts D1 and D2, are attached to Ethernets, while S3 and D3 are attached to the ATM. Routers R1 and R5 are attached to Ethernets only, while R2, R3 and R4 are attached to the ATM. The ATM datalink for subnet #3 and subnet #4 can be either physically separated datalinks or the same datalink. In other words, R3 can be either a one-port or multi-port router 🫧

   Ether    Ether        ATM          ATM        Ether    Ether
     |        |        +-----+      +-----+        |        |
     |        |        |     |      |     |        |        |
 S1--|   S2---|   S3---|     |      |     |---D3   |---D2   |--D1
     |        |        |     |      |     |        |        |
     |---R1---|---R2---|     |--R3--|     |---R4---|---R5---|
     |        |        |     |      |     |        |        |
     |        |        +-----+      +-----+        |        |
  subnet   subnet      subnet       subnet      subnet   subnet
    #1       #2          #3           #4          #5       #6


                   Figure 2  Network Reference Model

Bypass-pipes can be configured [S3 or R2]-->R3-->[D3 or R4] 🛤️ That means S3, D3, R2, R3 and R4 need to speak the Bypass-pipe control protocol, AND it means R3 has to be the CSR. We use the term "Bypass-capable nodes" for hosts/routers that can speak the Bypass-pipe control protocol but aren't necessarily CSRs 💜

As shown in this reference model, a Bypass-pipe can be configured from host to host (S3-->R3-->D3), router to host (R2-->R3-->D3), host to router (S3-->R3-->R4), and router to router (R2-->R3-->R4) 🎀

4.2. Possible Use of Bypass-pipe

this subsection is about the possible uses (or purposes) of the Bypass-pipe that CSRs provide 🌷 In other words, it covers the possible triggers that kick off the Bypass-pipe setup procedure 🚀

Two purposes for Bypass-pipe setup are assumed at present 💅

a) Provision of low latency path

this is when end hosts or routers start a Bypass-pipe setup procedure because they're about to send a large amount of datagrams toward a specific destination 📦 For instance:

• End hosts or routers start Bypass-pipe setup procedures based on measuring the IP datagrams they've transmitted toward a certain destination 📊
• End hosts or routers start Bypass-pipe setup procedures when they detect datagrams with certain higher layer protocols, such as ftp, nntp, http, etc. 🕵️‍♀️

Other triggers might be possible depending on each network's policy 🤷‍♀️ In any case, the whole point of Bypass-pipe setup in each of these cases is to reduce the IP processing burden at intermediate routers, AND to provide a low latency communication path for burst data transfer 💨 It's not about giving end host applications a specific bandwidth/QoS, though 🙈

ngl this is the part people mix up, so keep it in mind: there's no rule for determining bandwidth for these Bypass-pipes. no explicit bandwidth/QoS requirement from end hosts is available without IP-level resource reservation protocols like RSVP 😭 Using UBR VCs as components of the Bypass-pipe is the easiest choice, even though there are no guarantees for cell loss quality. Using other services like CBR/VBR/ABR with adequate parameter tuning would also be possible 💖

This one's the bandwidth/QoS-request trigger 💅 Routers or end hosts start a Bypass-pipe setup when an IP-level bandwidth/QoS request comes in from an end host. The resource management entity (the bit in the host or router that gets requests from apps or neighbouring nodes) gets to decide: squeeze the requested IP flow into an existing VC, or give it a brand-new Dedicated-VC 🦋. If a router picks the new-VC option, that choice can be the trigger for building a Bypass-pipe. When both the incoming VC and the outgoing VC (or VCs) are dedicated to the same IP flow(s), they can be concatenated at the CSR (ATM cut-through) to form a Bypass-pipe, and that's giving main character energy ✨.

Bandwidth for the Bypass-pipe, meaning the individual VCs that make it up, is based on what the end host asked for, which arrives via something like RSVP messages 📨. The ATM service class (CBR, VBR or ABR, for example) depends on the IP-level service class the end host asked for 🎀.

Here's the timing tea ☕. Setting up for purpose b) will be seriously valuable once the related IP-level resource reservation protocol is actually available, and once the individual service classes and flow specs offered to apps are clearly defined 🔥. Setting up for purpose a), on the other hand, can be useful right now, because it doesn't need any IP-level resource reservation protocol at all 🙌. So a) is the short-term play and b) is the long-term one 💜.

4.3. Variations of Bypass-pipe Control Architecture

There are a bunch of variations on how the Bypass-pipe control architecture can work 🧚. The architectural variations come down to these items:

• Ways of providing Dedicated-VCs
• Channels for Bypass-pipe control message transfer
• Bypass-pipe control procedures

We'll go through each one below, bestie 🫶.

4.3.1. Ways of Providing Dedicated-VCs

Roughly speaking, there are three ways to provide Dedicated-VCs in the individual IP subnets that act as components of a Bypass-pipe 🌸.

a) On-demand SVC setup

Dedicated-VCs get set up in each IP subnet every single time you want a Bypass-pipe through the ATM signaling procedure. Very dynamic, very on-brand 💅.

b) Picking up one from a bunch of (semi-)PVCs

A batch of VCs gets set up ahead of time, either between CSR and CSR, or between CSR and other ATM-attached nodes (hosts/routers) in each IP subnet 🍓. When a Bypass-pipe is needed, an unused VC gets picked up from those PVCs and used as the Dedicated-VC.

c) Picking up one VCI in PVP/SVP

PVPs or SVPs are set up between CSR and CSR, or between CSR and other ATM-attached nodes (hosts/routers) in each IP subnet 🌈. PVPs get set up during router or host initialization, while SVPs get set up through ATM signaling the first time either peer asks for a VC (Default- or Dedicated-) 📡. When a Bypass-pipe is needed, an unused VCI value inside the PVP/SVP gets picked up as the Dedicated-VC. An SVP can be released through ATM signaling once no VCI value on it is active anymore 🦋.

Okay so, which is best? For efficient use of network resources, the top pick is a) 👑. Heads up though: a) takes three steps, namely ATMARP (for unicast [RFC1577] or multicast [IPMC96] in each IP subnet), then SVC setup (in each IP subnet), then an exchange of Bypass-pipe control messages. Whether a) is actually practical depends on whether you can tolerate a longer Bypass-pipe setup time because of that three-step procedure, or whether you can keep sending datagrams hop-by-hop over Default-VCs while you wait for the Bypass-pipe to come up 🙈.

With b) or c), the setup-time issue gets better, because the SVC setup step can be skipped entirely ⚡. With b), every node (CSR or ATM-attached host/router) has to specify some traffic descriptors even for the unused VCs, and the ATM datalink has to reserve the resources it wants for them (like a VCI value and bandwidth) 💖. The ATM datalink may also have to run UPC functions for those unused VCs. That burden drops if you use UBR-PVCs and set each one's peak cell rate equal to the link rate, but then no bandwidth/QoS is provided for the Bypass-pipe 😭. With c), on the other hand, the traffic descriptors each node has to hand the ATM datalink are only for the VP, not for each VC 🧚‍♀️. Resource reservations for individual VCs happen in each CSR or ATM-attached host/router if needed, not inside the ATM datalink. What the ATM datalink does need to provide is control of the VPs' bandwidth only, such as UPC and dynamic bandwidth negotiation, if that becomes widely available 🔥.

4.3.2. Channels for Bypass-pipe Control Message Transfer

There are several options for the channel used to manage a Bypass-pipe, meaning setting it up, releasing it, and possibly changing its route 🛤️. This subsection walks through those options and talks about their properties.

Three options are on the table: Inband control message, Outband control message, and use of ATM signaling.

i) Inband Control Message

When a Bypass-pipe is being set up, control messages travel over a Dedicated-VC, the very VC that will eventually be part of the Bypass-pipe 🎀. These messages get handled at each CSR, and similar messages get sent to the next-hop node over a Dedicated-VC along the route picked from the IP routing table. Unlike the outband message protocol in ii), each message doesn't need to say which Dedicated-VC it's using, because the message is carried over "that" VC itself 💅.

An inband control message can be either a "datagram dedicated for Bypass-pipe control" or an "actual IP datagram" sent by a user application ✨. With the first type, actual IP datagrams can go over the Bypass-pipe once it's set up. With the second type, the first IP datagram (or a few of them) that arrives on an unused Dedicated-VC gets analysed at the IP level and forwarded toward the right next hop over an unused Dedicated-VC. Then the incoming Dedicated-VC and outgoing Dedicated-VC get concatenated to build the Bypass-pipe 🦋.

Here's a catch 🙈. With inband control, Bypass-pipe control messages sent after the Bypass-pipe is up can't be identified at intermediate CSRs, because those messages get forwarded at cell level there. One possible fix is for intermediate CSRs to mark the cell headers so they can spot control messages, for example by using the PTI bit that indicates an F5 OAM cell 🧚. As for releasing a Bypass-pipe, an explicit release message might not be needed at all, if each CSR keeps an eye on the amount of traffic over each Dedicated-VC and deletes the concatenation information for an inactive Bypass-pipe on its own call 💜.

ii) Outband Control Message

When a Bypass-pipe is set up or released, control messages travel over VCs that are different from the Dedicated-VCs that make up the Bypass-pipe 🌷. Unlike the inband message protocol in i), each message has to say which Dedicated-VCs it wants to control. That means a VC needs an identifier that uniquely tells it apart, and that identifier (which is not a VPI/VCI, since a VPI/VCI isn't the same at both endpoints of the VC) has to be defined and handed out during VC initiation 🫶. On the bright side, the issue of control messages being sent after a Bypass-pipe is up doesn't exist with the inband case 🙌.

There are four ways to carry Bypass-pipe control messages hop-by-hop over ATM datalink networks 🍒:

1. Defines VC for Bypass-pipe control messages only.
2. Uses Default-VC and discriminates Bypass-pipe control messages from user datagrams by an LLC/SANP value in RFC1483 encapsulation.
3. Uses Default-VC and discriminates Bypass-pipe control messages from user datagrams by a protocol field value in IP header.
4. Uses Default-VC and discriminates Bypass-pipe control messages from user datagrams by a port ID in the UDP frame.

When you think about interoperability with Bypass-incapable routers, option 1 is not a good pick 🙅‍♀️. Whether you go with option 2, 3 or 4 depends on whether you need to consider multiprotocol traffic rather than IP only 🌸.

For IP multicast, point-to-multipoint VCs in each subnet get concatenated consecutively at CSRs to form an end-to-end multicast tree 🌳. The four options above may need the same number of point-to-multipoint Default-VCs as there are requested point-to-multipoint Dedicated-VCs in the multicast case, which is a lot of VCs 😩. The fifth option, which can cut down the number of VCs needed to carry control messages in a multicast environment, is:

5. Defines point-to-multipoint VC whose leaves are members of multicast group 224.0.0.1. All nodes that are members of at least one active multicast group become leaves of this point-to-multipoint VC 👑.

Each upstream node may become the root of the point-to-multipoint VC, or each upstream node may send cells over a point-to-point VC to a sort of multicast server, which can become the root instead 🧜‍♀️. Either way, Bypass-pipe control messages for every multicast group get sent to all nodes that are members of either group. When a downstream node receives control messages that aren't related to a multicast group it belongs to, it should discard them after checking the destination group address in their IP header 🗑️. A downstream node would still need a point-to-point VC to send control messages back upstream ⬆️.

iii) Use of ATM Signaling Message

If ATM signaling messages can carry the IP addresses (and possibly port IDs) of the source and destination, then ATM signaling messages could also be used as Bypass-pipe control messages 📶. In that case, an ATM connection setup message says it's setting up a Dedicated-VC to the ATM address of the desired next-hop IP node, and it also says it's setting up a Bypass-pipe to the IP address (and possibly port ID) of the target destination node 🎯. The information elements for the Dedicated-VC setup (ATM address of the next-hop node, bandwidth, QoS, and so on) get handled at the ATM nodes. The information elements for the Bypass-pipe setup (source and destination IP addresses, possibly their port IDs, or the flow label for IPv6, and so on) get transferred transparently to the next-hop IP node. That next-hop IP node accepts the Dedicated-VC setup and handles those IP-level information elements 💁‍♀️.

ATM signaling messages can flow from receiver to sender as well as from sender to receiver when you set a zero Forward Cell Rate and a non-zero Backward Cell Rate as the ATM traffic descriptor information element in the unicast case. In the multicast case, the same thing becomes possible once Leaf Initiated Join capabilities become available 🌊.

Issues with this method:

• Information elements that specify IP-level (and port-level) information need to be defined, for example B-HLI or B-UUI, as part of the ATM signaling specification 📝.
• It would be difficult to support soft-state Bypass-pipe control, the kind that sends control messages periodically, because ATM signaling is a hard-state protocol 😵‍💫.

4.3.3. Bypass-pipe Control Procedures

This subsection covers several items about the actual procedures for Bypass-pipe control 🎀. Let's dive in, bestie 💖.

a) Distributed trigger vs. Centralized (restricted) trigger

okay so first up 💅 is whether the job of spotting a trigger for Dedicated-VC/Bypass-pipe control is distributed to all the nodes (CSRs and hosts/edge devices included) or restricted to specific nodes 🎀

in the distributed version, every node is regarded as being able to detect a trigger for Bypass-pipe setup or termination 🦋 for example, every node spots datagrams for ftp and sets up (or fetches) its own Dedicated-VC to build a Bypass-pipe 🧚 once those Dedicated-VCs are set up or fetched, adjacent nodes swap messages that inform (or request) that the IP flow will go over the Dedicated-VC 💜 this lets peer nodes share the same knowledge about which IP flow maps to which Dedicated-VC ✨ the best part is there's no end-to-end message transmission in the Bypass-pipe control procedure itself, just messages between adjacent nodes 🌸

in the centralized (or restricted) version, only nodes sitting at "the boundary of the CSR-cloud" can detect a trigger for Bypass-pipe setup or termination 🍓 for individual IP flows, that boundary means the first-hop or last-hop CSR-capable node 👑 so for example, a node that spots ftp datagrams can only kick off the Bypass-pipe setup procedure when its previous hop is non-ATM or CSR-incapable 🙈 in this case, the Bypass-pipe control messages start at the boundary of the CSR-cloud and get forwarded hop-by-hop toward the other side of the boundary, kinda like ATM signaling messages 🫶 the messages could mean a request for end-to-end Bypass-pipe setup, or a notification or request about the mapping between the IP flow and the Dedicated-VC 🔥

b) Upstream-initiated control vs. Downstream-initiated control

next is whether setting up a Dedicated-VC and the control procedure for building a Bypass-pipe is initiated by the upstream side or the downstream side 🌈

with upstream-initiated control, the upstream node takes the lead when it sets up a Dedicated-VC for a specific IP flow and creates the mapping between that flow and the Dedicated-VC 💖 for example, a CSR that spots ftp datagrams sets up (or fetches) a Dedicated-VC toward its downstream neighbor, then tells that neighbor it's about to send a specific IP flow over the Dedicated-VC 🎀 so the downstream node is asked to receive datagrams from that Dedicated-VC 🦋

with downstream-initiated control, the downstream node takes the lead instead 👑 for example, a CSR that spots ftp datagrams sets up (or fetches) a Dedicated-VC toward its upstream neighbor, and then asks that upstream neighbor to send a specific IP flow over the Dedicated-VC ✨ this means the upstream node is the one being asked to transmit the IP flow over the Dedicated-VC 💅

c) Hard-state management vs. Soft-state management

the last item is whether controlling the Bypass-pipe (setting it up, maintaining it, and releasing it) is based on hard-state or soft-state 🧚

in hard-state management, nodes only send Bypass-pipe control messages when they want to notify or request a change in their neighbors' state 💜 they should wait for an acknowledgement of the message before they change their own internal state 🫶 for example, once a Bypass-pipe is set up, it stays put until either peer sends a message to release it 🔒

in soft-state management, nodes periodically send Bypass-pipe control messages to keep their neighbors' state up to date 🌸 they don't have to wait for an acknowledgement before changing their internal state 🙈 for example, even after a Bypass-pipe is set up, either peer is required to periodically send refresh messages to its neighbor to keep the Bypass-pipe alive 😭🍓

---

5. Security Considerations 🔒

Security issues are not discussed in this memo. 😱 no cap, this is a big gap and nobody should treat it as a green light 💀

---

6. Summary 🎀

okay recap time 🫶 the basic concept of the Cell Switch Router (CSR) gets clarified, and the control architecture for CSR is discussed ✨ there are a bunch of ways to control the Bypass-pipe that will be possible, and each one has its own advantages and disadvantages 🦋 further investigation and discussion will be necessary to design a control protocol that may depend on the requirements from users 👑

---

7. References 📚

• [IPMC96] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
• [ATM3.1] The ATM-Forum, "ATM User-Network Interface Specification, v.3.1", Sept. 1994.
• [RSVP13] Braden, R., et al., "Resource ReSerVation Protocol (RSVP), Version 1 Functional Specification", Work in Progress.
• [IPNNI96] R. Callon, et al., "Issues and Approaches for Integrated PNNI", The ATM Forum Contribution No. 96-0355, April 1996.
• [NHRP09] Luciani, J., et al., "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress.
• [PNNI1.0] The ATM-Forum, "P-NNI Specification Version 1.0", March 1996.
• [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
• [RFC1577] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, October 1993.
• [RFC1819] Delgrossi, L, and L. Berger, "Internet STream Protocol Version 2 (STII) Protocol Specification Version ST2+", RFC 1819, August 1995.

---

8. Authors' Addresses 🧚

Yasuhiro Katsube
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : katsube@isl.rdc.toshiba.co.jp

Ken-ichi Nagami
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : nagami@isl.rdc.toshiba.co.jp

Hiroshi Esaki
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : hiroshi@isl.rdc.toshiba.co.jp