Network Working Group K. Kim, Ed.
Internet-Draft Ajou University
Expires: September 5, 2007 Soohong Daniel Park, Ed.
SAMSUNG Electronics
G. Montenegro
Microsoft Corporation
I. Chakeres
Boeing
C. Perkins
Nokia
March 4, 2007
Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing
draft-montenegro-6lowpan-dymo-low-routing-02
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 September 5, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Kim, et al. Expires September 5, 2007 [Page 1]
Internet-Draft DYMO-low March 2007
Abstract
This document specifies how to use the Dynamic MANET On-demand
Routing Protocol over IEEE802.15.4 networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Simplifications for DYMO over IEEE 802.15.4 . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 6
3.2. DYMO-low Messages . . . . . . . . . . . . . . . . . . . . 6
3.2.1. DYMO-low Routing Messages . . . . . . . . . . . . . . 6
4. Detailed operation . . . . . . . . . . . . . . . . . . . . . . 9
4.1. DYMO-low Routing Table Operations . . . . . . . . . . . . 9
4.1.1. Creating or Updating a Route Table Entry from New
Routing Information . . . . . . . . . . . . . . . . . 9
4.2. Routing message . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Routing message creation . . . . . . . . . . . . . . . 10
4.2.2. Routing message Processing . . . . . . . . . . . . . . 10
4.3. Route Maintenance . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Monitoring of Active Links . . . . . . . . . . . . . . 11
4.3.2. Updating Route Lifetimes . . . . . . . . . . . . . . . 11
4.3.3. Route Error Generation . . . . . . . . . . . . . . . . 11
4.4. General DYMO-low Processing . . . . . . . . . . . . . . . 12
4.4.1. DYMO-low Processing . . . . . . . . . . . . . . . . . 12
4.4.2. DYMO-low Control Packet Transmission . . . . . . . . . 12
4.5. Packet Generation Limits . . . . . . . . . . . . . . . . . 12
5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Kim, et al. Expires September 5, 2007 [Page 2]
Internet-Draft DYMO-low March 2007
1. Introduction
The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal
area networks. The "IPv6 over IEEE 802.15.4" document [I-D.ietf-
6lowpan-format] defines basic functionality required to carry IPv6
packets over IEEE 802.15.4 networks (including an adaptation layer,
header compression, etc). Likewise, as mesh topologies are expected
to be common in LoWPAN networks, the functionality required for
packet delivery in IEEE 802.15.4 meshes is defined. However, neither
the IEEE 802.15.4 standard nor the "IPv6 over IEEE 802.15.4"
specification provide any information as to how such a mesh topology
could be obtained and maintained.
This document specifies how to use the Dynamic MANET On-demand
Routing Protocol (DYMO) [I-D.ietf-manet-dymo] over IEEE 802.15.4
networks to provide mesh routing. To distinguish this instantiation
of the protocol from DYMO over IPv4 and DYMO over IPv6, the label
"DYMO-low" is used in this document. Given the very stringent
limitations of the target devices, this document specifies
simplifications that are recommended to the base DYMO specification.
1.1. Requirements notation
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 [RFC2119].
2. Overview
The addresses used in DYMO-low control messages are either 16 bit
link layer short address or IEEE 64-bit extended addresses [EUI64].
Additionally, it should be noted that as used in this specification,
DYMO-low is not layered on top of IP, but underneath it. It is an
underlay. As such, it creates a mesh network topology of IEEE
802.15.4 devices that use single wireless interface each, underneath
and unbeknownst to IP. IP sees a PAN as a single link. This is
similar to how other technologies regularly create complex structures
underneath IP (e.g., ethernet spanning tree bridges, token ring
source routing, ATM, etc). One can envision a sub-IP mesh creating
the illusion that all the devices on that PAN are on the same IPv6
link (sharing the same IPv6 prefix). At the same time, normal usage
of DYMO (above IP) could tie together several such "links"
(potentially using different technologies for each) into a larger
mesh.
DYMO makes use of link-local multicast in its route discovery. It
does so in order to propagate the Route Request control packets
(RREQs). In this specification, such link-local multicast packets
Kim, et al. Expires September 5, 2007 [Page 3]
Internet-Draft DYMO-low March 2007
are obtained by setting the PAN id to the link-local multicast PAN
(0xffff) and by setting the link layer destination address to the
link-local multicast short address (0xffff). DYMO-low control
packets use the encapsulation defined in [I-D.ietf-6lowpan-format].
All DYMO-low control packets shall use the prot_type value TBD
(suggested value of 5). This prot_type is used to send DYMO-low
messages in a manner similar to how DYMO uses a properly assigned UDP
port.
2.1. Simplifications for DYMO over IEEE 802.15.4
This section specifies simplifications and distinctive features of
DYMO-low compared to the base DYMO.
DYMO allows for minimalist implementations by specifying non-
essential functionality as optional [I-D.ietf-manet-dymo]. In
keeping with DYMO, DYMO-low implements the routing message(RM) which
provides both the RREQ (route request) and the RREP (route reply).
The RERR (route error) message is also implemented. DYMO-low has the
following characteristics:
o RREQ messages are transmitted as IEEE 802.15.4 link-local
multicast messages to reach all the next hop neighbors. DYMO
packets SHOULD NOT be fragmented.
o The generalized packet and message format [I-D.ietf-manet-
packetbb] is not used in DYMO-low for the limited packet size and
reducing packet processing complexity.
o Only the final destination SHOULD respond to a RREQ by replying
with a RREP.
o Link quality (LQI) of IEEE 802.15.4[ieee802.15.4] in addition to
the route cost is utilized for selecting best route to the
destination.
o The IEEE 802.15.4 acknowledgement mechanism is used to determine
if a neighbor is no longer responsive. This information is
obtained when transmitting a packet with acknowledgement option
turned on.
o Due to space limitations, nodes SHOULD append only one unreachable
destination in RERR.
o DYMO Sequence numbers allow nodes to judge the freshness of
routing information and ensure loop freedom.
Kim, et al. Expires September 5, 2007 [Page 4]
Internet-Draft DYMO-low March 2007
o The transmission method for RREQ and RERR messages in DYMO is
link-local multicast.However, considering the energy-constrained
nature of 6lowpan, some efficient mechanisms other than broadcast
are necessitated in DYMO-low (TBD).
2.2. Terminology
Link Layer Destination Address (LinkLayerDestinationAddress)
The 16 bit short or EUI-64 link layer address of the destination
in the MAC layer. It is also called as the next-hop destination
during hop-by-hop forwarding of packets.
Link Layer Source Address (LinkLayerSourceAddress)
The 16 bit short or EUI-64 link layer address of the source in
the MAC layer. It is also called as the previous-hop source
address during hop-by-hop forwarding of packets.
Broadcast
The broadcast in 6lowpan implies the link-local multicast in IEEE
802.15.4 MAC layer. This can be done by setting the link layer
destination field to 0xffff.
Target Node (TargetNode)
The TargetNode is the ultimate destination of a message.
This Node (ThisNode)
ThisNode corresponds to the node currently performing a
calculation or processing a message.
Unreachable Node (UnreachableNode)
An UnreachableNode is a node for which ThisNode does not have a
forwarding route.
DYMO Sequence Number (SeqNum)
A DYMO Sequence Number is maintained by each node. This sequence
number is used by other nodes to identify the order of routing
information generated by a node and to ensure loop-free routes.
Kim, et al. Expires September 5, 2007 [Page 5]
Internet-Draft DYMO-low March 2007
3. Data Structures
3.1. Route Table Entry
The route table entry is a conceptual data structure.
Implementations may use any internal representation that conforms to
the semantics of a route as specified in this document.
Conceptually, a route table entry has the following fields:
Route Destination Address (Route.DestAddress)
The 16 bit short or EUI-64 link layer address of the final
destination of a route.
Route Cost (Route.RouteCost)
Cumulative cost metric used for allowing a node to select an
optimum route to the final destination.
Route Next Hop Address (Route.NextHopAddress)
The 16 bit short or EUI-64 link layer address of the next-hop
node on the path toward the final destination.
Route Sequence Number (Route.SeqNum)
The 16 bit short or EUI-64 link layer address of the next-hop
node on the path toward the final destination.
Route.Broken
A flag indicating whether this Route is broken. This flag is set
if the next hop becomes unreachable or in response to processing
a RERR.
In addition to a route table data structure, each route table entry
may have several timers associated with the information. The
detailed timers/timeouts are TBD.
3.2. DYMO-low Messages
DYMO-low messages are categorized either as a Routing Message (RM) or
a Route Error (RERR) message.
3.2.1. DYMO-low Routing Messages
Routing Messages (RMs) are used to disseminate routing information.
A RM can be either a Route Request (RREQ) message or a Route Reply
Kim, et al. Expires September 5, 2007 [Page 6]
Internet-Draft DYMO-low March 2007
(RREP) message. These messages are very similar in information but
vary in the way of their processing.
3.2.1.1. DYMO-low Route Request (RREQ) and Route Reply (RREP) messages
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | HopLimit |T|O| CT | Res | TRouteCost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQID | TargetNode.Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OrigNode.Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OrigNode.SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Route Message Format
Message Type (Type) The following is the list of the currently
available message types.
Type Value
-------------------------------- -----
Route Request (RREQ) 1
Route Reply (RREP) 2
HopLimit
8-bit field that identifies the maximum number of times the message
is to be retransmitted.
Target (T-bit)
1 for the 16-bit address of the TargetNode.
0 for the EUI-64 address of the TargetNode.
Originator (O-bit)
1 for the 16-bit address of the OrigNode.
0 for the EUI-64 address of the OrigNode.
Cost Type (CT)
3-bits of cost type field defines the cost type. The detailed types
are TBD.
Kim, et al. Expires September 5, 2007 [Page 7]
Internet-Draft DYMO-low March 2007
Target Route Cost (TRouteCost)
8-bit field that identifies the routing cost across the number of
intermediate nodes through which a packet traversed on the route to
this particular TargetNode.Address.
RREQ ID
An identifier that uniquely identifies the particular RREQ when
taken in conjunction with the originator. It serves two purposes,
i) It allows intermediate nodes to process the RREQ message once
and ii) It matches a unique RREP message against unique RREQ in the
wake of multiple RREQ generation.
Target Node Address (TargetNode.Address)
The node that is the ultimate destination of the message. In a
RREQ the TargetNode is the destination for which a forwarding
route does not exist and a route discovery is being performed.
In a RREP the TargetNode is the corresponding RREQ's OrigNode.
Originator Node Address (OrigNode.Address)
In RREQ message, the OrigNode is the node that generates a RREQ
message. In RREP, the OrigNode is the node that replies to RREQ.
3.2.1.2. Route Error (RERR)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | HopLimit |T|O|U|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetNode.Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OrigNode.Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UnreachableNode.Address /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Route Error Message Format
Type Value
-------------------------------- -----
Route Error (RERR) 3
HopLimit
Kim, et al. Expires September 5, 2007 [Page 8]
Internet-Draft DYMO-low March 2007
8-bit field that identifies the maximum number of times the message
is to be retransmitted.
Target (T-bit)
1 for the 16-bit address of the TargetNode.
0 for the EUI-64 address of the TargetNode.
Originator (O-bit)
1 for the 16-bit address of the OrigNode.
0 for the EUI-64 address of the OrigNode.
U-bit (U-bit)
1 for the 16-bit address of UnreachableNode.
0 for the EUI-64 address of UnreachableNode.
Target Node Address (TargetNode.Address)
The 16-bit short or EUI-64 link layer address of the node that
is the destination of the RERR message.
Originator Node Address (OrigNode.Address)
The 16-bit short or EUI-64 link layer address of the node that
generates the RERR message.
UnreachableNode.Address
The 16-bit short or EUI-64 link layer address of the node that has
become unreachable.
4. Detailed operation
4.1. DYMO-low Routing Table Operations
4.1.1. Creating or Updating a Route Table Entry from New Routing
Information
While processing a RM, as described in Section 4.2.2, a node checks
its routing table for an entry to the OrigNode.Address in the RREQ.
If a valid route exists to TargetNode.Address, the route can be used
to send any queued data packets and to fulfill any outstanding route
requests.
Kim, et al. Expires September 5, 2007 [Page 9]
Internet-Draft DYMO-low March 2007
In the event that no matching entry is found, an entry is created.
If a matching entry is found, the routing information about
OrigNode.Address contained in this RM is considered stale if the
TRouteCost is greater than Route.RouteCost.
If there exists a route AND the TRouteCost is equal to the
Route.RouteCost in this RM, the information is not stale, but the
routing information SHOULD be disregarded and no routing update
should occur.
If the information in this RM is stale or disregarded this DYMO-low
packet MUST be dropped. If the route information for Originator is
not stale or disregarded, then the following actions occur to the
route table entry for OrigNode.Address:
1. the Route.RouteCost is set to the TRouteCost,
2. the Route.NextHopAddress is set to the node that transmitted this
DYMO-low packet (LinkLayerSourceAddress),
3. if a valid route exists to TargetNode.Address, the route can be
used to send any queued data packets and to fulfill any outstanding
route requests.
4.2. Routing message
4.2.1. Routing message creation
When a node creates a RREQ or RREP, it MUST create the RM. It sets
the OrigNode.Address to its own address.
4.2.2. Routing message Processing
After the general DYMO-low message pre-processing (Section 4.5.2),
the routing message is processed to yield the route cost TRouteCost.
That is, the route cost TRouteCost is said to be better (or
equivalently smaller) than or equal to (Route.RouteCost') if the
following condition holds (Note that the apostrophe refers to
Route.RouteCost i.e., an already existing route entry in the routing
table)
TRouteCost < = Route.RouteCost'
If a matching entry to the OrigNode.Address in the routing message is
found in the routing table, the routing information about
OrigNode.Address contained in this routing message is considered
Kim, et al. Expires September 5, 2007 [Page 10]
Internet-Draft DYMO-low March 2007
stale if TRouteCost is greater than the Route.RouteCost'. If the
information in this routing message is stale or disregarded this
DYMO-low packet MUST be dropped.
If there exists a route AND equal the information is not stale, then
the routing information SHOULD be disregarded and no routing update
should occur. If the route information for OrigNode.Address is not
stale or disregarded,then the following actions occur to the route
table entry for OrigNode.Address:
1. the Route.RouteCost is set to the TRouteCost,
2. the Route.NextHopAddress is set to the node that transmitted this
DYMO-low packet (LinkLayerSourceAddress),
If this node is the TargetNode.Address AND the received RM's type is
RREQ, this node MUST respond with a RREP. The target node creates a
new RM as described in Section 4.2.1. The TargetNode.Address in the
new RM is set to the OrigNode.Address from the RM currently being
processed. The LinkLayerDestinationAddress is set to the
Route.NextHopAddress for the TargetNode.Address. Then the new RM
undergoes post-processing, according to Section 4.5.3. If this node
is not the TargetNode.Address, the current RE SHOULD be handled
according to Section 4.5.4.
4.3. Route Maintenance
4.3.1. Monitoring of Active Links
Before a route can be used for forwarding a packet, it MUST be
checked to make sure that the route is still valid. The detailed
operation of checking is TBD. A RERR MUST be issued if a data packet
is received and it cannot be delivered to the next hop. RERR
generation is described in Section 4.4.3. A RERR SHOULD be issued
after detecting a broken link of an active route to quickly notify
nodes that a link break occurred and a route or routes are no longer
available.
4.3.2. Updating Route Lifetimes
TBD.
4.3.3. Route Error Generation
When a data packet is received for a destination without a valid
routing table entry, a Route Error (RERR) MUST be generated by this
node. A RERR informs the source that the current route is no longer
available. In the RERR, the TargetNode.Address field is the address
Kim, et al. Expires September 5, 2007 [Page 11]
Internet-Draft DYMO-low March 2007
of the unreachable node (final destination address) from the data
packet. The setting of theL inkLayerDestinationAddress of the RERR
and the RERR processing at the receiving node are TBD.
4.4. General DYMO-low Processing
4.4.1. DYMO-low Processing
The Routing Message (RM) MUST be processed completely prior to any
transmissions. Unless specific message processing requires dropping
the DYMO-low packet, it is retransmitted after processing, according
to the method described in Section 4.5.4.
4.4.1.1. Routing Message Pre-processing
The RM in a DYMO-low packet undergoes pre-processing before the
message specific processing occurs. During pre-processing, the
HopLimit is decremented by one (1).
4.4.1.2. Routing Message Post-processing
If the HopLimit is zero (0) the DYMO-low packet is dropped. If the
HopLimit is greater than zero the DYMO-low packet is re-transmitted
after processing of all messages. If the HopLimit of Routing Message
(RM) is zero (0) after processing, it MUST be removed from the DYMO-
low packet prior to transmission.
4.4.2. DYMO-low Control Packet Transmission
DYMO-low packet transmission and re-transmission is controlled by the
LinkLayerDestinationAddress. If the LinkLayerDestinationAddress is a
unicast address, the packet LinkLayerDestinationAddress is replaced
by the Route.NextHopAddress from a route table lookup for the
TargetNode.Address. If a route for the TargetNode.Address is unknown
or invalid the packet is dropped and a RERR SHOULD be generated.
4.5. Packet Generation Limits
To avoid congestion, a node SHOULD NOT transmit more than RATE_LIMIT
control messages per second. RREQ packets SHOULD be discarded before
RREP or RERR packets.
4.6 Sequence Numbers
The usage of sequence numbers in DYMO-low follows the base DYMO
except the sequence number rollover.
4.6.1 Sequence Number Rollover
If the sequence number has been assigned to be the largest possible
number representable as a 8-bit unsigned integer, then the sequence
number MUST be set to one (1) when incremented.
5. Configuration Parameters
Here are some default parameter values for DYMO-low:
Kim, et al. Expires September 5, 2007 [Page 12]
Internet-Draft DYMO-low March 2007
Parameter Name Suggested Value
--------------------------- ---------------
NET_DIAMETER 256
RATE_LIMIT 2
RREQ_WAIT_TIME 1000 milliseconds
RREQ_TRIES 2
6. IANA Considerations
This document needs an additional IANA registry for the prot_type
value that indicates the DYMO-low format.
7. Security Considerations
The security considerations of the [RFC3561] are applicable to this
document. As described in the charter of the 6lowpan w.g., DYMO-low
will also try to reuse existing security considerations related to Ad
hoc routing protocols. Further considerations will be studied in the
next version.
8. Acknowledgements
Thanks to Ali Hammad Akbar, Chae-Sung, Lim, Prof. Seung-Wha Yoo,
Prof. Byeong-Hee Roh, Shafique Ahmad Chaudhry, and Hee-Jung Kim for
their useful discussions and supports for writing this document.
9. References
9.1. Normative References
[EUI64] 802.15.4-2003, IEEE Standard.,
"GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER
(EUI-64) REGISTRATION AUTHORITY".
[I-D.ietf-manet-packetbb] Clausen, T., "Generalized MANET Packet/
Message Format",
draft-ietf-manet-packetbb-02 (work in
progress), July 2006.
[I-D.ietf-manet-dymo] Chakeres, I., "Dynamic MANET On-demand
(DYMO) Routing", draft-ietf-manet-dymo-07
(work in progress), February 2007.
[I-D.ietf-6lowpan-problem] Kushalnagar, N., Montenegro, G., and C.
Schumacher, "6LoWPAN: Overview,
Assumptions, Problem Statement and
Goals", draft-ietf-6lowpan-problem-08
(work in progress), February 2007.
Kim, et al. Expires September 5, 2007 [Page 13]
Internet-Draft DYMO-low March 2007
[I-D.ietf-6lowpan-format] Montenegro, G., N., Kushalnagar., Hui,
J., and D. Culler, "Transmission of IPv6
Packets over IEEE 802.15.4 Networks",
draft-ietf-6lowpan-format-11 (work in
progress), February 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines
for Writing an IANA Considerations
Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3561] Perkins, C., Belding-Royer, E., and S.
Das, "Ad hoc On-Demand Distance Vector
(AODV) Routing", RFC 3561, July 2003.
[IEEE802.15.4] 802.15.4-2003, IEEE Standard., "Wireless
medium access control and physical layer
specifications for low-rate wireless
personal area networks.", May 2003.
9.2. Informative References
Authors' Addresses
Kim, Ki Hyung (editor)
Ajou University
San 5 Wonchun-dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-749
KOREA
Phone: +82 31 219 2433
EMail: kkim86@ajou.ac.kr
Soohong Daniel Park (editor)
SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-742
KOREA
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
Kim, et al. Expires September 5, 2007 [Page 14]
Internet-Draft DYMO-low March 2007
Gabriel Montenegro
Microsoft Corporation
USA
EMail: gabriel_montenegro_2000@yahoo.com
Ian Chakeres
Boeing
P.O. Box 3707 Mailcode 7L-49
SeaHopLimite, WA 98124-2207
USA
EMail: ian.chakeres@gmail.com
Charles E. Perkins
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1-650-625-2986
EMail: charles.perkins@nokia.com
Kim, et al. Expires September 5, 2007 [Page 15]
Internet-Draft DYMO-low March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kim, et al. Expires September 5, 2007 [Page 16]