Hi Victoria,
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.
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 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 it?
This is what RFC5444 says on prefix length:
<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?
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,
Lotte
The data elements for each message need to be broken into much
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
will need to incorporate Lotte's text with the 69 character constraint.
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
<RFC5444 section - Lotte.txt>
