Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [leshan-dev] CoAP message as a HTTP payload
Hi,

May be we are all missing the point here, or I am miss reading it. 

The device will not send the message in HTTP, so how will the proxy work. Device will generate a CoAP message (not sure what format it would be as the message format for UDP and TCP are different).  Please note we are talking about the Non IP support where the device does not have an IP address. It will send the message as a signalling message to the wireless network.

The SCEF in wireless core network (TS 23.682) will push this message as received inside a HTTP message (HTTP Payload) as the north interface for SCEF is HTTP REST based.

Now, say in CoAP stack like we have UDP, TCP we have a HTTP connector, which receives the HTTP message looks at the payload and does the CoAP handling. So, I have few basic questions. What CoAP message format it would be (UDP, TCP ????). If you look at https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05 you will see that the message format for TCP and UDP are different.  ?

Can you please confirm how you think the HTTP to UDP proxy work? Are you thinking to develop an intermediate node which get the CoAP message as an HTTP payload and it extracts the message and creates an UDP tunnel to the CoAP server and sends the message? What advantage do you see for this rather than modifying the CoAP stack?

Kindly let us know.

Thanks, Santos



On Thu, Feb 16, 2017 at 7:58 AM, Okamoto Toshiaki <toshiaki.okamoto@xxxxxxxxx> wrote:
Hi
I suggest that you can interpret Coap messages from HTTP to UDP as a proxy.

Thank you.
Okamoto

On 2017/02/15 22:57, Santos Das wrote:
Hi,

I just put my requirement to the group. I want to send the CoAP message as a HTTP payload. Because SCEF (TS 23.682) will have the HTTP REST interface towards the server side. This is for the LWM2M communication for NBIOT. 

Please see appendix J in the attached document for more details.

Thanks, Santos

On Wed, Feb 15, 2017 at 6:13 PM, Okamoto Toshiaki <toshiaki.okamoto@xxxxxxxxx> wrote:
Hi Santos.
Do you mean HTTP-to-CoAP proxy in Section 10 of RFC 7252?
Here is a draft:
Guidelines for HTTP-to-CoAP Mapping Implementations draft-ietf-core-http-mapping-17
https://tools.ietf.org/html/draft-ietf-core-http-mapping-17#section-3

Thank you.
Okamoto

On 2017/02/15 20:54, Santos Das wrote:
Hi,

Does any one know how the CoAP message can be transmitted as a HTTP payload.

Looking at the RFCs, the message structure for UDP,TCP and WebScokets are different.

So, any idea how would it look like -


CoAP UDP RFC : https://tools.ietf.org/html/rfc7252

 

Message Structure:

 

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |Ver| T |  TKL  |      Code     |          Message ID           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Token (if any, TKL bytes) ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Options (if any) ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |1 1 1 1 1 1 1 1|    Payload (if any) ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

CoAP TCP RFC : https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05

 

Message Structure:

 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Len=13 |  TKL  |Extended Length|      Code     | TKL bytes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

CoAP Message Format over WebSockets

 

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Len |  TKL  |      Code     |    Token (TKL bytes) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 1 1 1 1|    Payload (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Regards, Santos
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

_______________________________________________ leshan-dev mailing list leshan-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/leshan-dev 
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev


_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev


Back to the top