randy/draft-l3dl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

revert and make it transmission sequence number in the datagram

Browse source
This commit is contained in:
Randy Bush 2019-07-17 13:05:18 -07:00
parent 76fe3aeb3f
commit 6390c249d8
1 changed files with 24 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

33
draft-ietf-lsvr-l3dl.xml
View file

@ -390,8 +390,13 @@
multiple Datagrams and reassembled by the receiver a la <xref
target="RFC0791"/> Section 2.3 Fragmentation.</t>
<t>Should a PDU need to be retransmitted, it MUST BE sent as the
identical Datagram set as the original transmission. The
Transmission Sequence Number assures the receiver that it is the
same PDU.</t>
<!--
protocol "Version:7,L:1,Datagram Number:24,Datagram Length:16,Checksum:32,Payload...:16"
protocol "Version:7,L:1,Transmission Sequence Number:16,Datagram Number:24,Datagram Length:16,Checksum:32,Payload...:32"
-->
<figure>
<artwork>
@ -416,9 +421,17 @@
is in the datagram as opposed to, for example, the PDU header.</t>
<t hangText="L:">A bit that set to one if this Datagram is the
last Datagram of the PDU. For a PDU which fits in only one
Datagram, it is set to one. Note that this is the inverse of the
marking technique used by <xref target="RFC0791"/>.</t>
last Datagram of the PDU. For a PDU which fits in
only one Datagram, it is set to one. Note that this is the
inverse of the marking technique used by <xref
target="RFC0791"/>.</t>
<t hangText="Transmission Sequence Number:">A 16-bit strictly
increasing unsigned integer identifying this PDU, possibly across
retransmissions, that wraps from 2^24-1 to 0. The initial value
is arbitrary. See <xref target="RFC1982"/> on DNS Serial Number
Arithmetic for too much detail on comparison and incrementing a
wrapping sequence number.</t>
<t hangText="Datagram Number:">A monotonically increasing 24-bit
value which starts at zero for each PDU. This is used to
@ -1295,8 +1308,9 @@ q-->
</figure>
<t>L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to
ensure session continuity. A receiver may choose to ignore
KEEPALIVE PDUs.</t>
ensure session continuity. The inter-KEEPALIVE interval is
configurable, with a default of ten seconds. A receiver may choose
to ignore KEEPALIVE PDUs.</t>
<t>An operational deployment MUST BE configured whether to use
KEEPALIVEs or not, either globally, or down to per-link granularity.
@ -1611,9 +1625,9 @@ q-->
Kovuru for comments during implementation, Jeff Haas for review and
comments, Joe Clarke for a useful review, John Scudder for deeply
serious review and comments, Larry Kreeger for a lot of layer 2
clue, Martijn Schmidt for his contribution, Neeraj Malhotra for
review, Russ Housley for checksum discussion and sBox, and Steve
Bellovin for checksum advice.</t>
clue, Martijn Schmidt for his contribution, Nalin Pai for transport
discussions, Neeraj Malhotra for review, Russ Housley for checksum
discussion and sBox, and Steve Bellovin for checksum advice.</t>
</section>
@ -1671,6 +1685,7 @@ q-->
<references title="Informative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.1122"?>
<?rfc include="reference.RFC.1982"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>
<reference anchor="Clos0" >