Internet-Drafts | 2 Feb 21:37 2005
Picon

I-D ACTION:draft-ietf-rddp-rdmap-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: An RDMA Protocol Specification
	Author(s)	: R. Recio, et al.
	Filename	: draft-ietf-rddp-rdmap-03.txt
	Pages		: 75
	Date		: 2005-2-2
	
This document defines a Remote Direct Memory Access Protocol 
(RDMAP) that operates over the Direct Data Placement Protocol (DDP 
protocol).  RDMAP provides read and write services directly to 
applications and enables data to be transferred directly into ULP 
Buffers without intermediate data copies. It also enables a kernel 
bypass implementation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-rdmap-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-rdmap-03.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

pat_thaler | 2 Feb 23:25 2005

RE: Terminate message a security threat?

I agree that the terminate message doesn't raise any additional attacks. Any node that could send a valid
terminate message has the ability to send a message with one of the errors that causes connection
termination. For completeness so readers know it wasn't an oversight it would be reasonable to add a
sentence to say that.

-----Original Message-----
From: rddp-bounces <at> ietf.org [mailto:rddp-bounces <at> ietf.org]On Behalf Of
Mallikarjun C.
Sent: Wednesday, 05 January, 2005 9:43 AM
To: RDDP
Subject: Re: [rddp] Terminate message a security threat?

Thanks Jim for patiently working through all the comments.

The note I wrote to Jim was:

"It may be worth dealing with for two reasons - (1) Terminate has a role 
in DoS attacks, (2) the current description of DDP/RDMAP message 
processing is seemingly comprehensive but is not due to the exclusion of 
Terminate."

Wrt #1 above, it so far appears that the WG believes that Terminate is 
not any worse than other security threats that were discussed.  I can go 
with this, some new text (summarizing the sentiments on this thread) & 
to address #2 might still be appropriate.  However, I will leave it to 
the authors at this point, I expect to be slow in responding to emails 
for the next 2 weeks.

Mallikarjun

(Continue reading)

Renato Recio | 3 Feb 14:59 2005
Picon

RDMAP Spec Update

Folks,

The RDMAP spec was updated to fix comments surfaced on this reflector and at the last IETF meeting. As described on page 11, the major changes (vs typos) from the -02 version:


      * Section 6.1 - Added normative text describing downward compatibility with version 0.

      * Section 6.8 - Changed the description of the reserved field size to match the size in the figure, which is 13 bits.

      * Section 10 - Aligned security section closely to [RDMASEC] and added normative text for security requirements.

Thanks,

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685
_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
Michael C. Cambria | 3 Feb 16:17 2005

Number of MPA Req/Reply exchanges


My reading of the MPA draft doesn't rule out the possibility of several 
MPA Request/Reply exchanges.  Is this the intent?

There are 2 cases.

When the Initiator receives the MPA Reply Frame with the R bit set (e.g. 
private data wasn't acceptable to ULP) the connection remains open.  The 
ULP may close TCP or use the connection for other purposes.  Can this 
other purpose be yet another MPA setup attempt?

Likewise, if the R bit is 0, the [Initiator] implementation SHOULD enter 
full MPA/DDP operation.  This text doesn't rule out the Initiator 
remaining in TCP stream mode and sending another MPA Request Frame.  For 
example, the responders private data wasn't acceptable.

Regards,
MikeC
Caitlin Bestler | 3 Feb 17:09 2005

RE: Number of MPA Req/Reply exchanges


> -----Original Message-----
> From: rddp-bounces <at> ietf.org [mailto:rddp-bounces <at> ietf.org] On 
> Behalf Of Michael C. Cambria
> Sent: Thursday, February 03, 2005 7:17 AM
> To: rddp <at> ietf.org
> Subject: [rddp] Number of MPA Req/Reply exchanges
> 
> 
> My reading of the MPA draft doesn't rule out the possibility 
> of several MPA Request/Reply exchanges.  Is this the intent?
> 
> There are 2 cases.
> 
> When the Initiator receives the MPA Reply Frame with the R 
> bit set (e.g. 
> private data wasn't acceptable to ULP) the connection remains 
> open.  The ULP may close TCP or use the connection for other 
> purposes.  Can this other purpose be yet another MPA setup attempt?
> 

Yes, that would be legitimate. However, it is highly likely
that the remote peer that has just indicated that it did not
want to talk with you has already closed the TCP connection.

If there is a need to engage in multiple rounds of proposed
RDMA connections and responses then this should probably be
explicitly stated in the ULP-specific protocol. Without such
guidance the passive side is unlikely to leave the connection
open just in case you intend to try again.

In fact I'd bet that the number of implementations doing so
right now would be zero.

> Likewise, if the R bit is 0, the [Initiator] implementation 
> SHOULD enter full MPA/DDP operation.  This text doesn't rule 
> out the Initiator remaining in TCP stream mode and sending 
> another MPA Request Frame.  For example, the responders 
> private data wasn't acceptable.
> 

If the responder's private data wasn't acceptable the initiator
side is expected to terminate the connection.
Internet-Drafts | 7 Feb 21:44 2005
Picon

I-D ACTION:draft-ietf-rddp-ddp-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: Direct Data Placement over Reliable Transports
	Author(s)	: H. Shah
	Filename	: draft-ietf-rddp-ddp-04.txt,.pdf
	Pages		: 37
	Date		: 2005-2-4
	
The Direct Data Placement protocol provides information to Place the 
incoming data directly into an upper layer protocol's receive buffer 
without intermediate buffers. This removes excess CPU and memory 
utilization associated with transferring data through the 
intermediate buffers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-ddp-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-ddp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rddp-ddp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Mon Feb  7 22:54:52 2005 the virus scanner said:
   External message bodies cannot be scanned and are removed

Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/quarantine/20050207
(message 1CyGp5-00081f-FR).
-- 
Postmaster
Gmane
gmane.org

MailScanner thanks transtec Computers for their support
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Mon Feb  7 22:54:52 2005 the virus scanner said:
   External message bodies cannot be scanned and are removed

Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/quarantine/20050207
(message 1CyGp5-00081f-FR).
--

-- 
Postmaster
Gmane
gmane.org

MailScanner thanks transtec Computers for their support
_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
pat_thaler | 8 Feb 23:16 2005

RE: DC Agenda

David, 

Once again we have IETF and T10 meetings falling on the same week. Will the rddp and ips meetings be able to be
held on Monday to help those of us who try to cover both?

Regards,
Pat
Black_David | 9 Feb 17:47 2005

RE: [rddp] DC Agenda

Pat,

I presume you meant "Minneapolis" as opposed to "DC" ;-) ...

Maybe - the Minneapolis schedule should get thrashed out this week
(efforts are being made for this meeting week to have firm meeting
dates/times further in advance), and I'll see what's possible.
There's very little content overlap with T10 for these meetings, as
there are essentially no SCSI-level issues pending in either WG
that I know about.  A complicating factor is that RDDP only needs
an hour (if that) in Minneapolis, which is likely to lead to it
meeting on Tuesday.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: pat_thaler <at> agilent.com [mailto:pat_thaler <at> agilent.com] 
> Sent: Tuesday, February 08, 2005 5:16 PM
> To: ips <at> ietf.org; Black_David <at> emc.com; rddp <at> ietf.org
> Subject: RE: [rddp] DC Agenda
> 
> David, 
> 
> Once again we have IETF and T10 meetings falling on the same 
> week. Will the rddp and ips meetings be able to be held on 
> Monday to help those of us who try to cover both?
> 
> Regards,
> Pat
>  

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Black_David | 9 Feb 20:53 2005

WG Last Call: Security, DDP, RDMAP

This is the message you've all been waiting for ...

It is my pleasure to (finally!) announce the RDDP Working
Group Last Call on the following three drafts:

DDP/RDMAP Security
	(draft-ietf-rddp-security-06.txt)
Direct Data Placement over Reliable Transports
	(draft-ietf-rddp-ddp-04.txt)
An RDMA Protocol Specification
	(draft-ietf-rddp-rdmap-03.txt)

This WG Last Call will run until 11:59pm Eastern Time
(US) on Monday, February 28th.  That should give the
draft authors and WG chair the rest of that week to
organize any Last Call issues that need attention at
the Minneapolis IETF meeting the following week.  An
hour of meeting time has been requested in Minneapolis,
but may be released if there's nothing to discuss.

Technical comments need to be posted to this mailing list.
Editorial comments may be sent directly to the primary
draft authors:

- Security: Jim Pinkerton <jpink -at- windows.microsoft.com>
- DDP: Hemal Shah <hemal.shah -at- intel.com>
- RDMAP: Renato J. Recio <recio -at- us.ibm.com>

Please copy me (as WG chair - David Black <black_david -at-
emc.com>) on any editorial comments, just in case something
initially thought to be editorial turns out to have technical
content.

There are other drafts linked to the WG's web page:

http://www.ietf.org/html.charters/rddp-charter.html

that may be of interest or relevance in reviewing the three
drafts for this WG Last Call.

Many thanks to all whose hard work has gotten us this far,
--David (RDDP WG chair)

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
Internet-Drafts | 11 Feb 21:32 2005
Picon

I-D ACTION:draft-ietf-rddp-mpa-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: Marker PDU Aligned Framing for TCP Specification
	Author(s)	: P. Culley, et al.
	Filename	: draft-ietf-rddp-mpa-02.txt,.pdf
	Pages		: 68
	Date		: 2005-2-11
	
A framing protocol is defined for TCP that is fully compliant with
applicable TCP RFCs and fully interoperable with existing TCP
implementations. The framing mechanism 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-mpa-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-mpa-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rddp-mpa-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Fri Feb 11 22:51:51 2005 the virus scanner said:
   External message bodies cannot be scanned and are removed

Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/quarantine/20050211
(message 1CzihR-0006C9-Gm).
-- 
Postmaster
Gmane
gmane.org

MailScanner thanks transtec Computers for their support
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Fri Feb 11 22:51:51 2005 the virus scanner said:
   External message bodies cannot be scanned and are removed

Note to Help Desk: Look on the Gmane MailScanner in /var/spool/MailScanner/quarantine/20050211
(message 1CzihR-0006C9-Gm).
--

-- 
Postmaster
Gmane
gmane.org

MailScanner thanks transtec Computers for their support
_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

Gmane