[resending from the right e-mail address]
On Mon, Feb 8, 2016 at 2:16 PM, Thomas Watteyne <[email protected]> wrote:
> 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) <
> [email protected]> 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:[email protected]]
>> *Sent:* lundi 18 janvier 2016 14:26
>> *To:* Pascal Thubert (pthubert) <[email protected]>
>> *Cc:* [email protected]; [email protected]
>> *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) <
>> [email protected]> 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:[email protected]] *On Behalf Of *Tengfei Chang
>> *Sent:* lundi 18 janvier 2016 09:18
>> *To:* [email protected]
>> *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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
