One document matched: draft-wakikawa-roll-invehicle-reqs-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 13:35:44 |