Internet Draft INTERNET DRAFT FUJIKAWA Kenji draft-fujikawa-ipsvc-01.txt Kyoto University November 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 IP-SVC that is another ATM signaling protocol for implementing IP protocols. IP-SVC restricts the range of signaling to an IP subnet, and this restriction makes the IP-SVC structure simple. IP-SVC provides easy implementation of the mechanism of ARP and IP multicasting without any servers. IP-SVC can not establish VCs across IP subnet boundaries by itself. However, adapting CSRs (Cell Switching Routers) with RSVP (Resource ReSerVation Protocol) enables end-to-end VC establishment across IP subnet boundaries in IP/ATM LANs based on IP-SVC. This method also shows one solution of RSVP over ATM. FUJIKAWA Kenji Expires on May 7, 1996 [Page 1] INTERNET DRAFT IP-SVC November 1996 1. Introduction There are several IP over ATM models[1][2][3], and these models require some kind of servers. IP multicasting with MARS[4] also needs a MARS server. However, requirement for servers is not favorable for LAN's reliability. This problem is caused by the fact that they utilize the UNI/NNI signaling even though the UNI/NNI signaling is determined entirely irrelevant to IP. We describe a new ATM signaling protocol, IP-SVC, which is supposed to implement IP protocols. IP-SVC restricts the range of signaling to an IP subnet, and this restriction makes the IP-SVC structure simple. IP-SVC provides easy implementation of the mechanism of ARP and IP multicasting without any servers. IP-SVC can not establish VCs across IP subnet boundaries by itself. However, it implements VC establishment across IP subnet boundaries to adapt CSRs (Cell Switching Routers)[5] with RSVP (Resource ReSerVation Protocol)[6] to IP-SVC environment. This method also shows one solution of RSVP over ATM. 1.1. Document Scope We describe IP-SVC's protocol scheme, packet formats and an implementation example. The following things are out of the scope in this document. o Encapsulation of IP packets over ATM/AAL. LLC/SNAP encapsulation may be used for IP packets, and nothing is specified for signaling messages. o The way to obtain connection information from adjacent switches and hosts. o VPI/VCI values of VCs for signaling. The VCs for exchanging signaling messages between a host and a switch or among switches are established immediately when they are connected to each other, but the VPI/VCI values for these VCs are not defined. 2. Requirement for Facility of ATM Switches We assume an ATM switch has the fabric of establishing unidirectional point-to-multipoint VCs. Bidirectional point-to-point VCs are not required, and an unidirectional point-to-point VC is considered as a special point-to-multipoint VC that have only one leaf end point. FUJIKAWA Kenji Expires on May 7, 1996 [Page 2] INTERNET DRAFT IP-SVC November 1996 3. Network Scale and Topology IP-SVC is simple since the range of signaling is restricted to an IP subnet. The network where IP-SVC is used as follows: o An IP subnet is small. The maximum number of hosts is up to about 300, and that of ATM switches is up to about 20. o Multiple switches are connected directly with one another, con- structing an IP subnet, and IP subnets are connected by routers. Switches and hosts do not send signaling messages across IP sub- net boundaries. Figure 1 shows the topology of IP subnets based on IP-SVC. subnet A subnet B +------+ +------+ +------+ +------+ |switch|---|router|---|switch|--|router|-- +------+ +------+ +------+ +------+ / \ / \ +------+ +------+ +------+ +------+ |switch| |switch| |switch| |switch| +------+ +------+ +------+ +------+ | | | | +----+ +----+ +----+ +----+ |host| |host| |host| |host| +----+ +----+ +----+ +----+ Figure 1: IP subnet 4. Protocol Scheme 4.1. Address Types IP-SVC handles several types of addresses. In the current version, IP-SVC considers IEEE 802 addresses, IPv4 addresses and IPv6 addresses. IEEE 802 address may be used for DHCP. The term 'address' refers to one of them in this document. 4.2. Signaling Messages In order to establish point-to-multipoint VCs, IP-SVC uses mainly just three types of message for signaling, JOIN, NOTIFY and ACCEPT: JOIN A host notifies to the adjacent switch by JOIN messages that it wants to receive data sent to a specified address. This address FUJIKAWA Kenji Expires on May 7, 1996 [Page 3] INTERNET DRAFT IP-SVC November 1996 can be either a unicast address or a multicast address. NOTIFY A host or a switch notifies correspondence between a VC and a flow to the adjacent switch(es) (and hosts) by NOTIFY messages. These messages are forwarded by the switches according to some routing policy. The current implementation of routing is based on the flooding routing algorithm with pruning. ACCEPT A switch sends ACCEPT messages to the adjacent upstream switch that is sending the NOTIFY messages to the switch, when the switch receives at least one sequence of JOIN messages from a host that is not an originator of the NOTIFY messages or receives at least one sequence of the ACCEPT messages from a downstream switch. Hosts and switches send these messages periodically to keep VCs in the soft-state manner. Joining states and VCs are deleted if the corresponding messages are not delivered for a defined period. In addition, LEAVE and RELEASE messages are defined against JOIN and NOTIFY messages respectively in order to improve the response time for the deletion. In the current implementation, a PRUNE message is defined in order to omit redundant NOTIFY messages. 4.3. Setting up VCs A host set up a VC when: o it starts to send a NOTIFY message. o it has received a NOTIFY message. A switch sets up a VC when: o it has received a sequence of NOTIFY messages and simultaneously has host(s) sending the corresponding JOIN messages. o it has received both a sequence of NOTIFY messages from an upstream switch or host and a sequence of the corresponding ACCEPT messages from a downstream switch. 4.4. Signaling Examples FUJIKAWA Kenji Expires on May 7, 1996 [Page 4] INTERNET DRAFT IP-SVC November 1996 4.4.1. Unicasting The example of establishing a VC for unicasting is shown in Figure 2, in which host B wants to send data to host A. 1. Host R sends the JOIN messages including its own unicast address to switch B. 2. Host S sends the NOTIFY messages including host R's address. These messages are also forwarded from switch A to switch B and from switch B to host R. 3. Switch B sends the ACCEPT messages to switch A since it has the host that is sending the JOIN messages. 4. The ACCEPT messages are forwarded to host S. 5. Thus the VC from host S to host R is established. When host R wants to send data to host S, host S sends JOIN messages and host R sends NOTIFY messages, conversely. host S ---- switch A --- switch B ---- host R | | | | | | | <-------- | | ---------> | | JOIN | | NOTIFY | ---------> | | | | NOTIFY | ---------> | | | <-------- | NOTIFY | | <--------- | ACCEPT | | | ACCEPT | | | =====================================> established VC Figure 2: VC establishment for unicasting 4.4.2. Multicasting Next, the example of establishing a VC for multicasting is shown in Figure 3. If there exist multiple hosts that send to the same multi- cast address, point-to-multipoint VCs are established per sender. Figure 3 shows the case of one sender and three receivers. 1. Host R1 and R2 send the JOIN messages to the adjacent switch of each in order to join multicast address M. FUJIKAWA Kenji Expires on May 7, 1996 [Page 5] INTERNET DRAFT IP-SVC November 1996 2. Host S sends the NOTIFY messages including multicast address M to switch A in order to establish the point-to-multipoint VC by which it can send data to multicast address M. 3. The NOTIFY and ACCEPT messages are delivered in the same way to that of unicasting. 4. The point-to-multipoint VC from host S to host R1 and R2 are established. 5. If host R3 connected to switch C joins multicast address M by sending the JOIN messages after the above setting, it receives the NOTIFY messages immediately. Switch C adds the leaf of host R1 to the established VC. 6. The total VC illustrated in Figure 3 is established. +----------------- switch C ---------------+ | +----------+ | | | | host R1 - switch B - switch A -- host S host R2 host R3 | | | | | | | |--------->| | | |<---------| | | JOIN | |<---------| | JOIN | | | | | NOTIFY | | | | | |<---------|-------------------->| | | |<---------| NOTIFY | NOTIFY |--------->| | | NOTIFY |--------->|<--------------------| NOTIFY | | | | ACCEPT | ACCEPT | | | | | |--------->| | | | | | | ACCEPT | | | | | | | | |<--------------------| | | | | | JOIN | | | | | |-------------------->| | | | | | NOTIFY | +========= A # B<====================+=====================+=========>C established p-to-mp VC # +====================>D Figure 3: VC establishment for multicasting Sending hosts and receiving hosts do not need to know the information that which hosts are senders or receivers in IP-SVC. Any servers FUJIKAWA Kenji Expires on May 7, 1996 [Page 6] INTERNET DRAFT IP-SVC November 1996 like a MARS server are not needed. 5. Packet Formats 5.1. Common Header All the messages have the common header illustrated in the figure below. Address Type | 0 1 v 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Hop | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other fields follow | : : Version IP-SVC version. The current version of IP-SVC is 2. Type Message type. 0x1: JOIN 0x2: NOTIFY 0x3: ACCEPT 0x4: LEAVE 0x5: RELEASE 0x6: PRUNE Hop Hop count of the message. This field is incremented every time the message is forwarded by switches. Address Type Type of address. 0x1: IEEE 802 address 0x2: IPv4 address 0x3: IPv6 address FUJIKAWA Kenji Expires on May 7, 1996 [Page 7] INTERNET DRAFT IP-SVC November 1996 Source Address Source address of a host originating the message first. In the case of IEEE 802 address or IPv4 address, a source address is simply the same to the address of the host originating the message, attached with 2 or 4 octets padding, while in the case of IPv6, an IPv6 address of the host is converted into 8 octets in a certain manner. Such a manner is not been defined, but it might add value to use simply lower 8 octets from the IPv6 address. A join address and a destination address, following below, obey these manners. 5.2. JOIN and LEAVE Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Join Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Join Address Address the host intends to join or leave. 5.3. NOTIFY Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * |Reservd| VPI | VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Bitrate Class Flow Flow identifier of a VC. FUJIKAWA Kenji Expires on May 7, 1996 [Page 8] INTERNET DRAFT IP-SVC November 1996 The value of this field is determined uniquely per flow by the sender. In an IP subnet, VCs are distinguished uniquely by a pair of a source address and a flow identifier. Destination Address Address the host intends to send to. Bitrate Class Bitrate class of a VC. 0x1: CBR 0x2: VBR 0x3: ABR 0x4: UBR VPI/VCI VPI and VCI values of a VC. Bandwidth Bandwidth of a VC. This field is specified in kpbs. 5.4. ACCEPT, RELEASE and PRUNE Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Further Application for Assuring QoS IP-SVC provides the method of specifying QoS (Quality of Service) parameters such as a bit rate class or bandwidth. We describe how to make use of this specification in this section. 6.1. Utilization of RSVP Utilizing RSVP[6] is indeed one solution to specify QoS. In the case of communication without RSVP, processes on the same host share UBR (or ABR if available) class VCs. that is, share non-QoS-specified VCs. In the case of communication with RSVP, a process can take pos- session of a QoS-assured VC per purpose. FUJIKAWA Kenji Expires on May 7, 1996 [Page 9] INTERNET DRAFT IP-SVC November 1996 6.2 VC Establishment across Subnet Boundaries by CSRs IP-SVC can not establish VCs across IP subnet boundaries by itself, since it restricts the range of signaling to an IP subnet. There- fore, routers usually assemble cells to a packet and re-fragment it to cells, so it is hard to make use of the advantage of ATM that assures end-to-end QoS across subnet boundaries. Introducing CSRs (Cell Switching Routers)[5] solves this problem. CSRs implement end-to-end VC establishment across IP subnet boun- daries when a setup protocol such as RSVP precedes the data transmis- sion. Figure 4 shows a signaling example, in which IP subnets consisting of an ATM network are connected by CSRs. 1. IP-SVC messages (JOIN and NOTIFY) are sent via the VCs dedicated to IP-SVC. 2. The JOIN messages are sent in order to receive RSVP PATH mes- sages and the data stream of purpose. 3. RSVP PATH messages are sent via established non-QoS-assured VCs by the first sequences of the NOTIFY messages. 4. RSVP RESV messages are sent via the non-QoS-assured VCs for uni- casting (the process of establishing the VC is not illustrated here). 5. The VCs for the data stream are established by the second sequences of NOTIFY messages. The CSRs can distinguish VCs for the data stream by RSVP PATH and RESV messages. According to this information, the CSRs forward the data flowed in the VCs in cell switching, In this way, the end-to-end VC establishment from host S to host R is accomplished. FUJIKAWA Kenji Expires on May 7, 1996 [Page 10] INTERNET DRAFT IP-SVC November 1996 host R -- switch -- CSR B --- switch -- CSR A --- switch -- host S | | | | | | | |-------->| |-------->| |-------->| | | JOIN | | JOIN | | JOIN | | | | | | | |<--------| | | | | |<--------| NOTIFY | | | | |<--------| NOTIFY | | | | |<--------| NOTIFY |<------------------| | |<--------| NOTIFY | | RSVP PATH | |<--------| NOTIFY |<------------------| | | | NOTIFY | | RSVP PATH | | | |<------------------| | | | | | RSVP PATH | | | | | |------------------>| | | | | | RSVP RESV | | | | | | |<--------|------------------>| | | |<--------| NOTIFY | RSVP RESV | | | | NOTIFY | | |<--------|------------------>| | | |<--------| NOTIFY | RSVP RESV | | | | NOTIFY | | |<--------| | | | | |<--------| NOTIFY | | | | | | NOTIFY | | | | | | | | | |<----------------------------------------------------------| | | | data stream | | | | | | | | | | <================== <================== <================== established VCs for sending RSVP PATH messages <========================================================== established end-to-end VC for data stream Figure 4: VC establishment over IP subnet boundaries by RSVP This method also shows one solution of RSVP over ATM. FUJIKAWA Kenji Expires on May 7, 1996 [Page 11] INTERNET DRAFT IP-SVC November 1996 7. Example of Implementation We have already implemented an IP-SVC prototype system. In this sys- tem, two types of daemons, atmswd (ATM SWitch Daemon) and atmesd (ATM EndSystem Daemon), are running and exchange signaling messages with one another by UDP packets (See Figure 5). The network provides users with IP unicasting and multicasting facility, not requiring any servers. /--------\ /--------\ | atmswd | | atmswd | \--------/ \--------/ +----+ +----+ | \/ | | \/ | | /\ |----------| /\ | /--------\ /+----+ +----+\ /--------\ | atmesd | / ATM SW ATM SW \ | atmesd | \--------/ / \ \--------/ +----+ +----+ | | | | +----+ +----+ /______\ /______\ workstation workstation Figure 5: IP-SVC system 8. Related Works IP-SVC is similar to the Ipsilon approach[7][8] regarding not using UNI/NNI for signaling. The difference between them is that an ATM switch of Ipsilon is a router at the same time it is a switch, that while that of IP-SVC is not a router but is like a hub having cell switching fabric. IP-SVC implements autoconfiguration of an IP/ATM network consisting of multiple switches. References [1] Cole, R., et al., "IP over ATM: A Framework Document", RFC1932, April 1996. [2] Laubach, M., et al., "Classical IP and ARP over ATM", RFC1577, January 1994. [3] Heinanen, J., et al., "NBMA Next Hop Resolution Protocol (NHRP)", IETF Internet Draft (work in progress), draft-ietf- rolc-nhrp-10.txt, September 1996. FUJIKAWA Kenji Expires on May 7, 1996 [Page 12] INTERNET DRAFT IP-SVC November 1996 [4] Armitage, 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. [5] Ohta, M., et al., "Conventional IP over ATM", IETF Internet Draft (work in progress), draft-ohta-ip-over-atm-02.txt, March 1995. [6] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", IETF Internet Draft (work in progress), draft-ietf-rsvp-spec-13.txt, August, 1996. [7] Newman, P., et al., "Ipsilon Flow Management Protocol Specifi- cation for IPv4 Version 1.0", RFC1953, May 1996. [8] Newman, P., et al., "Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0", RFC1954, May 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 Kenji Expires on May 7, 1996 [Page 13]