INTERNET-DRAFT J. Carrier Category: Informational Adaptec draft-carrier-rddp-rnic-interop-00.txt J. Pinkerton Expires: May 2005 Microsoft November 2004 RNIC Interoperability 1 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware of have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-Draft, I accept the provisions of Section 4 of RFC 3667. This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2 Abstract This document describes a mechanism for enabling RDMA Network Interface Cards (RNICs) that implement both the IETF and RDMAC versions of the DDP and RDMAP protocols to interoperate with legacy RNICs that are based on the RDMAC version of the protocols. The proposed scheme uses MPA Request/Reply Frames to negotiate the protocol version as well as MPA marker and MPA CRC. A ULP or other supporting entity must perform this negotiation on behalf of the RDMAC RNIC because RDMAC MPA does not define an MPA connection scheme using MPA Request/Reply frames. This draft also makes Carrier & Pinkerton Expires May 2005 1 Internet Draft RNIC Interoperability November 2004 specific recommendations for minor changes to the IETF MPA, DDP, and RDMAP internet drafts to aid in interoperability. Table of Contents 1 Status of this Memo 1 2 Abstract 1 3 Introduction 3 4 Proposed Modification to MPA Request/Reply Frame 5 5 Proposed Appendix B: IETF RNIC Interoperability with RDMA Consortium Protocols 7 5.1 Negotiated Parameters 7 5.2 RDMAC RNIC and Non-permissive IETF RNIC 8 5.2.1 RDMAC RNIC Initiator 9 5.2.2 Non-Permissive IETF RNIC Initiator 9 5.3 RDMAC RNIC and Permissive IETF RNIC 10 5.3.1 RDMAC RNIC Initiator 10 5.3.2 Permissive IETF RNIC Initiator 11 5.4 Non-Permissive IETF RNIC and Permissive IETF RNIC 11 6 Other Changes 12 6.1 Additional Changes to the MPA/DDP/RDMAP Drafts 12 6.2 Verbs Extensions 12 6.2.1 Changes to QueryRNIC Output: 12 6.2.2 Changes to CreateQP input: 12 6.2.3 Changes to CreateQP output: 13 6.2.4 Changes to QueryQP Output: 13 6.2.5 Changes to ModifyQP input: 13 6.2.6 Changes to ModifyQP output: 13 7 References 14 7.1 Normative References 14 7.2 Informative References 14 8 Author's Addresses 15 9 Acknowledgments 16 10 Full Copyright Statement 18 Table of Figures Figure 1. Connection Parameters for the RNIC Types. 8 Figure 2: MPA negotiation between an RDMAC RNIC and a Non- permissive IETF RNIC. 9 Figure 3: MPA negotiation between an RDMAC RNIC and a Permissive IETF RNIC. 10 Figure 4: MPA negotiation between a Non-permissive IETF RNIC and a Permissive IETF RNIC. 11 Carrier & Pinkerton Expires May 2005 2 Internet Draft RNIC Interoperability November 2004 3 Introduction As products based on the IETF MPA, DDP and RDMAP protocols come to market, they will encounter early RNIC implementations based on the RDMAC versions of these protocols. Although the IETF does not specify how to interoperate with non-IETF protocols, this draft describes a suggested framework for ensuring the widest range of interoperability with earlier RNIC implementations, especially when an RNIC can select between the RDMAC and IETF versions of the protocols on a per connection basis. Of the three iWARP protocols, DDP and RDMAP have changed the least since the RDMAC author teams first submitted the wire protocols to the RDDP WG. The IETF and RDMAC protocols have the same semantics and wire protocol format, but have different version numbers. The RDMAC uses version of zero [RDMACDDP, RDMACRDMAP] and the IETF uses version of one [IETFDDP, IETFRDMAP]. Additionally, the IETF versions have a more thorough analysis of security issues [RDMASEC], which drove normative statements into the [DDP] and [RDMAP] drafts. However, the only semantic changes of the [DDP] and [RDMAP] security sections was to make IPSec support normative. Thus the IETF and RDMAC versions should be able to interoperate, except for the minor issues outlined in this specification. The DDP/RDMAP specifications describe that the version number should be used to validate the received DDP segment. They do not, however, state what version numbers are valid. Some RNIC implementations may recognize the similarity between the IETF and RDMAC protocols and permissively allow either version one or zero; others may strictly require that the version number received match the version number sent. Since the specifications do not describe the version check, both implementations are valid and there is no way to predict how an IETF RNIC will interoperate with an RDMAC peer. MPA has had the most significant changes since it was first submitted to the IETF. The IETF protocol [IETFMPA] makes markers and CRC negotiable, whereas they are mandatory in the RDMAC version [RDMACMPA]. The IETF MPA also includes an exchange of start-up messages to ensure that both ends of the connection agree on the use of MPA markers and CRC before the connection is converted to RDMA mode. One approach that has been suggested is to specify interoperation between RDMAC and IETF RNICs by exchanging MPA Request/Reply frames on behalf of RDMAC RNICs. Even if the applications can negotiate the correct parameters for the RDMAC RNIC (markers and CRC enabled), there is still the issue of the DDP/RDMAP version numbers that must be resolved. Without this resolution the interoperability of the end nodes cannot be determined until after the connection converts Carrier & Pinkerton Expires May 2005 3 Internet Draft RNIC Interoperability November 2004 to RDMA mode and the end nodes begin interpreting each others DDP segments. The purpose of this draft is to describe an information exchange at the level of MPA to enable RNIC peers to negotiate a common protocol implementation using the MPA Request/Reply message exchange. The draft also proposes that DDP and RDMAP report their capability to support RDMAC as well as IETF wire protocols to ULPs so that the ULPs can configure the connection appropriately. Carrier & Pinkerton Expires May 2005 4 Internet Draft RNIC Interoperability November 2004 4 Proposed Modification to MPA Request/Reply Frame It is expected that RNICs will be available in three flavors: RDMAC RNICs -- implementations that require MPA markers and CRCs and use version zero (0) for DDP and RDMAP. IETF RNICs -- implementations that negotiate MPA markers and CRCs and use version one (1) for DDP and RDMAP. RDMAC/IETF RNICs -- implementations that negotiate MPA markers and CRCs, but can use either version zero (0) or version one (1) for DDP and RDMAP depending on the ULP request. As mentioned above, using the current specifications, interoperability between strict IETF RNICs and RDMAC RNICs is undefined. Even if a ULP or other supporting entity exchanges the MPA Request/Reply messages on behalf of the RDMAC RNIC, the success or the failure of the RDMA connection will depend on the specific RNIC implementation and will not be known until after both endpoints convert from streaming to RDMA mode. If an IETF RDMAP/DDP RNIC can be downgraded dynamically to an RDMAC mode (i.e. use version 0 DDP/RDMAP), then the success or failure of the connection could be determined during the MPA exchange with a simple modification of the REV field in the MPA Request/Reply Frames. The IETF MPA protocol defines the format of the MPA Request/Reply Frames in section 6.1.1 of [IETFMPA]. The following is the current definition of the Rev field: "Rev: This field contains the Revision of MPA. For this version of the specification senders MUST set this field to zero. MPA receivers compliant with this version of the specification MUST check this field for zero, and close the connection and report an error locally if any other value is detected." There are two changes to this definition required to enable protocol version negotiation: 1. "The sender must set this field to one." Since the IETF DDP and RDMAP protocols have version of one, then the IETF MPA protocol should also have the version of one, instead of zero. Changing the MPA version number would allow the ULPs or other supporting entities sending MPA Request/Reply Carrier & Pinkerton Expires May 2005 5 Internet Draft RNIC Interoperability November 2004 Frames on behalf of RDMAC RNICs to set this value to zero, which is also the version of the RDMAC DDP and RDMAP protocols. 2. "If the receiver cannot interoperate with the received version, it MUST gracefully close the connection and report an error locally. If the receiver can interoperate with the received version, then MPA should report the negotiated version to the ULP." The description of the version validation must change to allow receivers capable of altering their DDP and RDMAP version number to accommodate both the RDMAC and IETF versions of the protocols. In other words, whether or not MPA closes the connection depends on whether an RNIC implements a strict interpretation of the IETF protocol or a more permissive interpretation that can downgrade the protocol version number on a per connection basis. The following is the new Rev definition for the MPA Request/Reply Frame that includes the two proposed changes above: "Rev: This field contains the Revision of MPA. For this version of the specification senders MUST set this field to one. MPA receivers compliant with this version of the specification MUST check this field. If the MPA receiver cannot interoperate with the received version, then it MUST close the connection and report an error locally. Otherwise, the MPA receiver should report the received version to the ULP." If the above definition is acceptable, then the following section should be included as an appendix to the MPA specification. Carrier & Pinkerton Expires May 2005 6 Internet Draft RNIC Interoperability November 2004 5 Proposed Appendix B: IETF RNIC Interoperability with RDMA Consortium Protocols This appendix is Informative. Without the exchange of MPA Request/Reply Frames, there is no standard mechanism for enabling RDMAC RNICs to interoperate with IETF RNICs. Even if a ULP uses a well-known port to start an IETF RNIC immediately in RDMA mode (i.e., without exchanging the MPA Request/Reply messages), there is no reason to believe an IETF RNIC will interoperate with an RDMAC RNIC because of the differences in the version number in the DDP and RDMAP headers on the wire. Therefore, the ULP or other supporting entity at the RDMAC RNIC must implement MPA Request/Reply Frames on behalf of the RNIC in order to negotiate the connection parameters. The following section describes the results following the exchange of the MPA Request/Reply Frames before the conversion from streaming to RDMA mode. 5.1 Negotiated Parameters Three types of RNICs are considered: Upgraded RDMAC RNIC - an RNIC implementing the RDMAC protocols which has a ULP or other supporting entity that exchanges the MPA Request/Reply Frames in streaming mode before the conversion to RDMA mode. Non-permissive IETF RNIC - an RNIC implementing the IETF protocols which is not capable of implementing the RDMAC protocols. Such an RNIC can only interoperate with other IETF RNICs. Permissive IETF RNIC - an RNIC implementing the IETF protocols which is capable of implementing the RDMAC protocols on a per connection basis. The values used by these three RNIC types for the MPA, DDP, and RDMAP versions as well as MPA markers and CRC are summarized in Figure 1. Carrier & Pinkerton Expires May 2005 7 Internet Draft RNIC Interoperability November 2004 +----------------++-----------+-----------+-----------+-----------+ | RNIC TYPE || DDP/RDMAP | MPA | MPA | MPA | | || Version | Revision | Markers | CRC | +----------------++-----------+-----------+-----------+-----------+ +----------------++-----------+-----------+-----------+-----------+ | RDMAC || 0 | 0 | 1 | 1 | | || | | | | +----------------++-----------+-----------+-----------+-----------+ | IETF || 1 | 1 | 0 or 1 | 0 or 1 | | Non-permissive || | | | | +----------------++-----------+-----------+-----------+-----------+ | IETF || 1 or 0 | 1 or 0 | 0 or 1 | 0 or 1 | | permissive || | | | | +----------------++-----------+-----------+-----------+-----------+ Figure 1. Connection Parameters for the RNIC Types. For MPA markers and MPA CRC, enabled=1, disabled=0. It is assumed there is no mixing of versions allowed between DDP and RDMAP. The RNIC either generates the RDMAC protocols on the wire (version is zero) or the IETF protocols (version is one). During the exchange of the MPA Request/Reply Frames, each peer provides its MPA Revision, Marker preference (M: 0=disabled, 1=enabled), and CRC preference. The MPA Revision provided in the MPA Request Frame and the MPA Reply Frame may differ. From the information in the MPA Request/Reply Frames, each side sets the Version field (V: 0=RDMAC, 1=IETF) of the DDP/RDMAP protocols as well as the state of the Markers for each half connection. Between DDP and RDMAP, no mixing of versions is allowed. Moreover, the DDP and RDMAP version MUST be identical in the two directions. The RNIC either generates the RDMAC protocols on the wire (version is zero) or the IETF protocols (version is one). In the following sections, the figures do not discuss CRC negotiation because there is no interoperability issue for CRCs. Since the RDMAC RNIC will always request CRC use, then, according to the IETF MPA specification, both peers MUST generate and check CRCs. 5.2 RDMAC RNIC and Non-permissive IETF RNIC Figure 2 shows that a Non-permissive IETF RNIC cannot interoperate with an RDMAC RNIC, despite the fact that both peers exchange MPA Request/Reply Frames. For a Non-permissive IETF RNIC, the MPA negotiation has no effect on the DDP/RDMAP version and it is unable to interoperate with the RDMAC RNIC. The Non-permissive IETF RNIC should gracefully close the connection when it receives an MPA Request/Reply Frame with the Rev field equal to zero. Carrier & Pinkerton Expires May 2005 8 Internet Draft RNIC Interoperability November 2004 The rows in the figure show the state of the Marker field in the MPA Request Frame sent by the MPA Initiator. The columns show the state of the Marker field in the MPA Reply Frame sent by the MPA Responder. Each type of RNIC is shown as an initiator and a responder. The connection results are shown in the lower right corner, at the intersection of the different RNIC types, where V=0 is the RDMAC DDP/RDMAP version, V=1 is the IETF DDP/RDMAC version, M=0 means MPA markers are disabled and M=1 means MPA markers are enabled. The negotiated marker state is shown as X/Y, for the receive direction of the initiator/responder. +---------------------------++-----------------------+ | MPA || MPA | | CONNECT || Responder | | MODE +-----------------++-------+---------------+ | | RNIC || RDMAC | IETF | | | TYPE || | Non-permissive| | | +------++-------+-------+-------+ | | |MARKER|| M=1 | M=0 | M=1 | +---------+----------+------++-------+-------+-------+ +---------+----------+------++-------+-------+-------+ | | RDMAC | M=1 || V=0 | close | close | | | | || M=1/1 | | | | +----------+------++-------+-------+-------+ | MPA | | M=0 || close | V=1 | V=1 | |Initiator| IETF | || | M=0/0 | M=0/1 | | |Non-perms.+------++-------+-------+-------+ | | | M=1 || close | V=1 | V=1 | | | | || | M=1/0 | M=1/1 | +---------+----------+------++-------+-------+-------+ Figure 2: MPA negotiation between an RDMAC RNIC and a Non-permissive IETF RNIC. 5.2.1 RDMAC RNIC Initiator If the RDMAC RNIC is the MPA Initiator, its ULP sends an MPA Request Frame with Rev field set to zero and the M and C bits set to one. Because the Non-permissive IETF RNIC cannot dynamically downgrade the version number it uses for DDP and RDMAP, it would send an MPA Reply Frame with the Rev field equal to one and then gracefully close the connection. 5.2.2 Non-Permissive IETF RNIC Initiator If the Non-permissive IETF RNIC is the MPA Initiator, it sends an MPA Request Frame with Rev field equal to one. The ULP or supporting entity for the RDMAC RNIC responds with an MPA Reply Frame that has the Rev field equal to zero and the M bit set to one. Carrier & Pinkerton Expires May 2005 9 Internet Draft RNIC Interoperability November 2004 The Non-permissive IETF RNIC will gracefully close the connection after it reads the incompatible Rev field in the MPA Reply Frame. 5.3 RDMAC RNIC and Permissive IETF RNIC Figure 3 shows that a Permissive IETF RNIC can interoperate with an RDMAC RNIC regardless of its Marker preference. The figure uses the same format as shown with the Non-permissive IETF RNIC. +---------------------------++-----------------------+ | MPA || MPA | | CONNECT || Responder | | MODE +-----------------++-------+---------------+ | | RNIC || RDMAC | IETF | | | TYPE || | Permissive | | | +------++-------+-------+-------+ | | |MARKER|| M=1 | M=0 | M=1 | +---------+----------+------++-------+-------+-------+ +---------+----------+------++-------+-------+-------+ | | RDMAC | M=1 || V=0 | N/A | V=0 | | | | || M=1/1 | | M=1/1 | | +----------+------++-------+-------+-------+ | MPA | | M=0 || V=0 | V=1 | V=1 | |Initiator| IETF | || M=1/1 | M=0/0 | M=0/1 | | |Permissive+------++-------+-------+-------+ | | | M=1 || V=0 | V=1 | V=1 | | | | || M=1/1 | M=1/0 | M=1/1 | +---------+----------+------++-------+-------+-------+ Figure 3: MPA negotiation between an RDMAC RNIC and a Permissive IETF RNIC. A truly Permissive IETF RNIC will recognize an RDMAC RNIC from the Rev field of the MPA Request/Reply Frames and then adjust its receive Marker state and DDP/RDMAP version to accommodate the RDMAC RNIC. As a result, as an MPA Responder, the Permissive IETF RNIC will never return an MPA Reply Frame with the M bit set to zero. This case is shown as a not applicable (N/A) in Figure 3. 5.3.1 RDMAC RNIC Initiator When the RDMAC RNIC is the MPA Initiator, its ULP or other supporting entity prepares an MPA Request message and sets the revision to zero and the M bit and C bit to one. The Permissive IETF Responder receives the MPA Request message and checks the revision field. Since it is capable of generating RDMAC DDP/RDMAP headers, it sends an MPA Reply message with revision set to zero and the M and C bits set to one. The Responder must inform its ULP that it is generating version zero DDP/RDMAP messages. Carrier & Pinkerton Expires May 2005 10 Internet Draft RNIC Interoperability November 2004 5.3.2 Permissive IETF RNIC Initiator If the Permissive IETF RNIC is the MPA Initiator, it prepares the MPA Request Frame setting the Rev field to one. Regardless of the value of the M bit in the MPA Request Frame, the ULP or other supporting entity for the RDMAC RNIC will create an MPA Reply Frame with Rev equal to zero and the M bit set to one. When the Initiator reads the Rev field of the MPA Reply Frame and finds that its peer is an RDMAC RNIC, it must inform its ULP that it should generate version zero DDP/RDMAP messages and enable MPA markers and CRC. 5.4 Non-Permissive IETF RNIC and Permissive IETF RNIC For completeness, Figure 4 shows the results of MPA negotiation between a Non-permissive IETF RNIC and a Permissive IETF RNIC. The important point from this figure is that an IETF RNIC cannot detect whether its peer is a Permissive or Non-permissive RNIC. +---------------------------++-------------------------------+ | MPA || MPA | | CONNECT || Responder | | MODE +-----------------++---------------+---------------+ | | RNIC || IETF | IETF | | | TYPE || Non-permissive| Permissive | | | +------++-------+-------+-------+-------+ | | |MARKER|| M=0 | M=1 | M=0 | M=1 | +---------+----------+------++-------+-------+-------+-------+ +---------+----------+------++-------+-------+-------+-------+ | | | M=0 || V=1 | V=1 | V=1 | V=1 | | | IETF | || M=0/0 | M=0/1 | M=0/0 | M=0/1 | | |Non-perms.+------++-------+-------+-------+-------+ | | | M=1 || V=1 | V=1 | V=1 | V=1 | | | | || M=1/0 | M=1/1 | M=1/0 | M=1/1 | | MPA +----------+------++-------+-------+-------+-------+ |Initiator| | M=0 || V=1 | V=1 | V=1 | V=1 | | | IETF | || M=0/0 | M=0/1 | M=0/0 | M=0/1 | | |Permissive+------++-------+-------+-------+-------+ | | | M=1 || V=1 | V=1 | V=1 | V=1 | | | | || M=1/0 | M=1/1 | M=1/0 | M=1/1 | +---------+----------+------++-------+-------+-------+-------+ Figure 4: MPA negotiation between a Non-permissive IETF RNIC and a Permissive IETF RNIC. Carrier & Pinkerton Expires May 2005 11 Internet Draft RNIC Interoperability November 2004 6 Other Changes 6.1 Additional Changes to the MPA/DDP/RDMAP Drafts The RDMAP protocol needs to inform the consumer of the RDMA data stream of the results of the version negotiation. This is not required per the current IETF MPA/DDP/RDMAP drafts. Thus the drafts would need to be changed to state that MPA must pass the negotiated version to DDP, DDP must pass the version to RDMAP and RDMAP must make the version available to the ULP. For example, the following text is a suggested addition to [IETFMPA] section 3.2, "MPA's Interaction with DDP" : "MPA MUST provide the protocol version negotiated with its peer to DDP. DDP will use this version to set the version in its header and to report the version to RDMAP." 6.2 Verbs Extensions Most RNIC implementations include software to provide a Verbs interface [VERBS] to the host operating environment, even though Verbs are outside the scope of IETF protocols. The following extensions to Verbs are necessary to allow Verbs consumers to be active participants in RNIC interoperability. Note that some implementations will reserve RNIC resources before exchange of the MPA Request/Reply Messages. Other implementations will create the QP after the MPA Request/Reply Messages. Thus both CreateQP and ModifyQP need to be changed to enable both approaches. 6.2.1 Changes to QueryRNIC Output: - MPA Marker Receive preference - DDP/RDMAP version number - DDP/RDMAP version selectable on a per QP basis 6.2.2 Changes to CreateQP input: - Set MPA Marker for receive/transmit - Set DDP and RDMAP version number {0, 1} Carrier & Pinkerton Expires May 2005 12 Internet Draft RNIC Interoperability November 2004 6.2.3 Changes to CreateQP output: - New error code stating version number not supported. - New error code stating disabling markers not supported. 6.2.4 Changes to QueryQP Output: - MPA Marker selection for receive and/or transmit - DDP/RDMAP version number 6.2.5 Changes to ModifyQP input: Only on transition from Idle to Idle, or Idle to RTS. - Set MPA Marker for receive/transmit - Set DDP and RDMAP version number {0, 1} 6.2.6 Changes to ModifyQP output: - New error code stating version number not supported. - New error code stating disabling markers not supported. Carrier & Pinkerton Expires May 2005 13 Internet Draft RNIC Interoperability November 2004 7 References 7.1 Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [IETFMPA] Culley, P., Elzur, U., Recio, R., Bailey, S., Carrier, J., "Marker PDU Aligned Framing for TCP Specification", Internet Draft draft-ietf-rddp-mpa-01.txt, July 2004. [IETFDDP] Shah, H., J. Pinkerton, R.Recio, and P. Culley, "Direct Data Placement over Reliable Transports", Internet-Draft draft- ietf-rddp-ddp-02.txt, February 2004. [IETFRDMAP] Recio, R., P. Culley, D. Garcia, J. Hilland, "An RDMA Protocol Specification", Internet-Draft draft-ietf-rddp-rdmap- 01.txt, October 2003. [RDMASEC] Pinkerton J., Deleganes E., Romanow A., Bitan S., "DDP/RDMAP Security", draft-ietf-rddp-security-01.txt (work in progress), February 2004. [IPSEC] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 7.2 Informative References [RDMACMPA] P. Culley et al., "Marker PDU Aligned Framing for TCP Specification", RDMA Consortium Draft Specification draft- culley-iwarp-mpa-v1.0, October 2002 [RDMACDDP] H. Shah et al., "Direct Data Placement over Reliable Transports", RDMA Consortium Draft Specification draft- shahiwarp-ddp-v1.0, October 2002 [RDMACRDMAP] R. Recio et al., "An RDMA Protocol Specification", RDMA Consortium Draft Specification draft-recio-iwarp-rdmap-v1.0, October 2002 [VERBS] J. Hilland et al., "RDMA Protocol Verbs Specification", RDMAC Consortium Draft Specification draft-hilland-iwarp-verbs- v1.0-RDMAC, April 2003 Carrier & Pinkerton Expires May 2005 14 Internet Draft RNIC Interoperability November 2004 8 Author's Addresses John Carrier Adaptec Inc. 691 South Milpitas Blvd. Milpitas, CA 95035 USA Phone: (360) 378-8526 Email: john_carrier@adaptec.com Jim Pinkerton Microsoft, Inc. One Microsoft Way Redmond, WA USA 98052 USA Phone: Email: jpink@microsoft.com Carrier & Pinkerton Expires May 2005 15 Internet Draft RNIC Interoperability November 2004 9 Acknowledgments Caitlin Bestler Siliquent Technologies 1300 Crittenden, Suite 201 Mountain View, CA 94043 USA Phone: +1 (650) 962-1632 ext 100 Email: caitlinb@siliquent.com Paul R. Culley Hewlett-Packard Company 20555 SH 249 Houston, TX 77070 USA Phone: +1 (281) 514-5543 Email: paul.culley@hp.com Uri Elzur Broadcom 16215 Alton Parkway CA 92618 USA Phone: +1 (949) 585-6432 Email: uri@broadcom.com Fredy Neeser IBM Zurich Research Laboratory Saeumerstrasse 4 CH-8803 Rueschlikon, Switzerland Phone: +41 (0)1 724 8487 Email: nfd@zurich.ibm.com Renato J Recio IBM Internal Zip 9043 11400 Burnett Road Austin, TX 78759 USA Phone: +1 (512) 838-3685 Email: recio@us.ibm.com Barry Reinhold Lamprey Networks PO Box 539 Durham, NH 03824 USA Phone: +1 (603) 868-8411 Email: bbr@lampreynetworks.com Carrier & Pinkerton Expires May 2005 16 Internet Draft RNIC Interoperability November 2004 Tom Talpey Network Appliance 375 Totten Pond Road Waltham, MA 02451 USA Phone: +1 (781) 768-5329 EMail: thomas.talpey@netapp.com Patricia Thaler Agilent Technologies, Inc. 1101 Creekside Ridge Drive, #100 M/S-RG10 Roseville, CA 95678 USA Phone: +1 (916) 788-5662 email: pat_thaler@agilent.com Carrier & Pinkerton Expires May 2005 17 Internet Draft RNIC Interoperability November 2004 10 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP78, and except as set forth therein, the authors retain all their rights. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC Editor function is currently provided by the Internet Society. Carrier & Pinkerton Expires May 2005 18