Subject: [core] How to correlate request and responses in group communication

From: Likepeng <[email-masked]>
Date: Wed, 27 Nov 2013 02:49:50 +0000

Hi all,

When I read the group communication draft, I come up with one question, how to correlate a multicast request with the multiple responses from different nodes?

For example, a client sends a multicast GET request to a group URI: all.bldg6.example.com, and after some time, it will receive multiple responses from different nodes. In the request, it contains one token. In the responses, I assume that all the responses should use the same token according to the base coap spec. Then how can the client differentiate the different responses from different nodes, corresponding to the same request?

I searched the whole group communication draft, token is not mentioned. So I hope to get opinion from the group.

Thanks,
Kind Regards
Kepeng

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 27 Nov 2013 07:00:37 +0000

Hello Kepeng,

The identification of the individual response is by the (unicast) IP source address of the responding CoAP endpoint.
Indeed this would be good to mention somewhere in groupcomm.
Correlation of a single request with a set of responses is via Token; in case there are multiple outstanding multicast requests from a single endpoint.

Also core-coap has some information on use of IP address of the responding endpoint, section 8.2:

For the purposes of interpreting the Location-* options and any links
   embedded in the representation and, the request URI (base URI)
   relative to which the response is interpreted, is formed by replacing
   the multicast address in the Host component of the original request
   URI by the literal IP address of the endpoint actually responding.

Esko

From: core [mailto:[email-masked]] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: [email-masked]
Subject: [core] How to correlate request and responses in group communication

Hi all,

Thanks,
Kind Regards
Kepeng

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Likepeng <[email-masked]>
Date: Wed, 27 Nov 2013 08:31:53 +0000

Hi Esko,

>The identification of the individual response is by the (unicast) IP source address of the responding CoAP endpoint.

In the response, the only place to put the (unicast) IP source address is the UDP layer, right? Because HRI-Host is used to indicate the target node, not the source node.

(CoAP section 5.10.1) The Uri-Host, Uri-Port, Uri-Path and Uri-Query Options are used to specify the target resource of a request to a CoAP origin server.

That means, the requestor has to rely on UDP layer to get the (unicast) IP source address from the response, then correlate the multicast request and the unicast response. But in my opinion, the correlation should be done in the CoAP layer. CoAP layer should provide some information to be used for this purpose.

In CoAP spec, it mentions that Token MUST be used to match the responses with the multicast request. If there are multiple responses, we have to use source endpoint to differentiate. But this information can be only got from UDP layer. That is an issue, in my opinion.

CoAP Section 8.2
   When matching a response to a multicast request, only the token MUST
   match; the source endpoint of the response does not need to (and will
   not) be the same as the destination endpoint of the original request.

Any thoughts?

Thanks,
Kind Regards
Kepeng

发件人: Dijk, Esko [mailto:[email-masked]]
发送时间: 2013年11月27日 15:01
收件人: Likepeng; [email-masked]
主题: RE: [core] How to correlate request and responses in group communication

Hello Kepeng,

Esko

From: core [mailto:[email-masked]] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: [email-masked]<mailto:[email-masked]>
Subject: [core] How to correlate request and responses in group communication

Hi all,

Thanks,
Kind Regards
Kepeng

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 27 Nov 2013 15:13:37 +0000

Yes, it’s currently defined to use the UDP layer for that information. At least it’s efficient :)

If information other than IP address is needed, such as a non-volatile GUID, the CoAP server could include this as part of its response payload (in case of GET or PUT).
But that’s not the most beautiful solution I agree.

Esko

From: Likepeng [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; [email-masked]
Subject: Re: [core] How to correlate request and responses in group communication

Hi Esko,

CoAP Section 8.2

Any thoughts?

Thanks,
Kind Regards
Kepeng

发件人: Dijk, Esko [mailto:[email-masked]]
发送时间: 2013年11月27日 15:01
收件人: Likepeng; [email-masked]<mailto:[email-masked]>
主题: RE: [core] How to correlate request and responses in group communication

Hello Kepeng,

Esko

Hi all,

Thanks,
Kind Regards
Kepeng

---

From: "weigengyu" <[email-masked]>
Date: Thu, 28 Nov 2013 17:13:48 +0800

Hi Esko, 

In OMA LWM2M Requirements, 
    6. Requirements (Normative)
    6.1 High-Level Functional Requirements
    LightweightM2MHLF-001 The Lightweight M2M enabler SHALL support a unique ID to identify the LWM2M Device. 

It is understood that each device needs a unique ID. 
And within a decvice there may have a few of physical resources that can be remotely accessed individually. 

Based on CoAP –18 terminology, it seems that Endpoint is correspondant to the OMA Device. 
Whether or not?   If it is, attentions need to pay for that.  

I think that giving the description how to define and how to access the device or the physical resources is better than leaving that to the application. 

By the way, Location option is defined in CoAP –18. 
The current version describes the location-query and location-path used as the response to POST request. 
And In CoAP –18,    “
     5.10.6.1. ETag as a Response Option
The ETag Option in a response provides the current value (i.e., after the request was processed) of the entity-tag for the "tagged
representation". If no Location-* options are present, the tagged representation is the selected representation (Section 5.5.3) of the
target resource. If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged
representation is the representation that would be retrieved by a GET request to the location URI. 
    5.10.7. Location-Path and Location-Query
The Location-Path and Location-Query Options together indicate a relative URI that consists either of an absolute path, a query string
or both. A combination of these options is included in a 2.01 (Created) response to indicate the location of the resource created
as the result of a POST request (see Section 5.8.2). The location is resolved relative to the request URI. “

Based on the above text, by the URI the target resource can be accessed. 
I got a little confused wether the target resource is a Device or a phiscal resource?  

If the URI indicates a Device, the means to access phiscal resources is required. 
If the URI indicates a physical resource, CoAP –18 has the means to tell the differences. 

Regards, 

Gengyu 

Network Technology Center 
School of Computer
Beijng University of Posts & Telecommunications

From: Dijk, Esko 
Sent: Wednesday, November 27, 2013 11:13 PM
To: Likepeng ; [email-masked] 
Subject: Re: [core] How to correlate request and responses in group communication

Esko

Hi Esko,

CoAP Section 8.2

Any thoughts?

Thanks,

Kind Regards

Kepeng

Hello Kepeng,

Esko

Hi all,

Thanks,

Kind Regards

Kepeng

--------------------------------------------------------------------------------

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message

--------------------------------------------------------------------------------
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 28 Nov 2013 09:30:41 +0000

I don’t know the OMA LWM2M details, but the CoAP endpoint is likely to be different – one Device (=node?) usually supports many endpoints which could correspond e.g. to different applications on the Device. And the CoAP endpoint is identified by IP address (plus port, plus security context) so this is not a suitable UID since the IP address may change over time.

CoAP doesn’t support specific options to communicate a node/Device unique ID back and forth AFAIK. That could be accomplished at lower layer through security (DTLS authentication) or at higher layer in the application-level payloads (e.g. a resource /uid that tells the unique ID of a device, or a UID that is included in the payload of a CoAP response.)

Esko

From: weigengyu [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:14
To: Dijk, Esko
Cc: [email-masked]
Subject: Re: [core] How to correlate request and responses in group communication

Hi Esko,

Regards,

Gengyu

From: Dijk, Esko<mailto:[email-masked]>
Sent: Wednesday, November 27, 2013 11:13 PM
To: Likepeng<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Subject: Re: [core] How to correlate request and responses in group communication

Esko

From: Likepeng [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; [email-masked]<mailto:[email-masked]>
Subject: Re: [core] How to correlate request and responses in group communication

Hi Esko,

CoAP Section 8.2

Any thoughts?

Thanks,
Kind Regards
Kepeng

Hello Kepeng,

Esko

Hi all,

Thanks,
Kind Regards
Kepeng

[email-masked]<mailto:[email-masked]>

---

From: "weigengyu" <[email-masked]>
Date: Thu, 28 Nov 2013 19:09:14 +0800

Hi Esko, 

Thank you for you email. 
I got that the endpiont is identified by IP address (plus port, plus security context), and there may be a number of applicatons in one endpoint.  
CoAP URI could indicate an endpiont or an physical resourse.
CoAP could tell the different resours by CoAP contents (Payload). 

However, Location option is defined in CoAP –18. 
    In CoAP –18, 5.10.6.1. ETag as a Response Option

    If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged

Why not to use Location opotion? 

Regards, 

Gengyu 

School of Computer

From: Dijk, Esko 
Sent: Thursday, November 28, 2013 5:30 PM
To: weigengyu 
Cc: [email-masked] 
Subject: RE: [core] How to correlate request and responses in group communication

Esko

Hi Esko, 

And In CoAP –18,    “

 

Regards, 

Gengyu 

School of Computer

 

From: Dijk, Esko 

Esko

Hi Esko,

CoAP Section 8.2

Any thoughts?

Thanks,

Kind Regards

Kepeng

Hello Kepeng,

Esko

Hi all,

Thanks,

Kind Regards

Kepeng

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Nov 2013 15:33:32 +0100

> However, Location option is defined in CoAP –18.

In REST, there are two ways for a client to ask the server to create a resource:

— PUT, where the client supplies the URI for the new resource, and
— POST on a resource that supports creating new resources, where the server selects the URI for the new resource.

The Location options are for the latter case; they allow the server to indicate the URI that it actually chose, to the client, with the response to the POST request.

I’m not sure I understand what you are trying to achieve with this set of options.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Fri, 29 Nov 2013 12:03:35 +0800

Hi Carsten,

Thank you for your explanations.
> I’m not sure I understand what you are trying to achieve with this set of 
I would like to use the CoAP already defined mechanisms to resolve umbiguity 
locations.
Using CoAP-defined mechanisms is better than leaving it to applications.

The CoAP -18 gives descriptions about Location options are used by POST.
And in CoAP -18 "5.10.6 ETag" is defined as a request option and a response 
option, and ETag may contain Location Options.
In "5.10.6.1. ETag as a Response Option,
    If one or more Location-* options are present and thus a location URI is 
indicated (Section 5.10.7), the tagged
    representation is the representation that would be retrieved by a GET 
request to the location URI.
In CoAP -18 6. CoAP URIs
    CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP 
resources and providing a means of locating the resource.
Based on above texts, I see that the URI from Location options could be used 
"by a GET request to the location URI."

Current CoAP -18 has not given descriptions whether the GET is prohibited 
from Location options.
So, GET request could use the URI, or Etag, or Location options.
Then the responese(s) might use URI, or Etag, or Location options even 
though caches are existed.

When Location option(s) is in GET, the client can use the standard means to 
see the different responses from multiple locations.
I believe this CoAP Location facility could be beneficial to a number of 
location-based applicatons.

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts & Telecommunications

-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, November 28, 2013 10:33 PM
To: weigengyu
Cc: Dijk, Esko ; core ([email-masked])
Subject: Re: [core] How to correlate request and responses in group 
communication

> However, Location option is defined in CoAP –18.

In REST, there are two ways for a client to ask the server to create a 
resource:

— PUT, where the client supplies the URI for the new resource, and
— POST on a resource that supports creating new resources, where the server 
selects the URI for the new resource.

The Location options are for the latter case; they allow the server to 
indicate the URI that it actually chose, to the client, with the response to 
the POST request.

I’m not sure I understand what you are trying to achieve with this set of 
options.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 29 Nov 2013 09:51:44 +0000

If I understand correctly, the proposed idea is to use the Location-* Options in a response to indicate the identity/source of a response. In a response to a multicast, the identity/source of a response is not visible at the CoAP layer. (Only below it, in the UDP layer.)

However, there is no "Location-Host" option defined, only the relative Location-Path and Location-Query options. So this would not help in identifying the source of the response!  Unless we define an option like "Location-Host".

Perhaps a better solution is to allow the existing "Uri-Host" option in a response (optionally) to identify the source of the response. This is quite close to the current meaning of Uri-Host, but then applied to a CoAP response situation. The contents of Uri-Host may be an IP literal or a hostname (which I assume to be the most stable identifier). In terms of standardization, this looks like an easy thing to add, but there could be impact on implementations.

Any thoughts - do we need server identification as a standardized CoAP Option? Are there any transports other than UDP/TCP - that allow multicast - but somehow don't provide the source IP address of the response in the layer below COAP?

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Friday, November 29, 2013 05:04
To: Carsten Bormann
Cc: Dijk, Esko; [email-masked]
Subject: Re: [core] How to correlate request and responses in group communication

Hi Carsten,

> I'm not sure I understand what you are trying to achieve with this set
> of options.
I would like to use the CoAP already defined mechanisms to resolve umbiguity locations.
Using CoAP-defined mechanisms is better than leaving it to applications.

The CoAP -18 gives descriptions about Location options are used by POST.
And in CoAP -18 "5.10.6 ETag" is defined as a request option and a response option, and ETag may contain Location Options.
In "5.10.6.1. ETag as a Response Option,
    If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged
    representation is the representation that would be retrieved by a GET request to the location URI.
In CoAP -18 6. CoAP URIs
    CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP resources and providing a means of locating the resource.
Based on above texts, I see that the URI from Location options could be used "by a GET request to the location URI."

Current CoAP -18 has not given descriptions whether the GET is prohibited from Location options.
So, GET request could use the URI, or Etag, or Location options.
Then the responese(s) might use URI, or Etag, or Location options even though caches are existed.

When Location option(s) is in GET, the client can use the standard means to see the different responses from multiple locations.
I believe this CoAP Location facility could be beneficial to a number of location-based applicatons.

Regards,

Gengyu

---

From: Likepeng <[email-masked]>
Date: Fri, 29 Nov 2013 10:51:33 +0000

>Perhaps a better solution is to allow the existing "Uri-Host" option in a response (optionally) to identify the source of the response.

To avoid confusion, I prefer to define an option like "Location-Host".

>Any thoughts - do we need server identification as a standardized CoAP Option? 

Yes, I think we need that.

>Are there any transports other than UDP/TCP - that allow multicast - but somehow don't provide the source IP address of the response in the layer below COAP?

SMS allows multicast.

Even if transports other than UDP/TCP provide source address other than IP address, we still need to rely on transport layer. We should identify the source in the CoAP layer.

Kind Regards
Kepeng

-----邮件原件-----
发件人: core [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2013年11月29日 17:52
收件人: weigengyu; Carsten Bormann
抄送: [email-masked]
主题: Re: [core] How to correlate request and responses in group communication

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Friday, November 29, 2013 05:04
To: Carsten Bormann
Cc: Dijk, Esko; [email-masked]
Subject: Re: [core] How to correlate request and responses in group communication

Hi Carsten,

Regards,

Gengyu

---

From: "weigengyu" <[email-masked]>
Date: Fri, 29 Nov 2013 19:33:42 +0800

>> If I understand correctly, the proposed idea is to use the Location-* 
>> Options in a response to indicate the identity/source of a response.
   In a response to a multicast, the identity/source of a response is not 
visible at the CoAP layer. (Only below it, in the UDP layer.)
Yes.

>> Perhaps a better solution is to allow the existing "Uri-Host" option in a 
>> response (optionally) to identify the source of the response.
Actually, it is an extension of Location option.

> Yes, I think we need that.
+1.

>>In terms of standardization, this looks like an easy thing to add, but 
>>there could be impact on implementations.
I do not think that "impact on implementations" is a server problem.

>>Any thoughts - do we need server identification as a standardized CoAP 
Perhaps not.
With URI or extended Location option, a server could be accessed and servers 
could be distinguishied.

It seems that the CoAP Device should be defined.
The term "CoAP Device" has been appeared in CoAP drafts, but not as a 
terminology.

>>Are there any transports other than UDP/TCP - that allow multicast - but 
>>somehow don't provide the source IP address of the response in the layer 
>>below COAP?
> SMS
SMS is a transmission facility.
It depends on what you put into the SMS 140bytes' payload.

Regards,

Gengyu

-----原始邮件----- 
From: Likepeng
Sent: Friday, November 29, 2013 6:51 PM
To: Dijk, Esko ; weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] How to correlate request and responses in group 
communication

>Perhaps a better solution is to allow the existing "Uri-Host" option in a 
>response (optionally) to identify the source of the response.

>Are there any transports other than UDP/TCP - that allow multicast - but 
>somehow don't provide the source IP address of the response in the layer 
>below COAP?

SMS allows multicast.

Even if transports other than UDP/TCP provide source address other than IP 
address, we still need to rely on transport layer. We should identify the 
source in the CoAP layer.

Kind Regards
Kepeng

-----邮件原件-----
发件人: core [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2013年11月29日 17:52
收件人: weigengyu; Carsten Bormann
抄送: [email-masked]
主题: Re: [core] How to correlate request and responses in group 
communication

If I understand correctly, the proposed idea is to use the Location-* 
Options in a response to indicate the identity/source of a response. In a 
response to a multicast, the identity/source of a response is not visible at 
the CoAP layer. (Only below it, in the UDP layer.)

However, there is no "Location-Host" option defined, only the relative 
Location-Path and Location-Query options. So this would not help in 
identifying the source of the response!  Unless we define an option like 
"Location-Host".

Perhaps a better solution is to allow the existing "Uri-Host" option in a 
response (optionally) to identify the source of the response. This is quite 
close to the current meaning of Uri-Host, but then applied to a CoAP 
response situation. The contents of Uri-Host may be an IP literal or a 
hostname (which I assume to be the most stable identifier). In terms of 
standardization, this looks like an easy thing to add, but there could be 
impact on implementations.

Any thoughts - do we need server identification as a standardized CoAP 
Option? Are there any transports other than UDP/TCP - that allow multicast - 
but somehow don't provide the source IP address of the response in the layer 
below COAP?

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Friday, November 29, 2013 05:04
To: Carsten Bormann
Cc: Dijk, Esko; [email-masked]
Subject: Re: [core] How to correlate request and responses in group 
communication

Hi Carsten,

Regards,

Gengyu

________________________________
The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended 
recipient, please contact the sender by return e-mail and destroy all copies 
of the original message.