Subject: [6tisch] wrapping CoAP message in 6top IE

From: Qin Wang <[email-masked]>
Date: Wed, 19 Mar 2014 08:29:16 -0700 (PDT)

Hi all,

Background:

Beside negotiating for softcell reservation/remove, a node may need to access the MIB of its neighbors. For example,  GET neighbor's schedule may happen before a node wants  to make softcell reservation requirement, and SET action will happen when a parent wants to assign some cells in its chunk to its children. Thus, two interfaces between 6top-to-6top (one hop) will be needed, one is management interface responsible for accessing neighbor's MIB; and another one is negotiation interface responsible for softcell reservation/remove which is described in current version of draft-wang-6tisch-6top-sublayer. 

Possible solution for management interface:
Since we want to build a generic management interface between 6top-to-6top, we are thinking about taking advantage of YANG model and CoAP. The following is a preliminary scheme for further discussion. 

1) Add a new 6top IE, named as Wrapper IE. The content of Wrapper IE is the CoAP message translated from YANG model.
2) Include a Coap Parser-like module into 6top to deal with the content of Wrapper IE and access MIB.
3) Use the Block Option of CoAP to address the issue of IE size limitation

What do you think?

Thanks
Qin

---

From: <[email-masked]>
Date: Wed, 19 Mar 2014 16:10:36 +0000

Dear All,
A short question regarding to the usage of CoAP in 6top to 6top communication. Can we use CoAP methods in 6top sub-layer or we can only use CoAP methods in the transport layer? For example, in order to specify the URI path of the resources, don't we need the IP address (L3) of the nodes?
Regards,
Pouria

On 19 Mar 2014, at 16:29, "Qin Wang" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Background:

What do you think?

Thanks
Qin

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Wed, 19 Mar 2014 11:28:47 -0700 (PDT)

Hi Pouria,

Is it possible to replace Host name in URI with the MAC address of node, and keep the Path identifier of URI?

Thanks
Qin

On Thursday, March 20, 2014 12:11 AM, "[email-masked]" <[email-masked]> wrote:
 
Dear All, 

On 19 Mar 2014, at 16:29, "Qin Wang" <[email-masked]> wrote:

Hi all,
>[email-masked]

[email-masked]

---

From: <[email-masked]>
Date: Wed, 19 Mar 2014 19:44:01 +0000

Hi Qin,

Regarding to the following figure CoAP works on top of UDP:

+------------------------------+
|              Application            |
+------------------------------+
+------------------------------+
|  Requests/Responses     |
|------------------------------|  CoAP
|                 Messages             |
+------------------------------+
+------------------------------+
|                   UDP                      |
+------------------------------+

I think if we intend to use CoAP directly in 6top, then we need to do a surgery in CoAP protocol and make our own CoAP in 6top. If we consider a scenario that a node is using CoAP protocol to communicate with PCE as well as its children (6top-to-6top), so we need to have two implementations of CoAP in both transport layer and 6top layer, respectively. Am I right?

If we want to use the CoAP protocol for 6top-to-6top communication, I would suggest to make it possible for 6top sub-layer to ask the higher layer to make two end-points (in transport layer) in both neighboring nodes and handle this negotiation (with the neighboring node) from there. Does it make sense?

Regards,
Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 7:29 PM
To: Zand, P. (EWI)
Cc: [email-masked]
Subject: Re: [6tisch] wrapping CoAP message in 6top IE

Hi Pouria,

Thanks
Qin

On Thursday, March 20, 2014 12:11 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:
Dear All,
A short question regarding to the usage of CoAP in 6top to 6top communication. Can we use CoAP methods in 6top sub-layer or we can only use CoAP methods in the transport layer? For example, in order to specify the URI path of the resources, don't we need the IP address (L3) of the nodes?
Regards,
Pouria

Background:

What do you think?

Thanks
Qin

---

From: <[email-masked]>
Date: Wed, 19 Mar 2014 21:17:19 +0000

Hi Qin,
My suggestion is an immature idea to use one CoAP module in higher layer for both 6top-to-6top communication and 6top-to-PCE communication.
Regarding to your questions, either the CoAP server end-point or client end-point (parent or children in RPL) is responsible for establishing the connection. After establishing the connection, the regular method is used for setting the URI path by the IP address. I think the CoAP server and client can be either one hop or several hops far from each other. Does it make sense?
Regards,
Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 9:33 PM
To: Zand, P. (EWI)
Subject: Re: [6tisch] wrapping CoAP message in 6top IE

Hi Pouria,

I think, conceptually, a node may need two CoAP modules, one is in transport layer, and another one is in 6top sublayer. But, for implementation, there may be some way to save memory.

Regarding to your two end-points suggestion, I have some questions.  (1) who is responsible for setting the two end-points, a CoAP server or something else? (2) After the two end-points are set, how to form the URI, Host= IP address like that in conventional CoAP, or =MAC address, or something else? Since the end points are in transport layer as you said, I guess IP address will be used in URI. Then, is it possible for the two end points talk directly, i.e. in one hop?

Thanks
Qin

On Wednesday, March 19, 2014 3:44 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

Regards,
Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 7:29 PM
To: Zand, P. (EWI)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] wrapping CoAP message in 6top IE

Hi Pouria,

Thanks
Qin

Background:

What do you think?

Thanks
Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 20 Mar 2014 05:52:54 +0100

Hi Pouria

regarding to having CoAP implemented at 6top level and whehter it is
another flavour of CoAP or not. I think that what we want is the way CoAP
represents information to be used as a payload in a Wrapper IE. Note that
6top upon receiving a Wrapper IE element will parse its payload according
to general CoAP rules, e.g option parsing, option encoding, (using probably
a generic CoAP parser -- this would be desirable) etc.. but not supporting
all CoAP features or behaving as a REST interface.

Regarding URLs, I guess we can omit uri-host and uri-port option in the
wrapper IE and only use the uri-path and uri-query option (this second one
if applies).
The benefits I see on that approach is that we will not need to invent a
new content representation format and we will enable both PCE to Node and
Node to Node interaction using the same specification.
Note also that mac layer address is in the L2 header so uri-host address is
not needed to identify destination of a 6top-to-6top packet.

I see this analogous as the transformation from IPv6 to 6Lowpan in an LBR
(but much simpler).

I paste here a CoAP example to show how simply content is represented.

 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 | OC | Code | Message ID |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Options (if any) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Payload (if any) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Client Server
 |      |
 |      |
 +----->| Header: GET (T=CON, Code=1, MID=0x7d34)
 |  GET | Uri-Path: "temperature"
 |      |
 |      |
 |<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d34)
 | 2.05 | Payload: "22.3 C"
 |      |

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1 | 0 | 1 | GET=1 | MID=0x7d34 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 11 | 11 | "temperature" (11 B) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1 | 2 |   0   |    2.05=69    |          MID=0x7d34           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1 1 1 1 1 1 1 1|      "22.3 C" (6 B) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Maybe an exercise is to determine if CoAP header provides us all what we
want, and if there are things we need/can remove. The later will require us
to create a wrapper of CoAP packets to LowCoAP (I invent that name ;) ), as
if it was from IPv6 to 6LowPAN. However I guess would be desirable to use
it as is.

regards,
Xavi

2014-03-19 22:17 GMT+01:00 <[email-masked]>:

>  Hi Qin,
>
> My suggestion is an immature idea to use one CoAP module in higher layer
> for both 6top-to-6top communication and 6top-to-PCE communication.
>
> Regarding to your questions, either the CoAP server end-point or client
> end-point (parent or children in RPL) is responsible for establishing the
> connection. After establishing the connection, the regular method is used
> for setting the URI path by the IP address. I think the CoAP server and
> client can be either one hop or several hops far from each other. Does it
> make sense?
>
> Regards,
>
> Pouria
>
>
>
>
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* Wednesday, March 19, 2014 9:33 PM
> *To:* Zand, P. (EWI)
>
> *Subject:* Re: [6tisch] wrapping CoAP message in 6top IE
>
>
>
> Hi Pouria,
>
>
>
> I think, conceptually, a node may need two CoAP modules, one is in
> transport layer, and another one is in 6top sublayer. But, for
> implementation, there may be some way to save memory.
>
>
>
> Regarding to your two end-points suggestion, I have some questions.  (1)
> who is responsible for setting the two end-points, a CoAP server or
> something else? (2) After the two end-points are set, how to form the URI,
> Host= IP address like that in conventional CoAP, or =MAC address, or
> something else? Since the end points are in transport layer as you said, I
> guess IP address will be used in URI. Then, is it possible for the two end
> points talk directly, i.e. in one hop?
>
>
>
> Thanks
>
> Qin
>
>
>
> On Wednesday, March 19, 2014 3:44 PM, "[email-masked]" <
> [email-masked]> wrote:
>
> Hi Qin,
>
>
>
> I think if we intend to use CoAP directly in 6top, then we need to do a
> surgery in CoAP protocol and make our own CoAP in 6top. If we consider a
> scenario that a node is using CoAP protocol to communicate with PCE as well
> as its children (6top-to-6top), so we need to have two implementations of
> CoAP in both transport layer and 6top layer, respectively. Am I right?
>
>
>
> If we want to use the CoAP protocol for 6top-to-6top communication, I
> would suggest to make it possible for 6top sub-layer to ask the higher
> layer to make two end-points (in transport layer) in both neighboring nodes
> and handle this negotiation (with the neighboring node) from there. Does it
> make sense?
>
>
>
> Regards,
>
> Pouria
>
>
>
>
>
> *From:* Qin Wang [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, March 19, 2014 7:29 PM
> *To:* Zand, P. (EWI)
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] wrapping CoAP message in 6top IE
>
>
>
> Hi Pouria,
>
>
>
> A short question regarding to the usage of CoAP in 6top to 6top
> communication. Can we use CoAP methods in 6top sub-layer or we can only use
> CoAP methods in the transport layer? For example, in order to specify the
> URI path of the resources, don't we need the IP address (L3) of the nodes?
>
> Regards,
>
> Pouria
>
>
> Beside negotiating for softcell reservation/remove, a node may need to
> access the MIB of its neighbors. For example,  GET neighbor's schedule may
> happen before a node wants  to make softcell reservation requirement, and
> SET action will happen when a parent wants to assign some cells in its
> chunk to its children. Thus, two interfaces between 6top-to-6top (one hop)
> will be needed, one is management interface responsible for accessing
> neighbor's MIB; and another one is negotiation interface responsible for
> softcell reservation/remove which is described in current version of
> draft-wang-6tisch-6top-sublayer.
>
>
>
> Since we want to build a generic management interface between
> 6top-to-6top, we are thinking about taking advantage of YANG model and
> CoAP. The following is a preliminary scheme for further discussion.
>
> 1) Add a new 6top IE, named as Wrapper IE. The content of Wrapper IE is
> the CoAP message translated from YANG model.
>

---

From: <[email-masked]>
Date: Thu, 20 Mar 2014 09:19:54 +0000

Hi Xavi,

I completely agree with you that in this case, the same specification might be used for both PCE-to-6top and 6top-to-6top interactions.
However, I think the main question is if we can define a generic CoAP parser without the need to use other features of CoAP protocol in the 6top. For example, consider the case that a node need to interact with several neighboring nodes (end-points) simultaneously. Don't we need other features of CoAP to handle this situation. Am I missing anything?

Regards,
Pouria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Thursday, March 20, 2014 5:53 AM
To: Zand, P. (EWI)
Cc: Qin Wang; [email-masked]
Subject: Re: [6tisch] wrapping CoAP message in 6top IE

Hi Pouria

regarding to having CoAP implemented at 6top level and whehter it is another flavour of CoAP or not. I think that what we want is the way CoAP represents information to be used as a payload in a Wrapper IE. Note that 6top upon receiving a Wrapper IE element will parse its payload according to general CoAP rules, e.g option parsing, option encoding, (using probably a generic CoAP parser -- this would be desirable) etc.. but not supporting all CoAP features or behaving as a REST interface.

Regarding URLs, I guess we can omit uri-host and uri-port option in the wrapper IE and only use the uri-path and uri-query option (this second one if applies).
The benefits I see on that approach is that we will not need to invent a new content representation format and we will enable both PCE to Node and Node to Node interaction using the same specification.
Note also that mac layer address is in the L2 header so uri-host address is not needed to identify destination of a 6top-to-6top packet.

I see this analogous as the transformation from IPv6 to 6Lowpan in an LBR (but much simpler).

Client Server
 |      |
 |      |

Maybe an exercise is to determine if CoAP header provides us all what we want, and if there are things we need/can remove. The later will require us to create a wrapper of CoAP packets to LowCoAP (I invent that name ;) ), as if it was from IPv6 to 6LowPAN. However I guess would be desirable to use it as is.

regards,
Xavi

2014-03-19 22:17 GMT+01:00 <[email-masked]<mailto:[email-masked]>>:
Hi Qin,
My suggestion is an immature idea to use one CoAP module in higher layer for both 6top-to-6top communication and 6top-to-PCE communication.
Regarding to your questions, either the CoAP server end-point or client end-point (parent or children in RPL) is responsible for establishing the connection. After establishing the connection, the regular method is used for setting the URI path by the IP address. I think the CoAP server and client can be either one hop or several hops far from each other. Does it make sense?
Regards,
Pouria

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 19, 2014 9:33 PM
To: Zand, P. (EWI)

Hi Pouria,

Thanks
Qin

Regards,
Pouria

Hi Pouria,

Thanks
Qin

Background:

What do you think?

Thanks
Qin

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 07:04:32 -0700 (PDT)

Hi Xavi and Pouria,

Can you explain what the CoAP parser will do with uri-host when it receives a CoAP message? Is there something related with Security or Access check? 

In 6top, READ operation can happen between any pair of nodes, but the WRITE operation only can happen from parent to children. I'm not sure if such kind of check function should be included in 6top-CoAP parser or not. If yes, the wrapped CoAP should include something like MAC address; if not, the 6top-CoAP parser will not be self contained. Thought?

Thanks
Qin

On Thursday, March 20, 2014 5:20 PM, "[email-masked]" <[email-masked]> wrote:
 
Hi Xavi,
 
I completely agree with you that in this case, the same specification might be used for both PCE-to-6top and 6top-to-6top interactions.
However, I think the main question is if we can define a generic CoAP parser without the need to use other features of CoAP protocol in the 6top. For example, consider the case that a node need to interact with several neighboring nodes (end-points) simultaneously. Don’t we need other features of CoAP to handle this situation. Am I missing anything?
 
Regards,
Pouria
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Thursday, March 20, 2014 5:53 AM
To: Zand, P. (EWI)
Cc: Qin Wang; [email-masked]
Subject: Re: [6tisch] wrapping CoAP message in 6top IE
 
Hi Pouria

 

 
Client Server
 |      |
 |      |

 

regards,
Xavi

From:Qin Wang [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2014 9:33 PM
To: Zand, P. (EWI)

Hi Pouria,

 
Thanks
Qin
 
On Wednesday, March 19, 2014 3:44 PM, "[email-masked]" <[email-masked]> wrote:
Hi Qin,

 

Regards,
Pouria  

From:Qin Wang [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2014 7:29 PM
To: Zand, P. (EWI)
Cc: [email-masked]
Subject: Re: [6tisch] wrapping CoAP message in 6top IE
 
Hi Pouria,

Thanks
Qin

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Thu, 20 Mar 2014 14:34:30 +0000

Xavi, Pouria,
I agree with Qin.

Xavi — Note that 6top upon receiving a Wrapper IE element will parse its payload according to general CoAP rules, e.g option parsing, option encoding, (using probably a generic CoAP parser -- this would be desirable) etc.. but not supporting all CoAP features or behaving as a REST interface.

In this case we are forcing that 6top have a CoAP parser which increases the complexity of 6top. However, any other parsing scheme would also add an overhead (only maybe smaller).
Also, There are many redundancies like uri-host (which Qin has mentioned), content-length etc which will already be in an IE header.

I think what we really need here is a payload formatting method (like CBOR) as opposed to a protocol (CoAP).

I believe that the point of the YANG model was that different implementations/comms channels like PCE-to-6top and 6top-to-6top could use different payload formatting methods but still be parseable and have bahaviors/effects in a consistent manner.

In my opinion, instead of replicating the CoAP messages as payloads of the wrapper IE, we should use the YANG model to create a payload (possibly CBOR formatted) that will be contained in the wrapper IE. This will remove the redundancies that will be caused w.r.t replication of headers/control info. This will also be a proving method for the YANG model.

The 6top parser (e.g. CBOR in my example so far) can also implement 6top constraints as Qin has mentioned below.

Xavi - The benefits I see on that approach is that we will not need to invent a new content representation format and we will enable both PCE to Node and Node to Node interaction using the same specification.
Partly true. You will end up modifying the CoAP spec/parser in quite a significant way and it might be more prudent to start form the YANG model.

-raghuram

From: Qin Wang <[email-masked]<mailto:[email-masked]>>
Reply-To: Qin Wang <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 20, 2014 at 7:04 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] wrapping CoAP message in 6top IE

Hi Xavi and Pouria,

Thanks
Qin

On Thursday, March 20, 2014 5:20 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Xavi,

Regards,
Pouria

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Thursday, March 20, 2014 5:53 AM
To: Zand, P. (EWI)
Cc: Qin Wang; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] wrapping CoAP message in 6top IE

Hi Pouria

Client Server
 |      |
 |      |

regards,
Xavi

Hi Pouria,

Thanks
Qin

Regards,
Pouria

Hi Pouria,

Thanks
Qin

Background:

What do you think?

Thanks
Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 20 Mar 2014 19:27:42 +0100

Hi,

The Option format is composed by an option delta an option length that the
parser evaluates and decodes, this mechanism enables to encode multiple
options using very little space. While for CoAP does not make sense to skip
URI-PATH and URI-PORT options for our purpose a CoAP parser will support a
message without that options. So I guess that technically this would be
feasible.

The question is whether it is worth cherrypicking some options and fields
from a CoAP message and building a LowCoAP message. The later oposed to
defining a new 6top to 6top header based on the Yang Model and embed it in
the Wrapper IE. If we go for the second option, then the PCE-6top approach
using CoAP will need to parse CoAP messages and invoke 6top operations
while the 6top to 6top will probably use another parser. This will require
multiple implementation for the same yang model.

X

2014-03-20 15:34 GMT+01:00 Raghuram Sudhaakar (rsudhaak) <[email-masked]
>:

>  Xavi, Pouria,
>  I agree with Qin.
>
>  Xavi -- Note that 6top upon receiving a Wrapper IE element will parse its
> payload according to general CoAP rules, e.g option parsing, option
> encoding, (using probably a generic CoAP parser -- this would be desirable)
> etc.. but not supporting all CoAP features or behaving as a REST interface.
>
>  In this case we are forcing that 6top have a CoAP parser which increases
> the complexity of 6top. However, any other parsing scheme would also add an
> overhead (only maybe smaller).
>  Also, There are many redundancies like uri-host (which Qin has
> mentioned), content-length etc which will already be in an IE header.
>
>  I believe that the point of the YANG model was that different
> implementations/comms channels like PCE-to-6top and 6top-to-6top could use
> different payload formatting methods but still be parseable and have
> bahaviors/effects in a consistent manner.
>
>  In my opinion, instead of replicating the CoAP messages as payloads of
> the wrapper IE, we should use the YANG model to create a payload (possibly
> CBOR formatted) that will be contained in the wrapper IE. This will remove
> the redundancies that will be caused w.r.t replication of headers/control
> info. This will also be a proving method for the YANG model.
>
>  Xavi - The benefits I see on that approach is that we will not need to
> invent a new content representation format and we will enable both PCE to
> Node and Node to Node interaction using the same specification.
> Partly true. You will end up modifying the CoAP spec/parser in quite a
> significant way and it might be more prudent to start form the YANG model.
>
>   -raghuram
>
>   From: Qin Wang <[email-masked]>
> Reply-To: Qin Wang <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
>  Can you explain what the CoAP parser will do with uri-host when it
> receives a CoAP message? Is there something related with Security or Access
> check?
>
>  In 6top, READ operation can happen between any pair of nodes, but the
> WRITE operation only can happen from parent to children. I'm not sure if
> such kind of check function should be included in 6top-CoAP parser or not.
> If yes, the wrapped CoAP should include something like MAC address; if not,
> the 6top-CoAP parser will not be self contained. Thought?
>
>  Thanks
>  Qin
>
>
> I completely agree with you that in this case, the same specification
> might be used for both PCE-to-6top and 6top-to-6top interactions.
> However, I think the main question is if we can define a generic CoAP
> parser without the need to use other features of CoAP protocol in the 6top.
> For example, consider the case that a node need to interact with several
> neighboring nodes (end-points) simultaneously. Don't we need other features
> of CoAP to handle this situation. Am I missing anything?
>
> Regards,
> Pouria
>
>  *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Xavier Vilajosana
> *Sent:* Thursday, March 20, 2014 5:53 AM
> *To:* Zand, P. (EWI)
> *Cc:* Qin Wang; [email-masked]
>  Note also that mac layer address is in the L2 header so uri-host address
> is not needed to identify destination of a 6top-to-6top packet.
>
>   Is it possible to replace Host name in URI with the MAC address of
> node, and keep the Path identifier of URI?
>
>   Thanks
>   Qin
>

---

From: <[email-masked]>
Date: Fri, 28 Mar 2014 17:04:37 +0000

Dear All,

Regarding to our discussion in today's call, the worst case scenario that I can imagine is the case that a parent (node A) needs to subscribe to several attributes/parameters of one of its child (node B). Is this case, the parent might need to maintain several connections with that child. Using the port option and other CoAP feature is unavoidable in this scenario. Am I right? I am not sure if we need to address similar scenarios in 6top-to-6top interaction.

Best wishes,
Pouria

On 20 Mar 2014, at 19:27, "Xavier Vilajosana" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

The Option format is composed by an option delta an option length that the parser evaluates and decodes, this mechanism enables to encode multiple options using very little space. While for CoAP does not make sense to skip URI-PATH and URI-PORT options for our purpose a CoAP parser will support a message without that options. So I guess that technically this would be feasible.

The question is whether it is worth cherrypicking some options and fields from a CoAP message and building a LowCoAP message. The later oposed to defining a new 6top to 6top header based on the Yang Model and embed it in the Wrapper IE. If we go for the second option, then the PCE-6top approach using CoAP will need to parse CoAP messages and invoke 6top operations while the 6top to 6top will probably use another parser. This will require multiple implementation for the same yang model.

X

2014-03-20 15:34 GMT+01:00 Raghuram Sudhaakar (rsudhaak) <[email-masked]<mailto:[email-masked]>>:
Xavi, Pouria,
I agree with Qin.

-raghuram

Hi Xavi and Pouria,

Thanks
Qin

Regards,
Pouria

Hi Pouria

Client Server
 |      |
 |      |

regards,
Xavi

Hi Pouria,

Thanks
Qin

Regards,
Pouria

Hi Pouria,

Thanks
Qin

Background:

What do you think?

Thanks
Qin