Network Working Group K. Uehara Internet-Draft Keio Univ. Intended status: Informational M. Imaike Expires: May 12, 2011 FEAC K. Shima, Ed. IIJ II November 8, 2010 The Transport Protocol for Decentralized Probe Applications for Vehicles draft-uehara-dtnrg-decentralized-probe-transport-00 Abstract (This document is a description of the decentralized viechle to viechle probe mechanism currently being prototyped. The main purpose of disclosing this -00 document is to introduce the application idea and start discussion within the DTNRG. Because of this, the current mechanism described in this docment does not conform to the protocols defined in the DTNRG at this moment. The mechanism should be updated based on the discussion in this group.) This document describes the transport protocol specification used for the decentralized probe system for vehicles. The probe system exchanges probe messages between vehicles using a wireless communication methods with low bandwidth and lossy properties. The communication environment dynamically changes as vehicle moves. The protocol try to utilize the limited bandwidth as much as possible and increase reachability rate by using sender-side error correction mechanism. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 12, 2011. Uehara, et al. Expires May 12, 2011 [Page 1] Internet-Draft DCP Transport November 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Message Multiplex/De-multiplex . . . . . . . . . . . . . . . . 4 5. Message Fragment/Reassemble . . . . . . . . . . . . . . . . . 4 5.1. Reed-Solomon Processing . . . . . . . . . . . . . . . . . 5 6. Packet Sending Rate Control . . . . . . . . . . . . . . . . . 6 7. ICM Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 7.1. ICM Common Header . . . . . . . . . . . . . . . . . . . . 7 7.2. ICM Multiplex Header . . . . . . . . . . . . . . . . . . . 8 7.3. ICM Fragment Header . . . . . . . . . . . . . . . . . . . 9 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Uehara, et al. Expires May 12, 2011 [Page 2] Internet-Draft DCP Transport November 2010 1. Introduction Thanks to the the advance of the Internet and the wireless communication technology, it becomes possible to equip communication mechanisms for vehicles for various purposes, such as for safety applications, entertainment applications, and so on. Recently, another approach utilizing the DTN (Delay Tolerant Network) technology for inter-vehicle communication is attracting people from both academy and industry. One of the application of the approaches is decentralized probe system for traffic information. It is considered that by combining the existing centralized approach for traffic monitoring and the proposed decentralized approach, more detailed information exchange is possible and wider area can be covered. This document proposes a standard way to exchange packets between vehicles. 2. Terminology ICM: Inter-vehicle communication module. 3. Protocol Overview Each vehicle is equipped with at least one ICM (Inter-vehicle communication module) device. ICM interacts with other ICM devices equipped in other vehicles using the UDP mechanism. ICM receives application messages which are generated by the application software (e.g. traffic information generator) in the same vehicle and broadcasts to other ICM devices nearby as ICM packets. It also receives broadcasted packets from other ICM devices, extract application messages and pass them to the application software. To utilize the lower layer link bandwidth as much as possible, the ICM device uses the following two techniques. 1. Message multiplexing/de-multiplexing 2. Message fragmentation/reassemble with FEC Since the lower layer media may only have limited bandwidth, the protocol tries to multiplex application messages into one UDP packet whenever possible. The number of multiplexed messages depends on the MTU size of the lower layer media and the size of each application messages. When the ICM device receives a multiplexed packet, it de- multiplexes the received packet and passes each message to upper layer applications. Uehara, et al. Expires May 12, 2011 [Page 3] Internet-Draft DCP Transport November 2010 On the other hand, some application messages may be bigger than the maximum allowed transmission size of the link layer. In this case, the ICM device fragments the message into several blocks to fit to the MTU size, and add additional error recovery information using the Reed-Solomon Coding. Since the packets are broadcasted and no acknowledgement messages is defined, the FEC mechanism is adopted to reduce the loss of the fragmented packets which causes the entire message loss. The underlying layer 2 mechanism is out of the scope of this document. The requirements to the lower layer media is as follows. o UDP and IP (either IPv4 or IPv6) capability 4. Message Multiplex/De-multiplex If the ICM packet that contains an application message is smaller than the MTU of the outgoing interface, the ICM device may multiplex following ICM packets up to the MTU size. Every ICM packets is concatenated and packed into a UDP payload as long as the total size of the UDP packet does not exceeds the MTU size. When receiving an ICM packet, the node first checks the ICM payload length of the first ICM packet in the received UDP payload. If the size of the UDP payload is bigger than the size of the first ICM packet, then extract following ICM packets until no extra bytes are found in the UDP payload. Each extracted ICM packets is passed to the upper layer application after removing the ICM header described in Section 7. 5. Message Fragment/Reassemble If the application message passed from the upper layer to the ICM layer is bigger than the link MTU size, the message will be fragmented into several ICM packets. Since this Inter-vehicle communication protocol does not provide message reachability confirmation, the Reed-Solomon error correction mechanism is used when making each fragment. Each ICM packet header contains the partial length of the fragmented data and offset from the original message. Since the Reed-Solomon mechanism is used, even if some of the fragmented packets are lost, the original message can be reassembled. Once the application message is reassembled, the message is passed to the upper layer application. Uehara, et al. Expires May 12, 2011 [Page 4] Internet-Draft DCP Transport November 2010 5.1. Reed-Solomon Processing A large message will be fragmented to fit to the link MTU. Since the link is typically provided as a wireless media, the link quality is not always stable. To avoid losing application message as much as possible, the large message is encoded using the Reed-Solomon procedure. The parameter of coding is described in the ICM Fragment Header as described later in Section 7.3. In this section, we use 4 as the bit length of symbols, and 11 as the number of data symbols as example parameters. With these parameters, we can encode 5 bytes data into 7 bytes data including 2 bytes error correction code, and we can recover 1 byte error at maximum. When the message is fragmented and encoded, the original message is first divided into several messages using the unit of the fragmented message size. The Reed-Solomon coding is done using the n-th bytes of each fragmented message. With the parameters assumed in this section, 5 packets are sent first and 2 packets which include error correction data follow the data packets. If the last part of the encoded block is shorter than the 5 packets, then it is assumed that all-0 data are virtually appended to the end of the message. Figure 1 shows an example of a large message fragmented into 8 parts. Since we can only encode 5 bytes at one time with the currently assumed parameters (4 bits symbol data, and 11 data symbols), the first 5 fragment packets are sent first. The following 2 packets include the error correction data calculated based on the Reed- Solomon coding. As described in the previous paragraph, the calculation is done based on the position of each data in the each fragmented packets. The first bytes of the two error correction packets is calculated with the first bytes of the previously sent 5 data packets. The following error correction data are calculated in the same way. In this case, the second data block does not have full data, because of the original message is too short to fill the last block. In this case, the Reed-Solomon coding is performed as if there were data in the missing positions. The value of the virtual data is 0. Uehara, et al. Expires May 12, 2011 [Page 5] Internet-Draft DCP Transport November 2010 Error Original message correction packets <----------------------> <-------> +--+ +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | | | <= 5 of 1st bytes and 2 bytes ECC | | | | | | | | | | | | | | <= 5 of 2nd bytes and 2 bytes ECC | | | | | | | | | | | | | | <= (same procedures follows) | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | 00 00 | | | | <= missing parts are | | | | | | 00 00 | | | | considered as 0 | | | | | | 00 00 | | | | | | | | +--+ 00 00 | | | | | | | | 00 00 00 | | | | | | | | 00 00 00 | | | | +--+ +--+ +--+ +--+ Figure 1: Reed-Solomon Processing Example 6. Packet Sending Rate Control Since the communication model defined in this specification is not centralized, and not based on the one to one communication model, it is impossible to achieve precise information of the packet sending rate. To avoid link congestion, all the sender node must control its packet sending rate autonomously. One assumption in this specification is that the available bandwidth of the link is notified by the lower layer protocol stack. The packet sending/receiving layer should behave not to overuse the available bandwidth, and not to overload the link so that other nodes nearby can send their packets. A reference congestion control scheme defined in this specification is as follows. The node periodically counts the number of nodes nearby by monitoring the broadcast (in IPv4) or multicast (in IPv6) packets on the link. The available bandwidth for this node is calculated as (Available link bandwidth notified by the lower layer) / (number of neighboring Uehara, et al. Expires May 12, 2011 [Page 6] Internet-Draft DCP Transport November 2010 nodes). The packet sending function must respect the value and try to send packets within the available bandwidth to the node. 7. ICM Packet Format An application message, or one of the fragmented application messages are encapsulated by the ICM packet header described below. All the ICM packets are sent as UDP packets. 7.1. ICM Common Header The following header is the ICM common header. Based on the value of the Type field, every ICM header has its unique header format. 0 7 8 15 16 23 24 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Packet Type | Type specific data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : : IP source: The link-local address of the interface of the source node of the packet The IPv6 link-local address [RFC4291] assigned to the outgoing interface is used if the communication is done in IPv6. The dynamically configured IPv4 link-local address [RFC3927] assigned to the outgoing interface is used if the communication is done in IPv4. IP destination: The link-local multicast or broadcast address of the outgoing medium. The IPv6 all-node multicast address [RFC4291] of the outgoing medium is used if the packet is sent as an IPv6 packet, otherwise the IPv4 link-local broadcast address [RFC0919] is used if the packet is sent as an IPv4 packet. Next header: 17 (UDP) Source port: (TO BE ASSIGNED BY IANA) Destination port: Same as the value of the source port Uehara, et al. Expires May 12, 2011 [Page 7] Internet-Draft DCP Transport November 2010 Version: The ICM header format version The version number 1 is the only version currently defined. Packet Type: The packet type of the following ICM packet. Type specific data: The type specific data The ICM packet is broadcasted (in IPv4) or multicasted (in IPv6) to all the neighboring nodes. The version number of the ICM packets is 1 at this moment. Based on the processing type, different ICM packet headers are defined. 7.2. ICM Multiplex Header 0 7 8 15 16 23 24 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message data (length = Length) + : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Version: 1 Packet Type: 0 Length: The length of the message data When multiple messages are multiplexed in one UDP packet, the ICM multiplex messages are concatenated. The total length of the multiplexed UDP packet must not exceed the link MTU. Uehara, et al. Expires May 12, 2011 [Page 8] Internet-Draft DCP Transport November 2010 7.3. ICM Fragment Header 0 7 8 15 16 23 24 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meesage Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Unit | Smbl Bit Len | Data Smbl Cnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Fragmented Message data (length = Length) + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Version: 1 Type: 1 or 2 The packet type 1 is used for the data packets and the packet type 2 is used for the error correction packets. Length: The length of the fragmented message data Message Length: The length of the original message Message Offset: The offset of this fragmented message data from the beginning of the original message This field includes the offset value of the fragmented part of the message, if the Packet Type value is 1. If the Packet Type value is 2, the field is set to 0. Message Identifier: A unique identifier assigned to the series of fragmented packets Sequence Number: The sequence number of fragmented packets and error correction packets Uehara, et al. Expires May 12, 2011 [Page 9] Internet-Draft DCP Transport November 2010 Length of Unit: The unit size of the fragmented message data Smbl Bit Len: The bit length of the Reed-Solomon coding Data Smbl Cnt: The number of symbols used as data symbols in the Rees-Solomon processing 8. Protocol Constants ICM_VERSION: 1 ICM_TYPE_MULTIPLEX: 0 ICM_TYPE_FRAGMENT: 1 ICM_TYPE_ECC: 2 9. IANA Considerations The UDP port number should be assigned by IANA. 10. Security Considerations In this layer, message integrity is not assured. The validation of the message contents is performed in the application layer. 11. Normative References [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, October 1984. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Uehara, et al. Expires May 12, 2011 [Page 10] Internet-Draft DCP Transport November 2010 Authors' Addresses Keisuke Uehara Keio University 5233 Endo Fujisawa-shi, Kanagawa 252-8520 Japan Email: kei@wide.ad.jp Masayoshi Imaike FEAC International 3-4-11 Mita Minato-ku, Tokyo 108-0073 Japan Email: isle@feac.jp Keiichi Shima (editor) IIJ Innovation Institute Inc. 1-105 Kanda-Jinbocho Chiyoda-ku, Tokyo 101-0051 Japan Email: keiichi@iijlab.net Uehara, et al. Expires May 12, 2011 [Page 11]