ROLL Working Group R. Wakikawa Internet-Draft H. Kuwabara Intended status: Informational Toyota ITC Expires: November 30, 2008 May 29, 2008 In-Vehicle Routing Requirements in Low Power and Lossy Networks draft-wakikawa-roll-invehicle-reqs-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on November 30, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Wakikawa & Kuwabara Expires November 30, 2008 [Page 1] Internet-Draft In-Vehicle Routing Requirements May 2008 Abstract This document presents the routing requirements for in-vehicle low power and lossy networks. Automobiles are already equipped with several sensors and devices named Electronic Control Unit (ECU) for controlling, monitoring and entertainment, etc. For the future in- vehicle networks, the shift to wireless is desirable due to heavy weight and volume of cables in vehicles and to be able to efficiently install devices. However, with the limitation of low power, in- vehicle network still requires reliability and scalability in nature of the rolls of ECU. The routing protocol should support the features of low-power, high-reliability, Subnetting, QoS, Mobility, etc. This document briefly explains the in-vehicle networks and ECUs, then discusses the requirements for the future wireless in- vehicle networks. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction of In-Vehicle Networks . . . . . . . . . . . . . 6 2.1. In-vehicle BUS system . . . . . . . . . . . . . . . . . . 6 2.2. Classification of In-Vehicle Networks . . . . . . . . . . 7 2.3. In-Vehicle Network Size . . . . . . . . . . . . . . . . . 10 3. Routing Requirements of In-Vehicle Network . . . . . . . . . . 11 3.1. Low Power . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Path Reliability . . . . . . . . . . . . . . . . . . . . . 11 3.3. Subnetting Support . . . . . . . . . . . . . . . . . . . . 11 3.4. QoS Support . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.7. Network Convergence . . . . . . . . . . . . . . . . . . . 12 3.8. Manageability . . . . . . . . . . . . . . . . . . . . . . 13 3.9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.10. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log From Previous Versions . . . . . . . . . . 18 Wakikawa & Kuwabara Expires November 30, 2008 [Page 2] Internet-Draft In-Vehicle Routing Requirements May 2008 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Wakikawa & Kuwabara Expires November 30, 2008 [Page 3] Internet-Draft In-Vehicle Routing Requirements May 2008 1. Terminology We define the following terms to explain the in-vehicle networks. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Electronic Control Unit (ECU) ECU controls the driving and stability of the vehicle as well as managing usability, environmental input and safety. The role of ECU is getting spread to the vehicle systems. An ECU is connected to several sensors and actuators, which computes the input from sensors and acts accordingly to control vehicle's operation. Most of vehicles can no longer be operated without these ECUs. Several tens of ECUs are installed in each vehicle. Actuator Actuator is device to handle events of drivers, passenger and vehicles. There are two different types of actuators: automatic and manual. For instance, the wiper's actuator is triggered by an ECU when the driver controls the wiper's switch. This manual actuator waits for physical action of drivers. On the other hand, automatic light actuator turns on the lights when it gets dark. From the view of network, there aren't many differences. We treat both manual and automatic as an actuator in this document. Sensor Sensors are distributed to every corner of vehicles. Examples are fuel level sensors, tire air-pressure sensors, etc. These sensors collect the required information of vehicle's status and send the sensed information to an appropriate ECU. Rear-view and side-view cameras are also in this category. Gateway Gateway is used to inter-connect different bus systems in the in- vehicle networks. This gateway translates the bus protocol if required. In-Vehicle Network The In-Vehicle network is designed to exchange the information and the commands between ECU, Actuator and Sensors. Figure 1 shows the relationship among an ECU, sensors, and actuators. Wakikawa & Kuwabara Expires November 30, 2008 [Page 4] Internet-Draft In-Vehicle Routing Requirements May 2008 One ECU is connected with m sensors (m >= 0) and n actuators (n >= 0). All the connections are wired at this moment. However, some of wired lines will be replaced by wireless in the near future. actuator Each ECU are connected with : - sensors x m (m >= 0) +-----+ - actuators x n (n >= 0) | ECU | .. sensor +-----+ : sensor Figure 1: ECU, Sensor, and Actuator Wakikawa & Kuwabara Expires November 30, 2008 [Page 5] Internet-Draft In-Vehicle Routing Requirements May 2008 2. Introduction of In-Vehicle Networks Automobiles are recently equipped with several devices which are used for driving control, stability control, usability management, environmental management, and safety management. Electronic control unit (ECU) is a device to control automobile according to sensed information and actuator's actions. In early 1970s, a few ECUs were initially installed in vehicles. However, after advancements of IT technology, a typical vehicle now have about 100 ECUs and high-end vehicles have a few hundreds ECUs inside. Several local area network technologies dedicated for vehicles have been introduced such as Local Interconnect Network (LIN) [LIN] and Controller Area Network (CAN) [CAN1] [CAN2]. As the number of ECUs grow, volume and weight of copper and fiber became a considerable problem for vehicle's performance. Small wireless systems such as IEEE 802.15.4, IEEE 802.15.1 and IEEE 802.15.3a have been standardized and are available in the market. It is very natural to consider to shift to wireless in the in-vehicle networks. Indeed, some of the sensors already have wireless capability. For instance, the sensors for tires cannot be connected via wires due to obvious reasons. Considering the fact that the in- vehicle network is now essential to vehicle control, shifting to the "wireless" in-vehicle network has become a serious option. This section introduces the in-vehicle bus system used by current vehicles and classifies the in-vehicle network into 5 different networks. 2.1. In-vehicle BUS system The existing in-vehicle network consists of several different bus systems according to the system and its requirements. The four different bus systems are introduced in this document. Although the wireless system is not well-performed for some bus systems due to extremely high performance requirements, the goal of this document is to start activities towards the ultimate goal of replacing the all these bus systems by IP network in wireless. CAN Control Area Network (CAN) [CAN1] [CAN2] was standardized at ISO. CAN is often used for the powertrain network (see Section 2.2). The access control method of CAN is CSMA/CD (Carrier Sense Multiple Access/Collision Detection). The priority based data transmission is supported. The highest priority data can be transmitted without any delay. The supported bandwidth is from 10Kbps to 1Mbps. The maximum numbers of nodes per bus is 16. Wakikawa & Kuwabara Expires November 30, 2008 [Page 6] Internet-Draft In-Vehicle Routing Requirements May 2008 LIN Local Interconnect Network (LIN) [LIN] is a low cost serial communication bus system often used for body networks. It uses Universal Asynchronous Receiver Transmitter/Serial Communication Interface (UART/SCI), master-slaves concept, and the automatic clock synchronization for devices (so that a crystal oscillator is not required). The supported bandwidth is from 1Kbps to 20Kbps. The maximum number of nodes per bus is 16. FlexRay With the increasing number of ECUs, sensors and devices, the complexity and demands of in-vehicle network has become higher. Therefore, FlexRay [FlexRay] is being standardized by the the FlexRay Consortium. The characteristics of FlexRay is higher bandwidth support, collision-free bus access, guaranteed message latency, fault-tolerance by using dual channels. FlexRay can be used for any kind of system bus in a vehicle. The maximum bandwidth is 10Mbps. MOST Media Oriented Systems Transport (MOST) [MOST] is designed for infotainment system in a vehicle. Audio, Video and control data can be exchanged over the MOST bus. The maximum bandwidth is about 20Mbps. There is another specification for multimedia network named Audio Visual Communication-LAN (AVC-LAN) [AVC-LAN]. 2.2. Classification of In-Vehicle Networks The in-vehicle network can be classified into five different bus networks. This section introduces the five bus networks and gives the network requirements. Figure 2 is an example of an in-vehicle network. The different bus systems are inter-connected by gateways (illustrated as GW in Figure 2). Wakikawa & Kuwabara Expires November 30, 2008 [Page 7] Internet-Draft In-Vehicle Routing Requirements May 2008 ECU ECU | | drive assistance ===++=====+===+===============++======++=========++========.. || || || || || || || || || || || || ====||==++================++===||======||=========||===++===.. || || || || \\ || || ++==GW GW===++ \\ ++===GW powertrain | | BODY \\ Chassis | ==+===+==+==+===+.. =+===+===+===+===++.. || =+====+===+=.. | | | | | | | | || || | | | ECU ECU ECU ECU ECU ECU ECU ECU GW ===++ ECU ECU ECU | ==+==+==+== | | infotainment ECU ECU Figure 2: In-Vehicle Topology Powertrain Network Engine ECUs, accelerator pedal assembly, valve control motors, air intake valve controller, etc. are connected to the powertrain network. These ECUs receive the sensing information from acceleration sensors, O2 sensors, heat sensors, traction sensors and determine the action according to the information. After the determination, the engine ECUs control the fuel injection actuator, ignition actuator, valve actuator, and so on. The network requirement is extremely high. The expected network latency is from a few hundreds usec to a few ten msec between ECU, sensors, and actuators. The engine control is operated every 2 to 6 msec. Therefore, both sensors and actuators are accessed frequently. Chassis Network This network is mainly used for transmission control, traction control, Anti Lock Brake System(ABS), and suspension control, etc. By collecting the information from wheel speed sensors, height sensors, yaw sensors, engine revolution sensors, gear sensors, ECUs connected to the Chassis network activate the required actuators. The expected network latency is within about 1 msec. The frequency of these operations are every 4 to 8 msec. Wakikawa & Kuwabara Expires November 30, 2008 [Page 8] Internet-Draft In-Vehicle Routing Requirements May 2008 Body Network This network is basically designed for door lock control, door window control, side mirror control, air-bag control, keyless entry control, tire pressure monitor, air conditioner control etc. In addition, when a driver control switches such as a light switch, an ECU takes appropriate action by controlling actuators over this network. The requirement of network latency is relaxed to about 100 msec. This latency is the average time for drivers not to get frustrated while waiting for the action after controlling switches. Most of operation is carried out with event-driven traffic. Note that the communication for the air-bag control is exception in this network. Since this communication is directly related to the drivers' and passengers' safety, the network requirement is same as or even higher than the one of the powertrain network. Body network connects Body ECUs, Air-Bag ECUs, Door ECUs, keyless system ECUs, immobilizer ECUs, Seating ECUs, etc. Infortainment Network Infotainment network is installed for navigation system, audio and visual systems, telematics related systems, electronic toll collection system, etc. The network latency is not important for this network except for electronic toll collection system and hands-free cell-phone system. For instance, about 100 msec is required for the hand-free cell-phone system. On the other hand, the bandwidth requirement is higher than other networks due to the streaming data for audio and visual system and navigation systems. A few Mbps is required for these applications. In near future, this network may be responsible for more role by combining with the Chassis and the powertrain networks. For instance, vehicles may control the break system according to the map and navigation information. Drive Assistance Network Several drive assistance systems have been introduced to recent vehicles such as auto-parking system, back-view monitoring system, side-view monitoring system, cruise control system, night-view system and even future auto-driving system. This driver assistance network is laid on top of above four networks like overlay fashion. Therefore, requirements of the drive assistance network are based on the requirements of four networks. These five bus networks have different network characteristics. Therefore, it is difficult to design an in-vehicle network by using a single wireless technology. 802.15.1 can be a candidate for the Wakikawa & Kuwabara Expires November 30, 2008 [Page 9] Internet-Draft In-Vehicle Routing Requirements May 2008 higher bandwidth requirements and fast network latency and 802.15.4 can be used for non-critical connectivity but low-cost installation. Wired connectivity will be left due to the high network requirements and the importance of reliability. Therefore, ROLL routing protocol should be able to run over different layer1 technologies. When the in-vehicle network is operated by IP network, subnetting support is desired. Since different bus systems have specific tasks and network requirements, it is reasonable to divide the in-vehicle networks into several subnets (ex. five subnets in Figure 2). In this document, we assume that the future IP-based in-vehicle network consists of several different subnets such as powertrain subnet, body subnet, chassis subnet, infotainment subnet, and drive assistance subnet. 2.3. In-Vehicle Network Size This document considers typical cars and does not take commercial vehicles such as buses and cargo trucks into account. Variety of cars are available on the market. In general, cars are categorized into three classes such as compact class, sedan class, and SUV/VAN/ Truck class. The typical size of the three classes are shown in below. The information below is available at the catalogues of Toyota Vitz(Yaris), LEXUS IS350RWD, and Toyota TUNDRA [TOYOTA-HP] [LEXUS-HP]. o Compact Class: 3.785x1.695x1.520 meter (Vitz) o Sedan Class: 4.575x1.795x1.430 (IS350RWD) o SUV/VAN/Track Class: 5.809x2.029x1.935 (TUNDRA) From the network point of view, many ECUs, sensors and actuators are installed in a smaller area compared to other ROLL scenarios. The number of ECUs, sensors and actuators does not depend on the vehicle class, rather it depends on the number of vehicle's functionalities. Therefore, high-end cars are equipped with much more ECUs, sensors and actuators, while inexpensive vehicles have only a limited number of them for the basic functionalities. Wakikawa & Kuwabara Expires November 30, 2008 [Page 10] Internet-Draft In-Vehicle Routing Requirements May 2008 3. Routing Requirements of In-Vehicle Network 3.1. Low Power Although each vehicle is equipped with a battery, not all the sensors, ECUs, and actuators are operated via battery. Therefore, the ROLL routing protocol must save power consumption for these un- powered sensors, actuators, and ECUs. It might be reasonable to operate routing protocol in the power saving mode only for these un- powered device. Powered devices should assist the un-powered devices or take care of more functionalities than un-powered devices in the ROLL routing protocol. 3.2. Path Reliability Reliability is the most important factor in in-vehicle networks. The functionality of the in-vehicle network is directly related to the drivers' and passengers' safety. The ROLL routing protocol SHOULD support high path reliability. Passengers often carry big luggage, shopping bags, ski equipments in a vehicle. These cabin baggage and even passengers become obstacles of the in-vehicle wireless networks. Therefore, the reachability might be varied dynamically depending on the number of passengers and the amount of baggage in each vehicle. The ROLL routing protocol MUST calculate the path regardless of these obstacles in the dense network. If a path failure occurs, the ROLL routing protocol SHOULD also recover the path with the similar network condition of the previous path. If the path is used for the powertrain subnet, the new path SHOULD also meet the network requirements of the powertrain subnet in terms of latency and bandwidth, etc. 3.3. Subnetting Support The in-vehicle network consists of several different bus systems at this moment. The IP-based in-vehicle network consists of several subnets as we explained in Section 2.2. Therefore, the ROLL routing protocol SHOULD support subnetting. The ROLL routing protocol is capable of operating both intra- and inter- subnets. In addition, the ROLL routing protocol SHOULD be capable of subnetting-aware routing. Each subnet and each device have specific purposes and different performance requirements as shown in Section 2.2. Moreover, the topology of each subnet might be different, for instance using star-like topology for powertraine network and using multi-hop topology for body networks, etc. The ROLL routing protocol SHOULD be able to change the behavior or routing algorithm depending on subnets and their role. Some subnets are calculated by the Wakikawa & Kuwabara Expires November 30, 2008 [Page 11] Internet-Draft In-Vehicle Routing Requirements May 2008 shortest-path-first, while the other subnets might be calculated by other metrics such as latency and reliability. 3.4. QoS Support QoS support is similar requirement to the subnetting-aware routing described in Section 3.3, but QoS-aware routing indicates the path establishment is varied according to device's role. For instance, latency sensitive communication SHOULD be prioritized than the other communications. The path recovery scheme might be also different based on the role of the failed path. The best-effort is not always enough for in-vehicle networks. 3.5. Scalability A few hundreds ECUs, sensors and actuators are connected in the in- vehicle networks. The number of such devices is expected to increase in the near future. Since physical space for these devices is very limited as we explained in Section 2.3, the network density is also extremely high compared to other ROLL network scenarios. The ROLL routing protocol SHOULD be scalable for the in-vehicle network. 3.6. Latency Each ECU, sensor, and actuator is installed with a specific role and high performance requirements. If the latency cannot be achieved, it may cause danger. The usec-order latency is required in some scenarios, while the msec-order latency is the average requirements. Note that not all the devices operates wirelessly in the in-vehicle network. This is because the usec-order latency is difficult to achieve with the current wireless technology. Even if it is possible, the complexity and the reliability are still considerable issues. The ROLL routing protocol SHOULD calculate the path which meets the latency requirements of each device. 3.7. Network Convergence The ROLL routing protocol should be able to converge quickly after the path failure or node failures are occurred. The failures should not impact the entire in-vehicle networks. The local repair is preferable. When a driver cranks the engine up, the in-vehicle network should be established before vehicle's moving. Note that the part of body network is always active regardless of engine's running (ex. during the parking period) because it needs wait for actions from the driver such as the keyless entry system, etc. Wakikawa & Kuwabara Expires November 30, 2008 [Page 12] Internet-Draft In-Vehicle Routing Requirements May 2008 3.8. Manageability Autoconfiguration is required for some parts of the in-vehicle network. Although the critical part of subnets such as the powertrain and the chassis subnets are not managed dynamically, the infotainment and the body subnets should be extensible by users anytime. For instance, there are cases where a user purchases a navigation system and installs it onto the vehicle by him/herself (i.e. not by dealer). Moreover, the average life-cycle of a vehicle is about 10 years. During this period, the network might be extended or updated. The ROLL routing protocol should be extensible for new functions and devices. Therefore, the ROLL routing protocol should support auto-configuration for easy installation of devices and extensibility. The ROLL routing protocol SHOULD NOT force autoconfiguration to all the devices in the in-vehicle network. Some part of the in-vehicle network such as the powertrain subnet MUST be ready right after starting the engine. The static configuration is preferable in terms of quick bootstrap, reliability and stability of networks. The powertrain network is built-in and is installed only by vehicle manufacturers. Most of the devices in the powertrain subnet is not going to shift to wireless due to the extremely high requirements and duties. 3.9. Mobility Mobility is not required for in-vehicle network right now. All ECUs, sensors and actuators are pre-installed by vehicle manufacturers and the placement is very stable in a vehicle. However, if devices are un-wired in the future in-vehicle network, several devices such as navigation display and some switches can be moved in a vehicle. Thus, mobility support is optionally required for the ROLL routing protocol. Since each device cannot move widely due to the limit of vehicle spaces, topology change is not frequent depending on the wireless transmission range. However, the path reliability and network latency will be varied due to the movements. The ROLL routing protocol should detect such network conditions changes and update the topology to adequate condition for each device when necessary. 3.10. Security In-vehicle network directly effects drivers' and passengers' safety. The security is extremely important. Several low-level (L1 and L2) security mechanisms are employed for in-vehicle network. From the routing point of view, a malicious node should not intrude the in- Wakikawa & Kuwabara Expires November 30, 2008 [Page 13] Internet-Draft In-Vehicle Routing Requirements May 2008 vehicle network and should not disturb the in-vehicle network. To exclude such security vulnerability, the ROLL routing protocol SHOULD support encryption and authentication of devices. The security support is activated specially for wireless devices. Since not all the devices in vehicles are going to be wireless and some parts of network are hidden inside the vehicle's body, security support is not required to the entire in-vehicle network. Security support sometime brings protocol complexity and protocol overhead. It is not acceptable if high network requirements cannot be achieved because of security support. The physical level security approaches (securing powertrain network physically) are taken for some part of networks. Wakikawa & Kuwabara Expires November 30, 2008 [Page 14] Internet-Draft In-Vehicle Routing Requirements May 2008 4. IANA Considerations This document does not require IANA Action. Wakikawa & Kuwabara Expires November 30, 2008 [Page 15] Internet-Draft In-Vehicle Routing Requirements May 2008 5. Security Considerations There is no security concern because of informational document. Wakikawa & Kuwabara Expires November 30, 2008 [Page 16] Internet-Draft In-Vehicle Routing Requirements May 2008 6. References 6.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [CAN1] Road vehicles - Interchange of digital information - controller area network (CAN) for high-speed communication. Technical Report 11898/Amd:1995, ISO, 1995. [CAN2] Road vehicles - Low-speed serial data communication Part 2: Lowspeed controller area network (CAN). Technical Report 11519- 2:1994, ISO, 1994 [MOST] MOST Specification Framework Rev.1.1. Technical report, MOST Cooperation, 1999. http://www.mostcooperation.com [LIN] LIN Specifications, LIN Consortium, http://www.lin-subbus.org/ [FlexRay] FlexRay Specifications, The FlexRay Consortium, http://www.flexray.com/ [AVC-LAN] [TOYOTA-HP] http://www.toyota.com [LEXUS-HP] http://www.lexus.com Wakikawa & Kuwabara Expires November 30, 2008 [Page 17] Internet-Draft In-Vehicle Routing Requirements May 2008 Appendix A. Change Log From Previous Versions initial document Wakikawa & Kuwabara Expires November 30, 2008 [Page 18] Internet-Draft In-Vehicle Routing Requirements May 2008 Authors' Addresses Ryuji Wakikawa Toyota ITC 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: ryuji@jp.toyota-itc.com Hiroshi Kuwabara Toyota ITC 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: h-kuwabara@jp.toyota-itc.com Wakikawa & Kuwabara Expires November 30, 2008 [Page 19] Internet-Draft In-Vehicle Routing Requirements May 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wakikawa & Kuwabara Expires November 30, 2008 [Page 20]