Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-ohta-ip-over-atm-02.txt < prev next >

Wrap

Text File | 1995-03-09 | 23KB | 560 lines

INTERNET DRAFT M. Ohta draft-ohta-ip-over-atm-02.txt Tokyo Institute of Technology H. Esaki K. Nagami Toshiba Corporation March 1995 Conventional IP over ATM 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The possibility to construct a conventional model to transfer IP over ATM is studied. The model contains concepts of subnet, bridges, routers, broadcast and so on, all of which are familiar with the model of IP over Ethernet. Still, the model allows QoS assured seamless internetwork level (not link level) ATM connection which can be directly supported by existing ATM hardware. That is, new communication model with resource reservation such as RSVP or STII can be supported efficiently. Introduction This memo describes a framework of transmitting IP packets over existing ATM hardware without assuming any change to the existing model of transmitting IP over other media. ATM is a good candidate of the platform for very high speed QoS Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 1] INTERNET DRAFT Conventional IP over ATM March 1995 (Quality of Services [RSVP, STII]) assured link layer. But, unlike enthusiastic ATM lovers, the Author does not think ATM will rule the world. On the other hand, the Author believes IP will rule the world, at which time ATM based equipments must cooperate with other media such as Ethernet or something like Ethernet. To make the cooperation smooth, it is better if the model of IP over ATM is no different from the model of IP over Ethernet. Thus, unlike the model of "Classical IP and ARP over ATM" [CLIP], which is modified, non-classical IP technology over PDN-like, classical, ATM, the conventional model trys to keep IP as classical and conventional as possible. The conventional model is designed so that existing ATM hardware can be used as is. Framework difference between the Classical and the Conventional Model The purpose of IP over ATM is to relay data between hosts cell by cell. If a quality requirement is not so severe, routers may relay data packet by packet. But to assure low delay, high throughput communication, cell by cell relaying is strongly desirable. The basic difference between the Classical and the Conventional Model is whether it is assumed that a router can relay data cell by cell or not. The classical model is constructed as follows: A router can not relay data cell by cell. To relay data between hosts cell by cell, both hosts must be placed in a single link layer. To scale the network, it is necessary to place all the hosts in the world in a single link layer. As the link layer of ATM is purely connection oriented, cell by cell relaying must be connection oriented. In such a large link layer, broadcasting is impossible. ARP, DHCP and other protocols must be redesigned not to use broadcast. If packet relaying routers are tolerated, LIS (logical IP subnet) model connected by the routers is possible, which is useful for Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 2] INTERNET DRAFT Conventional IP over ATM March 1995 connectionless communication but may waste resource by not using the optimal path. But, as shown in the section "Connection Oriented QoS Assured Communication over ATM" of this memo, if a proper reservation, or a connection setup, is done in advance, it is perfectly possible to have a router which relays data cell by cell. Thus, the conventional model is constructed as follows: With a proper reservation, a router can relay data cell by cell. To relay data between hosts cell by cell, both hosts may be connected by multiple routers. To scale the network, it is possible to place routers between hosts not to make a single link layer so large. As the reservation is required, cell by cell relaying must be connection oriented. In such a small link layer, broadcasting is perfectly possible. The resulting model is no different from that of the existing Internet, including broadcasting ARP, DHCP and other protocols. If packet relaying routers are tolerated, routers may relay data packet by packet without any prior reservation, which is useful for connectionless communication and is as efficient as the existing Internet for path optimization. Overview of the WAN/LAN model of the Conventional IP While other models of IP over ATM [CLIP, IPATM] assumes PDN like ATM WAN, which somewhat affects ATM LAN model and is a lot different from Ethernet LAN, the conventional model assumes no fundamental difference between Ethernet LAN, ATM LAN and ATM WAN. It seems to the Author that there is common misunderstanding of many ATM experts that cell-by-cell relaying can only be performed at link layer, which make thier model unnatural. The last section shows how internetwork layer cell-by-cell relaying is possible. Just as the current IP LAN over Ethernet and IP WAN are fundamentally same, ATM LAN and ATM WAN of the model are fundamentally same. That is, just as the current T3 backbone, the WAN model of this memo is constructed by leased lines directly connecting IP routers, which Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 3] INTERNET DRAFT Conventional IP over ATM March 1995 directly support IP protocols including routing. Routing packets will be propagated by WAN operators as maintenance packets. When IP rules the world and WAN is IP, there is no cloud. So, ROLC (Routing over Large Cloud) [ROLC] technology is not necessary. See [SMAI] for more details. With the conventional model, just as Ethernet equipments, ATM switches are classified into routers or bridges (or brouters, maybe). whose roles are no different from those of Ethernet equipments. Bridges are link layer entity which connect several physical layers. Bridges copy the incoming packets to all of the output ports without trying to optimize the path. If a bridge is a learning bridge and knows to which interface the destination is attached, unnecessary copying can be suppressed. If a link level topology contains a loop, bridges should support spanning tree algorithm to avoid packets copied infinitely along the loop. Routers are internetwork layer entity which connect several data link layers. Routers relay packets beyond (sub-)networks. Routers exchange routing information and maintains routing tables. Logically, each packet is relayed to the optimal interface by looking up the routing table. Actually, some cache or bypass is often used to minimize the routing delay of complex table looking up. It is not the business of bridges to choose the best path to the destination. Doing so will make the link level layer as complex as the conventional link and internetwork layers added together, which is the destruction of layering. So, to operate a network with a lot of hosts and some amount of redundant pathes, the network should be divided into several link layers connected by routers to make use of the bandwidth of redundant pathes. It is impractical to have a single link layer containing a lot of hosts. As PVC based network needs a lot of link level static configuration, it is difficult to manage and unrealistic for the network with more than hundreds of hosts. As exemplified with broadcast storm, wrong static setting at link level is often fatal. With ATM, if link layer configuration is wrong, cells may loop. It should be noted that on point-to-point links such as ATM, looping of cells is equally harmful as broadcasted looping on multiple access media for the consumed bandwidth of the link. That is, though looping on a single physical link does not affect other physical links, single link layer looping affect several physical links. To make the matter worse, as ATM has no link level hop count, looping will continue forever. So, PVC ATM is not considered in this memo. Communication over ATM in the Link Layer Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 4] INTERNET DRAFT Conventional IP over ATM March 1995 As the conventional model is properly layered, the internetwork layer of the conventional model can cooperate with any link layer which can cooperate with the model of IP over Ethernet or any other medium. Especially, a link layer of classical model with NBMA ARP or even a link layer with pure PVC may co-operate with the internetwork layer of the conventional model. But, as cell by cell relaying over routers is possible, it is much better to construct a broadcast-capable ATM link layer than modifying a lot of existing broadcast-based protocols not to use broadcast. This section discusses the possibility to have such a link layer. Unless a link layer is made of a single physical layer, it is beneficial for bridges to maintain some amount of connection information. With Ethernet, without learning bridges, all the packets are copied to all the physical layers. With learning bridges, as a packet is relayed by bridges, bridges learn from which interfaces the packet is received, which is equivalent to the path setup to the source of the packet. If two hosts exchange packets, a soft connection between the hosts are established as the state of learning bridges. With ATM, things can be no different, though additional support for more rigid connection may present. Such a rigid connection is necessary and useful to assure QoS. If QoS is not necessary, link layer communication may be just like that of Ethernet. To do so, an AAL containing the MAC addresses of the sender and the receiver in the first cell is necessary. ATM bridges then peek into the first cell and learn that the sender is located toward the incoming interface of the cell. Then, if the receiver's location is not learned, cells are broadcasted. Unfortunately, the scheme can not be supported efficiently by the current hardware. Alternative way is to use broadcasted ARP [EARP] followed by signaling to establish SVC between a pair of hosts. As for broadcast, at a physical layer, there is no such thing as NBMA (Non-Broadcast Multi-Access). Regardless of whether the layer is point-to-point or multiple-access, everything a sender sends is received by all the hosts connected to the layer. So, it is not surprising that a link layer attempt to throw way the physical layer property results in serious loss of information necessitating some static configuration [ROLC]. Thus, the conventional wisdom of the conventional IP is to support broadcast at the link layer. It should be noted that, with conventional IP, the Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 5] INTERNET DRAFT Conventional IP over ATM March 1995 size of a well-managed link layer is not so large. So, excessive amount of copying of a broadcast packet does not occur. Ethernet bridges copies broadcast packets to all the interfaces (on the spanning tree). ATM bridges can also do so. Most of existing ATM switches have efficient hardware mechanism of such copying to support point-to-multipoint connections. Moreover, broadcast is the only way to communicate with neighbors without prior knowledge of neighbor's addresses. For example, one of the goals of DHCP (Dynamic Host Configuration Protocol) to make hand configuration completely unnecessary, can not be achieved without broadcast. So, there seems to be no reason not to have broadcast with ATM. This memo merely describe a possible architecture of IP over ATM and does not attempt to propose any standard. So, the detailed mechanism on broadcast with ATM is not discussed further. Conventional Communication over ATM in a Internetwork Layer The conventional communication, that is communication that does not assume connectivity, is no different from that of the existing IP, of course. Communication within a link layer is performed as described in the previous section. Communication beyond link layers is performed by first communicating to a router. Routers exchange routing information and forward packets decrementing TTL by one or more toward the next hop routers. No further explanation is necessary nor given. Though it is possible to reduce hop counts by having ATM connections between non-adjacent routers, it is beyond the scope of the conventional model and not discussed in this memo. Connection Oriented QoS Assured Communication over ATM The goal of connection oriented communication is to provide end-end IP connection. Such a connection is necessary to have QoS-assured communication. Unlike other models of IP over ATM, the model in this memo assumes QoS-assured communication over not only ATM but also other types of media. The model, in general, is not so different from that of the previous section, though seamless optimization is possible for communication between ATM link layers. Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 6] INTERNET DRAFT Conventional IP over ATM March 1995 It is assumed that QoS reservation protocol within a link layer is present and is preformed by hosts (including routers) attached to the layer. How it will be is not addressed in this memo. Communication within a link layer can directly use the link layer QoS reservation protocol and needs no special care. Communication beyond link layers is performed by first establishing QoS assured connection to a neighbor router. Routers then establishes the QoS connection using the link level reservation protocol to the next hop router until the destination is reached. Some processing power of routers should also be reserved. After the connection is established, packets are forwarded through the QoS assured link layer connection. As there can be multiple QoS assured connection between the source and the destination, some identifier other than source/destination addresses is necessary to uniquely identify a connection. A single identifier, called flow ID, could be used along the connection. The pair of the source address and the flow ID uniquely identifies the connection. In general, QoS assured communication can be routed to an appropriate next hop link layer connection by flow ID. That is: 1) a packet arrives at a router 2) packet's flow ID and source address are checked and the next hop is determined 3) packet's TTL is decremented by 1 (or more) 4) unless the router is the destination, the packet is forwarded the above scheme assumes nothing ATM specific and applicable to all the QoS assured media such as a fixed speed dedicated link, FDDI II or switched Ethernet. If both incoming and outgoing interfaces are ATM, packets are reassembled at step 1) and re-celled at step 4), which means certain amount of delay and certain amount of processing overhead and is not so desirable. Optimization is possible by making use of the fact that flow ID is Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 7] INTERNET DRAFT Conventional IP over ATM March 1995 not necessary at step 2). That is, if some information to identify flow locally at each interface is provideed, it is enough to determine the next link layer connection. With ATM, VCI/VPI is such locally unique identifier. Moreover, ATM equipments have efficient hardware mechanism to forward cells based on VCI/VPI of incoming cells. So, if both the incoming and outgoing interface are ATM, the following cell-by-cell scheme works: 1) a cell arrives at a router 2) cell's VCI/VPI/incoming_interface is checked and the next hop VCI/VPI/outgoing_interface is determined by hardware 3) unless the router is the destination, the cell is forwarded It is assumed that information used at the step 2) is provided during the connection establishment. Thus, if ATM hosts communicate purely over ATM routers, a seamless single ATM link is established between them. It should be noted that, though many think ATM connection is considered to be at the link layer, the above seamless connection on ATM routers is at the internetwork layer. So, all the internetwork layer property such as the selection of the best path is naturally available. Seamlessness, here, should considered to be something like lower level caching. Whether some ATM equipment forward information cell by cell or packet by packet is merely an internal implementation detail, which does not affect the classification on whether the equipment is considered to be a bridge or a router. The problem of the scheme above is that TTL of the packet is not decremented at all. If ATM routers recognize AAL and can decrement TTL by hardware, it's OK. But, currently, they can't. As the number of routers along the seamless path is known in advance, packets with insufficient TTL may be dropped at the starting point of the seamless link. The TTL issue never be an issue in practice, unless the path itself is setup to form a loop, in which case no models of IP over ATM with seamless connection can function, anyway. Resource reservation protocols should be designed to make the formation of the loop completely unlikely. The lack of link level TTL makes the looping serious issue. It might be necessary in the future to design a new AAL that supports cell-wise or packet-wise TTL supported by hardware. Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 8] INTERNET DRAFT Conventional IP over ATM March 1995 References [CLIP] M. Laubach, "Classical IP and ARP over ATM", RFC1577, January 1994. [EARP] D. Plummer, "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD37, RFC826, November 1982. [IPATM] An Internet Draft may be available (J. Heinanen, R. Govindan, "IP over ATM: A Framework Document", <draft-ietf-atm- framework-doc-00.txt, .ps>). [ROLC] An Internet Draft may be available (J. Heinanen, R. Govindan, "NBMA Next Hop Resolution Protocol (NHRP)", <draft-ietf-rolc- nhrp-00.txt>). [RSVP] An Internet Draft may be available (L. Zhang, R. Braden, D. Estrin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", <draft-ietf-rsvp-spec-03.txt, .ps>). [SMAI] An Internet Draft may be available (M. Ohta, "Shared Media Architecture for the Internet", <draft-ohta-shared-media- 01.txt>). [STII] C. Topolcic, "Experimental Internet Stream Protocol, Version 2 (ST-II)", RFC1190, October 1990. Acknowledgements This memo is a result of discussion in TNG (The Next Generation) working group of JAIN consortium. Many ATM experts in Japan including Masayuki Murata of Osaka University, Kenji Fujisawa of SONY, Yuichiroh Nozue of Sumitomo Electric Industries and Akira Chugo of Fujitsu have contributed to the discussion. Interested parties are encouraged to read the original discussion (available as ftp.jain.ad.jp:pub/archive/tng-wg in Japanese with ISO-2022-JP encoding). Security Considerations Unlike the classical model, the conventional model does not change the architecture of the Internet, including but not limited to, the security architecture. Thus, all the existing and upcoming security architecture for the Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 9] INTERNET DRAFT Conventional IP over ATM March 1995 Internet will work and all the existing and upcoming security holes of the Internet will remain unclosed. Authors' Addresses Masataka Ohta Computer Center Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5499-7084 Fax: +81-3-3729-1940 EMail: mohta@cc.titech.ac.jp Hiroshi Esaki R&D Center, Toshiba Corporation 1 Komukai-Toshiba-cho, Saiwai-ku Kawasaki 210, JAPAN Phone: +81-44-549-2238 Fax: +81-44-549-2262 EMail: hiroshi@csl.rdc.toshiba.co.jp Ken-ichi Nagami R&D Center, Toshiba Corporation 1 Komukai-Toshiba-cho, Saiwai-ku Kawasaki 210, JAPAN Phone: +81-44-549-2238 Fax: +81-44-549-2262 EMail: nagami@csl.rdc.toshiba.co.jp Comments may also be directed to: TNG Working Group JAIN Consortium EMail: tng-wg@jain.ad.jp Ohta, Esaki & Nagami Expires on Sept. 15, 1995 [Page 10]