HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:20:49 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 09 Aug 1997 04:22:39 GMT ETag: "2e6b8e-5706-33ebf08f" Accept-Ranges: bytes Content-Length: 22278 Connection: close Content-Type: text/plain INTERNET DRAFT I. Jeyasubramanian FSPL July 25, 1997 Synchronous IP Switching Protocol draft-jeya-sync-ip-switch-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 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 (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The "Synchronous IP Switching" protocol provides a framework for synchronous communication among end stations through an ethernet switch. This proposal enhances the capability of an ethernet switch to forward the packets from a variety of real time applications in a synchronous manner with less delay variations and consistent throughput by introducing the concept of "Time Switch". This protocol proves its importance, as more and more applications need constant delay, effective bandwidth while forwarding their packets to their destination. Jeyasubramanian Expires January 30, 1998 [Page 1] Internet Draft Synchronous IP Switching Protocol July 1997 1. Introduction The Synchronous IP Switching protocol (hereafter, referred to as SIPSw) suggests an efficient way of switching IP packets in an ethernet switch for real-time applications. The protocol comprises of two entities, namely, a server component which resides in an ethernet switch, and a client component in the end stations. It is assumed that the end stations which need to communicate with the server component of this protocol should run the client component. Currently, the packets that are forwarded by the ethernet switches incur considerable amount of delay which varies from time to time. All real time applications are sensitive to the delay variations and may perform well in environments which provide a faster response time with less delay variations. The SIPSw attempts to provide a solution for the aforementioned problem by imparting the concept of switching packets synchronously using a time switch. The client component which wishes to send the packets to the remote stations in synchronous manner, will issue a request the ethernet switch to maintain constant delay between the packets. The server component accepts such requests from the clients and dynamically configures the time switch with the necessary information. The time switch switches the packets based on the preassigned timeslots using the configuration. In addition, the server component synchronizes the client components. Since the packet forwarding is done by time switch, this is the most efficient way of relaying packets. This protocol takes into consideration an ethernet switch with each of its interfaces connected to atmost a single end station. This assumption simplifies the protocol scenario. The scenarios involving multiple ethernet switches connected to each other are outside the scope of this version. However such scenarios can be handled by tagging the timeslot number in the inter-switch frames and time switch can use this tag for identifying the time-slot. 2. Motivation With the advent of multimedia real time applications, most of the information servers send the data to their clients in a constant rate with minimum delay. The current IP network and ethernet switches forward the packets in an asynchronous manner and hence they can not guarantee the minimum and constant delay required by these applications even in intranet situations. If the entire intranet is connected by ethernet switches, one can assure constant delay between the IP packets, by implementing this protocol. Jeyasubramanian Expires January 30, 1998 [Page 2] Internet Draft Synchronous IP Switching Protocol July 1997 The following enumerates the technical reasons behind the design of the SIPSw: o Ethernet switches assure dedicated bandwidth for end stations connected to each interface. This feature can be used for synchronous communication. o Time Switch is easier to implement in hardware. It is a proven technology. These are the advantages of using this protocol: o Fast Switching - Since it is time slot switching, it is faster. o Protocol Independent - While packets are switched, all packets are identified by timeslot and not by the address related intricacies of the received packet. 3. Synchronous IP Switching Protocol Synchronous IP Switching Protocol performs the following operations: 1. Dynamic allocation of timeslots for end users. 2. Maintains Timeslot Table. 3. Configures the Time Switch according to Timeslot table. 4. Fast Switching of IP packets using time switch. 5. Automatic deregistration of end users by keep alive timer. 6. Sends periodic service advertisement message. Jeyasubramanian Expires January 30, 1998 [Page 3] Internet Draft Synchronous IP Switching Protocol July 1997 3.1. Topology Ethernet Switch with SIPSw Protocol Synchronous +----------------+-------------+ IP Switching | SIPSw - Server | | Protocol +----------------+ | | | +------------------------------+ / Interface \ Interface / X \ Y +---------+---------+ +---------+---------+ | SIPSw - | | | SIPSw - | | | Client | | | Client | | +---------+ | +---------+ | | Video App. Client | | Video App. Server | +-------------------+ +-------------------+ 3.2. Packet Formats All SIPSw messages (Except SIPSw Service Advertise Message, which are sent to IP broadcast addresses) must be encapsulated within an Ipv4 packet and must be sent to the destination IP address. The protocol field in the IP header must contain the value 121 (decimal) indicating that the IP packet contains a SIPSw message. SIPSw message structures are the following: SIPSw Service Advertise 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot Count | Slot Rate | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jeyasubramanian Expires January 30, 1998 [Page 4] Internet Draft Synchronous IP Switching Protocol July 1997 SIPSw Register 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot Count | Slot Rate | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source UDP/TCP Port Number |Destination UDP/TCP Port Number| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPSw Deregister 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Slot Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPSw Deregistered 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Slot Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPSw Keep Alive 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Slot Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jeyasubramanian Expires January 30, 1998 [Page 5] Internet Draft Synchronous IP Switching Protocol July 1997 SIPSw ACK 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Slot Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPSw NACK 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot Count | Slot Rate | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPSw SYNC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Slot Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The SIPSw protocol version number. The current Version = 1. Message Type Specifies the function of the message. Eight Message Types are defined in this version of the protocol. SIPSW_ADVERTISE : Message Type = 0 SIPSW_REGISTER : Message Type = 1 SIPSW_DEREGISTER : Message Type = 2 SIPSW_DEREGISTERED: Message Type = 3 SIPSW_KEEP_ALIVE : Message Type = 4 SIPSW_ACK : Message Type = 5 SIPSW_NACK : Message Type = 6 SIPSW_SYNC : Message Type = 7 Jeyasubramanian Expires January 30, 1998 [Page 6] Internet Draft Synchronous IP Switching Protocol July 1997 Slot Count Number of consequent slots. Slot Rate The rate at which the "Slot Count" number of slots should be forwarded. Slot Identifier Identifies the unique number assigned for the registration. Source IP Address IP address of the source end station. Destination IP Address IP address of the destination end station. Source UDP/TCP Port Number UDP or TCP port number of the source end node application. Destination UDP/TCP Port Number UDP or TCP port number of the destination end node application. 3.3. Procedure The SIPSw protocol operation is described by the following procedure. The SIPSw server protocol is present in the Ethernet Switch. The SIPSw server maintains a list of registered SIPSw clients. SIPSw Client - Server Interactions Procedure -------------------------------------------- 1. The SIPSw server periodically (once in 30 seconds) sends the "SIPSw Service Advertisement Message Packet" on all interfaces of the switch. This packet carries the information about the maximum number of timeslots and packet rate available for any end node. Jeyasubramanian Expires January 30, 1998 [Page 7] Internet Draft Synchronous IP Switching Protocol July 1997 2. The SIPSw client assures the availability of SIPSw server by waiting for the "SIPSw Service Advertisement Message Packet" for atmost 30 seconds. On hearing the advertisement packet, the SIPSw client requests for the required number of time slots to the SIPSw server by sending "SIPSw Register Packet". This packet carries the information about IP address & UDP/TCP port numbers of the source and destination, Packet rate and the number of slots requested. 3. The SIPSw server checks for the availability of the number of time slots and the slot rate that are requested. If they are available, it registers the information found in the received packet in its Time slot Table. The time slot index from the Time Slot table is sent to the client using the "SIPSw ACK Packet". 4. If the required number of time slots and the packet rate are not available, the SIPSw server sends "SIPSw Register NACK Packet" with the actual number of slots and packet rate available with the SIPSw server at that particular moment. 5. After receiving "SIPSw ACK Packet", the client should wait for the SYNC packet from the server to synchronize the transmission. 6. As soon as the "SIPSw SYNC Packet" appears, the client starts the transmission at the requested packet rate. 7. After receiving "SIPSw Register NACK Packet", the client sends "SIPSw Register Packet" with the SIPSw server recommended available number of time slots and packet rate. The SIPSw client will not send new "SIPSw Register Packet", if any of the following conditions are true. a. There was no response from SIPSw server (Timeout of 30 seconds). The server may be down. b. The SIPSw server says only "0" time slot and "0" packet rate is available. The server switches at its maximum capacity. Jeyasubramanian Expires January 30, 1998 [Page 8] Internet Draft Synchronous IP Switching Protocol July 1997 c. The SIPSw client found that the received number of time slots and the slot rate are less than the required values. (e.g., The application cannot accept the SIPSw server's recommended values) 8. Once the data transfer is over, the SIPSw client should deregister with the SIPSw client by sending the "SIPSw Deregister Packet", with the corresponding slot Identifier. 9. In case the SIPSw client doesn't have any data packets, but it wants to maintain the registration, the SIPSw client should send a "SIPSw Keep Alive Packet" within the period of 30 seconds. The SIPSw server deregisters a SIPSw client, if it doesn't send any data packet or keep alive packet within the keep alive period. This is done to improve the throughput of the this service. 10. If the SIPSw server deregisters a client, the server sends client "SIPSw Deregistered Packet" to the client. Upon receiving this frame, the client should reinvoke the registration procedure to use this SIPSw facility. Otherwise the packets will be handled by the usual forwarding component of the ethernet Switch. SIPSw Server Functionality -------------------------- In addition to the client-server interaction procedure, the server also implements the following set of functionalities to effect synchronization. 1. The SIPSw server receives client registration packets and stores the relevant information in its Timeslot table. It returns the slot Identifier on its ACK packet. It sends NACK packet, in case it cannot provide the number of timeslots and the slot rate. It recommends the possible number of timeslots and the packet rate to the clients in its NACK packet. 2. The SIPSw server sends the SYNC packet so that the client can send its first data packet at the next valid timeslot. 3. If the SIPSw client sends the deregister packet, the SIPSw server deregisters the client and removes the client entry from the table using the Slot Identifier. Jeyasubramanian Expires January 30, 1998 [Page 9] Internet Draft Synchronous IP Switching Protocol July 1997 4. The SIPSw server periodically monitors the rate at which the client sends the packet. During this, it also sends the "SIPSw Deregistered Packet" to the client if any of the observed slot rate exceeds the pre-registered slot rate. SIPSw Server IP Packet Switching Procedure ------------------------------------------ 1. The SIPSw server maintains a table of entries indexed by the timeslot. For each timeslot, the ingress and egress interface numbers on which the packets should be switched at this timeslot, are maintained. 2. The time switch switches the packets from the ingress interface to the egress interface for each timeslot as maintained by the SIPSw server. Table maintained by SIPSw server IP Packet Switching ---------------------------------------------------- +------+---------+--------+---------------+--------------+ | Time | Ingress | Egress | Ingress Addr. | Egress Addr. | | Slot | I/F | I/F +----+----------+----+---------+ | No. | | | IP | UDP/TCP | IP | UDP/TCP | +------+---------+--------+----+----------+----+---------+ | | | | | | | | +------+---------+--------+----+----------+----+---------+ | | | | | | | | +------+---------+--------+----+----------+----+---------+ 4. References [1] [RFC 791] J. Postel, "Internet Protocol", RFC 791, Sep 1981. [2] [RFC 768] J. Postel, "User Datagram Protocol", RFC 768, August 1980. [3] [RFC 793] J. Postel, "Transmission Control Protocol", RFC 793, Sep 1981. [4] [RFC 1953] P. W. Edwards, R. E. Hoffman, F. Liaw, T. Lyon, G. Minshall, "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0", RFC 1953, May 1996. Jeyasubramanian Expires January 30, 1998 [Page 10] Internet Draft Synchronous IP Switching Protocol July 1997 [5] [RFC 1954] P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Liaw, T. G. Minshall, "Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0", RFC 1954, May 1996. 5. Acknowledgements The author wishes to thank Srinivasan.E.S., for his many comments and suggestions which improved this document. 6. Security Considerations Security issues are not discussed in this memo. 7. Author's Address I.Jeyasubramanian Future Software Private Limited. Madras - 600 035, INDIA. Phone: +91-44-4340323 Fax: +91-44-4344157 Email: jeyai@future.futsoft.com Table of Contents 1. Introduction ............................................... 2 2. Motivation ................................................. 2 3. Synchronous IP Switching Protocol........................... 3 3.1. Topology ................................................. 4 3.2. Packet Format ............................................ 4 3.3. Procedure................................................. 7 4. References .................................................. 10 5. Acknowledgements ........................................... 11 6. Security Considerations .................................... 11 7. Author's Address ........................................... 11 Jeyasubramanian Expires January 30, 1998 [Page 11]