Re: [6tisch] [6lo] Format inside of an RPL domain

Pascal,

I hope my comments don't come too late. Please find below some edits of
your suggested text.

My biggest comment is about naming, as I think we are using "nicknames" for
things, which makes things very hard to follow.

Thomas

## DODAG Root Address {#impl-comp-ref}

With this specification, an optimal compression

TW> I would drop the word "optimal", which implies you can prove it.
Replace by "efficient"?

of IP-in-IP encapsulation can be

achieved if an endpoint of the packet is the root of the RPL DODAG
associated to

the Instance

TW> please make sure that you use the capital "I" on purpose

that is used to forward the packet, and the root address is known

implicitly as opposed to signaled explicitly in the data packets.

With RPL {{RFC6550}}, the address of

TW> add "the"

DODAG root is known from the DODAGID field

of the DIO messages. For a Global Instance, the RPLInstanceID that is
present in

the RPI

TW> where does the term RPI come from? According to RFC6553, the full name
is "RPL Option", no?

is enough information to identify the DODAG that this node participates

to and its associated root. But for a Local Instance, the address of the
root

MUST be explicit, either in some device configuration or signaled in the
packet,

as the source or the destination address, respectively.

When implicit, the address of the DODAG root MUST be determined as follows:

If the whole network is a single DODAG then the root can be well-known and
does

not need to be signaled in the packets. But

TW> "if" missing?

RPL does not expose that property

and it can only be known by a configuration applied to all nodes.

Else, the router that encapsulates the packet and compresses it with this

specification MUST also place an RPI in the packet as prescribed by
{{RFC6550}}

to enable the identification of the DODAG. The RPI must be present even in
the

case when the router also places an RH3 header in the packet.

It is expected that the RPL implementation provides an abstract context
table,

indexed by Global RPLInstanceID, that provides the address of the root of
the

DODAG that this nodes participates to for that particular Instance.

## Compression Reference {#sig-comp-ref}

In order to optimize the compression of IP addresses present in the RH3
headers,

this specification requires that the 6LoWPAN layer identifies an address
that is

used as reference for the compression. With this specification, the
Compression

Reference for addresses found in an RH3 header is the source of the IPv6
packet.

With RPL {{RFC6550}}, an RH3

> In the same vain as my comment about RPI, we should really force
ourselves to use the same terminology, or else it gets really really
confusing.

> I understand that RH3 stands for
the-Routing-header-with-IPv6-routing-type-3, but according to RFC6554, this
is called "RPL Source Route Header". Let's please use that name...

header may only be present in Non-Storing mode, and

it may only be placed in the packet by the root of the DODAG, which must be
the

source of the resulting IPv6 packet {{RFC2460}}. In this case, the address
used

as Compression Reference is that the address of the root, and it can be
implicit

when the address of the root is.

The Compression Reference MUST be determined as follows:

The reference address may be obtained by configuration. The configuration
may

indicate either the address in full, or the identifier of a 6LoWPAN Context
that

carries the address {{RFC6775}}, for instance one of the 16 Context
Identifiers

used in LOWPAN-IPHC {{RFC6282}}.

Else, and if there is no IP-in-IP encapsulation, the source address in the
IPv6

header that is compressed with LOWPAN-IPHC is the reference for the
compression.

Else, and if the IP-in-IP compression specified in this document is used
and the

Encapsulator Address is provided, then the Encapsulator Address is the
reference.

(note that this means that the specification does not expect IP-in-IP-in-IP
and

does not enforce any order in 6LoRH ... should it???).

On Wed, Jan 20, 2016 at 4:14 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Tengfei and Simon (and all):
>
>
>
> I’ll need some more help from you.
>
>
>
> I’m in the process of refining the text that indicates how the root
> address is obtained and how to compute the Compression Reference for the
> RH3.
>
>
>
> I came up with the following, which indicates that the source of the
> packet (which should always be the root for now but who knows) is the
> reference for RH3 compression.
>
>
>
> Is that what we want? Is it clear enough?
>
>
>
>
>
> ## DODAG Root Address {#impl-comp-ref}
>
>
>
> With this specification, an optimal compression of IP-in-IP encapsulation
> can be
>
> achieved if an endpoint of the packet is the root of the RPL DODAG
> associated to
>
> the Instance that is used to forward the packet, and the root address is
> known
>
> implicitly as opposed to signaled explicitly in the data packets.
>
>
>
> With RPL {{RFC6550}}, the address of DODAG root is known from the DODAGID
> field
>
> of the DIO messages. For a Global Instance, the RPLInstanceID that is
> present in
>
> the RPI is enough information to identify the DODAG that this node
> participates
>
> to and its associated root. But for a Local Instance, the address of the
> root
>
> MUST be explicit, either in some device configuration or signaled in the
> packet,
>
> as the source or the destination address, respectively.
>
>
>
> When implicit, the address of the DODAG root MUST be determined as follows:
>
>
>
> If the whole network is a single DODAG then the root can be well-known and
> does
>
> not need to be signaled in the packets. But RPL does not expose that
> property
>
> and it can only be known by a configuration applied to all nodes.
>
>
>
> Else, the router that encapsulates the packet and compresses it with this
>
> specification MUST also place an RPI in the packet as prescribed by
> {{RFC6550}}
>
> to enable the identification of the DODAG. The RPI must be present even in
> the
>
> case when the router also places an RH3 header in the packet.
>
>
>
> It is expected that the RPL implementation provides an abstract context
> table,
>
> indexed by Global RPLInstanceID, that provides the address of the root of
> the
>
> DODAG that this nodes participates to for that particular Instance.
>
>
>
>
>
> ## Compression Reference {#sig-comp-ref}
>
>
>
> In order to optimize the compression of IP addresses present in the RH3
> headers,
>
> this specification requires that the 6LoWPAN layer identifies an address
> that is
>
> used as reference for the compression. With this specification, the
> Compression
>
> Reference for addresses found in an RH3 header is the source of the IPv6
> packet.
>
>
>
> With RPL {{RFC6550}}, an RH3 header may only be present in Non-Storing
> mode, and
>
> it may only be placed in the packet by the root of the DODAG, which must
> be the
>
> source of the resulting IPv6 packet {{RFC2460}}. In this case, the address
> used
>
> as Compression Reference is that the address of the root, and it can be
> implicit
>
> when the address of the root is.
>
>
>
> The Compression Reference MUST be determined as follows:
>
>
>
> The reference address may be obtained by configuration. The configuration
> may
>
> indicate either the address in full, or the identifier of a 6LoWPAN
> Context that
>
> carries the address {{RFC6775}}, for instance one of the 16 Context
> Identifiers
>
> used in LOWPAN-IPHC {{RFC6282}}.
>
>
>
> Else, and if there is no IP-in-IP encapsulation, the source address in the
> IPv6
>
> header that is compressed with LOWPAN-IPHC is the reference for the
> compression.
>
>
>
> Else, and if the IP-in-IP compression specified in this document is used
> and the
>
> Encapsulator Address is provided, then the Encapsulator Address is the
> reference.
>
>
>
> (note that this means that the specification does not expect
> IP-in-IP-in-IP and
>
> does not enforce any order in 6LoRH ... should it???).
>
>
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* Tengfei Chang [mailto:tengfei.chang@gmail.com]
> *Sent:* lundi 18 janvier 2016 14:26
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>
> *Cc:* 6lo@ietf.org; 6tisch@ietf.org
> *Subject:* Re: [6lo] Format inside of an RPL domain
>
>
>
> I agree with this format! +1
>
>
>
> Tengfei
>
>
>
> On Mon, Jan 18, 2016 at 9:41 AM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:
>
> Dear TengFei:
>
>
>
> I agree that the draft is lacking description when there is no IP in IP.
> I’ll create a ticket.
>
>
>
> When there is no IP in IP present in the 6LoRH, then the headers
> compressed by 6LoRH are considered placed right after the IP header
> compressed by IPHC, and considered as compressed. It results that the NH
> bit in the IPHC really indicates how the compression is done for the header
> that is after the headers compressed by 6LoRH.
>
>
>
> For an ICMP message I’d think that you’ll be using:
>
>
>
>    +- ...  -+- ...  -+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
>
>    |11110001|  RPI   |  NH = 0       | NH = 58  |  ICMP message
>
>    |Page 1  | 6LoRH  | 6LOWPAN-IPHC  | (ICMP)   |  (no compression)
>
>    +- ...  -+- ... +-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
>
>                       <-        RFC 6282       ->
>
>                             No RPL artifact
>
>
>
> Does that make sense?
>
>
>
> Pascal
>
>
>
> *From:* 6lo [mailto:6lo-bounces@ietf.org] *On Behalf Of *Tengfei Chang
> *Sent:* lundi 18 janvier 2016 09:18
> *To:* 6lo@ietf.org
> *Subject:* [6lo] Format inside of an RPL domain
>
>
>
> Dear All,
>
>
>
> Currently I have a question about the format of packet inside of an RPL
> domain when using 6LoRH.
>
>
>
> For example when ping a mote inside an RPL domain, will the format of echo
> request and reply look like this?
>
>
>
> PAGE DISPATCH (page 1) + IPHC + 6LoRH RH3 + ICMPv6
>
> PAGE DISPATCH (page 1) + IPHC + 6LoRH RPI + ICMPv6
>
>
>
> If so, there is no next header field in 6LoRH to indicate the following
> field is ICMP.
>
> What's the right format for this case?
>
>
>
> Thanks a lot!
>
> Tengfei
>
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
>