idnits 2.17.1 draft-davies-broker-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 114 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. INTRODUCTION.' ) ** 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.) ** There are 67 instances of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TITLE: A MODEL FOR SECURE CALL-LIKE SESSIONS 2 WITHIN THE INTERNET 3 5 - September 1996 - 7 AUTHORS: P.J.Williams) GPT Limited, UK. 8 Ian Davies ) 10 Status of this document 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by 20 other documents at any time. It is inappropriate to use 21 Internet-Drafts as reference material or to cite them other 22 than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please 25 check the ``1id-abstracts.txt'' listing contained in the 26 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West 29 Coast). 31 ABSTRACT 33 The Internet is increasingly being used for commercial and 34 industrial purposes which, apart from causing an explosion in 35 traffic, will require that the future network provides a 36 highly efficient "on-demand" service. The provision of an 37 efficient on-demand service will require Internet "sessions" 38 to use virtual-message-paths that must be opened and closed in 39 a manner similar to the establishment of calls in a telephone 40 network; enabling the network to refuse traffic which exceeds 41 the available capacity and ensuring that established sessions 42 will not be violated. It is felt that the RSVP mechanism will 43 not fully meet these requirements for the commercial services 44 described below, and this paper describes an alternative. 46 As the Internet becomes the ultimate source of information, 47 the "Global Net", users will need intermediary "Broker" 48 services to clarify their requirement, select the appropriate 49 service and arrange delivery of the information. It is 50 proposed that Broker-type "special-service" sessions should be 52 established in reverse. The Broker or Receptionist will be 53 given identifiers enabling the virtual-message-path to the 54 user to be picked-up at the user's Internet Router. As the 55 user's requirements are recognised, these identifiers can be 56 passed from Broker to Broker and from Server to Server 57 enabling other Brokers or Servers to join the session, or 58 enabling the user to be transferred from one to the other 59 until service delivery is complete. 61 The proposed method of service delivery is very user-friendly. 62 From the user's point of view, every session appears to be a 63 simple session with a single Internet host. Whatever starting 64 point is chosen (even the wrong one), the transfer activity 65 will eventually deliver the required information. The method 66 is also commercially secure. The user does not participate in 67 the transfer activity and cannot short-circuit the Broker on 68 future occasions. Servers deliver information directly to the 69 user - whose identity is verified, thereby easing if not 70 completely eliminating the "hacking" problem. 72 TABLE OF CONTENTS. 74 1. INTRODUCTION . . . . . . . . . . . . . . . . . . .0004 76 2. REQUIREMENTS OF THE FUTURE INTERNET. . . . . . . .0004 77 2.1. The "connection-oriented" requirement. . . . . . .0004 78 2.2. The simple-session requirement . . . . . . . . . .0005 79 2.3. The "special-service" requirement. . . . . . . . .0005 81 3. OUTLINE OF SPECIAL-SERVICE IMPLEMENTATION. . . . .0006 83 4. INTERNET NAMES AND ADDRESSES . . . . . . . . . . .0006 84 4.1. Internet names . . . . . . . . . . . . . . . . . .0006 85 4.2. Internet addresses . . . . . . . . . . . . . . . .0007 86 4.2.1. User addresses . . . . . . . . . . . . . . . .0007 87 4.2.2. Service-delivery addresses . . . . . . . . . .0007 88 4.2.3. Special-service networks . . . . . . . . . . .0008 90 5. TRANSPORT LAYER PROTOCOL MIGRATION STRATEGY. . . .0008 92 6. CREATING A VIRTUAL-MESSAGE-PATH. . . . . . . . . .0008 93 6.1. The host/Router link . . . . . . . . . . . . . . .0008 94 6.1.1. The host/Router link header. . . . . . . . . .0009 95 6.2. The OPEN message . . . . . . . . . . . . . . . . .0009 96 6.3. The message-path through the Internet. . . . . . .0010 97 6.3.1. VCN allocation . . . . . . . . . . . . . . . .0010 98 6.3.2. Switching tables . . . . . . . . . . . . . . .0010 99 6.3.3. The OPEN_DONE message. . . . . . . . . . . . .0011 100 6.3.4. Reserving capacity . . . . . . . . . . . . . .0012 101 6.3.5. Using the message-path . . . . . . . . . . . .0012 102 6.3.6. Diverting a message-path . . . . . . . . . . .0013 103 6.3.7. Closing the message-path . . . . . . . . . . .0013 105 7. SPECIAL-SERVICES . . . . . . . . . . . . . . . . .0013 106 7.1. Invoking special-service delivery. . . . . . . . .0013 107 7.1.1. The SERVICE_ACK message. . . . . . . . . . . .0014 108 7.1.2. The SERVICE_REQUEST message. . . . . . . . . .0014 109 7.2. Establishing the service delivery path . . . . . .0015 110 7.2.1. The OPEN_SERVICE message . . . . . . . . . . .0015 111 7.2.2. The OPEN_DONE messages . . . . . . . . . . . .0016 112 7.2.2.1. OPEN-DONE to the Server. . . . . . . . . .0016 113 7.2.2.2. OPEN_DONE to the user. . . . . . . . . . .0017 114 7.2.3. Control message interface. . . . . . . . . . .0017 115 7.2.4. The REQUEST_DONE message . . . . . . . . . . .0018 116 7.3. Delivering the service . . . . . . . . . . . . . .0018 117 7.4. Service transfer . . . . . . . . . . . . . . . . .0018 118 7.4.1. The TRANSFER_REQUEST message . . . . . . . . .0018 119 7.4.2. The OPEN_TRANSFER message. . . . . . . . . . .0018 120 7.4.3. The OPEN_DONE and CLOSE_REQUEST messages . . .0018 121 7.4.4. The REQUEST_DONE message . . . . . . . . . . .0019 122 7.5. Subsequent transfers . . . . . . . . . . . . . . .0019 124 8. ACCOMMODATING EXISTING EQUIPMENT . . . . . . . . .0021 125 8.1. A simple session in the unknown Internet . . . . .0021 126 8.1.1. The OPEN message . . . . . . . . . . . . . . .0022 127 8.1.2. The OPEN_OLD message . . . . . . . . . . . . .0022 128 8.1.3. Conducting the session . . . . . . . . . . . .0023 129 8.1.3.1. Forward messages . . . . . . . . . . . . .0023 130 8.1.3.2. Backward messages. . . . . . . . . . . . .0023 131 8.1.3.3. Closing the session. . . . . . . . . . . .0024 132 8.2. A special-service session in the unknown Internet.0024 133 8.2.1. Invoking the service . . . . . . . . . . . . .0024 134 8.2.2. SERVICE_REQUEST via old network. . . . . . . .0024 135 8.2.2.1. UDP/IP header. . . . . . . . . . . . . . .0024 136 8.2.2.2. The ACK_OLD message. . . . . . . . . . . .0024 137 8.2.3. Service delivery via old network . . . . . . .0025 138 8.2.3.1. The OPEN_SERVICE message . . . . . . . . .0025 139 8.2.3.2. The OPEN_OLD message . . . . . . . . . . .0025 140 8.2.4. Conducting the session . . . . . . . . . . . .0027 141 8.2.4.1. Forward messages . . . . . . . . . . . . .0027 142 8.2.4.2. Backward messages. . . . . . . . . . . . .0028 143 8.2.4.3. Closing the previous message-path. . . . .0028 144 8.2.5. Closing the session. . . . . . . . . . . . . .0028 146 9. MULTI-SESSIONS . . . . . . . . . . . . . . . . . .0029 148 10. THE FUTURE INTERNET - CHARGING . . . . . . . . . .0029 149 10.1. Basic charges. . . . . . . . . . . . . . . . . . .0029 150 10.2. Special-service charges. . . . . . . . . . . . . .0029 151 10.3. Collecting Service Providers charges . . . . . . .0030 153 11. SECURITY . . . . . . . . . . . . . . . . . . . . .0030 154 11.1. User identity verification . . . . . . . . . . . .0030 155 11.2. Breeching security . . . . . . . . . . . . . . . .0030 157 1. INTRODUCTION. 159 This paper describes a very simple, very user-friendly and 160 commercially secure means of providing access to the endless 161 variety of services and sources of information that is and 162 will be available via the Internet. The proposals are an 163 adaptation of the principles employed in the "Enhanced 164 Intelligent Network" proposed for the telephone network and 165 are equally applicable to ATM, X25 or similar networks. 167 To gain access to even the most remote and obscure source of 168 information, a user simply opens a session with a Broker or 169 Enquiry type service. As the user's needs are identified, the 170 session will be transferred from Broker to Broker and from 171 Server to Server until the final objective is reached. The 172 user is not required to participate in the transfer activity. 174 Brokers do not reveal any information to their client users as 175 they transfer sessions to other Brokers or Servers. Having 176 gained access to a service via a Broker, a user cannot regain 177 access to that service without again going via the Broker. 179 Servers deliver information directly to the user whose 180 identity is verified. The Broker cannot copy the information. 182 The paper also shows how the proposals can interwork with the 183 existing Internet architecture and protocols. 185 2. REQUIREMENTS OF THE FUTURE INTERNET. 187 The Internet is increasingly being used for commercial and 188 industrial purposes which, apart from causing an explosion in 189 traffic, will require that the future network provides a 190 highly efficient and commercially secure "on-demand" service. 192 The current arrangement, in which users benevolently handle 193 and switch one-another's traffic (and do not quarrel about the 194 performance), cannot continue. Internet Providers must be 195 independent of and impartial to the users. Users must know 196 that their messages are not handled in a competitor's network. 198 The future Internet Providers will be similar to the telephone 199 network Providers. Users will pay a fixed charge for Internet 200 access and will almost certainly pay an additional usage 201 charge. In some cases, a further charge may be levied by the 202 distant terminal for the actual information delivered. The 203 charging arrangements are reviewed in Section 10. 205 2.1. The "connection-oriented" requirement. 207 The provision of an efficient on-demand service will require 208 Internet "sessions" to use virtual-message-paths that must be 209 opened and closed in a manner similar to the establishment of 210 calls in a telephone network; enabling the network to refuse 212 traffic which exceeds the available capacity and ensuring that 213 established sessions will not be violated. 215 Charging is another aspect of the future Internet that will 216 require sessions to be opened and closed. Internet Providers 217 will record the traffic at network terminals and at gateways 218 to other networks for charging purposes, but will need to know 219 which terminal originated the session to which the messages 220 belong; - that is "which end is paying?" 222 2.2. The simple-session requirement. 224 Perhaps the majority of Internet usage will continue to be 225 where a user establishes a virtual-message-path to another 226 user to conduct a simple one-to-one session. 228 The present method of gaining access to remote information 229 during a simple session is for the terminating end to open a 230 session with the remote source and relay information as 231 required. This method is known as "chaining". 233 Alternatively, the terminating end may send to the user the 234 address of the remote information. The user is required to end 235 the current session and open a session with the new address to 236 obtain the information, Returning an Internet address in this 237 manner is known as "referral". 239 "Chaining" and "referral" will continue to be used in the 240 future but in many cases it will be preferable to use the 241 proposed means of "special-service" delivery. 243 2.3. The "special-service" requirement. 245 In many cases, an Internet user may merely know that he wishes 246 to buy software, insurance, or contact a large multi-national 247 business organisation and will need to open an initial session 248 with a broker or receptionist in order to proceed. 250 Having interrogated the user to identify the service required, 251 the Broker/Receptionist may not need to participate in the 252 ensuing activity but may be unwilling to use "referral" as 253 this would give information to the user that could be used, or 254 misused on future occasions. 256 e.g. the user could bypass the Broker on future occasions. 258 the user could pass the information to other users. 260 the user could amend the information to gain access to 261 other services provided by the Server. 263 the information may enable privileged access to the 264 service and privileged charges to be applicable. 266 "Chaining" may also be unacceptable. Apart from the additional 267 handling and resources involved, the Server may be unwilling 268 to deliver its service via a Broker and may require to deal 269 directly with the user. 270 Service delivery requires that the user can be transferred 271 from Broker to Broker and from Server to Server as service 272 delivery proceeds, without being involved in the transfer 273 activity. 275 3. OUTLINE OF SPECIAL-SERVICE IMPLEMENTATION. 277 "Special-service" sessions will be established in reverse. 279 When a user attempts to open a session with a special-service, 280 the special-service Server will be given identifiers enabling 281 it to establish a virtual-message-path through the Internet to 282 pick-up the virtual-message-path from the user at the user's 283 Internet Router (a message switching node of the Internet). 285 As the session proceeds, the identifiers may be passed from 286 Server to Server enabling the user to be transferred from one 287 Server to another, or enabling other Servers to be brought 288 into the session. 290 This basic concept of special-service delivery is very simple, 291 but because the present Internet is not connection-oriented, a 292 detailed description of its implementation requires that the 293 creation of a virtual-message-path for a simple session is 294 described and that the method of interworking with existing 295 equipment is included. 297 Consequently, the implementation is detailed in three parts. 299 Part 1. Creating a virtual-message-path. (Section 6.) 301 Part 2. Special-service delivery. (Section 7.) 303 Part 3. Accommodating existing equipment. (Section 8.) 305 4. INTERNET NAMES AND ADDRESSES 307 4.1. Internet names. 309 To send a message or open a session in the Internet, a user 310 provides the Internet name of the distant end. The initial 311 task in any activity is to consult a cache or Domain Name 312 Server to obtain the Internet address. As a result the choice 313 of an Internet name is, and will remain, rather arbitrary. 315 4.2. Internet addresses. 317 4.2.1. User addresses. (See Figure 1) 319 For the majority of Internet users, the more significant bits 320 of the user's address (netID) will identify the user's Router; 321 the lesser bits (hostID) identifying the user's terminal. 323 The user's Internet address will not identify a particular 324 Router if the user is connected to an elongated private 325 network that gains access to the Internet via several Routers. 327 host host 328 1 n 329 + + + + + + + + + + + + + + + + 330 | | | | | | | | | | | | | | | | 331 +-+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-+ 332 | ELONGATED PRIVATE NETWORK | 333 | netID d; hostID 1-n | 334 +---------+---------------------+---------------------+---------+ 335 + | + + | + + | + 336 | | | | | | | | | 337 +-+---+---+-+ +-+---+---+-+ +-+---+---+-+ 338 +---+ ROUTER A +---+ +---+ ROUTER B +---+ +---+ ROUTER C +---+ 339 | | | | | | 340 +---+ netID a +---+ +---+ netID b +---+ +---+ netID c +---+ 341 | hostID 1-n| | hostID 1-n| | hostID 1-n| 342 +---+ +---+ +---+ +---+ +---+ +---+ 343 host+-----+-----+host host+-----+-----+host host+-----+-----+host 344 1 | n 1 | n 1 | n 345 | | | 346 +----+---------------------+---------------------+----+ 347 | I N T E R N E T | 348 +-----------------------------------------------------+ 350 FIGURE 1. INTERNET ADDRESSES 352 Such users present no problems for simple Internet sessions; 353 whichever Router is used to establish a virtual-message-path 354 at the start of a session will be the Router used throughout 355 the session. However, when users have to be picked-up for 356 special-service delivery, the address used must identify the 357 Router that invoked the service. 359 4.2.2. Service Delivery addresses. 361 To deliver a "special-service", a Server establishes a virtual 362 message-path through the Internet to pick-up the message-path 363 to the user at the user's Internet Router. To establish the 364 path, the Server uses a "service delivery address" allocated 365 by the Router at the time of service invocation. The netID 366 part of the address identifies the Router, the hostID part 367 enables the Router to identify the current session-record. 369 4.2.3. Special-service networks. 371 The future Internet address structure will include "networks" 372 (netIDs) that identify Brokers and Services but have no 373 relation to the location of the Routers and Servers. A single 374 address (hostID) within such a network might identify all the 375 worldwide services provided by General Motors of America, 376 adjacent addresses identifying Siemens of Germany, Reuters 377 News Agency or Mitsubishi of Japan. 379 Thus, the netID part of the address is merely a "special- 380 service" identifier and the hostID part is no more than an 381 index number identifying the service. 383 5. TRANSPORT LAYER PROTOCOL MIGRATION STRATEGY. 385 In order to accommodate existing Internet equipment, all new 386 equipment (hosts and Routers) will continue to handle the 387 existing protocols (IP/TCP,etc.). 389 As the penetration of new style equipment increases, new 390 transport layer protocols will be introduced which are more 391 suited to a connection-oriented environment, but some time 392 will elapse before such protocols are universally available. 394 The old protocols will continue to be used when no other 395 protocol is mutually available. When old protocols are used in 396 a connection-oriented manner, the IP header is redundant and 397 should be ignored or even omitted. (It would be used only to 398 make a checksum?) 400 To accommodate the introduction of new protocols, when opening 401 a session, a user will indicate in the OPEN message the old 402 and new protocols available for the transport layer session. 403 The distant end will indicate in the OPEN_DONE message the 404 chosen mutually available protocol. (If old network equipment 405 is encountered, the session will use old network protocols.) 407 6. CREATING A VIRTUAL-MESSAGE-PATH. (SEE FIG.2, page 11) 409 6.1. The host/Router link. 411 Internet terminals are called "hosts". A host may be a PC 412 capable of little more than one task at a time; an ISDN type 413 terminal with several ports, each capable of several sessions; 414 or a mainframe computer with innumerable hardware and software 415 "ports", each capable of countless simultaneous sessions. 417 Whatever the configuration, a session within a host can be 419 uniquely identified by a "port" and "session" number. 421 A session-reference number identifies a session on the link 422 between a host and its parent Router. All messages sent or 423 received during a session will have the session-reference 424 number in the host/Router link header. The reference may be 425 supplemented by a sub-session number during multi-sessions. 427 The host relates the session-reference to the appropriate port 428 and session, the Router relates the host/session-reference to 429 the route and virtual-channel-number (VCN) that forms the next 430 link in the chain toward the distant end. 432 The session-reference number will be allocated by the host on 433 originating sessions or by the Router on terminating sessions. 435 A host passes control messages (OPEN/CLOSE) received from the 436 Internet to its control port. On hosts which deliver special- 437 services, this port will require a standard port number in 438 order to allow new version SERVICE-REQUEST messages to be 439 received via old version Internet equipment. (See 8.2.2.1.) 441 6.1.1. The host/Router link header. 443 The host/Router link header might appear as follows: 444 +-------------------------------+\ 445 |to host/Router|from host/Router|| 446 |Control flags|SESSION-REFERENCE|)Link Header 447 | Sub-session | TOTAL LENGTH || 448 +-------------------------------+/ 449 | MESSAGE | 450 | | 451 The control flags may be used as follows: 452 00 - ordinary message packet (new version), 453 10 - session control message (OPEN/CLOSE etc.) 454 01 - (not used) 455 11 - old version message packet (no session-reference) 457 6.2. The OPEN message. 459 To open a virtual-message-path through the Internet, a host 460 sends an OPEN message to its Internet Router. The message 461 contains the distant host's address and port number which are 462 derived from the Internet name and protocol indicator (ftp, 463 http, etc) specified by the user. 465 As new transport layer protocols are introduced, more than one 466 protocol indicator might indicate the same port (ftp, newftp). 467 The OPEN message will list the different protocols that are 468 available at the user end and the distant end will indicate 469 the chosen protocol in the OPEN_DONE message. 471 +--------------------+ 472 | VERSION | LENGTH | 473 | Function - OPEN | 474 |DISTANT_HOST_ADDRESS| 475 | PORT | 476 | User's protocols | 477 | (with "more" flag) | 478 | " | 479 | CHECKSUM | 480 +--------------------+ 482 TYPICAL OPEN MESSAGE 484 6.3. The message-path through the Internet. 486 6.3.1. VCN Allocation. 488 Each Router uses the distant-host-address in the OPEN message 489 to identify the route towards the destination and allocates a 490 VCN to identify the session on the link to the next Router. 491 The OPEN message is then passed on the control channel (VCN 492 0000?) to the next Router in a message packet carrying the 493 allocated VCN where the process will be repeated. 495 At the link level, an OPEN message being passed from Router to 496 Router might appear as follows: 498 +-----------------------------------------+ 499 + VIRTUAL CHANNEL 0000 (control channel) + 500 + TOTAL MESSAGE LENGTH + 501 +-----------------------------------------+ 502 | ALLOCATED VCN (changed by each Router) | 503 +-----------------------------------------+ 504 | OPEN MESSAGE | 505 | | 506 Messages received on a link's control channel (VCN 0000) will 507 be passed to the Router's session processer for attention. 509 To avoid VCN collisions, the Router at one end of a link may 510 allocate VCNs in the range 0001 - 7FFF while the Router at the 511 other end allocates 8000 - FFFF. (This assumes that VCN 0000 512 is used in both directions for control messages.) 514 To accommodate the existing and other network-layer protocols, 515 link implementation may find it convenient to allocate a 516 separate control VCN for each protocol. Messages received on 517 such VCNs will be passed directly to the appropriate handler. 519 6.3.2. Switching tables. 521 As sessions are opened and closed, Routers will update tables 522 which, for each incoming route (link) and VCN, will indicate 523 the corresponding outgoing route, VCN and message switching 524 priority. Each session will have two complimentary entries in 526 the tables; one for each direction of transmission. 528 For charging or traffic recording purposes, Routers will also 529 record which party established each session (which party is 530 paying). Whilst this information could be derived from the 531 session records, it may be convenient to have a flag in the 532 switching tables. 534 6.3.3. The OPEN_DONE message. 536 When the message-path is complete, the distant host will 537 return an OPEN_DONE message indicating the chosen protocol, 538 and the capacity and message switching priority to be reserved 539 in the network in both directions. 541 +----------------------------+ 542 | VERSION | LENGTH | 543 | Function - OPEN_DONE | 544 | CHOSEN PROTOCOL | 545 | Forward priority & capacity| 546 |Backward priority & capacity| 547 | CHECKSUM | 548 +----------------------------+ 550 TYPICAL OPEN_DONE MESSAGE 552 (1) (2) (1) 553 > OPEN > > OPEN > > OPEN > 554 >SESS-REFa> > VCNx > >SESS-REFb> 555 +-----+>to Host n>+------+>to Host n>+------+> to Host n>+------+ 556 |USER +-----------+ROUTER+-----------+ ROUTER+-----------+HOST n| 557 +-----+ (3) +------+ (3) +-------+ (3) +------+ 558 +ROUTER+ - - - ->- - - - +ROUTER+ ->+ 805 ^ +------+ +------+ v 806 (2b) | (3) | 807 SERVICE_REQUEST SERVICE_REQUEST 808 to Sorter | to Server| 809 ^ (4) (4) v 810 +----+ (1) >OPEN> +--+---+OPEN_SERVICE+------+OPEN_SERVICE+--+---+ 811 |USER+------->-------+ROUTER+------<-----+ROUTER+------<-----+SERVER| 812 +----+ - - path of SERVICE_REQUEST message 822 ---<--- virtual-message-path & direction of establishment 824 CREATING A SPECIAL-SERVICE MESSAGE-PATH 826 FIGURE 3. 828 +------+ 829 |SORTER| 830 (6) +-+--+-+ (6) 831 REQUEST_DONE v ^REQUEST_DONE 832 +-+--+-+ +------+ 833 +<- +ROUTER+ - - - -<- - - - +ROUTER+ -<+ 834 v +------+ REQUEST_DONE (6)+------+ ^ 835 (6) | | (6) 836 REQUEST_DONE REQUEST_DONE 837 | | 838 v ^ 839 +----+ +--+---+ +------+ +--+---+ 840 |USER+------------+ROUTER+------------+ROUTER+------------+SERVER| 841 +----+OPEN_DONE> +------+>OPEN_DONE> +------+ 842 to user (5b) to Server(5a) to Server(5a) 844 No. Message Refer to Text 845 (5a) OPEN_DONE to Server 7.2.2.1. 846 (5b) OPEN_DONE to User 7.2.2.2. 847 (6) REQUEST_DONE 7.2.4. 849 - - - - - - - - - - SERVICE_REQUEST message path 850 ----------------- established virtual-message-path 852 After receiving REQUEST_DONE the user's Router closes the 853 SERVICE_REQUEST message path 855 PATH-COMPLETE MESSAGES 857 FIGURE 4. 859 7.2.2.2. OPEN_DONE to the user. 861 The same OPEN_DONE message will be sent to the user but with 862 the forward and backward capacity and priority fields reversed 863 (the capacity and priority may be required by a LAN Gateway?) 865 The message tells the user which transport layer protocol will 866 be used for service delivery and overrides the default old 867 network protocol established by the SERVICE_ACK message. At 868 the end of the transport layer session, the user must revert 869 to the default. (See 7.1.1.) 871 7.2.3. Control message interface. 873 The user's Internet Router will be required to provide an 874 interface for subsequent control messages as both the user and 875 Server will consider themselves to be the session originator. 876 For charging purposes, the session must be considered to be 877 originated by the Server. 879 7.2.4. The REQUEST_DONE message. 881 Having received OPEN_DONE indicating that the message-path is 882 complete, the Server will return a REQUEST_DONE message to the 883 originating Router using the message-path created by the 884 SERVICE_REQUEST message; the Router will then CLOSE that path. 886 7.3. Delivering the service. 888 Using the established message-path, the Server will open a 889 transport layer session with the user to commence service 890 delivery. This will often involve interrogating the user to 891 further identify the service required after which the user may 892 be transferred to another Server. 894 7.4. Service Transfer. (See Figures 5 & 6, pages 20 & 21) 896 7.4.1. The TRANSFER_REQUEST message. 898 A Server transfers a user to another Server by closing the 899 transport layer session and sending a TRANSFER_REQUEST message 900 to the other Server. The TRANSFER_REQUEST message contains the 901 same information as the original SERVICE_REQUEST message, but 902 indicates that the existing message-path must be diverted. 904 The message will usually be addressed directly to the other 905 Server but may be addressed via a Sorter as before, in which 906 case the SPECIAL_SERVICE_ADDRESS field must be updated. 908 The message packet may include information for the new Server 909 obtained during the earlier session (regarding payment etc.). 910 All such information is of no consequence to the Internet. 912 The TRANSFER_REQUEST message will be forwarded to the new 913 Server and a message-path created to return the REQUEST_DONE 914 or FAILURE message. (Similar to a SERVICE_REQUEST message.) 916 7.4.2. The OPEN_TRANSFER message. 918 The new Server will use a OPEN_TRANSFER message to establish a 919 message-path via the Internet to the user. The message content 920 is the same as an OPEN_SERVICE message and is treated as an 921 ordinary OPEN message by all Routers except the final Router 922 that connects to the user or user's LAN. This Router uses the 923 SERVICE_DELIVERY_ADDRESS (and REFERENCE_NO. See 7.1.2.) to 924 find the session record, verify the USER'S NAME and complete 925 the virtual-message-path to the user. 927 7.4.3. OPEN_DONE and CLOSE_REQUEST messages. 929 Having completed the new message-path, the Router will send an 930 OPEN_DONE message to the new Server and to the user as before 931 (See 7.2.2) and will send a CLOSE_REQUEST message to the old 933 Server on the old message-path. (If the previous session used 934 old network procedure, no CLOSE_REQUEST message can be sent.) 936 The previous Server will CLOSE the old message-path when the 937 CLOSE_REQUEST message is received. (See also 8.2.4.3.) 939 Upon receiving the OPEN_DONE message, the user will cancel the 940 default situation (restored when the previous transport layer 941 session was closed. See 7.2.2.2) and await the opening of a 942 new transport layer session using the protocol indicated in 943 the OPEN_DONE message. 945 7.4.4. The REQUEST_DONE message. 947 When the new Server receives the OPEN_DONE message, it will 948 send REQUEST_DONE to the old Server on the TRANSFER_REQUEST 949 message-path and will commence service delivery. 951 After receiving REQUEST_DONE, the old Server will close the 952 TRANSFER_REQUEST message-path. 954 7.5. Subsequent transfers. 956 The session transfer activity may be repeated any number of 957 times. 959 +- -- -+ 960 SORTER 961 +- -- -+ 962 +------+ 963 |ROUTER+ -<- + 964 +---+--+ ^ 965 (1) | | (1) 966 TRANSFER_REQUEST| TRANSFER 967 v _REQUEST 968 +------+ (2) +--+---+ ^ 969 (2) +--+ROUTER+-------<--------+ NEW | | 970 OPEN_TRANSFER v +------+ OPEN_TRANSFER |SERVER| 971 +------+ | +------+ +--+---+ 972 +----+ | +-<--+ +------+ | OLD | 973 |USER+-------+ROUTER+/-/-/-/+ROUTER+/-/-/-/-/-/-/-/-/-/-/-/-/+SERVER| 974 +----+ +------+ +------+ +------+ 976 No. Message Refer to text 977 (1) TRANSFER_REQUEST 7.4.1. 978 (2) OPEN_TRANSFER 7.4.2. 980 - - ->- -path of TRANSFER_REQUEST message 981 -----<---new virtual-path & direction of establishment 982 -/-/-/-/-old virtual-path 984 INITIATING SERVICE TRANSFER 986 FIGURE 5. 988 +- -- -+ 989 SORTER 990 +------+ 991 |ROUTER+ - >+ 992 +--+---+ v 993 (5) ^ | 994 REQUEST_DONE| | (5) 995 ^ REQUEST 996 (3a) +------+ OPEN_DONE +--+---+ _DONE 997 OPEN_DONE +-+ROUTER+------->---+ NEW | | 998 to Server ^ +------+ to Server |SERVER| v 999 +------+ | +------+ +--+---+ 1000 +----+(3b) OPEN_DONE| +->-+ <(6) CLOSE< +------+ | OLD | 1001 |USER+------<-------+ROUTER+/-/-/-/-/-/-/-/-/-/+ROUTER+//-/-/+SERVER| 1002 +----+ to User +------+>(4) CLOSE_REQUEST>+------+ >(4)>+------+ 1004 No. Message Refer to text 1005 (3a) OPEN_DONE to Server 7.4.3. 1006 (3b) OPEN_DONE to User 7.4.3. 1007 (4) CLOSE_REQUEST 7.4.3. 1008 (5) REQUEST_DONE 7.4.4. 1009 (6) CLOSE 7.4.3. 1011 - - - - - path of TRANSFER_REQUEST message 1012 --------- new virtual-path 1013 -/-/-/-/- old virtual-path 1015 After receiving REQUEST_DONE the old Server closes the 1016 REQUEST message-path 1018 PATH-COMPLETE MESSAGES 1020 FIGURE 6. 1022 8. ACCOMMODATING EXISTING EQUIPMENT. 1024 To interwork with existing equipment, new version hosts and 1025 new version Routers must be able to handle the existing 1026 procedures and must be able to receive and send old version 1027 messages. Control flags indicate the presence of old version 1028 messages on host/Router links (See 6.1.1.); on links between 1029 Routers, old version messages use a special VCN. (See 6.3.1) 1031 8.1. A simple session in the unknown Internet. See Fig 7, p22) 1033 Although capable of old network procedures, new version hosts 1034 will never initiate old version sessions. Even when a session 1035 is known to involve old version equipment, a new version host 1036 will attempt to establish a virtual-message-path; ensuring as 1037 far as possible, the continuity of the session. (If only the 1038 distant host were old version equipment a virtual-message-path 1039 could be established right across the Internet.) 1041 8.1.1. The OPEN message. 1043 When a new version host sends an OPEN message into the 1044 Internet, a message-path will established to the distant host 1045 or to the point that the path meets old version equipment. 1047 If the path meets old version equipment, the Router at the 1048 interface to the old equipment completes the path to the old 1049 network route and returns OPEN_OLD to the originating end. 1051 8.1.2. The OPEN_OLD message. 1053 The OPEN_OLD message informs the user that the message-path is 1054 open but is not complete and that old network procedures must 1055 be used. The message includes a SOURCE_ADDRESS for use in the 1056 IP Headers; it identifies the interface Router and its active 1057 session-record. (An "option" achieves address economy by using 1058 an additional REFERENCE_NO field. See SERVICE_DELIVERY_ADDRESS 1059 in SERVICE_REQUEST messages. Section 7.1.2.) 1061 The OPEN_OLD message also indicates nominal capacities and 1062 priorities to be reserved by the Routers. 1064 +----------------------------+ 1065 | VERSION | LENGTH | 1066 | Function - OPEN_OLD | 1067 | Forward capacity & priority| 1068 |Backward capacity & priority| 1069 |SOURCE_ADDRESS (and REF.NO?)| 1070 | CHECKSUM | 1071 +----------------------------+ 1073 TYPICAL OPEN_OLD MESSAGE 1075 Once an interface to old version equipment has been provided, 1076 it is not possible to return to the new version procedures if 1077 later equipment has new version capability. 1079 (1) (1) 1080 > OPEN > > OPEN > 1081 > SESS._REFa > > VCNx > ( ) 1082 +----+> to HOSTn >+------+> to HOSTn >+------+ ( OLD ) 1083 |USER+--------------+ROUTER+------------+ROUTER+--( NETWORK ) 1084 +----+< SESS._REFa <+------+< VCNx <+------+ ( ) 1085 < OPEN_OLD < < OPEN_OLD < ( ) 1086 (2) (2) 1088 No. Refer to text 1089 (1) OPEN 8.1.1. ESTABLISHING AN INCOMPLETE MESSAGE-PATH 1090 (2) OPEN_OLD 8.1.2. FIGURE 7. 1092 (3) (3) 1093 | SESS._REFa | | VCNx | 1094 | TCP/IP | | TCP/IP | 1095 +----+| MESSAGES |+------+| MESSAGES |+------+ 1096 |USER+----->--<-----+ROUTER+---->--<----+ROUTER| 1097 +----+ +------+ +---+--+ 1098 | 1099 +--------->----<-----------+ 1100 | 1101 | 1102 | ( (4,5) ) (4,5) 1103 | ( | TCP/IP | ) | TCP/IP | 1104 | ( | MESSAGES | ) +------+ | MESSAGES | +-----+ 1105 +--(- - ->- -<- - - -)--+ROUTER+----->--<-----+HOSTn| 1106 ( ) +------+ +-----+ 1107 ( OLD ) 1108 ( NETWORK ) 1110 No. Refer to text 1111 (3) 8.1.3. 1112 (4) 8.1.3.1. 1113 (5) 8.1.3.2. 1115 USING AN INCOMPLETE MESSAGE-PATH 1117 FIGURE 8. 1119 8.1.3. Conducting the session. (See Figure 8) 1121 The user will send and receive messages with IP/TCP type 1122 headers on the established message-path. (i.e. With the 1123 link-header using the SESSION-REFERENCE and the control bits 1124 set to 00.) The DESTINATION_ADDRESS in the IP header will be 1125 the same as the distant-host-address in the OPEN message, the 1126 SOURCE_ADDRESS (and REFERENCE NO?) will be that provided in 1127 the OPEN_OLD message. 1129 8.1.3.1. Forward messages. 1131 Upon receiving forward messages from the user, the Router at 1132 the interface will pass the messages to the old network route. 1133 The messages will continue to their destination using old 1134 network procedures. 1136 8.1.3.2. Backward messages. 1138 Messages returned from the distant end will be addressed to 1139 the SOURCE_ADDRESS given in the forward messages, which (with 1140 an optional REFERENCE NO.?) identifies the interface Router 1141 and its session-record. 1143 Upon receiving the returned messages, the interface Router 1145 will find the session-record and return the messages, with 1146 headers, to the user on the established message-path. 1148 8.1.3.3. Closing the session. 1150 When the session ends, the originating host will CLOSE the 1151 message-path to the interface Router in the normal manner. 1153 8.2. A special-service session in the unknown Internet. 1155 8.2.1. Invoking the service. 1157 When a new version host attempts to OPEN a session with a 1158 special-service address, the Internet Router addresses a 1159 SERVICE_REQUEST message to the nearest Sorter which 1160 re-addresses the message to an appropriate Server. 1162 If an old version host attempts to gain access to such a 1163 service, the special-service address will appear in the 1164 DESTINATION_ADDRESS of an IP header. A variety of treatments 1165 are possible; but are not detailed in this document. 1167 8.2.2. SERVICE_REQUEST via old network. (See Figure 9, p 26) 1169 8.2.2.1. UDP/IP Header. 1171 If the message path from the Router via the Sorter to the 1172 chosen Server encounters old version equipment, the Router at 1173 the interface will prefix the SERVICE_REQUEST message with an 1174 IP/UDP Header and forward it via the old version equipment. 1176 For this purpose, new version Routers will have a ready-made 1177 IP/UDP Header. The Router will be required to complete the 1178 DESTINATION_ADDRESS, CHECKSUM and LENGTH fields each time the 1179 header is used. The ready-made header may also be used to 1180 forward TRANSFER_REQUEST messages. 1182 A Sorter will be required to accept IP/UDP messages only when 1183 old network equipment exists in the path between the Sorter 1184 and the Routers which it serves; or when SERVICE_REQUEST 1185 messages are received from Sorters in other networks or other 1186 countries (See 7.1. last para). Having received a request 1187 message using IP/UDP, the message should be forwarded to the 1188 Server in the same manner. 1190 The SERVICE_REQUEST message will be delivered using the IP/UDP 1191 protocol to the Server's control port (a standard port number 1192 on special-service equipment. See 6.1. last para.). 1194 8.2.2.2. The ACK_OLD message. 1196 Servers do not acknowledge SERVICE_REQUEST messages delivered 1197 by IP/UDP. Having forwarded the message, the interface Router 1199 will return ACK_OLD to the originating Router. 1201 The ACK_OLD message has no parameters. The originating Router 1202 will CLOSE the partly established REQUEST message-path (used 1203 only to return DONE or FAILURE messages from the Server) and 1204 await the commencement of service delivery; a time-out and 1205 escape procedure being available if no response arises. 1207 8.2.3. Service delivery via old network. (See Figure 10, p26) 1209 8.2.3.1. The OPEN_SERVICE message. 1211 Having received the SERVICE_REQUEST message (by whatever 1212 means), the Server will attempt to open a message-path to the 1213 user by sending a OPEN_SERVICE message into the Internet. 1215 If the message-path meets old version equipment, the Router at 1216 the interface to the old equipment will complete the path to 1217 the old network route and return OPEN_OLD to the Server. 1219 8.2.3.2. The OPEN_OLD message. (See 8.1.2. ) 1221 The OPEN_OLD message informs the Server that the message-path 1222 is not complete and that old network procedure must be used. 1224 The message gives nominal capacity and priority reservations 1225 and includes a SOURCE_ADDRESS to be used by the Server in the 1226 IP Headers. The address (including an optional REFERENCE_NO.) 1227 identifies the interface Router and its session-record. 1229 Upon receiving the OPEN_OLD message, the Server will return 1230 REQUEST_DONE to the request message source. (If the request 1231 message delivery had also encountered old-network equipment, 1232 it will not be possible to return a REQUEST_DONE message.) 1234 (1) (1) 1235 > SESS_REFa > > VCNx > 1236 > OPEN > >SVCE_REQ > 1237 +----+> to Svce n >+------+>to Sorter>+------+ 1238 |USER+-------------+ROUTER+-----------+ROUTER| 1239 +----+ (1) +------+ (3) +---+--+ 1240 < SESS_REFa < < VCNx < | 1241 ------)-+ROUTER+-------->------+SERVER| 1252 ( OLD ) +------+ +------+ 1253 ( NETWORK ) 1255 No. Refer to text 1256 (1) 7.1; 7.1.1; & 7.1.2. 1257 (2) 8.2.2.1. 1258 (3) 8.2.2.2. 1260 FIGURE 9. SENDING SERVICE_REQUEST VIA OLD NETWORK 1262 No. Refer to text 1263 (1) 8.2.3.1. ( ) 1264 (2) 8.2.3.2. ( ) 1265 +- -+ +- -- -+ ( ) 1266 |USER+ - - - - - - +ROUTER+ -( )------+ 1267 +- -+ +- -- -+ ( OLD ) | 1268 ( NETWORK ) | 1269 | 1270 +-------------------------------------+ 1271 | 1272 | (1) (1) 1273 | < VCNn < < SESS_REFx < 1274 | < OPEN_SVCE < < OPEN_SVCE < 1275 | +------+ < to User < +------+ < to User <+------+ 1276 +-+ROUTER+---------------+ROUTER+--------------+SERVER| 1277 +------+ (2) +------+ (2) +------+ 1278 > VCNn > > SESS_REFx > 1279 > OPEN_OLD > > OPEN_OLD > 1281 FIGURE 10. ESTABLISHING AN INCOMPLETE SERVICE-DELIVERY MESSAGE-PATH 1283 (1,2) 1284 | SESS_REFa| ( (1,2) ) 1285 | IP/TCP | ( | IP/TCP | ) 1286 +----+ | Messages |+------+ ( | Messages | ) 1287 |USER+---->----<---+ROUTER+--(---->----<-----)------+ 1288 +----+ +------+ ( OLD ) | 1289 ( NETWORK ) | 1290 | 1291 +-------------->---------<------------+ 1292 | 1293 | 1294 | (1,2) (1,2) 1295 | | VCNn | | SESS_REFx| 1296 | | TCP/IP | | TCP/IP | 1297 | +------+ | Messages | +------+ | Messages | +------+ 1298 +--+ROUTER+---->----<----+ROUTER+---->----<----+SERVER| 1299 +------+ +------+ +------+ 1301 No. Refer to text 1302 (1) 8.2.4.1. 1303 (2) 8.2.4.2. 1305 FIGURE 11. DELIVERING SERVICE VIA INCOMPLETE MESSAGE-PATH 1307 8.2.4. Conducting the session. (See Figure 11, above) 1309 8.2.4.1. Forward messages. 1311 The Server will commence service delivery using the part 1312 established message-path. (i.e. The link header will hold the 1313 session_reference number with the control bits set to 00.) 1315 Each message packet will have an old version IP/TCP header. 1316 The SOURCE_ADDRESS (and REFERENCE NO.?) in the header will be 1317 as received in the OPEN_OLD message, identifying the interface 1318 Router and its session-record. The DESTINATION_ADDRESS (and 1319 REFERENCE NO.?) will be the SERVICE_ DELIVERY_ADDRESS from the 1320 SERVICE/TRANSFER_REQUEST message, identifying the originating 1321 Router and its session-record. 1323 The interface Router passes messages received from the Server 1324 into the old network which forwards the messages to the 1325 originating Router as identified by the DESTINATION_ADDRESS. 1327 The originating Router recognises that the DESTINATION_ADDRESS 1328 in the forward messages is a SERVICE_DELIVERY_ADDRESS. It uses 1329 the address (and REFERENCE_NO?) to find the session-record and 1330 send the messages to the user on the established message-path, 1331 albeit only one link. (Link headers hold the session-reference 1332 number with the control bits set to 00.) 1334 The user will be in the default situation and will be 1336 expecting service delivery using old network protocols. The 1337 port and session to which the messages belong will be 1338 identified by the session-reference number in the link header; 1339 the IP Header in the forward messages will be used only for 1340 checksums and to provide the address for returned messages. 1342 8.2.4.2. Backward messages. 1344 To simplify the handling of backward messages, the originating 1345 Router may record in its switching table the route from which 1346 forward messages are received. The table must be updated each 1347 time a forward message is received as the route may change 1348 without notice if service delivery is transferred to a Server 1349 which also needs to use old network procedure. 1351 Messages returned to the Router from the user will have IP/TCP 1352 type headers and will use the established message-path (the 1353 link-header holding the session-reference and the control bits 1354 set to 00). The DESTINATION_ADDRESS will be the SOURCE_ADDRESS 1355 from the forward messages, which (with a REFERENCE NO.?) 1356 identifies the interface Router and its session-record. 1358 The Router processes the messages using old-network procedure. 1360 When the interface Router receives the messages it uses the 1361 DESTINATION_ADDRESS (and REF.NO?) to find the session-record 1362 and return the messages to the Server on the established 1363 message-path. 1365 8.2.4.3. Closing the previous message-path (if any). 1367 If the service delivery were the result of a service transfer, 1368 the originating Router's records would hold references to the 1369 path used for the earlier session. The records will be updated 1370 and a CLOSE_REQUEST message sent on the previous message-path. 1372 The previous Server will CLOSE the previous message-path when 1373 it receives the CLOSE_REQUEST message. 1375 If the previous session encountered old-network equipment, no 1376 CLOSE_REQUEST message could be sent. The previous Server would 1377 CLOSE the previous incomplete message-path after receiving 1378 REQUEST_DONE from the new Server; or after receiving ACK_OLD 1379 in response to its TRANSFER_REQUEST message indicating that 1380 REQUEST_DONE would not be received. 1382 8.2.5. Closing the session. 1384 When service-delivery is complete, the final Server will CLOSE 1385 the part established message-path in the normal manner. The 1386 user will CLOSE the host/Router link when no more transfers 1387 are expected. 1389 9. MULTI-SESSIONS 1391 A user may establish several simultaneous sub-sessions in the 1392 pursuit of a session. No special handling is required in the 1393 Internet as the user would be able to relate the different 1394 Internet sessions as being part of one master-session. 1396 A multi-session may also be formed by a special-service Server 1397 adding other Servers instead of transferring to other Servers; 1398 or by a mixture of user and Server created sub-sessions. 1400 A Server adds another Server by sending an ADD_REQUEST message 1401 to the new Server containing the same information that would 1402 be contained in a TRANSFER_REQUEST message. 1404 The new Server will establish a message-path to the user with 1405 an OPEN_ADD message containing the same information that would 1406 be contained in an OPEN_TRANSFER message. 1408 The user's Router will return an OPEN_DONE message to the new 1409 Server which will send REQUEST_DONE to the Server that 1410 initiated the ADD. 1412 The user's Router will also allocate a sub-session number 1413 before sending an ADD_DONE message to the user containing 1414 similar information to that contained in the OPEN_DONE 1415 message. (See 7.2.2.2.) 1417 Upon receiving the ADD_DONE message, the user's host will open 1418 a sub-session as indicated by the SESSION_REFERENCE and 1419 sub-session number in the link header. 1421 The ADD facility is dependant upon new version equipment. 1422 There is no means of separating the different sub-session 1423 windows if old version equipment is encountered. 1425 10. THE FUTURE INTERNET - CHARGING. 1427 10.1. Basic charges. 1429 Internet users will pay a fixed-fee to their Internet Provider 1430 and will probably pay an additional usage charge, each session 1431 being charged to the session originator. 1433 Session charges will depend upon the time that a session 1434 remains open (and upon the number and size of the messages 1435 carried?). Session charges should be sufficient to deter users 1436 from blocking network resources by keeping sessions open 1437 unnecessarily. 1439 10.2. Special-service charges. 1441 Sessions originated by Brokers or Servers in response to 1443 service or transfer request messages will be charged to the 1444 Broker or Server. Some Service Providers may choose to pay the 1445 session charges (like Freefone in the telephone network) while 1446 others may not only pass-on the session charges to the user 1447 but levy an additional charge for the actual service delivered 1448 (like Premium Rate services). 1450 10.3. Collecting Service Provider's charges. 1452 To deliver special-services, Brokers and Servers are given the 1453 USER'S INTERNET NAME. Most simply, the charge for the service 1454 should be collected from that name. 1456 Collecting service delivery charges on behalf of the Service 1457 Providers could be a very attractive and very profitable 1458 service provided by the Internet Operators. 1460 Recording the charges levied by Servers for service delivery 1461 will be the responsibility of the Service Providers, - not a 1462 problem for the Internet! (A Broker may elect to pay for a 1463 session between a Server and a user - then add commission 1464 before charging the user.) 1466 11. SECURITY. 1468 11.1. User identity verification. 1470 The user-friendliness and commercial security of this proposal 1471 are interdependant and lie in the fact that services are 1472 delivered directly to the user who has no knowledge of the 1473 service's source or the detail of its invocation. The Server 1474 is given the user's identity which is verified by the user's 1475 Internet Router from the session records. (See 7.2.1.) 1477 11.2. Breeching security. 1479 The commercial security of this proposition is in part 1480 attributable to the fact that services are delivered to a 1481 verifiable user name. 1483 This verification is not possible when services are delivered 1484 via old version equipment as the DESTINATION_ADDRESS in the IP 1485 header is an address which identifies a session-record and the 1486 user's identity is not included. 1488 Also, when message-paths are established via old version 1489 equipment, the user is given an address which identifies a 1490 session-record to use as the SOURCE_ADDRESS in IP headers. 1492 Having established a message-path via old version equipment, a 1493 knowledgeable and meddlesome user could extricate this number 1494 and use it to build SERVICE or TRANSFER_REQUEST messages with 1495 a bogus user-name. 1497 The user may also cheat the system when services are known to 1498 be delivered via old version equipment, by sending REQUEST 1499 messages to Servers containing a false user's name but with 1500 the true user's address in the SERVICE_DELIVERY_ADDRESS field. 1501 This method may not be so attractive to a dishonest user as it 1502 requires revealing the true address. 1504 Consequently, Servers must be aware that the user's identity 1505 cannot be verified when services are delivered via old network 1506 equipment. 1508 ********DOCUMENT EXPIRES MARCH 1997********** 1510 Authors' addresses 1512 P.J. Williams Ian Davies 1513 IN / R&S Central Engineering 1514 GPT Limited GPT Limited 1515 PO Box 53 PO Box 53 1516 New Century Park New Century Park 1517 Coventry CV3 1HJ Coventry CV3 1HJ 1518 UK UK 1520 Please note - Pip Williams (who did all the work!) is now a consultant 1521 to GPT and not usually available except on Wenesdays. He is not 1522 directly accessible by e-mail. Please address comments to Ian Davies 1523 (daviesic@ncp.gpt.co.uk) tel. +44 1203 562755 or fax +44 1203 562566.