idnits 2.17.1 draft-bogdanov-comments-umsp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2001) is 8409 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 3018 (ref. '2') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Alexander Bogdanov 2 draft-bogdanov-comments-umsp-01.txt 3 Expires: October 2001 April 2001 5 Comments to the Unified Memory Space Protocol 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026 [1]. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This memo contains the description of the several systems models, for 30 which the Unified Memory Space Protocol (UMSP, RFC3018) is intended. 31 The purpose of this memo is the review of problems, which were defined 32 during the protocol specification development. 34 1 Introduction 36 This memo is the addition to the document "Unified Memory Space 37 Protocol Specification" [2]. UMSP is the network protocol, which 38 gives a capability of immediate access to memory of the remote nodes. 39 It is based on the model of the 128-bit distributed address space of 40 memory. The models, submitted in the memo, were used at the problem 41 definition for the development of the UMSP and its have influenced a 42 choice of the engineering solutions. There are no detailed projects 43 for the described systems. In addition, for them is not given the 44 strict substantiation of a possibility of realization. 46 The following models are described in the document: 47 O the control of simple devices 48 O the universal high-level protocol 49 O the distributed application, created in single process of 50 compilation 51 O the distributed virtual memory. 53 2 The Models Description 55 2.1 Control of Simple Devices 57 The architecture, considered in the given section, is focused on the 58 remote control of simple devices. The logic of the minimal UMSP 59 profile is relatively simple and can be realized in such devices. 60 The base architecture is given in the following figure: 62 +----------------+ 63 | Internet Host | 64 | | 65 | +-----------+ | 66 | | Control | | +----------------+ 67 | | Program | | +------| Slave Device 1 | 68 | +-----------+ | | +----------------+ 69 +-----|----------+ | 70 | +------------+ +----------------+ 71 | | |-----| Slave Device 2 | 72 Internet ----/ | Control | +----------------+ 73 / | | . 74 /--------| Computer |--+ . 75 | | | . 76 +------------+ | . 77 | +----------------+ 78 +--| Slave Device N | 79 +----------------+ 81 The control computer (CC) can carry out the following functions: 82 O to realize the protection from the unauthorized access 83 functions, 84 O to carry out the gateway functions, if the communications 85 between CC and slave devices (SD) are distinct from TCP/IP, 86 O to contain the program, which carrying out part of the SD 87 logic. 89 The slave devices (SD) can have simple logic and interact with CC 90 under the not-network communications. 92 UMSP provides the immediate interaction between the control program 93 (CP) and SD. The possibility of realization of the given architecture 94 is provided with the following functions of the protocol: 95 O The establishment of session connection is not obligatory. 96 Prior to the beginning of exchange, CP can receive the 97 information about SD (for example about a type of the device or 98 VM) immediately reading out data from the definite addresses of 99 device memory. 101 O The interaction between CP and SD can be realized through three 102 simple instructions with fixed length of data: reading/write in 103 memory and synchronization (for tracking of asynchronous 104 events). These instructions can even be executed by devices 105 with no having micro code. All other instructions can be 106 ignored on SD. 107 O From the UMSP logic point of view, SD can be: 108 1) The addressable node to which is nominated the VM of the 109 definite type. Such VM has no its own instructions system 110 and directly executes the UMSP instructions. 111 2) The separate VM connected to the CC node. 112 3) The programmed object in the CC addresses space. In this 113 case, the device logic is completely defined by the CC 114 functionalities. 116 In general case, SD can have the large computing resources and 117 realize TCP/IP stack. Thus, the various variants of architecture are 118 possible, which have been not considered in the document. 120 2.2 Universal High-level Protocol 122 UMSP can be last in stack and only one high-level network protocol. 123 All other functions can be realized as Application Program Interface 124 (API) of standard virtual machines (VM). It is possible to quote the 125 following arguments for the benefit of told: 126 O It is easier to standardize VM, than the network protocol. 127 Thus, it is possible to realize compound API even on VM with 128 the elementary instructions set. 129 O The API standardization is more simple task, than 130 standardization of the network protocol with the same 131 functions. Moreover, API can considerably be complicated and 132 multifunctional in comparison with possibilities of the network 133 protocols. 134 O UMSP directly converts the logic of the application programs 135 instructions, working with data in memory, in the logic of 136 network exchange. The consumption of computing resources can be 137 reduced due to this, as disappears the necessity of 138 presentation layer functions. 139 O It is easier to use API, than to use the protocol, for the 140 programs development. It allows to lower considerably the work 141 content of creation of the distributed applications and to 142 realize inaccessible at using of the network protocols 143 functions. 144 O The unification of the high-level protocol allows to carry out 145 100% verification of the user traffic on gateways and to 146 provide effective protection of local networks from external 147 attacks. 149 Probably, even the functions of network control, routing, DNS and 150 other can be realized as API. 152 2.3 Distributed Application Created in Single Process of Compilation 154 The basic convenience to the developer consists in essential 155 simplification of the distributed applications creation. The programs 156 examples, with nonexistent for today extensions of languages, are 157 given in this section to show it. These examples are only 158 illustration. 160 The examples contain a minimally necessary code. A possibility to 161 address memory on the remote system opens many opportunities before 162 the VM developers for realization of the various distributed services 163 and API. The decision of these questions does not concern to sphere 164 of the network protocol. 166 1) The following example is written in BASIC language by using of the 167 procedural approach: 169 ' It is supposed to execute this function by the remote machine. 170 ' Probably, the distributed function code has some restrictions, 171 ' in comparison with usual function. So as the compiler to check 172 ' them, the qualifier 'Relocatable' is used in definition. 173 ' Besides, variables of access type in such function should be 174 ' processed by the special method by the compiler. 175 Relocatable Function dFunc(parm1 As Integer) As String 177 ' It is possible to write here a usual code, using local and 178 ' global variable, or calling the user-defined functions or API 179 ' functions, given by the VM. 181 DFunc = "OK" 182 End Function 184 ' Example of execution of the function on other machine with using 185 ' of preliminary establishment of connection 186 Sub RunD() 187 On Error GoTo Next 189 ' The variable identifying a remote host 190 Dim OtherVM As RelocatableVM 191 Dim ForRet As String 193 ' To set connection with the remote node. First parameter is 194 ' constant of the address type (the decimal IP address in this 195 ' case). 196 Set OtherVM = ConnectVM(vbTpIP, "10.15.127.15") 197 If Err Then 198 MsgBox "Error of connection establishment" 199 Exit Sub 200 End If 201 ' To call function 202 ForRet = OtherVM.Call dFunc(10) 203 If Err Then 204 MsgBox "Error of function execution" 205 Exit Sub 206 End If 207 End Sub 209 2) The second example is written in JAVA language with the object 210 approach using: 212 /** 213 * The instances of this class can be created on the remote node. 214 */ 215 relocatable class dClass 216 { 218 // There can be variable-members of the classes 220 /** 221 * This constructor will be called on the remote node after the 222 * memory allocation. 223 */ 224 dClass() 225 { 227 // Initialization code is located here 228 } 230 /** 231 * Function-member of the class 232 */ 233 String dMetod(int Parm1) 234 { 236 // The code located here, can execute usual calculations, 237 // call API functions, can create instances of standard or 238 // special classes, instances of classes definite in this 239 // program and having the 'relocatable' qualifier 241 return "OK"; 242 } 243 } 245 /** 246 * Example of creation of the class instance on the remote node 247 */ 248 class dExamp 249 { 250 dFunc(int Parm1) 251 { 252 try 253 { 255 // Create class on the remote IP node 256 dClass dc = new ("10.15.5.120", dClass); 258 // Call function. This function is executed on the remote 259 // node. 260 String sRet = dc.dMetod(15); 262 // Delete the instance 263 dc = null; 264 } 265 catch (Exception e) 266 { 267 // Exception handling 268 } 269 } 270 } 272 It is visible from the given examples that the obligatory processing 273 of errors is the basic complication in comparison with the not 274 distributed application for programs developer. It is explained to 275 that the exception condition can be caused by any operator. 277 2.4 Distributed Virtual Memory 279 The creation of virtual memory distributed between Internet nodes is 280 complex task with the ambiguous decision. Traditional page swapping 281 is probably inexpedient, as will result in the large traffic of 282 unnecessary data. Besides, the algorithms of pages blocking in the 283 network environment are not obvious. UMSP will not provide these 284 functions in an obvious kind for these reasons. 286 The single requirement to the protocol, which was generated on basis 287 of the analysis of similar systems, is the 128-bit address of memory 288 of fixed length. Probably, such address is optimum from the point of 289 view of hardware realization and is simultaneously convenient at 290 program realization. In addition, such length of the address can 291 ensure the decision of any task on any platforms now and in the 292 predictable future. 294 3 Used Abbreviations 296 API Application Programming Interface. 298 CC Control Computer 300 CP Control Program 302 SD Slave Device 303 UMSP Unified Memory Space Protocol 305 VM Virtual Machine 307 4 References 309 [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 310 9, RFC 2026, October 1996. 312 [2] A. Bogdanov, "Unified Memory Space Protocol Specification", 313 RFC 3018, December 2000. 315 5 Author's Address 317 Alexander Bogdanov 319 23-126, Generala Kuznetsova St. 320 Moscow, Russia 109153 321 RU 323 Email: a_bogdanov@pisem.net 324 Phone: +7 901 732 9760 326 Full Copyright Statement 328 Copyright (C) the Internet Society (2000). All Rights Reserved. 330 This document and translations of it may be copied and furnished to 331 others, and derivative works that comment on or otherwise explain it 332 or assist in its implementation may be prepared, copied, published 333 and distributed, in whole or in part, without restriction of any 334 kind, provided that the above copyright notice and this paragraph are 335 included on all such copies and derivative works. However, this 336 document itself may not be modified in any way, such as by removing 337 the copyright notice or references to the Internet Society or other 338 Internet organizations, except as needed for the purpose of 339 developing Internet standards in which case the procedures for 340 copyrights defined in the Internet Standards process must be 341 followed, or as required to translate it into languages other than 342 English. 344 The limited permissions granted above are perpetual and will not be 345 revoked by the Internet Society or its successors or assigns. 347 This document and the information contained herein is provided on an 348 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 349 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 350 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 351 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 352 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.