Subject: [Roll] [Fwd: New Version Notification for draft-mulligan-roll-ripless-01]

From: Geoff Mulligan <[email-masked]>
Date: Mon, 08 Mar 2010 16:40:51 -0700

I don't think my previous message about -00 made it to the list.

		geoff

PS- I didn't spell successfully incorrectly below :-)  Other spelling
errors are all mine.

From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Subject: New Version Notification for draft-mulligan-roll-ripless-01
Date: Mon, 8 Mar 2010 15:29:52 -0800 (PST)

A new version of I-D, draft-mulligan-roll-ripless-01.txt has been successfuly submitted by Geoffrey Mulligan and posted to the IETF repository.

Filename:	 draft-mulligan-roll-ripless
Revision:	 01
Title:		 Optimized RIP for embedded RF networks
Creation_date:	 2010-03-08
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
This document specifies an optimization to the Routing Information
Protocol (RIP) routing protocol for use in embedded RF IPv6 internets
such as those used in 6lowpan [7] networks.  RIPless specifies the
minimal changes to RIP, as specified in RIPng [2], RIP [3] and RIPv2
[4] to allow the protocol to be used in a "lossy" RF networks where
the routing fabric of the network is built upon powered nodes and
that only the edge devices may be battery powered.

The IETF Secretariat.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Mar 2010 18:48:53 +0100

Hello,

I am happy this draft draft-mulligan-roll-ripless-01 exists, because it
relies on widely available software and deployments.

Are you requesting comments?

I have one comment with respect to the metrics section "6.1. Routing
Metric":

" The routing metric described in the RIP RFCs is a simple hop-count.
It is thought in the RF sensor networking community (???need
reference???) that just a simple hop count is insufficient to
properly determine the "best path" between two nodes. It is suggest
here that a weighted hop-count might provide a better metric. The
hop-count would be weighted by the RSSI/LQI value for the link
between each node."

I am not sure a unique metric, be that hopcount weighted by RSSI, is
enough to express various other needs like energy expenditure to send
packets on a particular link.

> The specific weighting could be implementation specific, but for an
> IEEE 802.15.4 [9] type network using 8 discrete LQI values links with
> an LQI of 0x00 and 0x01 might have the metric set to "infinite", LQIs
> of 0x02 through 0x05 would set metric to 2 and an LQI of 0x06 or 0x07
> would use the standard metric value of 1. If the implementor would
> rather use RSSI values or more values in LQI (256) are available some
> different step funtion might be use.

Hmmm... I would avoid filling up so many values of that RIP 8bit metric
value. Out of 255 values about 238 are left free. I would only take 1
value "0xfe", call it "energy metric encoded in RIPng RTE", as described
in the paragraphs below.

Alex

> 5.  Energy Metric Encoded in RIPng RTE
>
>    A RIPng packet can be depicted as follows:
>
>
>    +-----------+    +-----------------+ +---+    +----+
>    |Base Header| ...|Extension Headers| |UDP| ...|RTEs|
>    +-----------+    +-----------------+ +---+    +----+
>
>
>    A RIPng packet contains a list of RTEs (Route Table Entries) as
>    explained in [RFC2080] "RIPng for IPv6".  An 'address' RTE contains a
>    128 bit address, an 8 bit route tag, an 8 bit prefix length and an 8
>    bit metric (all for 20bytes).  A 'next hop' RTE is an RTE with a
>    metric value of 0xFF.  Many 'address' RTEs (actually, prefixes)
>    correspond to a single 'next hop' RTE.
>
>    The existing 8-bit metric value is used to express metrics between 1
>    and 15, thus determining the potential size of a RIPng routing
>    domain.  We propose to reserve the value 0xFE for an 'energy' metric
>    within an address RTE.
>
>    The energy RTE relates to the immediately preceding address RTE.  A
>    typical sequence of RTEs would be as depicted in the figure below:
>
>
>    +-----------+ +------------++-----------+ +------------++-----------+
>    |NextHop1RTE| |Address1 RTE||Energy1 RTE| |Address2 RTE||Energy2 RTE|
>    +-----------+ +------------++-----------+ +------------++-----------+
>
>
>    This sequence should be interpreted as follows: for any destination
>    address longest-prefix matching the prefix in Address1 RTE, the
>    energy metric is in Energy1 RTE and the next hop address is in Next
>    Hop1 RTE.  The same for Address2 RTE and Energy2 RTE.
>
>    The bit layout of the Energy RTE follows.
>
>     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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Max Energy Send                      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Min Energy Send                      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Max Energy Receive                   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Min Energy Receive                   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         route tag (2)         | prefix len (1)| Energy Metric |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>    Max Energy Send
>
>            Single-precision 32bit floating point number in binary
>            interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a
>            C 'float' type (see [ISOIEC-C99]), in network byte order.
>            The value represents the maximum energy, expressed in Joules,
>            necessary to send an IP packet of size 1280 bytes to any
>            address valid on the IPv6 prefix of the immediately preceding
>            address RTE.  This is the sum of the max energy values needed
>            to transmit this packet on each intermediary IPv6 Link.
>
>    Min Energy Send
>
>            Single-precision 32bit floating point number in binary
>            interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a
>            C 'float' type (see [ISOIEC-C99]), in network byte order.
>            The value represents the minimum energy, expressed in Joules,
>            necessary to send 1280 bytes to any address valid on the IPv6
>            prefix of the immediately preceding address RTE.  This is the
>            sum of the min energy values needed to transmit this packet
>            on each intermediary IPv6 link.
>
>    Max Energy Receive
>
>            Single-precision 32bit floating point number in binary
>            interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a
>            C 'float' type (see [ISOIEC-C99]), in network byte order.
>            The value represents the maximum energy, expressed in Joules,
>            necessary to receive 1280 bytes from any address valid on the
>            IPv6 prefix of the immediately preceding address RTE.  This
>            is the sum of the max energy values needed to receive this
>            packet on each intermediary IPv6 link.
>
>
>    Min Energy Receive
>
>            Single-precision 32bit floating point number in binary
>            interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a
>            C 'float' type (see [ISOIEC-C99]), in network byte order.
>            The value represents the minimum energy, expressed in Joules,
>            necessary to receive 1280 bytes from any address valid on the
>            IPv6 prefix of the immediately preceding address RTE.  This
>            is the sum of the min energy values needed to receive this
>            packet on each intermediary IPv6 link.
>
>    route tag
>
>            Set to 0 by sender, ignored by receiver.
>
>
>    prefix len
>
>            Set to zero by sender and ignored by receiver.
>
>
>    Energy Metric
>
>            Energy Metric for IPv6 Links.
>
>            TBA
>
>            We are not aware of IANA assignments for this metric field,
>            althtough IANA does maintain RIP Message Types at
>            http://www.iana.org/assignments/rip-types
>
>            We propose this field to contain 0xFE.  Existing values of
>            which we are aware are: 0, 1, ... 15, 0XFF.
>
>

Le 09/03/2010 00:40, Geoff Mulligan a écrit :
> From: IETF I-D Submission Tool<[email-masked]>
> To: [email-masked]
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Mar 2010 19:52:35 +0100

I meant to say one could reserve only one value e.g. 0xfd to mean e.g. 
"RSSI-weighted hopcount" in the 8bit metric and further detail in a new RTE.

Alex

Le 10/03/2010 18:48, Alexandru Petrescu a écrit :
>> A new version of I-D, draft-mulligan-roll-ripless-01.txt has been
>> successfuly submitted by Geoffrey Mulligan and posted to the IETF
>> repository.
>>