2.8.15 Remote Direct Data Placement (rddp)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-28

Chair(s):

David Black <black_david@emc.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Technical Advisor(s):

Allyn Romanow <allyn@cisco.com>
Stephen Bailey <steph@cs.uchicago.edu>

Mailing Lists:

General Discussion: rddp@ietf.org
To Subscribe: rddp-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/rddp/index.html

Description of Working Group:

The purpose of this WG is to enable Remote Direct Data Placement (rddp)
capabilities with IP transport protocols, in particular with
SCTP. RDDP capabilities refer to the ability to place data directly
from the NIC into application buffers, without intensive CPU
usage. This strategy avoids the costs of data copying and enables
using IP as a method for high speed buffer to buffer transfer,
allowing IP to replace special purpose networks currently in use.
Remote Direct Memory Access (RDMA) is an example of this concept.

Conceptually, RDDP functionality can be viewed as consisting of two
layers. First the direct data placement capability, which is
accomplished through a tag and a lookup table on the NIC. Above this
core functionality, an RDDP control protocol is needed to specify how
the direct data placement can be used, for example READ and WRITE
commands.

The work of the WG is to accomplish four items:

1) A (transport independent) protocol core to support direct data
  placement from the NIC into specified memory, usually application
  buffers.

2) A (transport independent) protocol core layered on top of the direct
  data placement protocol that specifies control of RDDP.

3) A mapping of the direct data placement protocol onto SCTP,
  for standards track, including a clear applicability statement
  of the expected service from the mapping.

4) A mapping of the direct data placement protocol onto TCP, for
  informational, because TCP's service is a less good match to RDDP,
  including an applicability statement of the issues regarding the
  service available from the mapping.

The working group will ensure that the resulting technology will be
secure and will not enable new attacks on systems supporting RDDP.

The WG will not modify existing Internet transport protocols, but
may forward issues it discovers in such transport protocols that
are not full Internet Standards to the appropriate IETF WGs for
their consideration.

Goals and Milestones:

Done  Submit Internet-Draft including problem statement and architecture
Done  Submit Initial draft of Remote Direct Data Placement protocol (RDDP)
Done  Submit Initial draft of RDMA control protocol, to be named.
Done  Initial draft mapping the RDDP core and control onto SCTP including A/S
Done  Submit problem statement and architecture drafts to IESG for consideration as informational publications
Done  Initial draft of security considerations for RDDP
Done  Initial draft of informational mapping of the RDDP core and control onto TCP
Done  Initial draft of applicability statement covering both the SCTP and TCP mappings
Mar 04  Submit RDMA control protocol (named TBD) to IESG for consideration as a Proposed Standard
Mar 04  Submit Remote Data Placement Protocol (RDDP) to IESG for consideration as a Proposed Standard
Mar 04  Submit RDDP security considerations draft to IESG
Sep 04  Submit mapping of the RDDP core and RDMA control protocols onto SCTP to IESG for consideration as proposed standard
Sep 04  Submit mapping of the RDDP core and RDMA control protocols onto TCP for consideration as an informational publication
Sep 04  Submit applicability statement for RDDP core and RDMA control protocols over both SCTP and TCP for consideration as an informational publication
Oct 04  Consult Area Directors about any additional work the WG should undertake

Internet-Drafts:

  • draft-ietf-rddp-rdma-concerns-01.txt
  • draft-ietf-rddp-arch-06.txt
  • draft-ietf-rddp-problem-statement-05.txt
  • draft-ietf-rddp-rdmap-02.txt
  • draft-ietf-rddp-ddp-03.txt
  • draft-ietf-rddp-applicability-02.txt
  • draft-ietf-rddp-sctp-01.txt
  • draft-ietf-rddp-mpa-01.txt
  • draft-ietf-rddp-security-05.txt

    No Request For Comments

    Current Meeting Report

    RDDP Minutes - 61st IETF Meeting DRAFT
    11/8/2004
    Washington D.C.
    --------------------------------

    Thanks to Hemal V. Shah for taking the minutes

    Letters in [square brackets] are first letter in presentation file name.
    Note that "?" at second indent position is a bullet, it does not introduce a question.

    * Agenda bashing

    * Status of drafts (from all authors) [A]
    o Problem statement has been in RFC editor queue.
    o Architecture document very close to being in RFC editor queue.
    o RDMAP/DDP drafts are not ready for WG last call at this point. Security sections need to be checked for MUST implement IPsec (RFC 3723). Only open issues are security requirements.
    o Applicability draft (when to use SCTP versus TCP) in process.
    o Once we have security requirements in RDMAP/DDP drafts, then security, DDP, and RDMAP drafts will go to the first round of WG Last Call.
    o Second batch of last calls will be MPA, SCTP, and Applicability.

    * Security draft (Presenter: Jim Pinkerton) [B]
    o Major changes
    ? Quickly iterated -03, -04, and -05 in one month.
    ? Changed the draft to be standards track
    ? Resolved several TBDs: channel binding, connection hijacking, finished summary tables of attacks in appendix
    ? New or substantially revised appendices: appendix A is normative, appendices B & C are informative.
    o Major new normative statements
    ? Most RECOMMENDED statements were changed to MUST/MAY.
    ? IPsec is MUST implement and OPTIONAL to use
    ? Resource manager
    * MUST be used if a scarce resource
    * MUST NOT assume shared partial mutual trust
    o Planned changes to -06 draft
    ? Resolve some more TBDs.
    ? Need review.

    * RDMAP Security issues (Presenter: Renato Recio) [C]
    o RDMAP and DDP drafts need to have security requirements.
    o Approach
    ? List out informative text
    ? Summary of RDMAP specific security requirements
    ? Security services for RDMAP
    o Security Model and general assumptions
    ? Mainly list the attacks, attack types, and resources. Details are in RDMA security draft.
    o RDMAP specific security requirements
    ? Privileged resource manager requirements
    o There are some requirements that might be added to RDMAP and RDMA security drafts
    o Need to revise MUST requirement on firmware load in RDMA security draft.
    o List of normative requirements will be sent to the reflector.
    o Email discussion on the reflector on the normative text.
    o DDP draft will address the requirements on the list through the discussions and then it will be added to the draft.

    * MPA (Presenter: Paul Culley) [D]
    o Issues
    ? Need to add text from the security draft
    ? Marker pointer clarification
    ? Minor clarification of meaning of "connection establishment"
    o Zero-markers
    ? Where do the non-zero markers of the FPDU point to?
    * ULPDU_length
    * Or Zero-marker
    ? Marker should point to ULPDU_length instead of start of FPDU-Hdr [sense of room]
    o IPsec requirement is it needed in MPA?
    ? Need to cross-reference requirement from DDP.
    * Safest thing to do is have MPA list IPsec as MUST implement and optional to use. Derived from DDP requirement as DDP is the only protocol that can be above MPA. [no objection]

    * SCTP mapping (Presenter: Caitlin Bestler) [E]
    o Main changes
    ? Updated to new boilerplate (e.g., IPR)
    ? SCTP/MPA differences noted
    * Size of private data 512 B for SCTP mapping
    * MPA requires first FPDU come from initiating side
    * In MPA spec, we need specify that MPA MUST allow private data up to 512B.
    ? Session control changed to align with MPA
    * Only one exchange per side. Eliminated negotiate message.
    * Added explicit reject message.
    ? Dealt with small PDUs

    * iWARP interoperability w/RDMAC versions + APIs (Presenter: John Carrier) [F]
    o Interoperability on the wire
    ? RDMAC/IETF RDMAP/DDP protocols have same semantics and wire protocol format, but they both use different versions.
    ? No standard way for ULPs to exchange version information that could be used to configure the RNICs
    ? If IETF implementation decides to turn markers off, then IETF RNIC won't interoperate with RDMAC RNIC.
    o Interoperability above RDDP
    ? Discussion on standardizing private data format - Not appropriate to specify ULP data format [sense of room]
    ? Add a requirement on that version information should be available to ULP [sense of room]
    ? No consensus on the private data format.
    * Worry around breaking the existing implementations.
    ? Within a week, the text on the interoperability will be generated and sent to list. It'll be headed for appendices of the MPA, DDP, and RDMAP protocol drafts. [no objection]

    * Next steps
    o Revise security draft.
    o Add appropriate security requirements in DDP & RDMAP.

    * Meeting adjourned @ 9:30pm on November 8, 2004.

    Slides

    Agenda
    Status & Summary of outstanding issues
    RDMAP Security Section
    MPA discussion for IETF61
    Applicability Draft Updates
    iWARP Interoperability