INTERNET-DRAFT Petr Cach, Petr Fiedler Category:Experimental Brno University of Technology <draft-cafi-can-ip-00.txt> March 2001 Comments are welcome at: Expires: September 2001 cach@dame.fee.vutbr.cz fiedlerp@dame.fee.vutbr.cz IP over CAN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This protocol is intended to allow direct connection of low cost devices to Internet using an inexpensive serial communication bus. Presented protocol is not intended for hard real-time operations. Cach & Fiedler Experimental [Page N] INTERNET-DRAFT IP over CAN March 2001 1. Introduction At present time there is no standard technology that would allow connection of low cost devices to Internet through inexpensive serial communication bus. To connect low cost devices to Internet the only standardized and inexpensive interface is a point-to-point serial interface (eg. RS-232) using PPP or SLIP protocols. The main disadvantage of these protocols is operation over point-to-point interfaces only. In automation there are used inexpensive serial communication bus technologies (eg. RS-485, CAN, etc. ) that allow connection of many devices to a single serial bus and those serial buses could be used to transfer IP protocol datagrams as well. However, there is no standardized protocol that would define how to transfer IP datagrams over such inexpensive serial buses. The purpose of this document is to present a draft specification of a protocol that would define how to transfer IP datagrams over CAN. 2. Controller Area Network Controller Area Network (CAN,CAN-bus) is a serial communication bus that is used in automation and automotive industry. CAN allows communications speeds up to 1 Mb/s and bus lengths over 1 km, however maximum bit rate depends on bus length. The access method is CSMA/CR. This access method guarantees that in case of collision the frame with higher priority is not corrupted. The main advantage of CAN is reliability and low cost of implementation. At present time CAN is used in a wide variety of applications, ranging from cars and trucks to process and building automation. CAN specifications (ISO 11898, ISO 11519) describe only physical and link layers of well known OSI model. Above CAN are used many different protocols that define higher level protocols, however at present time there is no open standard that would define how to use CAN to transfer datagrams of the most important protocol of this decade - datagrams of Internet Protocol. 3. IP over CAN To specify how to transfer IP datagrams over CAN it is necessary to define: - How to address devices on CAN (CAN nodes); - Structure of CAN identifier; - Distribution of Internet addresses among CAN nodes; - Fragmentation of IP datagrams; - Timing requirements (minimum and maximum delays). 3.1 Addressing of CAN nodes Number of nodes connected to one bus is physically limited by properties of available CAN transceivers and the transceivers usually allow less than 127 devices connected to one bus. CAN message contains identifier field (11 bits or 29 bits long) which can be used for addressing purposes. This identifier identifies content of message and each particular node can use this identifier to automatically ignore messages that are of no importance for that particular node. It is obvious, that the header of IP datagram does not fit into the CAN identifier. Also it seems to be useful to include in the identifier both address of receiver and address of sender. For this reasons is seems adequate to use CAN according to specification CAN 2.0B that uses 29 bit long identifier and to differentiate devices on the same bus by eight bit "CAN-IP" address. Number of nodes connected to one IP over CAN subnet is thus limited to approx. 256 devices (some addresses are reserved). The "CAN-IP" address corresponds to the least significant byte of IP address. So a device with IP address of 147.229.14.45 would have "CAN-IP"address of 45. 3.1.1 Structure of CAN identifier in IP over CAN 27 24 0 +------+----+---------------------------------------------+ | PRIO | MG | MG Dependent | +------+----+---------------------------------------------+ | | | | | +- Content depends on MG | +---------------------- Message Group (3 bits) +---------------------------- Priority (2 bits) Figure 1: Bit assignment in CAN identifier Identifier of CAN message contains following fields: - Priority (2 bits) - priority of a message; - Message group (3 bits) - message group is used to interpret the next 24 bits; - Additional 24-bits - these bits depend on message group used. Message group (MG) is used to distinguish among different message groups. Each group consists of messages that are used for a particular service. Placement of MG to the beginning of identifier also allows to differentiate priority of message groups in a way that minimizes risk of congestion of a bus. There are defined following message groups: - IP address assignment messages - these messages will be used during assignment of IP addresses to nodes; - DID Check message - Duplicate ID Check - test if specified "CAN-IP" address is free to use in cases when C-DHCP server is not responding; - Fragmented IP datagram - these messages will be used for transmission of IP datagrams when the node is fully configured and in operational state. 3.2 IP address assignment messages (C-DHCP) These messages are distinguished by value 0 in MG field. Messages in this group are used for assignment of IP address to a node connected to CAN bus. It is required that all devices contain unique hardware identifier (HWID). This HWID is assigned by manufacturer of that particular device. Examples of such unique identifiers are MAC address in Ethernet and Neuron ID in LonWorks networks. Length of HWID is not specified here, this specification only limits the maximum length of this identifier to 32 octets (32 bytes). IP address assignment messages use following structure of CAN identifier: - Priority (PRI - 2 bits) - priority of message; - Message group (MG - 3 bits) - value is 0 ('000b'); - Message type (MT - 2 bits) - value depends on type of message; - More IP addresses (MIP - 1 bit) - indicates whether primary or additional IP is being assigned; - More Fragments (MF - 1 bit) - indicates whether the receiver should expect more fragments; - Fragment Counter (FC - 4 bits) - contains fragment number; - XDATA (XDATA1:XDATA2 - 16 bits) - data that take part in bus arbitration. 27 24 23 22 20 16 0 +------+----+---+---+----+------+------------+------------+ | PRIO | MG |MIP| MF| MT | FC | XDATA1 | XDATA2 | +------+----+---+---+----+------+------------+------------+ | | | | | | \ / | | | | | | +- Depends on MT | | | | | +-- Fragment Counter (4 bits) | | | | +--------- Message Type (2 bits) | | | +------------- More Fragments (1 bit) | | +----------------- More IP addresses (1 bit) | +---------------------- Message Group (3 bits) +---------------------------- Priority (2 bits) Figure 2: IP address assignment message identifier During the process of IP address assignment there are defined following types of messages: - Fragmented request and response for IP address assignment arbitration; - Message which assigns IP address to a device that "won" the arbitration; - Unfragmented message that forces a node(s) to request new IP address. 3.2.1 Request and response for an IP address assignment arbitration Device that requests assignment of IP address sends CAN Remote Frame with identifier filled with following values: MG = 1h (001b) MT = 0 (00b) MIP = 0 or 1 MF = 0 or 1 FC = 0 .. 15 XDATA - contains fragmented HWID of node that sends the request. Value of MIP is 0 if the device requests primary IP address. If the device needs more than one IP address it should send request with the MIP bit is set to 1 which indicates request for additional (non-primary) IP address. Field XDATA is used to transfer fragments of the unique HWID of device that requests the IP address. In the first message (first fragment, FC = 0) the XDATA contains first (least significant) and second byte of HWID, in the second message (second fragment, FC = 1) the XDATA contains third and fourth byte of HWID, etc. If there will be additional fragments the MF bit must be set to 1. In the last fragment the MF bit has to be set to 0. Fragment Counter (FC) is set to 0 in the first fragment and is incremented by 1 in each consecutive fragment. This fragmentation protocol is able to transmit HWID up to 32 bytes long. After transmission of the fragment the sender has to wait for response from a C-DHCP server for a maximum time of T1. The response is Data Frame (with no data) that contains the same identifier as was in the request. If the sender does not receive response until the timeout period T1 expires, it should start the request procedure again from the first fragment. After reception of a response from the C-DHCP server the requesting device may send next fragment. After reception of the response with last fragment (MF = 0) the requesting device should wait for period of T2 for a message that assigns an IP address. If the device does not receive a IP address assigning message, it should start again the request for IP address. 3.2.2 Message that assigns IP address After reception of last fragment of request for an IP address the C-DHCP server has to send both response to that request and a message that assigns IP address. Message that assigns an IP address is based on CAN Data Frame and may be fragmented if necessary (e.g. IP version 6). The CAN identifier of message that assigns IP address is filled by following values: MG = 1 (001b) MT = 1 (01b) MIP = 0 or 1 - according to request MF = 0 or 1 - according to FC FC = 0 .. 15 - fragment counter used as above XDATA1 = 255 XDATA2 = 255 The IP address is transmitted in the data field of Data Frame and is transmitted MSB (Most Significant Byte) first. 3.2.3 Message that forces reconfiguration of nodes Message which forces reconfiguration of nodes is used to force the addressed node(s) to request a new IP address. The message may be addressed to either one or all devices (unicast or broadcast). In case of unicast the addressed device must discard current IP address (addressed one) and must apply for new IP address as a replacement of the discarded one. In case of broadcast all connected devices must discard all IP addresses and apply for new ones. Message that forces reconfiguration of nodes is based on CAN Data Frame and has following identifier: MG = 1 (001b) MT = 2 (10b) MIP = 0 MF = 0 FC = 0 .. 15 - fragment counter used as above XDATA1 = 255 XDATA2 = 0..255 - address of node that must reconfigure If the XDATA2 = 255 then all devices on the bus must reconfigure. 3.3 Fragmentation protocol of IP datagrams The CAN bus was originally developed for use in automotive communications. The automotive applications need to send small amount of data very often. Thus the CAN is able transmit only up to 8 bytes of data in one Data Frame. In order to transmit messages longer then 8 bytes is necessary to use some kind of fragmentation. Proposed fragmentation protocol is inspired by ISO 15765-2. ISO 15765-2 specifies transfer protocol between two devices which use acknowledgement. This allows only point-to-point data transmision. Because the IP protocol specifies possibility to broadcast data, it is necessary to add some extensions to this fragmentation protocol. The fragmentation protocol allows transmission of only one fragmented IP datagram between two nodes in each direction at the same time. This requirement prevents corruption of IP datagrams. 3.3.1 Structure of message identifier Fragmentation protocol uses Data Frames of CAN bus protocol only, no Remote Frames are used. The message identifier of each frame is divided into eight fields of different size. - PRI (Priority - 2 bits) - defines priority group of the CAN message; - MG (Message group - 3 bits) - defines type of message group. IP datagram messages belong to the group 7; - R (Reserved - 2 bits) - reserved for future use. Both bits have recessive value; - MT (Message type - 2 bits) - specifies the type of fragmentation protocol message; - PARAM (Parameters - 4 bits) - specifies the parameters of current fragmentation protocol message. The meaning di#ers according to the specified Message Type; - SOURCE (Source address - 8 bits) - this field contains address of sending device. The value of the address is equal to the lowest eight bits of IP address of source device; - DESTINATION (Destination address - 8 bits) - this field contains destination address. The value of the address is equal to the lowest eight bits of IP address of destination device. 27 24 23 22 20 16 0 +------+----+---+---+----+------+------------+------------+ | PRIO | MG | R | R | MT | Param| Source | Destination| +------+----+---+---+----+------+------------+------------+ | | \ / | | | | | | \ / | | | +- Destination | | | | | | Address | | | | | +- Source address | | | | +-- Message Parameters (4 bits) | | | +--------- Message Type (2 bits) | | +--------------- Reserved (2x1 bit) | +---------------------- Message Group (3 bits) +---------------------------- Priority (2 bits) Figure 3: IP datagram fragment message identifier There are defined three types of fragmentation protocol messages. Two of them are used for data flow control, one for data transfer. The message types are distinguished by value in MT field of CAN identifier (see Tab. 1). Message Type Meaning ------------------------------------------ 0 Reserved for future use 1 First Frame (FF) 2 Consecutive Frame (CF) 3 Flow Control Frame (FC) Table 1: Fragmentation protocol message types 3.3.2 Message Type First Frame - FF Transfer of an IP datagram is started by this frame. It specifies the total length of transferred data message. CAN message identifier CAN message data +---+---+---------------+ +----+---------------+ | MT | PARAM | | 0 | 1 .. 7 | +---+---+---------------+ +----+---------------+ | 0 | 1 | XDL | | DL | reserved | +---+---+---------------+ +----+---------------+ Figure 4: First Frame definition - XDL (Extended Data Length - 4 bits) - specifies upper part of segmented data message length. - DL (Data Length - 1 byte) - the first byte of data part of CAN message specifies the lower part of the segmented data message length. So the total length is represented by 12 bits. It allows to transfer data messages up to 4095 bytes long. The remaining data bytes are reserved for future use. Consecutive Frame - CF All data of the segmented data message are transferred using Consecutive Frames. CAN message identifier CAN message data +---+---+---------------+ +--------------------+ | MT | PARAM | | 0 .. 7 | +---+---+---------------+ +--------------------+ | 1 | 0 | SN | | app. data | +---+---+---------------+ +--------------------+ Figure 5: Consecutive Frame definition - SN (Sequence Number - 4 bits) - the sequence number is used to detect duplication or loss of Consecutive Frames. It's range is zero to fifteen. The first CF sent after the First Frame has Sequence Number initialized to one, each following CF has SN incremented by one. Upon overflow the SN is initialized back to zero. All eight data bytes of CAN data frame should be used to transmit application data. Flow Control Frame - FC In case of unicast (point-to-point) data transfers the Flow Control is used to maintain the transmission. It informs the sender of the status of the data transmission. CAN message identifier CAN message data +---+---+---------------+ +----+----+----------+ | MT | PARAM | | 0 | 1 | 2 .. 7 | +---+---+---------------+ +----+----+----------+ | 1 | 1 | FS | | BS | ST | reserved | +---+---+---------------+ +----+----+----------+ Figure 6: Flow Control Frame definition - FS (Flow Status - 4 bits) - status of the current data transmission. In the current proposal is defined only one value, see Tab 2. The remaining values are reserved for future use. Flow Status Meaning ----------------------------------------------------------- 1 FC.CTS - Flow Control.Clear to send. This parameter value is sent to the sender to resume message transmission. Other values Reserved for future use Table 2: Flow Control frame status - BS (Block Size - 1 byte) - value of Block Size defines how many Consecutive Frames can be sent without immediate FlowControl.ClearToSend message from receiving network entity. The value is accepted only upon reception of the FC.CTS frame that follows the First Frame. The Block Size parameter shall be within the range of 0 to 255 (see Tab. 3). - ST (Separation Time - 1 byte) - value of Separation time defines the minimum time gap between the transmission od Consecutive Frames. The time is specified by the receiver and kept by the sender for a particular message transmission. The value is accepted only upon reception of the FC.CTS frame that follows the First Frame. Block Size Meaning ---------------------------------------------------------- 0 No further flow control shall be performed during the transmission of CF's. FC frame is sent only after FF. 1 .. 255 Flow control will be used accordingly. Table 3: Flow Control frame Block Size 3.3.3 Transmission sequence The transmission sequence differs according to the type of transmission - broadcast or unicast. In case of unicast transmission the whole flow control mechanism shall be used. In case of broadcast transmission, no flow controll is possible. Unicast transmission If the destination address is other then 255 then the message is sent as unicast message (see Fig. 7). The transmission is started by the sender by sending the First Frame. The sender then waits for an acknowledgement from receiver. The Flow Control Frame of type Clear to Send contains parameters Block Size (BS) and Separation Time (ST). After reception of FC.CTS, the sender starts sending data of segmented data message using Consecutive Frames. After the number of successive CF formerly specified by BS parameter the sender stops transmission and waits for Flow Control frame. After reception of FC.CTS, the sender sends next block of CF's, until the current transmission is finished. The CF's in one block are sent with time gap specified by the ST parameter set by receiver. sender receiver | FF, data length = 40 | | -----------------------> | | | | FC.CTS, BS = 3 | | <----------------------- | | CF.SN = 1 | | -----------------------> | | CF.SN = 2 | | -----------------------> | | CF.SN = 3 | | -----------------------> | | | | FC.CTS | | <----------------------- | | CF.SN = 4 | | -----------------------> | | CF.SN = 5 | | -----------------------> | Figure 7: Unicast fragmentation protocol Broadcast transmission When the destination address equals 255, the message is sent as broadcast message (see Fig. 8). In this case no flow control frames are used. The transmission is introduced by the First Frame, which specifies length of segmented data message. After that follows the rest of data message in the form of Consecutive Frame. Each frame is separated from the others by a time gap, which value is arbitrary for each device so maximum time gap allowed must be used. sender receiver | FF, data length = 40 | | -----------------------> | | CF.SN = 1 | | -----------------------> | | CF.SN = 2 | | -----------------------> | | CF.SN = 3 | | -----------------------> | | CF.SN = 4 | | -----------------------> | | CF.SN = 5 | | -----------------------> | Figure 8: Broadcast fragmentation protocol 3.4 DID Check message After reset of a device every device has to apply for appropriate number of IP addresses. During normal operation these IP addresses are assigned to all devices by a C-DHCP server. To assure trouble free operation in case of C-DHCP server failure the device may use the IP address it had before it was restarted (e.g. the IP address was saved into EEPROM). However to use the former IP address the device has to check if another device does not use identical "CAN-IP" address by following procedure: 1. The device has to apply for an IP address assignment from the C-DHCP server at least N times. 2. If there was no reply from the C-DHCP server the device has to send DID Check message with "CAN-IP" address that it intends to use. 3. The device has to wait for an DID Check response for period of T4. If the device receives the DID Check response during the T4 the device is not allowed to use the tested address. If the device receives during T4 DID Check message with same address as it intends to use the device is not allowed to use the tested address. 4. If the device has not received any DID Check response it has to send the DID Check message again and again has to wait for a response for T4. If the device receives the DID Check response during the T4 the device is not allowed to use the tested address. If the device receives during T4 DID Check message with same address as it intends to use the device is not allowed to use the tested address. 5. If the device did not recieve the DID Check response it may switch to operational state and use the intended "CAN-IP" address. The DID Check message is based on CAN Remote Frame, structure of identifier is in Fig. 9, the identifier fields are filled with following values: MG = 4 (100b) DEST - contains "CAN-IP" address which is being tested 27 24 16 8 0 +------+----+------------+------------+------------+ | PRIO | MG | 0xFF | 0xFF | Destination| +------+----+------------+------------+------------+ | | | | | +-- CAN IP Address | | under test | +---------------------- Message Group (3 bits) +---------------------------- Priority (2 bits) Figure 9: DID Check and Response identifier The DID check response is based on CAN Data Frame, the CAN identifier is same as in the DID Check message. During normal operation all devices must "listen" for DID Check messages and DID Check response. If any device receives DID Check message with its "CAN-IP" address it must send DID Response as soon as possible and not later than T5 after reception of DID Check message. If any device receives DID Check response with its "CAN-IP" address it must cancel all its operations and switch to a nonactive state. 4. Conclusion Specification of IP over CAN bus is still in development, some refinements and extensions will follow. We expect that the work will continue in following steps: - Specification of properties of gateway between CAN bus and Ethernet including C-DHCP description; - Definition of required/recomended values and time constants of this protocol; - Implementation of IP over CAN protocol to a 8-bit microprocessor; - Realization of the CAN to Ethernet gateway; - Specification of requirements on bus topology and bus timing according to the desired length and number of devices; Please do not hesistate and send your commnets to the authors. 5. References [1] Robert Bosch GmbH, "CAN specification 2.0", 1991, can be downloaded from: http://www.bosch.de/de_e/productworld/k/products/prod/can/docu/ can2spec.pdf [2] Postel, J., "Internet Protocol", RFC 791, STD 5, September 1981 [3] Deering, S.Postel, and Hinden, R., "Internet Protocol, Version (IPv6) specification", RFC 2460, December 1998 6. Authors addresses Petr Cach Petr Fiedler UAMT FEI UAMT FEI Brno University of Technology Brno University of Technology Bozetechova 2 Bozetechova 2 612 66 Brno 612 66 Brno Czech Republic Czech Republic Fax: +420 5 41141123 Fax: +420 5 41141123 E-mail: cach@dame.fee.vutbr.cz E-mail: fiedlerp.fee.vutbr.cz 6. Full copyright statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document expires September 2001.