One document matched: draft-li-core-coap-node-id-option-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY COAP PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml'>
<!ENTITY COAPOBS PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-observe.xml'>
<!ENTITY COAPRD PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-resource-directory.xml'>
<!ENTITY COAPMISC PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-coap-misc.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc
category="std"
ipr="trust200902"
docName="draft-li-core-coap-node-id-option-01">
<front>
<title abbrev="CoAP NodeId Option">
CoAP Option Extension: NodeId
</title>
<author initials="K." surname="Li" fullname="Kepeng Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<phone>+86-755-28974289</phone>
<email>likepeng@huawei.com</email>
</address>
</author>
<author initials="G." surname="Wei" fullname="Gengyu Wei">
<organization abbrev="BUPT">Beijing University of Posts & Telecommunications</organization>
<address>
<postal>
<street>No.10 Xitucheng Road, Haidian District</street>
<city>Beijing</city>
<code>100876</code>
<country>P. R. China</country>
</postal>
<phone>+86-10-62283067</phone>
<email>weigengyu@bupt.edu.cn</email>
</address>
</author>
<date year="2014" />
<area>Applications</area>
<workgroup>core</workgroup>
<abstract>
<t>
CoAP is a RESTful application protocol for constrained nodes and
networks. This specification provides a simple extension for
CoAP, the NodeId Option. This Option can be used to identify the node,
either the client or the server.
</t>
</abstract>
<note title="Note">
<t>
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
This specification adds a new option NodeId to CoAP <xref target="I-D.ietf-core-coap" />.
The main purpose is for a node to have a unique identity, named as NodeId.
The NodeId is used by the node, as a sender, to identify itself to the recipient,
during registration and communications.
</t>
<section anchor="just" title="Justification">
<t> A node is set to have a NodeId and the node nerver changes its NodeId.
There are several scenarios to have the NodeId to identify the nodes.
</t>
<t>
In the network, it is quite common for a node to change its IP address
due to rebooting. After the server or client changes its IP address, the peer of
the other side lacks a facility to correlate the old IP address and the new IP address
as the same node. This will cause the other side to lose some contexts. If the
node can use NodeId after its IP address being changed, it is very easy for the
node to correlate the old IP address and the new one by NodeId.
<!-- Any other issues introduced by the IP address change? -->
</t>
<t>
In the multicast observation case, after a client sends a multicast observation
request to a group URI, e.g. all.bldg6.example.com, the client will receive
multiple notifications from different servers of the multicast group with the
same token as specified in the multicast request. As a result, the client can't use token
to correlate multicast request and notification responses. The client
may use the IP address extracted from UDP/IP transport/network layers to differentiate
servers and responses. If a server changes its IP address and sends back the notification,
the client can't determine where the notification message comes from any more. In this case,
if NodeId is included in the notifications, it can be used to correlate multicast
request and subsequent notifications by the node.
</t>
<t>
The NodeId can also be used for authentication and authorization of the node.
</t>
</section>
<section anchor="terms" title="Terminology">
<t>
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 <xref target='RFC2119' />.
</t>
</section>
</section>
<section anchor="NodeId" title="NodeId Option Extension">
<section anchor="Definition" title="NodeId Option Definition">
<t>
<figure>
<artwork>
+------+---+---+---+---+--------+--------+--------+---------+
| Type | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+--------+--------+--------+---------+
| TBD | - | - | - | - | NodeId | string | 1-255 B| (none) |
+------+---+---+---+---+--------+--------+--------+---------+
</artwork>
</figure>
</t>
<t>
The NodeId option is used to identify the node.The value SHOULD be
unique for each node within a Resource Directory server. The value
can be in the form of Binary bits, IMEI (International Mobile Equipment Identity number),
IEEE 802 MAC Address, or other identifiers which can uniquely identify itself.
Usually the value is pre-configured or pre-previsioned in the node.
</t>
</section>
<section anchor="Using" title="Using the NodeId Option">
<section anchor="Registration" title="Registration">
<t>
When a node registers itself to the Resource Directory server, the registration request
SHOULD contain its node identifier. This node identifier MAY be included in the NodeId
option in the registration request, or MAY be included in the URI-Query option as specified
in <xref target="I-D.ietf-core-resource-directory" />.
</t>
</section>
<section anchor="Usage" title="Usage">
<t>
This option MAY be used in a CoAP request or response. And it can be used to correlate
the messages for a node in case of IP address change.
As long as a node changes its IP address, the NodeId SHALL be included in the first request
and response and sent in CON message.
</t>
<t>
Whenever the node reboots or moves, the NodeId MUST NOT change. And the node SHOULD send the
updated IP address with the NodeId to the RD server, using the update interface as specified in
<xref target="I-D.ietf-core-resource-directory" />.
This informs the RD server a mapping relation
between the new IP address and the NodeId identified node.
</t>
<t>
For the usage of notifications in the observe, when a server in a group receives a
multicast observe request, it SHOULD include a NodeId option in the notifications.
In this way, even the server changes the IP address, the client can still correlate
all the notifications with this server.
</t>
<t>It is recommended to use NodeId as identifier during authentication and authorization.
</t>
<t>
Todo: How to use it for authentication and authorization?
</t>
<t>
This option is "elective". It MUST NOT occur more than once.
</t>
</section>
</section>
</section>
<section anchor="example" title="Example">
<section anchor="regexample" title="Registration example">
<t>
This section gives a short example with a message flow that
illustrates the use of the NodeId option in a registration request.
</t>
<t>
This example (<xref target="RegistrationExample"/>) shows that the
requester includes its NodeId in the registration request.
</t>
<figure title="NodeId Option in a registration request" anchor="RegistrationExample">
<artwork> <![CDATA[
Node RD
| |
| |
+----->| Header: POST (T=CON, Code=1, MID=0x7d38)
| POST | Token: 0x53
| | NodeId: node12345
| | Uri-Path: "rd"
| |
|<-----+ Header: 2.01 Created (T=ACK, Code=69, MID=0x7d38)
| 2.01 | Token: 0x53
| |
| |
]]>
</artwork>
</figure>
</section>
<section anchor="NotificationExample" title="Notification example">
<t>
This section gives a short example with a message flow that
illustrates the use of the NodeId option in an observe
notification.
</t>
<t>
This example (<xref target="NotificationExample"/>) shows that the
server includes its NodeId option in an observe notification after IP address changes.
</t>
<figure title="NodeId Option in an observe notification" anchor="ObserveExample">
<artwork> <![CDATA[
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | Token: 0x53
| | Observe: 0
| | Uri-host: "all.bldg6.example.com"
| | Uri-Path: "temperature"
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38)
| 2.05 | Token: 0x53
| | NodeId: node12345
| | Payload: "22.3 C"
| |
| |
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
This presents no security considerations beyond those in
section 9 and 11 of the base CoAP specification
<xref target="I-D.ietf-core-coap" />.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
The IANA is requested to add the following "CoAP Option Numbers" entry
as per Section 12.2 of <xref target="I-D.ietf-core-coap"/>.
</t>
<figure>
<artwork>
+--------+------------------+----------------+
| Number | Name | Reference |
+--------+------------------+----------------+
| TBD | NodeId | Section 2 |
+--------+------------------+----------------+
</artwork>
</figure>
</section>
<section anchor="acknowledgement" title="Acknowledgements">
<t>
The authors of this draft would like to thank the Esko Dijk, Carsten Bormann,
Bert Greevenbosch and Klaus Hartke for the email discussions on this issue.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&COAP;
&COAPOBS;
&COAPRD;
</references>
<references title="Informative References">
&COAPMISC;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:06:26 |