Hi again
A proposed text would be like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
.... Registration Ownership Verifier ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
Opaque:
One-byte Opaque field; this is an octet that ND does not need to process
but that the 6LN wishes the 6LR to pass transparently to another process.
I:
Two-bit Integer: A value of zero indicates that the Opaque field carries
an abstract index that is used to decide in which routing topology the
address is expected to be injected. In that case, the Opaque field is
passed to a routing process with the indication that this is a topology
information and the value of 0 indicates default. All other values are
reserved.
Does that work?
Pascal
From: Pascal Thubert (pthubert)
Sent: jeudi 12 avril 2018 15:40
To: [email protected]
Cc: Yan Filyurin <[email protected]>; Tony Przygienda <[email protected]>;
[email protected]
Subject: instance ID in rfc6775 update
Dear all :
During a conversation on the RIFT protocol it appeared that there are use cases
in RIFT to support host mobility with rfc6775-update.
There is a caveat, though, which is in fact common with RPL. Both cases need a
concept of multi topology routing.
In the case of RPL, the topology is indexed by an instance ID. In the case of
RIFT, there is a need for an index to a RIB, so one octet is probably enough.
A suggestion is thus to use the reserved octet in the ARO to carry an instance
ID, and use a bit to signal that this is what that field does, in case there is
a need later to overload it with something else.
I understand this is coming late in the process; but then there is no logic
associated to the change, this is just passing on an additional information
that is useful for more than one candidate protocol.
Please let me know if there is an issue pursuing this. If there is no
opposition, my plan it currently to add this in rev-19.
All the best,
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
