Network Working Group D. Otis Internet Draft SANlight Document: draft-otis-ddp-iov-00.txt Expires September, 2002 March 22, 2002 IO Vectoring to support DDP Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. abstract This draft describes local interchange routines to support Direct Data Placement shim layers. This includes memory authorization, memory boundary assignment, logical to physical address translation, cumulative TSN pooling per association, and Payload Protocol Identifiers with Stream binding. These functions may implement data vectoring as DMA bus master for a network interface card working above an SCTP transport layer. Table of Contents 1. Overview......................................................2 2. Conventions used in this document.............................2 3. DDP Support Functions.........................................2 3.1 Memory Authorization and Boundary Assignment..............2 3.2 Logical to Physical Address Translation...................3 3.3 Cumulative TSN Pooling per Association....................3 3.4 Payload Protocol Identifier with Stream Binding...........3 4. Security Considerations.......................................3 5. Acknowledgements..............................................4 6. Author's Address..............................................4 Otis Expires - September 2002 [Page 1] IO Vectoring to support DDP March 22, 2002 7. References....................................................4 8. Full Copyright Statement......................................4 1. Overview This is a description of local interaction needed for Direct Data Placement routines servicing an ULP above a Direct Data Placement shim. These routines provide the following set of services: - Memory Authorization - Memory Boundary Assignment - Logical to Physical Address Translation - Cumulative TSN Pooling per Association - Payload Protocol Identifier with Stream Binding Routines or hardware associated with DDP vectoring is normally protected by the operating system from access by users. Instead, access is obtained through a set of routines necessary for the implementation of DDP. The DDP shim provides access to the transport and works in conjunction with local buffer handlers. Buffer handling is separated isolated from shim definitions to reduce transport dependence. 2. Conventions used in this document The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. DDP is a mnemonic for Direct Data Placement and ULP is for Upper-Level Protocol. 3. DDP Support Functions 3.1 Memory Authorization and Boundary Assignment A routine that accepts vectors assures it is valid for the process. The request may return a handle to be used by the shim layer. The alignment of the referenced memory region need not coincide with the address requested by the process. It may be expedient to align to pages and adjust low to high boundary assignments. If Streams are used as the handle rather than a Tag, the address requested should coincide with the beginning of the memory region with only an upper boundary being required. For SCTP, Tags should be independently defined per Stream as well. Otis Expires - September 2002 [Page 2] IO Vectoring to support DDP March 22, 2002 3.2 Logical to Physical Address Translation In most systems, the processor incorporates an embedded memory translation scheme to visualize memory. Normally, the Operating System is required to locate the memory translation tables used by the processor. To allow the interface to function, the logical address understood by the processor must be translated into an array of physical addresses. This same process also normally includes marking the memory pages as not being cacheable. Upon the routine being released the memory pages, the pages may once again be marked for caching to hard storage. 3.3 Cumulative TSN Pooling per Association As each queue receiving message flags from the shim is tested against the cumulative TSN, this same TSN also excludes replicate packets from being placed once a complete sequence has been received. By allowing multiple adapters to share cumulative TSNs upon those points where a flag becomes valid, this ensures a means of synchronizing multiple adapters. Only after ensuring each adapter receives the update of the TSN, can message flags be processed. 3.4 Payload Protocol Identifier with Stream Binding The vectoring hardware can assist the process by confirming the Payload Protocol Identifier is as expected. There can be negotiations handled on a single Streams that is then applied to multiple Streams, or done Stream by Stream. Once this negotiation is completed, the process can bind a Payload Protocol Identifier to the Stream. The Payload Protocol Identifier also assures for additional processing as a means of further extending the DDP layer. The handling of DDP shim together with the IO vectoring is defined by the draft that obtains the IANA registry of the Payload Protocol Identifier. Both the IO Vectoring and DDP shim do not define the details related to ULP. These details must be clarified in the drafts that wish to employ the DDP shim. 4. Security Considerations Any direct placement of memory poses a significant security risk. Great caution must be taken when referencing offsets to memory addresses in behalf of peer endpoints. The DDP Tag SHOULD NOT be a direct memory address passed to a peer but instead an index to be translated into a memory address. Otis Expires - September 2002 [Page 3] IO Vectoring to support DDP March 22, 2002 The DDP Offset must be carefully verified to assure that the offset is within a valid range of the buffer. If any data placement specification is incorrect the association SHOULD be aborted. 5. Acknowledgements The author would like to thank the following people that have provided comments and input- Randall Stewart, Stephen Bailey, Allyn Romanow, David Black, and Caitlin Bestler. 6. Author's Address Douglas Otis 800 E. Middlefield Mountain View, CA 94043 USA Email dotis@sanlight.net 7. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. 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. Otis Expires - September 2002 [Page 4] IO Vectoring to support DDP March 22, 2002 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. Otis Expires - September 2002 [Page 5]