sra Transport field lengths fixed in text
spell check sender pacing finessed -06 published
This commit is contained in:
parent
2fb5ac051b
commit
ddbaacdace
1 changed files with 23 additions and 23 deletions
|
|
@ -11,7 +11,7 @@
|
|||
<?rfc tocindent="yes"?>
|
||||
<?rfc tocompact="yes"?>
|
||||
|
||||
<rfc category="std" docName="draft-ietf-lsvr-l3dl-05" ipr="trust200902">
|
||||
<rfc category="std" docName="draft-ietf-lsvr-l3dl-06" ipr="trust200902">
|
||||
|
||||
<front>
|
||||
|
||||
|
|
@ -258,7 +258,7 @@
|
|||
|
||||
<t>There are two protocols, the inter-device (left-right in the
|
||||
diagram) per-link layer 3 discovery and the API to the upper level
|
||||
BGP-like routing prototol (up-down in the above diagram):
|
||||
BGP-like routing protocol (up-down in the above diagram):
|
||||
<list style="symbols">
|
||||
|
||||
<t>Inter-device PDUs are used to exchange device and logical link
|
||||
|
|
@ -294,7 +294,7 @@
|
|||
VLANs) of the received HELLOs. Once a session is established
|
||||
through the OPEN exchange, the Encapsulations (<xref
|
||||
target="afisafi"/>) configured on an end point may be announced and
|
||||
modified. Note that these are only the encapsuation and addresses
|
||||
modified. Note that these are only the encapsulation and addresses
|
||||
configured on the announcing interface; though a device's loopback
|
||||
and overlay interface(s) may also be announced. When two devices on
|
||||
a link have compatible Encapsulations and addresses, i.e. the same
|
||||
|
|
@ -409,15 +409,15 @@
|
|||
There are no intermediate devices capable of further fragmentation
|
||||
or reassembly.</t>
|
||||
|
||||
<t>As fragments are not ACK paced (as PDUs are), a PDU might need a
|
||||
large number of frames to be sent. To avoid overwhelming bursts,
|
||||
the sender should pace them ***********.</t>
|
||||
<t>A PDU might need a large number of frames to be sent. As
|
||||
fragments are not ACK paced (as PDUs are), to avoid overwhelming
|
||||
bursts, the sender should pace fragments of a large PDU.</t>
|
||||
|
||||
<t>L3DL is carrying relatively small amounts of data on relatively
|
||||
high bandwidth links, and at a time when the link is not active with
|
||||
other data as it does not yet have layer three connectivity. So
|
||||
congestion is not considered a sufficiently significant risk to
|
||||
warrent additional complexity.</t>
|
||||
warrant additional complexity.</t>
|
||||
|
||||
<t>Should a PDU need to be retransmitted, it MUST BE sent as the
|
||||
identical Datagram set as the original transmission. The
|
||||
|
|
@ -432,9 +432,9 @@
|
|||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Version | Transmission Sequence Number |L| ~
|
||||
| Version | Transmission Sequence Number |L| Dtgm Number ~
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
~ Datagram Number | Datagram Length |
|
||||
~ Datagram Number (contd) | Datagram Length |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Checksum |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
|
@ -446,17 +446,11 @@
|
|||
<t>The fields of the L3DL Transport Header are as follows:
|
||||
<list style="hanging">
|
||||
|
||||
<t hangText="Version:">Seven-bit Version number of the protocol,
|
||||
<t hangText="Version:">Eight-bit Version number of the protocol,
|
||||
currently 0. Values other than 0 MUST BE treated as an error.
|
||||
The protocol version needs to be in one and only one place, so it
|
||||
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>
|
||||
|
||||
<t hangText="Transmission Sequence Number:">A 16-bit strictly
|
||||
increasing unsigned integer identifying this PDU, possibly across
|
||||
retransmissions, that wraps from 2^16-1 to 0. The initial value
|
||||
|
|
@ -464,7 +458,13 @@
|
|||
Arithmetic for too much detail on comparing and incrementing a
|
||||
wrapping sequence number.</t>
|
||||
|
||||
<t hangText="Datagram Number:">A monotonically increasing 24-bit
|
||||
<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>
|
||||
|
||||
<t hangText="Datagram Number:">A monotonically increasing 23-bit
|
||||
value which starts at zero for each PDU. This is used to
|
||||
reassemble frames into PDUs a la <xref target="RFC0791"/> Section
|
||||
2.3. Note that this limits an L3DL PDU to 2^24 frames.</t>
|
||||
|
|
@ -479,7 +479,7 @@
|
|||
|
||||
<t>If a Datagram fails checksum verification, the datagram is
|
||||
invalid and should be silently discarded. The sender will
|
||||
retransmit the PDU, and the receiver can assmble it.</t>
|
||||
retransmit the PDU, and the receiver can assemble it.</t>
|
||||
|
||||
<t hangText="Payload:">The PDU being transported or a fragment
|
||||
thereof.</t>
|
||||
|
|
@ -848,7 +848,7 @@ q-->
|
|||
|
||||
<t>Although delay and jitter in responding with an OPEN were
|
||||
specified above, beware of load created by long strings of
|
||||
authentication failures and retries. A confugurable failure count
|
||||
authentication failures and retries. A configurable failure count
|
||||
limit (default 8) SHOULD result in giving up on the connection
|
||||
attempt.</t>
|
||||
|
||||
|
|
@ -1229,7 +1229,7 @@ q-->
|
|||
<t>The MPLS IPv4 Encapsulation describes a logical link's ability
|
||||
to exchange labeled IPv4 packets on one or more subnets. It does
|
||||
so by stating the interface's addresses the corresponding prefix
|
||||
lengths, and the corresponding labels which will be accepted fpr
|
||||
lengths, and the corresponding labels which will be accepted for
|
||||
each address.</t>
|
||||
|
||||
<!--
|
||||
|
|
@ -1259,7 +1259,7 @@ q-->
|
|||
</figure>
|
||||
|
||||
<t>The 24-bit Count is the sum of the number of MPLSv4
|
||||
Encapsulation being announced and/or withdrawns.</t>
|
||||
Encapsulation being announced and/or withdrawn.</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -1544,8 +1544,8 @@ q-->
|
|||
<section anchor="security" title="Security Considerations">
|
||||
|
||||
<t>The protocol as is MUST NOT be used outside a datacenter or
|
||||
similarly closed environment without authentication ans
|
||||
authorisation mechanisms such as <xref
|
||||
similarly closed environment without authentication and
|
||||
authorization mechanisms such as <xref
|
||||
target="I-D.ymbk-lsvr-l3dl-signing"/>.</t>
|
||||
|
||||
<t>Many MDC operators have a strange belief that physical walls and
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue