Internet Draft INTERNET-DRAFT FUJIKAWA, Kenji <draft-fujikawa-ipsvc-00.txt> Kyoto University May 6th, 1996 Another ATM Signaling Protocol for IP (IP-SVC) 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), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes the IP-SVC that is another ATM signaling protocol for implementing IP protocols. The IP-SVC restricts the range of signaling to an IP subnet and uses IP for signaling. This restriction makes the IP-SVC structure simple. The IP-SVC provides ease implementation of the mechanism of ARP and IP multicasting without any servers. The IP-SVC can not establish VCs across IP subnet boundaries by itself. But adapting the conventional IP over ATM model with the RSVP enables end-to-end VC establishment across IP subnet boundaries. This method also shows one solution of RSVP over ATM. 1 Introduction Applications requiring broad bandwidth for transferring continuous media in the Internet have been being developed. These applications require that the network be capable of IP multicasting, since these are used for something like conferences. ATM networks can provide these applications with broad bandwidth and QoS. There are several IP over ATM models[FRAM][CLIP][NHRP], requiring some servers. This means that these models are not so fault tolerant. IP multicasting with MARS[MARS] also needs MARS servers. The problem of requiring servers is caused from using UNI x.x as ATM FUJIKAWA, K. Expires November 6th, 1996 [Page 1] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 signaling. We propose a new ATM signaling protocol, IP-SVC, which is supposed to implement IP, and describe how to implement this with IP and PVC interfaces. The IP-SVC restricts the range of signaling to an IP subnet and uses IP for signaling. This restriction makes the IP-SVC structure simple. The IP-SVC provides ease implementation of the mechanism of ARP and IP multicasting without any servers. We adapt the conventional model as an IP over ATM model, and describe signaling when RSVP is used as a resource reservation protocol. 2 Problem of Classical Model, NHRP and MARS In IP over ATM models that use UNI x.x for signaling, UNI x.x is considered as a network layer protocol. Thus they are trying to modify IP to fit to UNI x.x. That is why servers are necessary. But considering ATM network is only datalink layer technology, developing a new signaling scheme that suits to IP solves the problem. 3 Overview of IP-SVC Considering ATM is only datalink layer protocol, the IP-SVC is designed to implement IP over it. The IP-SVC has the following features: o a simple signaling protocol valid only in an IP subnet. o establishing VCs with soft state. o not modifying an ATM cell switching fabric. o providing ease implementation of IP unicasting and multicasting. o no servers such as ARP servers or MARS servers are necessary when constructing IP on the IP-SVC. 3.1 Environment The network where the IP-SVC is effective has the following features: o An IP subnet is small (the maximum number of hosts is about 200, ATM switches about 20) o ATM switches and hosts does not do signaling over IP subnet boundaries. In this case, routers are needed . The IP-SVC is simple since the range of signaling is restricted to an IP subnet. You can establish end-to-end VCs between IP subnets that differs from each other, although routers has to forward the data. This function FUJIKAWA, K. Expires November 6th, 1996 [Page 2] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 is described in the section 4. 3.2 IP-SVC system In the IP-SVC system, UDP/IP packets are used for ATM signaling to make the implementation of IP-SVC easy. Two daemons are designed for processing UDP packets for signaling. o atmsd An atmsd is the daemon that manages an ATM switch. It decides a VPI/VCI value of a VC and set up an ATM switch with PVC interfaces, communicating with other atmsds and atmesds. o atmesd An atmesd is the daemon that manages ATM end systems such as ATM hosts (workstations), MPEG CODECs and etc. It sets up VCs of ATM end systems with PVC interfaces, communicating with the atmsd it is connected to. These daemons communicate with one another with the predefined VPI/VCI and IP address (class D). /-------\ /-------\ | atmsd | | atmsd | \-------/ \-------/ +----+ +----+ | \/ | | \/ | | /\ |----------| /\ | /--------\ /+----+ +----+\ /--------\ | atmesd | / ATM SW ATM SW \ | atmesd | \--------/ / \ \--------/ +----+ +----+ | | | | +----+ +----+ /______\ /______\ ATM end system ATM end system Figure 1: IP-SVC system 3.3 IP-SVC signaling protocol The daemons send UDP packets periodically so that VCs become soft state. A VC is released if UDP packets for it are not received in some period of time. The signals of the IP-SVC are shown below: o JOIN An ATM host notifies to the adjacent ATM switch by JOINs that it wants to receive data sent to a certain IP address. This address may be a multicast address. FUJIKAWA, K. Expires November 6th, 1996 [Page 3] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 o LEAVE An ATM host notifies to the adjacent ATM switch by LEAVEs that it will not receive data sent to the IP address specified by them any more. o VC REQUEST An ATM host notifies to the adjacent ATM switch by VC REQUESTs that it wants to send data to a unicast address in the IP subnet or a multicast address. This signal includes a VCID and a VC identifier which an ATM host decides. VC REQUESTs cause VC NOTIFYs. o VC RELEASE An ATM host notifies to the adjacent ATM switch by VC RELEASEs that it will not use the VC specified by them any more. o VC NOTIFY An ATM switch sends VC NOTIFYs to other ATM switches and to ATM hosts to notify which VC corresponds to the IP address. ATM switches and ATM hosts assign a VC to the IP address according to VC NOTIFYs. o ROUTE An ATM switch notifies the connection status of switches in the IP subnet by ROUTEs. Units of a ATM switch and IP addresses which ATM hosts connected to it joins. In the IP-SVC, a VC REQUEST corresponds to an ARP request, and a VC NOTIFY corresponds to an ARP reply. A JOIN and a ROUTE distribute joining information without discriminating between unicasting and multicasting. If a sending host sends VC REQUESTs with a VCID that differs from each other, it can use multiple VCs for one IP address, not concerning whether unicasting or multicasting. This mechanism enables an application to have its own VCs. 4 LAN by IP-SVC 4.1 VC Establishment for IP Unicasting The example of establishing a VC for IP unicasting is shown in Figure 2, in which host B wants to send data to host A. Note that signals are sent periodically. 1) Host A sends JOINs including its own IP address to switch A. The VC is not established at this moment. 2) All the switches in the IP subnet become to know by ROUTEs that switch A has an adjacent host which wants to receive data sent to host A's IP address. FUJIKAWA, K. Expires November 6th, 1996 [Page 4] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 3) Host B sends VC REQUESTs including host A's IP address. 4) Switch B establishes the VC from host B to switch A, and sends VC NOTIFYs to host B and switch A. VC NOTIFYs are also sent from switch A to host A. 5) Each node establishes the VC according to the received VC NOTIFYs. 6) Thus the VC from host B to host A is established. host A ---- switch A --- switch B ---- host B | | | | | ---------> | | | | JOIN | ---------> | | | | ROUTE | <--------- | | | <--------- | VC REQUEST | | <--------- | VC NOTIFY | ---------> | | VC NOTIFY | | VC NOTIFY | | | | | Figure 2: VC establishment for IP unicasting 4.2 VC Establishment for IP Multicasting Next, the example of establishing a VC for IP multicasting is shown in Figure 3. If there exist multiple hosts that send to the same IP multicast address, point-to-multipoint VCs are established per sender. Figure 3 shows the case that there is one sender. 1) Host B and C send JOINs to the adjacent switch of each in order to join multicast address M. 2) Switch A can know by ROUTEs that a host connected to switch B and one connected to switch C joins multicast address M. Note that the information that which hosts join multicast address M is not notified. 3) Host A sends VC REQUESTs including multicast address M to switch A in order to establish a point-to-multipoint VC by which it can sends data to multicast address M. 4) Switch A set up a point-to-multipoint VC from host A to switch B and C, and sends VC NOTIFYs to switch B and C. Switch B and C set up a VC and send VC NOTIFYs to host B or C respectively. 5) Host A set up a send-only VC, and host B and C set up a receive-only VC, according to the received VC NOTIFYs 6) If host D connected to switch C joins multicast address M by sending VC REQUESTs after the above setting, it receives VC NOTIFYs immediately. Switch C should change the established VC into a point-to-multipoint one. FUJIKAWA, K. Expires November 6th, 1996 [Page 5] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 7) The total VC illustrated in Figure 3 is established. +----------------- switch C ---------------+ | +----------+ | | | | host B -- switch B - switch A -- host A host C host D | | | | | | | |--------->| | | |<---------| | | JOIN |--------->|<--------------------| JOIN | | | | ROUTE | ROUTE | | | | | |<---------| | | | | | |VC REQUEST| | | | | |<---------|-------------------->| | | | |VC NOTIFY | VC NOTIFY | | | |<---------| |--------->| |--------->| | |VC NOTIFY | |VC NOTIFY | |VC NOTIFY | | | | | | | | | | | | | |<--------------------| | | | | | JOIN | | | | | |-------------------->| | | | | | VC NOTIFY | | | | | | | | +--------- A | B<--------------------+---------------------+--------->C established p-to-mp VC | +-------------------->D Figure 2: VC establishment for IP multicasting In case that UNI 3.0/3.1 is utilized for IP multicasting, point to multipoint VCs are established in a sender initiated manner. Thus a sender has to know all the receivers. Though a receiver initiated manner is available in case of UNI 4.0, a receiver has to know all senders. In the IP-SVC, A sender do not have to know which are receivers, and receivers do not have to know which are senders. That means the IP-SVC is very suitable to the current IP multicasting scheme. 4.3 Adaptation of Conventional Model The IP-SVC can not establish VCs across IP subnet boundaries by itself, since it restricts the range of signaling to an IP subnet. Routers, therefore, assemble cells to a packet and re-fragment it to cells, so it is hard to make use of the advantage of ATM that end to end QoS assurance is available. FUJIKAWA, K. Expires November 6th, 1996 [Page 6] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 Adapting the conventional model as an IP over ATM model solves the problem. The conventional model provides the special routers, CSRs (Cell Switching Router), which enable end-to-end VC establishment across IP subnet boundaries if resource reservation protocols such as RSVP precede the data transfer. VC establishment using RSVP and CSRs is described in 4.4. 4.4 Utilizing RSVP The IP-SVC provides the method of specifying a service (UBR or CBR) and maximum bit rate. In case of communication without resource reservations, however, only UBR services are applied to applications. Each application communicating with ones of the same IP address uses a single VC of UBR in this case. An application can use a separate VC of CBR when it reserve the communication by RSVPs or something. Figure 4 shows a network where IP subnets that consist of a ATM network are connected by CSRs. RSVP PATHs and RSVP RESERVs are sent with pre-established UBR VCs. Assume that the reserved VC of CBR from host S to CSA A has been already established in Figure 4. host R -- switch -- CSR B --- switch -- CSR A --- switch -- host S | | | | | | | | | | | |<------------------| | | | | | RSVP PATH | | | |<------------------| | | | | | RSVP PATH | | | |<------------------| | | | | | RSVP PATH | | | | | |------------------>| | | | | | RSVP RESERV | | | | | |-------->| |------------------>| | | | JOIN | | RSVP RESERV | | | | |<--------|-------->| | | | | | VC REQ. | JOIN | | | | |<--------|-------->| |<--------| | | |VC NOTIFY|VC NOTIFY| | VC REQ. | | | | | |<--------|-------->| | | | | |VC NOTIFY|VC NOTIFY| | | | | | | | | | Figure 4: VC establishment over IP subnet boundaries by RSVP The routine of establishing the VC from host S to R is as the following: 1) RSVP PATHs are sent through intermediate CSRs from host S to R. 2) Host R sends RSVP RESERVs to CSR B, and also sends JOINs if RSVP RESERVs includes a multicast address which host R must join. FUJIKAWA, K. Expires November 6th, 1996 [Page 7] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 3) CSR B, which receives RSVP RESERVs, specifying QoSs, the host R address or the multicast address and a new VCID, sends VC REQUESTs. 4) VC NOTIFYs are sent to host R, to CSR B and to the intermediate switches. Then the VC from host R to CSR B is established. 5) The VC between CSR B and A is established in the same way. The VC between host S and CSR A, however, is not created because it already exists. 6) Each CSR recognizes the VCs which is on the way from host S to R, and treats them as a single VC by its cell-relaying fabric. The delay caused by assembling cells into packets does not occur. Finally the end-to-end VC is established. In the RSVP, routers merge different incoming RSVP RESERV messages into one outgoing RSVP RESERV message, that is, data paths are merged by routers. IP over ATM models that use UNI x.x instead of using IP routers, data paths are decided with no relation to IP. It is, therefore, difficult to implement the mechanism of merging data paths. In the conventional model with the IP-SVC, that problem does not arise. The SINP[SINP] is also used for notifying correspondences between a VC and a session. But this mechanism is not described in this document. 5 Related Works The Ipsilon approach[FLMN][FLLB] is similar to the IP-SVC at the point that it discards Q.2931 signaling but make use of IP for signaling. The main difference between the Ipsilon approach and the IP-SVC is that the Ipsilon approach makes all ATM switches IP routers like CSR, while the IP-SVC does not. Multiple IP-SVC's ATM switch can be connected to one another in a single IP subnet. References [FRAM] Cole, R., et al., "IP over ATM: A Framework Document", RFC1932, April 1996. [CLIP] Laubach, M., et al., "Classical IP and ARP over ATM", RFC1577, January 1994. [CVIP] Ohta, M., et al., "Conventional IP over ATM", IETF Internet Draft (work in progress), draft-ohta-ip-over-atm-02.txt, March 1995. [NHRP] Heinanen, J., et al., "NBMA Next Hop Resolution Protocol (NHRP)", IETF Internet Draft (work in progress), draft-ietf-rolc-nhrp-07.txt, December 1995. FUJIKAWA, K. Expires November 6th, 1996 [Page 8] INTERNET-DRAFT draft-fujikawa-ipsvc-00.txt May 6th, 1996 [RSVP] Zhang, L., et al., "Resource ReSerVation Protocol (RSVP), Version 1 Functional Specification", IETF Internet Draft (work in progress), draft-ietf-rsvp-spec-07.ps, April 1995. [MARS] Amitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", IETF Internet Draft (work in progress), draft-ietf-ipatm-ipmc-12.txt, February 1996. [MCST] Deering, S., "Host Extensions for IP Multicasting", RFC1112, August 1989. [SINP] Goto, Y., "Session Identity Notification Protocol (SINP)", IETF Internet Draft (work in progress), draft-goto-sinp-01.txt, January 1996. [FLMN] Newman, P., et al., "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0", IETF Internet Draft (work in progress), draft-rfced-info-flowman-00.txt, February 1996. [FLLB] Newman, P., et al., "The Transmission of Flow Labelled IPv4 on ATM Data Links Version 1.0", IETF Internet Draft (work in progress), draft-rfced-info-flowlabel-00.txt, February 1996. Author's Address FUJIKAWA, Kenji Department of Information Science, Faculty of Engineering, Kyoto University Yoshidahonmachi, Sakyo Ku, Kyoto city, 606-01, Japan Phone : +81 75-753-5387 Email : magician@kuis.kyoto-u.ac.jp FUJIKAWA, K. Expires November 6th, 1996 [Page 9]