Hi Lotte, everyone,
I've tweaked this text a bit further and here is the end result (attached).
This replaces the table we previously had in the RFC 5444 Representation
section, and the preceding paragraph. The first part of this section was
left unchanged.
Thanks Lotte for coming up with this text, I think it makes it SO much
clearer and I'm sure Henning will be pleased too!
Kind regards,
Vicky.
On Wed, Apr 29, 2015 at 10:39 AM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Victoria,The following sections show how AODVv2 data elements are represented
Am 29.04.2015 um 10:59 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte,
I've just put your text into the document and this is how its turned out -
attached (I removed some whitespace because when it generated tables, it
only included the first row, and the other rows were garbled text
underneath it)
I think it looks great. The 69 character thing doesn't matter, because as
you say below, its a table which gets fitted to the page width anyway.
it looks very nice indeed!
I do need to check the references etc., but here's the first look of it
anyway. What does everyone think?
More comments in line.
On Wed, Apr 29, 2015 at 9:41 AM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, hi all,
Am 29.04.2015 um 10:12 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Charlie, hi all,
Comments in line.
On Wed, Apr 29, 2015 at 7:39 AM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Lotte,it? This is what RFC5444 says on prefix length:
It says "Each address is connected to its PrefixLength."
But if all the PrefixLengths are the default (32 for IPv4, 128 for IPv6),
no PrefixLength field is required.
Why dont we just give this information to RFC5444 and let it deal with
<prefix-length> is an 8-bit unsigned integer field containing the
length, in bits, of an address prefix. If the ahassingleprelen
flag is set ('1'), then a single <prefix-length> field is included
that contains the prefix length of all addresses in the Address
Block. If the ahasmultiprelen flag is set ('1'), then <num-addr>
<prefix-length> fields are included, each of which contains the
prefix length of the corresponding address prefix in the Address
Block (in the same order). Otherwise, no <prefix-length> fields
are present; each address object can be considered to have a
prefix length equal to 8 * address-length bits. The Address Block
is malformed if any <prefix-length> element has a value greater
than 8 * address-length.
Where we have:
address-length is a variable whose value is the length of an address
in octets and is calculated as follows:
address-length = <msg-addr-length> + 1
So, wont the RFC5444 parser decide what to do?
- If all prefix lengths are the same as the address length, it would
surely omit the prefix length field.
- If all prefix lengths were not equal to the address length, but
were the same as each other, it would use a single prefix length (
ahassingleprelen).
- If prefix lengths are not all the same, it would need to use
multiple prefix lengths (ahasmultiprelen).
This is an RFC5444 thing, AODVv2 doesnt need to try to force it.
Sounds reasonable to me. But then I should add a remark that if no prefix
length is specified (as this is legal in the rest of the draft), prefix
length should equal address length, right?
Yes. Is that clear in the draft at the moment?
I just checked the most recent update I could find (-9b) and I think it is
:)
Cheers,
Lotte
:)
Also, the table has to be somehow formatted to look good within the
constraints imposed by RFC formats. So, tables with row widths greater
than 69 characters become far less readable.
This was my only concern.
I was trying to adhere to the pandoc table format, hoping that pandoc2rfc
would translate it into an RFC-appropriate table. Apparently that went
wrong.. Would it be okay if Vicky sent me the markdown/pandoc file she's
currently working with so I can figure out and test the tables and supply
you with something that's proven to work? :)
My bad, I wrote that before I actually tested it. I think it looks great
Regards,
Vicky
Regards,<RFC5444 section - Lotte.txt>
Lotte
The data elements for each message need to be broken into muchwill need to incorporate Lotte's text with the 69 character constraint.
more clearly separated sections, something more like
###################### RREP #########################
than "## RREP", but this might have something to do with
whatever md needs.
"## RREP" means a "9.2" type heading in the markdown format. But yes, we
Regards,
Vicky.
Regards,
Charlie P.
On 4/21/2015 8:50 AM, Lotte Steenbrink wrote:
## RREQ
### Message header
Corresponding Data Element Header field Value
-------------------------- --------------- -----
msg_hop_limit <msg-hop-limit> ???
msg_hop_count <msg-hop-count> Number of hops traversed so
far
by the message
Message Type <msg-type> RREQ
### Address Block TLVs
A RREQ contains two Addresses, OrigAddr and TargAddr.
Because Address Block TLVs are always associated with a specific
address, the following section will contain one table per Address.
Each address is connected to its PrefixLength.
The numeric values of each TLV Type are specified in section TODO.
#### OrigAddr/PrefixLength
Corresponding Data Element TLV type Extension type Value
-------------------------- ------------ -------------- -----
OrigSeqNum OrigSeqNum -- Sequence Number
of the node
which
initiated the route discovery
OrigAddrMetric Metric MetricType Metric Value for
the route from OrigNode
to TargNode,
as calculated
by Metric of
MetricType
#### TargAddr/PrefixLength
Corresponding Data Element TLV type Extension type Value
-------------------------- ------------ -------------- -----
TargSeqNum (optional) TargSeqNum -- value of a
previously
known
TargSeqNum (optional)
### Message TLVs
none.
## RREP
### Message header
Corresponding Data Element Header field Value
-------------------------- --------------- -----
msg_hop_limit <msg-hop-limit> ???
msg_hop_count <msg-hop-count> Number of hops traversed so
far
by the message
Message Type
<msg-type> RREP
### Address Block TLVs
A RREP contains two Addresses, OrigAddr and TargAddr.
Because Address Block TLVs are always associated with a specific
address, the following section will contain one table per Address.
Each address is connected to its PrefixLength.
The numeric values of each TLV Type are specified in section TODO.
#### OrigAddr/PrefixLength
Corresponding Data Element TLV type Extension type Value
-------------------------- ------------ -------------- -----
none -- -- --
#### TargAddr/PrefixLength
Corresponding Data Element TLV type Extension type Value
-------------------------- ------------ -------------- -----
TargSeqNum TargSeqNum -- Sequence number
of the TargNode
TargAddrMetric Metric MetricType Metric Value for
the route from TargNode
to OrigNode,
as calculated
by Metric of
MetricType
### Message TLVs
A RREP message may contain the AckReq message TLV to monitor
bidirectional connectivity, as described in section TODO.
Corresponding Data Element TLV type Extension type Value
-------------------------- ------------ -------------- -----
AckReq AckReq -- 0
## RERR
### Message header
Corresponding Data Element Header field Value
-------------------------- --------------- -----
msg_hop_limit <msg-hop-limit> ???
Message Type <msg-type> RERR
### Address Block TLVs
RERR messages contain one or more Addresses, all of type
UnreachableAddress. Each UnreachableAddress has its own PrefixLength and is
associated with the following TLVs.
#### UnreachableAddress/PrefixLength
Corresponding Data Element TLV type Extension type Value
-------------------------- ------------ -------------- -----
SeqNum (optional) SeqNum -- The Sequence
Number associated with
UnreachableAddress
MetricType (optional) MetricType -- Metric Type of
the broken route entry
### Message TLVs
A RERR message may contain one optional message TLV, as detailed in
section TODO.
Corresponding Data Element TLV type Extension type Value
-------------------------- ------------ -------------- -----
PktSource PktSource -- The IP address
of the unreachable
destination
triggering RERR generation
