How to correlate request and responses in group communication

[Likepeng]

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

[Dijk, Esko]

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:core-***@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: ***@ietf.org
Subject: [core] How to correlate request and responses in group communication

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

________________________________
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.

[Likepeng]

Hi Esko,

Post by Dijk, 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:***@philips.com]
·¢ËÍʱŒä: 2013Äê11ÔÂ27ÈÕ 15:01
ÊÕŒþÈË: Likepeng; ***@ietf.org
Ö÷Ìâ: RE: [core] How to correlate request and responses in group communication

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:core-***@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [core] How to correlate request and responses in group communication

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

________________________________
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.

[Dijk, Esko]

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:***@huawei.com]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication

Hi Esko,

Post by Dijk, 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:***@philips.com]
·¢ËÍʱŒä: 2013Äê11ÔÂ27ÈÕ 15:01
ÊÕŒþÈË: Likepeng; ***@ietf.org<mailto:***@ietf.org>
Ö÷Ìâ: RE: [core] How to correlate request and responses in group communication

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:core-***@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [core] How to correlate request and responses in group communication

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

________________________________
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.

[weigengyu]

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 šC18 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 šC18.
The current version describes the location-query and location-path used as the response to POST request.
And In CoAP šC18, ¡°
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 šC18 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 ; ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication

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:***@huawei.com]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication



Hi Esko,

Post by Dijk, 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:***@philips.com]
·¢ËÍʱŒä: 2013Äê11ÔÂ27ÈÕ 15:01
ÊÕŒþÈË: Likepeng; ***@ietf.org
Ö÷Ìâ: RE: [core] How to correlate request and responses in group communication



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:core-***@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: ***@ietf.org
Subject: [core] How to correlate request and responses in group communication



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




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

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



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

[Dijk, Esko]

I don¡¯t know the OMA LWM2M details, but the CoAP endpoint is likely to be different šC 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:***@bupt.edu.cn]
Sent: Thursday, November 28, 2013 10:14
To: Dijk, Esko
Cc: ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication

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 šC18 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 šC18.
The current version describes the location-query and location-path used as the response to POST request.
And In CoAP šC18, ¡°
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 šC18 has the means to tell the differences.


Regards,

Gengyu

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


From: Dijk, Esko<mailto:***@philips.com>
Sent: Wednesday, November 27, 2013 11:13 PM
To: Likepeng<mailto:***@huawei.com> ; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [core] How to correlate request and responses in group communication

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:***@huawei.com]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [core] How to correlate request and responses in group communication

Hi Esko,

Post by Dijk, 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:***@philips.com]
·¢ËÍʱŒä: 2013Äê11ÔÂ27ÈÕ 15:01
ÊÕŒþÈË: Likepeng; ***@ietf.org<mailto:***@ietf.org>
Ö÷Ìâ: RE: [core] How to correlate request and responses in group communication

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:core-***@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [core] How to correlate request and responses in group communication

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

________________________________
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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/core

[weigengyu]

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 šC18.
In CoAP šC18, 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.



Why not to use Location opotion?



Regards,



Gengyu


Network Technology Center

School of Computer

Beijng University of Posts & Telecommunications





From: Dijk, Esko
Sent: Thursday, November 28, 2013 5:30 PM
To: weigengyu
Cc: ***@ietf.org
Subject: RE: [core] How to correlate request and responses in group communication

I don¡¯t know the OMA LWM2M details, but the CoAP endpoint is likely to be different šC 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:***@bupt.edu.cn]
Sent: Thursday, November 28, 2013 10:14
To: Dijk, Esko
Cc: ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication



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 šC18 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 šC18.

The current version describes the location-query and location-path used as the response to POST request.

And In CoAP šC18, ¡°

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 šC18 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 ; ***@ietf.org

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



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:***@huawei.com]
Sent: Wednesday, November 27, 2013 09:32
To: Dijk, Esko; ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication



Hi Esko,

Post by Dijk, 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:***@philips.com]
·¢ËÍʱŒä: 2013Äê11ÔÂ27ÈÕ 15:01
ÊÕŒþÈË: Likepeng; ***@ietf.org
Ö÷Ìâ: RE: [core] How to correlate request and responses in group communication



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:core-***@ietf.org] On Behalf Of Likepeng
Sent: Wednesday, November 27, 2013 03:50
To: ***@ietf.org
Subject: [core] How to correlate request and responses in group communication



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




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

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


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

[Carsten Bormann]

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

[weigengyu]

Hi Carsten,

Thank you for your explanations.

Post by Carsten Bormann
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

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 (***@ietf.org)
Subject: Re: [core] How to correlate request and responses in group
communication

Post by Carsten Bormann
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

[Dijk, Esko]

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:***@bupt.edu.cn]
Sent: Friday, November 29, 2013 05:04
To: Carsten Bormann
Cc: Dijk, Esko; ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication

Hi Carsten,

Thank you for your explanations.

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

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

________________________________
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.

[Likepeng]

Post by Dijk, Esko
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".

Post by Dijk, Esko
Any thoughts - do we need server identification as a standardized CoAP Option?

Yes, I think we need that.

Post by Dijk, Esko
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:core-***@ietf.org] 代表 Dijk, Esko
发送时间: 2013年11月29日 17:52
收件人: weigengyu; Carsten Bormann
抄送: ***@ietf.org
主题: 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:***@bupt.edu.cn]
Sent: Friday, November 29, 2013 05:04
To: Carsten Bormann
Cc: Dijk, Esko; ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group communication

Hi Carsten,

Thank you for your explanations.

Post by Dijk, Esko
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

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

________________________________
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
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

[weigengyu]

Post by Likepeng

Post by Dijk, Esko
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.

Post by Likepeng

Post by Dijk, Esko
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".

Actually, it is an extension of Location option.

Post by Likepeng

Post by Dijk, Esko
Any thoughts - do we need server identification as a standardized CoAP Option?

Yes, I think we need that.

+1.

Post by Likepeng

Post by Dijk, Esko
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.

Post by Likepeng

Post by Dijk, Esko
Any thoughts - do we need server identification as a standardized CoAP Option?

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.

Post by Likepeng

Post by Dijk, Esko
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: ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group
communication

Post by Likepeng
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".

Post by Likepeng
Any thoughts - do we need server identification as a standardized CoAP Option?

Yes, I think we need that.

Post by Likepeng
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:core-***@ietf.org] 代表 Dijk, Esko
发送时间: 2013年11月29日 17:52
收件人: weigengyu; Carsten Bormann
抄送: ***@ietf.org
主题: 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:***@bupt.edu.cn]
Sent: Friday, November 29, 2013 05:04
To: Carsten Bormann
Cc: Dijk, Esko; ***@ietf.org
Subject: Re: [core] How to correlate request and responses in group
communication

Hi Carsten,

Thank you for your explanations.

Post by Likepeng
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

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

________________________________
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
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

[Bert Greevenbosch]

Concerning the two option solutions "Location-Host" and re-use of "Uri-Host": do we care that the "Uri-*" options are critical, whereas the "Location-*" options are not? It seems that an elective option might be more appropriate, especially given that non-supporting devices may be interested in sending multicast requests (esp. PUTs and POSTs) without being interested in the responses.

When would such a "?-Host" option be included in the response? Does the responder need to inspect the UDP layer to indicate that the request is a multicast request? Then for this we are also mixing the layers.

Just some thoughts about this...

Post by Dijk, Esko
-----Original Message-----
Sent: 29 November 2013 17:52
To: weigengyu; Carsten Bormann
Subject: 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-----
Sent: Friday, November 29, 2013 05:04
To: Carsten Bormann
Subject: Re: [core] How to correlate request and responses in group communication
Hi Carsten,
Thank you for your explanations.

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
Network Technology Center
School of Computer
Beijing University of Posts & Telecommunications
________________________________
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
https://www.ietf.org/mailman/listinfo/core

[Dijk, Esko]

Post by Bert Greevenbosch
It seems that an elective option might be more appropriate,

Fully agree, that would be more appropriate. In terms of its semantics though, the Uri-Host Option still is a better fit than Location-Host. So a new type of option similar to Uri-Host would be needed to get the best solution.

Post by Bert Greevenbosch
Does the responder need to inspect the UDP layer to indicate that the request is a multicast request?

Yes, it's certainly assumed that the server at CoAP layer is aware of this fact. Hence all the rules about being allowed (or even, advised) to ignore certain multicast requests for security/congestion reasons. "Cross-layer optimization" is at the heart of 6LoWPAN's design and also CoAP's, if you ask me.

Esko

-----Original Message-----
From: Bert Greevenbosch [mailto:***@huawei.com]
Sent: Monday, December 02, 2013 02:15
To: Dijk, Esko; weigengyu; Carsten Bormann
Cc: ***@ietf.org
Subject: RE: [core] How to correlate request and responses in group communication

Concerning the two option solutions "Location-Host" and re-use of "Uri-Host": do we care that the "Uri-*" options are critical, whereas the "Location-*" options are not? It seems that an elective option might be more appropriate, especially given that non-supporting devices may be interested in sending multicast requests (esp. PUTs and POSTs) without being interested in the responses.

When would such a "?-Host" option be included in the response? Does the responder need to inspect the UDP layer to indicate that the request is a multicast request? Then for this we are also mixing the layers.

Just some thoughts about this...



________________________________
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.