Subject: [6lo] #17 (routing-dispatch): Format inside of an RPL domain

From: "6lo issue tracker" <[email-masked]>
Date: Mon, 08 Feb 2016 13:42:44 -0000

#17: 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???).

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-6lo-routing-
  [email-masked]     |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  routing-     |    Version:
  dispatch               |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/17>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Mon, 08 Feb 2016 13:43:17 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]
 * status:  new => assigned

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect              |      Status:  assigned
 Priority:  major               |   Milestone:
Component:  routing-dispatch    |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/17#comment:1>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Wed, 10 Feb 2016 14:23:05 -0000

Comment (by [email-masked]):

 From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert
 (pthubert)
 Sent: mercredi 10 février 2016 12:36
 To: Thomas Watteyne <[email-masked]>
 Cc: Simon Duquennoy <[email-masked]>; [email-masked]; Tengfei Chang
 <[email-masked]>; [email-masked]
 Subject: Re: [6tisch] [6lo] Format inside of an RPL domain

 Thanks Thomas!

 The only thing I did not act upon much is renaming the X-6LoRH, I really
 need to see a consensus on that at this late stage. Couls we start a
 different thread?

 More below:

 With this specification, an optimal compression
 TW> I would drop the word "optimal", which implies you can prove it.
 Replace by "efficient"?
 PT> The text was meant to say the most optimal this spec can do. What
 about
 The most efficient compression of an IP-in-IP encapsulation that can be
 achieved with this specification is obtained when an endpoint of the
 packet is
 the root of the RPL DODAG associated to the RPL Instance that is used to
 forward the packet, and the root address is known implicitly as opposed to
 signaled explicitly in the data packets.  …

 -----------
 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
 PT >It is; I added RPL in front to clarify
 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"
 PT > done
 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?
 PT > RPL option is the HbH encoding. RFC 6550 is more generic and defines
 the RPI independently of how it is placed in the packet.
 There is already text about that in the draft
 As an example, the [Routing Protocol for Low Power and Lossy
 Networks](#RFC6550)
 (RPL) is designed to optimize the routing operations in constrained LLNs.
 As part of this optimization, RPL requires the addition of RPL Packet
 Information
 (RPI) in every packet, as defined in Section 11.2 of {{RFC6550}}.

 The [RPL Option for Carrying RPL Information in Data-Plane
 Datagrams](#RFC6553)
 specification indicates how the RPI can be placed in a RPL Option for use
 in an
 IPv6 Hop-by-Hop header.

 PT > We can change that latter sentence into

 The [RPL Option for Carrying RPL Information in Data-Plane
 Datagrams](#RFC6553)
 specification indicates how the RPI can be placed in a RPL Option (RPL-
 OPT) that
 is placed in an IPv6 Hop-by-Hop header.

 ----

 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?
 PT > Since maybe?
 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 since RPL does not expose that
 property, it can only be known by a configuration applied to all nodes.

 type-3, but according to RFC6554, this is called "RPL Source Route
 Header". Let's please use that name...
 PT > This is a really classical way in IPv6. Just lookup IPv6 RH0 or RH2.
 Also, this document defines it on first use “RPL requires a Routing Header
 type 3 (RH3) “ . Which abbreviation should I use for the LoRH then? SRH-
 6LoRH? This is effectively less specific, and may create ambiguity. RPL-
 SRH-6LoRH is fine but long. I’d rather have a thread and get a rough
 consensus on renaming before taking actions.

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/17#comment:2>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Fri, 12 Feb 2016 18:11:43 -0000

* status:  assigned => closed
 * resolution:   => fixed

Comment:

 Fixed in 05
 RH3-6LoRH is now SRH-6LoRH
 RPI-6LoRH remains
 goal is to have a generic compression when the encoding may change from a
 techno to another

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect              |      Status:  closed
 Priority:  major               |   Milestone:
Component:  routing-dispatch    |     Version:
 Severity:  Active WG Document  |  Resolution:  fixed
 Keywords:                      |
--------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/17#comment:3>
6lo <https://tools.ietf.org/6lo/>