< draft-ietf-rddp-mpa-07.txt   draft-ietf-rddp-mpa-08.txt >
Remote Direct Data Placement Work Group P. Culley Remote Direct Data Placement Work Group P. Culley
INTERNET-DRAFT Hewlett-Packard Company INTERNET-DRAFT Hewlett-Packard Company
draft-ietf-rddp-mpa-07.txt U. Elzur draft-ietf-rddp-mpa-08.txt U. Elzur
Broadcom Corporation Broadcom Corporation
R. Recio R. Recio
IBM Corporation IBM Corporation
S. Bailey S. Bailey
Sandburst Corporation Sandburst Corporation
J. Carrier J. Carrier
Cray Inc. Cray Inc.
Expires: April 2007 October 5, 2006 Expires: April 2007 October 7, 2006
Marker PDU Aligned Framing for TCP Specification Marker PDU Aligned Framing for TCP Specification
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
Figure 14. Connection Parameters for the RNIC Types. 64 Figure 14. Connection Parameters for the RNIC Types. 64
Figure 15: MPA negotiation between an RDMAC RNIC and a Non-permissive Figure 15: MPA negotiation between an RDMAC RNIC and a Non-permissive
IETF RNIC. 65 IETF RNIC. 65
Figure 16: MPA negotiation between an RDMAC RNIC and a Permissive Figure 16: MPA negotiation between an RDMAC RNIC and a Permissive
IETF RNIC. 66 IETF RNIC. 66
Figure 17: MPA negotiation between a Non-permissive IETF RNIC and a Figure 17: MPA negotiation between a Non-permissive IETF RNIC and a
Permissive IETF RNIC. 68 Permissive IETF RNIC. 68
Revision history [To be deleted prior to RFC publication] Revision history [To be deleted prior to RFC publication]
[draft-ietf-rddp-mpa-08] workgroup draft with following changes:
Re-submission to correct conversion errors.
[draft-ietf-rddp-mpa-07] workgroup draft with following changes: [draft-ietf-rddp-mpa-07] workgroup draft with following changes:
Minor clarifications; added CRC to glossary, made 2.1 discussion Minor clarifications; added CRC to glossary, made 2.1 discussion
on probabilistic/deterministic a little less global. Added note on probabilistic/deterministic a little less global. Added note
that MULPDU is likely smaller than 64768, clarified 'M' bit that MULPDU is likely smaller than 64768, clarified 'M' bit
description, added xref to private data discussion in field description, added xref to private data discussion in field
definition, removed LLP acronym, added sentence on DOS attack to definition, removed LLP acronym, added sentence on DOS attack to
"Man in Middle" in security. "Man in Middle" in security.
[draft-ietf-rddp-mpa-06] workgroup draft with following changes: [draft-ietf-rddp-mpa-06] workgroup draft with following changes:
skipping to change at page 8, line 32 skipping to change at page 8, line 32
or dropped packets. or dropped packets.
Many approaches have been proposed for a generalized framing Many approaches have been proposed for a generalized framing
mechanism. Some are probabilistic in nature and others are mechanism. Some are probabilistic in nature and others are
deterministic. An example probabilistic approach is characterized by deterministic. An example probabilistic approach is characterized by
a detectable value embedded in the octet stream, with no method of a detectable value embedded in the octet stream, with no method of
preventing that value elsewhere within user data. It is preventing that value elsewhere within user data. It is
probabilistic because under some conditions the receiver may probabilistic because under some conditions the receiver may
incorrectly interpret application data as the detectable value. incorrectly interpret application data as the detectable value.
Under these conditions, the protocol may fail with unacceptable Under these conditions, the protocol may fail with unacceptable
frequency. AOne deterministic approach is characterized by embedded frequency. One deterministic approach is characterized by embedded
controls at known locations in the octet stream. Because the controls at known locations in the octet stream. Because the
receiver can guarantee it will only examine the data stream at receiver can guarantee it will only examine the data stream at
locations that are known to contain the embedded control, the locations that are known to contain the embedded control, the
protocol can never misinterpret application data as being embedded protocol can never misinterpret application data as being embedded
control data. For unambiguous handling of an out of order packet, control data. For unambiguous handling of an out of order packet, a
athe deterministic approach is preferred. deterministic approach is preferred.
The MPA protocol provides a framing mechanism for DDP running over The MPA protocol provides a framing mechanism for DDP running over
TCP using the deterministic approach. It allows the location of the TCP using the deterministic approach. It allows the location of the
ULPDU to be determined in the TCP stream even if the TCP segments ULPDU to be determined in the TCP stream even if the TCP segments
arrive out of order. arrive out of order.
2.2 Protocol Overview 2.2 Protocol Overview
The layering of PDUs with MPA is shown in Figure 1, below. The layering of PDUs with MPA is shown in Figure 1, below.
skipping to change at page 12, line 24 skipping to change at page 12, line 24
As such, MPA accepts complete records (ULPDUs) from DDP at the sender As such, MPA accepts complete records (ULPDUs) from DDP at the sender
and returns them to DDP at the receiver. and returns them to DDP at the receiver.
MPA MUST encapsulate the ULPDU such that there is exactly one ULPDU MPA MUST encapsulate the ULPDU such that there is exactly one ULPDU
contained in one FPDU. contained in one FPDU.
MPA over a standard TCP stack can usually provide FPDU Alignment with MPA over a standard TCP stack can usually provide FPDU Alignment with
the TCP Header if the FPDU is equal to TCP's EMSS. An optimized the TCP Header if the FPDU is equal to TCP's EMSS. An optimized
MPA/TCP stack can also maintain alignment as long as the FPDU is less MPA/TCP stack can also maintain alignment as long as the FPDU is less
than or equal to TCP's EMSS. Since FPDU Alignment is generally than or equal to TCP's EMSS. Since FPDU Alignment is generally
desired by the receiver, DDP must cooperates with MPA to ensure desired by the receiver, DDP cooperates with MPA to ensure FPDUs'
FPDUs' lengths do not exceed the EMSS under normal conditions. This lengths do not exceed the EMSS under normal conditions. This is done
is done with the MULPDU mechanism. with the MULPDU mechanism.
MPA provides information to DDP on the current maximum size of the MPA MUST provide information to DDP on the current maximum size of
record that is acceptable to send (MULPDU). DDP SHOULD limit each the record that is acceptable to send (MULPDU). DDP SHOULD limit
record size to MULPDU. The range of MULPDU values MUST be between each record size to MULPDU. The range of MULPDU values MUST be
128 octets and 64768 octets, inclusive. between 128 octets and 64768 octets, inclusive.
The sending DDP MUST NOT post a ULPDU larger than 64768 octets to The sending DDP MUST NOT post a ULPDU larger than 64768 octets to
MPA. DDP MAY post a ULPDU of any size between one and 64768 octets, MPA. DDP MAY post a ULPDU of any size between one and 64768 octets,
however MPA is not REQUIRED to support a ULPDU Length that is greater however MPA is not REQUIRED to support a ULPDU Length that is greater
than the current MULPDU. than the current MULPDU.
While the maximum theoretical length supported by the MPA header While the maximum theoretical length supported by the MPA header
ULPDU_Length field is 65535, TCP over IP requires the IP datagram ULPDU_Length field is 65535, TCP over IP requires the IP datagram
maximum length to be 65535 octets. To enable MPA to support FPDU maximum length to be 65535 octets. To enable MPA to support FPDU
Alignment, the maximum size of the FPDU must fit within an IP Alignment, the maximum size of the FPDU must fit within an IP
skipping to change at page 28, line 43 skipping to change at page 28, line 43
mode receivers MUST check this field for the same value, and mode receivers MUST check this field for the same value, and
close the connection and report an error locally if any other close the connection and report an error locally if any other
value is detected. Responder mode senders MUST set this field to value is detected. Responder mode senders MUST set this field to
the fixed value "MPA ID Rep frame" or (in byte order) 4D 50 41 20 the fixed value "MPA ID Rep frame" or (in byte order) 4D 50 41 20
49 44 20 52 65 70 20 46 72 61 6D 65 (in hexadecimal). Initiator 49 44 20 52 65 70 20 46 72 61 6D 65 (in hexadecimal). Initiator
mode receivers MUST check this field for the same value, and mode receivers MUST check this field for the same value, and
close the connection and report an error locally if any other close the connection and report an error locally if any other
value is detected. value is detected.
M: This bit declares an endpoint's REQUIRED Marker usage. When this M: This bit declares an endpoint's REQUIRED Marker usage. When this
bit is '1' in an MPA Request Frame, the Initiator declares that a bit is '1' in an MPA Request Frame, the Initiator declares that
receiver's requirement for Markers are REQUIRED in FPDUs sent Markers are REQUIRED in FPDUs sent from the Responder. When set
from the Responder. When set to '1' in an MPA Reply Frame, this to '1' in an MPA Reply Frame, this bit declares that Markers are
bit declares that Markers are REQUIRED in FPDUs sent from the REQUIRED in FPDUs sent from the Initiator. When in a received
Initiator. When in a received MPA Request Frame or MPA Reply MPA Request Frame or MPA Reply Frame and the value is '0',
Frame and the value is '0', Markers MUST NOT be added to the data Markers MUST NOT be added to the data stream by that endpoint.
stream by that endpointsender. When '1' Markers MUST be added as When '1' Markers MUST be added as described in section 4.3 MPA
described in section 4.3 MPA Markers on page 15. Markers on page 15.
C: This bit declares an endpoint's preferred CRC usage. When this C: This bit declares an endpoint's preferred CRC usage. When this
field is '0' in the MPA Request Frame and the MPA Reply Frame, field is '0' in the MPA Request Frame and the MPA Reply Frame,
CRCs MUST not be checked and need not be generated by either CRCs MUST not be checked and need not be generated by either
endpoint. When this bit is '1' in either the MPA Request Frame endpoint. When this bit is '1' in either the MPA Request Frame
or MPA Reply Frame, CRCs MUST be generated and checked by both or MPA Reply Frame, CRCs MUST be generated and checked by both
endpoints. Note that even when not in use, the CRC field remains endpoints. Note that even when not in use, the CRC field remains
present in the FPDU. When CRCs are not in use, the CRC field present in the FPDU. When CRCs are not in use, the CRC field
MUST be considered valid for FPDU checking regardless of its MUST be considered valid for FPDU checking regardless of its
contents. contents.
skipping to change at page 39, line 39 skipping to change at page 39, line 39
be followed. For example, if network data is lost, re-segmented be followed. For example, if network data is lost, re-segmented
or re-ordered, TCP MUST recover appropriately even when this or re-ordered, TCP MUST recover appropriately even when this
occurs while switching stacks. occurs while switching stacks.
7.2 Normal Connection Teardown 7.2 Normal Connection Teardown
Each half connection of MPA terminates when DDP closes the Each half connection of MPA terminates when DDP closes the
corresponding TCP half connection. corresponding TCP half connection.
A mechanism SHOULD be provided by MPA to DDP for DDP to be made aware A mechanism SHOULD be provided by MPA to DDP for DDP to be made aware
that a graceful close of the LLP TCP connection has been received by that a graceful close of the TCP connection has been received by the
the LLPTCP (e.g. FIN is received). TCP (e.g. FIN is received).
8 Error Semantics 8 Error Semantics
The following errors MUST be detected by MPA and the codes SHOULD be The following errors MUST be detected by MPA and the codes SHOULD be
provided to DDP or other Consumer: provided to DDP or other Consumer:
Code Error Code Error
1 TCP connection closed, terminated or lost. This includes lost 1 TCP connection closed, terminated or lost. This includes lost
by timeout, too many retries, RST received or FIN received. by timeout, too many retries, RST received or FIN received.
 End of changes. 9 change blocks. 
22 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/