Skip to main content

Marker PDU Aligned Framing for TCP Specification

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    rddp mailing list <>, 
    rddp chair <>
Subject: Protocol Action: 'Marker PDU Aligned Framing for TCP 
         Specification' to Proposed Standard 

The IESG has approved the following document:

- 'Marker PDU Aligned Framing for TCP Specification '
   <draft-ietf-rddp-mpa-09.txt> as a Proposed Standard

This document is the product of the Remote Direct Data Placement Working 

The IESG contact persons are Lars Eggert and Magnus Westerlund.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary
  MPA (Marker Protocol data unit Aligned framing) is designed to work
  as an "adaptation layer" between TCP and the Direct Data Placement
  [DDP] protocol, preserving the reliable, in-order delivery of TCP,
  while adding the preservation of higher-level protocol record
  boundaries that DDP requires. MPA is fully compliant with applicable
  TCP RFCs and can be utilized with existing TCP implementations. MPA
  also supports integrated implementations that combine TCP, MPA and
  DDP to reduce buffering requirements in the implementation and
  improve performance at the system level.

Working Group Summary
  The degree to which TCP should be changed for MPA (and hence the
  rddp protocol stack) has been a source of controversy.  The WG has
  adopted an approach that requires no TCP modifications, and there is
  now strong WG consensus for that approach.

Protocol Quality
  The protocol has been reviewed for the rddp WG by David L. Black.
  There are multiple implementations of the MPA protocol, including
  the Request and Reply frames for connection setup added by the WG
  at the direction of the Transport Area.

  David Black ( was the PROTO Document Shepherd.

  Lars Eggert ( has reviewed this document for
  the IESG.

Note to RFC Editor
   The decision for hosts to request CRC suppression MAY be made on an
   administrative basis for any path that provides equivalent protection
   from undetected errors as an end-to-end CRC32c.

   An administrative decision to have a host request CRC suppression
   SHOULD NOT be made unless there is assurance that the TCP connection
   involved provides protection from undetected errors that is at least as

   strong as an end-to-end CRC32c.  End-to-end usage of an IPsec
   cryptographic integrity check is among the ways to provide such
   protection, and the use of channel bindings [NFSv4CHANNEL] by the
   ULP can provide a high level of assurance that the IPsec protection
   scope is end-to-end with respect to the ULP.

RFC Editor Note