Internet Draft
Internet-Draft Arup Acharya, C&C Research Labs, NEC USA
Expiration Date: Rajiv Dighe, C&C Research Labs, NEC USA
January 1998 Furquan Ansari, C&C Research Labs, NEC USA
July 1997
IPSOFACTO: IP Switching Over Fast ATM Cell Transport
<draft-acharya-ipsw-fast-cell-00.txt>
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes a method for mapping IP flows to ATM
switches. No signaling is necessary to setup a path through ATM
switches. Switch controllers run a IP routing protocol and execute IP
forwarding. The Ipsofacto component is responsible for mapping a IP flow
to a switched path. The focus of this document is primarily on switching
IP multicast. Mechanisms for switching unicast flows are also described.
Table of Contents
1. Introduction
2. Basic operation
3. Related Schemes
4. Switch configuration
5. Protocol Independent Multicast-Dense Mode
6. Protocol Independent Multicast-Sparse Mode
7. Switching Unicast flows
7.1 TCP Optimizations
7.2 Fixed Length IP routing tag
7.3 Optimizing Mobile-IP flows
7.4 Aggregation through IP-in-IP encapsulation
7.5 Merging aggregated flows through a
multipoint-to-point tunnel
7.6 Handling Route Changes
Acharya, Dighe, Ansari Expires: January 1998 [Page 1]
8. Conclusions
9. Security Considerations
10. Intellectual Property Considerations
11. Acknowledgments
12. References
13. Authors' Addresses
1. Introduction
IPSOFACTO is a methodology for executing the IP protocol stack
directly on ATM switches. The ATM signaling stack is not used. This
draft describes how IP multicast and unicast may be mapped directly to
ATM switches.
The target scenario consists of (a) a cloud of ATM switches running
the IP protocol stack and optionally, (b) hosts that are directly
connected to this cloud. Each switch in this cloud runs the IP
protocol stack along with an Ipsofacto component for mapping IP flows
to switched paths. The description in this draft assumes
configuration (a).
2. Basic Operation
The basic premise of operation for Ipsofacto is that all unused VCs on a
input port of a switch are mapped to the switch control processor
(Fig. 1).
---------------------
| IP | IPSOFACTO |
---------------------
| Switch Controller |
---------------------
|
| \
/|\ \
/ | \ \_______unused VC=1
Port1 --/-----\--- Port3
----------- | /Switch \ |------------
-/---------\-
__________/ | \
unused VC=1 | |
Port2 | unused VC=1
FIGURE 1
A cell-level switched path for data forwarding is established in the
following way. A sender selects an unused VC on an outgoing link to
forward the first packet of a new flow. This is received by the switch
processor at the downstream end of the link, which then selects
Acharya, Dighe, Ansari Expires: January 1998 [Page 2]
outgoing links based on its IP routing tables, and an unused VC for
each selected link. This first packet is then forwarded by the
processor on the selected outgoing links by picking an unused VC on
each link (Fig. 2).
---------------------
| IP | IPSOFACTO |
---------------------
| Switch Controller |
---------------------
========> (IP forwarding)
Pkt1 | Pkt1
/ | \
/ | \.............unused VC=1
Port1 ---/-------- Port3
-----------| / SWITCH |------------
------ -/---------
| Pkt1.........../ |
----- unused VC=1 |
Port2|
FIGURE 2
Subsequently, the switch processor adds an entry in the VC tables,
<{input port, input VC}, {output port, output VC}>. Following packets
are then switched at the cell level, eliminating the need for
packet-level forwarding at the control processor.
---------------------
| IP | IPSOFACTO |
--------- ||---------
| Switch Controller |
--------- || --------
| ||
| || ADD switched path
| || (port1, VC=1 --> port2, VC=1)
| ||
|----- ||----|
| __\/__|________
-----------| / SWITCH |------------
Port1 |--/---------| Port3
___________________/ |
|
Port2|
FIGURE 3
In contrast to data packets, which are forwarded through a switched
path (following the first packet), a switched path is never created
Acharya, Dighe, Ansari Expires: January 1998 [Page 3]
for IP "control" messages: typically, IP "control" messages will be
sent and received on a predefined "control VC", and will therefore, be
forwarded through the switch processor. As a result of processing
these control messages, a per-flow forwarding state may be established
on the switch processor. Changes in the forwarding state,e.g. pruning
an outgoing interface, is then used to modify the switched path
(e.g. deleting an from the VC tables). When the
forwarding state is removed from the control processor, the
corresponding switched data path is released, by marking the input and
output VCs as unused. For PIM, the "control" packets are distinguished
from data packets, based on protocol number in the IP header. For TCP,
the "control" packets may be decided based on flags in the TCP header
(SYN/FIN). ICMP packets are always forwarded through the control
processor.
When an outgoing VC, that is currently in use, is reclaimed back,
i.e. marked as 'unused', this action is preceded by marking the VC to
be in 'transient' state, sending a RECLAIM message from the upstream
to the downstream node, and waiting for a RECLAIM-ACK in reply. When
the downstream node receives a RECLAIM message, it marks the
corresponding incoming VC as 'unused', responds with a RECLAIM-ACK,
followed by sending RECLAIM messages further downstream. The RECLAIM
message may need to be re-sent if a RECLAIM-ACK is not received within
a specified interval. Once the RECLAIM-ACK is received, the VC is
marked as 'unused' at the upstream node. Note that it may not be
necessary to send a per-VC RECLAIM and RECLAIM-ACK, and instead, a
single RECLAIM and RECLAIM-ACK message may contain multiple VC
numbers; this cuts down the inter-switch control traffic at the
expense of delayed reclamation.
A RECLAIM message is triggered as a result of some protocol action at
the controller, e.g. an outgoing branch of a switched path may be
removed because a PIM "Prune" message was received.
It is not necessary that the RECLAIM is only sent from the upstream to
the downstream node; the downstream node may initiate the RECLAIM as
well.
In this draft, the terms 'marking a VC unused' or 'reclaiming a VC'
implicitly imply that RECLAIM and RECLAIM-ACK message exchange has
been completed.
3. Related Schemes
Unlike MPOA [MPOA], Ipsofacto does not use ATM signaling to setup
switched paths for IP flows. Ipsofacto is similar in spirit to Ipsilon's
IP switching [Ipsilon] [IFMP] and Toshiba's CSR [CSR]. Ipsilon selects
the VC for switching a flow from the downstream node, while CSR
selects the VC at the upstream node. Both use a notification protocol
(IFMP for Ipsilon, FANP [FANP] for CSR) to inform the upstream/
downstream neighbour of the selected VC. Ipsofacto informs the
downstream node of the selected VC implicitly through usage. Other
related proposals include Tag-switching [TAG] and ARIS [ARIS]: both
pre-establish switched paths based on routing information.
Acharya, Dighe, Ansari Expires: January 1998 [Page 4]
4. Switch configuration
Each port of a switch is assigned to be an IP interface. Incoming
cells on all unused VCs are directed to the control processor. When a
packet is received on a unused VC, the incoming VC and port number
information associated with the packet is made available to the
Ipsofacto layer. Ipsofacto layer keeps track of all unused VCs on each
port, and maintains a flow-table which maps a flow to a switched path.
e.g.
---> <{input port, input VC}, list of {output port, out VC} pairs>
The flow-id is constructed from the source/destination IP addresses
and port numbers along with the incoming TTL value on the packet.
Although not strictly necessary, we will assume that there is a
dedicated control VC between neighbouring switches. Typically, the
control VC will be used to forward IP multicast "control" messages
(i.e. PIM packets with protocol number 103) between adjacent switches.
In effect, each switch together with its IP/Ipsofacto layers appears
as a network router to its adjacent switches/hosts.
5. Protocol Operation: Mapping PIM Dense Mode [PIM-DM] flows in Ipsofacto
When there exists no forwarding cache entry at a switch controller for
a multicast flow, the first data packet for that flow will install a
forwarding cache for the flow at the controller, as specified by the
protocol operation for Protocol-Independent-Multicast(Dense Mode).
The VC# and the port number (selected by the upstream switch
controller) on which the data packet is received, is available to
Ipsofacto. Additionally, for each outgoing interface in the newly
created multicast forward cache, Ipsofacto selects an unused VC to
forward the packet to the downstream switch controller. At this time,
it adds an entry in the flow-table, mapping the flow-id to a switched path {, list of