OctetView
0x00000…00100 (0, 0, 0) Sector 00974b30303937 ┆ K0097K ┆
[…0x1…]
0x00200…00300 (0, 0, 2) Sector ff00ffffffe0ff ┆ ` | @ ┆
0x00300…00306 (0, 0, 3) WangDocument {d00=0x12, d01=0x64, d02=0x56, ptr=(32,0, 8), d05=0x00}
0x00306…0030c WangDocument {d00=0x12, d01=0x65, d02=0x56, ptr=(10,0, 0), d05=0x00}
0x0030c…00312 WangDocument {d00=0x12, d01=0x66, d02=0x56, ptr=( 8,0, 8), d05=0x00}
0x00312…00318 WangDocument {d00=0x20, d01=0x93, d02=0x41, ptr=(51,0, 8), d05=0x00}
0x00318…00320 00 00 00 00 00 00 00 00 ┆ ┆
0x00320…00340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ┆ ┆
[…0x5…]
0x003e0…00400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 ┆ ┆
0x00400…00500 (0, 0, 4) Sector 00000000000000 ┆ ┆
0x00500…00600 (0, 0, 5) Sector 86312020202020 ┆ 1 B 7 Q? > 7 Y, \ _ [ [ d d N ~<) 0uH &4'>( 1c5 & & ┆
0x00600…00700 (0, 0, 6) Sector 421c402600415b ┆B @& A[' 5 X% % PO P ; fVd- C g x g V WD O B :@- A! 1266V g L < {C < { ; 6 b b bD 3 K 9 : 8 t byyy X/Y(Y)Y-( I ┆
0x00700…00800 (0, 0, 7) Sector 00000000000000 ┆ ┆
0x00800…00900 (0, 0, 8) Sector 0009ff41126556 ┆ A eV1265V Rovsimg TCA683 TC 04 23 82 16 11 23 04 82 16 44 0097K 27 ' *J 7 k _┆
0x00900…00a00 (0, 0, 9) Sector 000a1b00126556 ┆ eV ┆
0x00a00…00b00 (0, 0, 10) Sector 000bff52126556 ┆ R eV 1 91 UNIVAC I/F Adaptor (UIA) as described in CSD/005/PSP/0053. The hardware meets the spe cifications of SP-2025 UNIVAC lll0 Procesor I/O interface. The Univa┆
0x00b00…00c00 (0, 0, 11) Sector 000cff2a126556 ┆ * eVc Channel Driver can be seen located between the Univac Link Manager (ULM) and the Univac I/F connected to the channel. The driver implements the SAI protocol to insure the data transmission. The driver permits to send and to receive data blocks ┆
0x00c00…00d00 (0, 0, 12) Sector 000dff69126556 ┆ i eVthrough the channel, and also to manage the Read-Write operations coming from the ULM. The ULM informs the driver by means of system messages from the I/O system. The Univac I/F sends interrupts indicating an I/O operator done on the channel. * ┆
0x00d00…00e00 (0, 0, 13) Sector 000eff95126556 ┆ eVTo control the data transmission and to present the loss of data, several queues are implemented. One serves the Receive and Read side of the driver. The Sub Port Data Units (SPDU|s) coming from the channel enter a list until they all form a single ┆
0x00e00…00f00 (0, 0, 14) Sector 000fff3a126556 ┆ : eVPort Data Unit (PDU). Then, this PDU becomes ready to be read (read command) by the ULM. On the other side, the driver controls the Send and Write operation. PDU|s are received from the ULM. They are separated into SPDU|s and placed in a queue re┆
0x00f00…01000 (0, 0, 15) Sector 0100af21126556 ┆ /! eVady to enter a special queue called "window". The window controls the number of messages sent, but not yet acknowledged. This process prevents a loss of data. 2.R=7! 6 CN7 E xOE MH{*sfMM e> I!`?r+s+p+q!a?6 !t 6 *]?e*_?DM M?72-?~ B┆
0x01000…01100 (1, 0, 0) WangDocumentBody
[…0x1a…]
0x02b00…02c00 (2, 0, 11) Sector 020cff33126556 ┆ 3 eVtwork of DCP/40's, an NMS-logical subchannel and systems session is implemented. The termination point of the NMS-session is the HAS, where a number of tables are kept and updated to fulfil the needs of status-information from any terminal or host ┆
0x02c00…02d00 (2, 0, 12) Sector 020d2833126556 ┆ (3 eVwith valid access-rights. he TIP port CSU-PROCESS,TIPCSU logical port nbr matches lsch in Telcon SESSN stmt. PORT,ACDEMAND LPN,2 ; . The DEMAND port CSU-PROCESS,RSDSCU . PORT,ACBATCH LPN,3 ┆
0x02d00…02e00 (2, 0, 13) Sector 020eff52126556 ┆ R eV 1 Future Extension Possibilities The future extension possibilities of the interface between the ACNC and the UNIVAC ll00/xx- host may be grouped in three main categories. o exte┆
0x02e00…02f00 (2, 0, 14) Sector 020fff52126556 ┆ R eVnsion of existing functions already provided, o extensions based upon new releases from UNIVAC that support new enhanced functions, o extensions based upon implementation of new services in the ACNC. Extension of Existing Function In this gro┆
0x02f00…03000 (2, 0, 15) Sector 0200ff52126556 ┆ R eVup the UNIVAC interface could be extended at the PFC-level to support the class 6 protocol. On the NMS-side the functionality of the ACNC could be to support a mapping of all possible NCC-information on their equivalent NMS- tables residing in the H┆
0x03000…03100 (3, 0, 0) WangDocumentBody
[…0x57…]
0x08800…08900 (8, 0, 8) WangDocumentHead {hdr=WangSectHead {next=( 8,0, 9), len=0xff, h3=41126656}, f00=»1266V «, f01=»Rovsing «, f02=»TCA684 «, f03=»TC «, f04=» «, f05=04-23-82 16:33, f06=» «, f07=»00 «, f08=» 6 «, f09=24-04-82 15:31, f10=» «, f11=»32 «, f12=» 1971 «, f13=23-04-82 18:34, f14=06-08-82 13:50, f15=»0097K «, f16=» 7 «, f17=» «, f18=»32 «, f19=» 156 «, f20=» 1977 «, f21=» «, f22=» «, f99=020010000110062710130301aa0af6040000000000000037033000df}
0x08900…08a00 (8, 0, 9) WangDocumentBody
[…0xc…]
0x09600…09700 (9, 0, 6) Sector 0907ff52126656 ┆ R fVlt of octel header information codes. The DMF performs the following functions: - Data flow control on a system session basis. - Dynamic establishment of system sessions. - Close-down of system session. - End-to-end assurance of data delivery┆
0x09700…09800 (9, 0, 7) Sector 08082852126656 ┆ (R fV - System session status check. 2:^=~ B<2:b= R<2M/,:g=~ BG2M")M2&! "(=~~ BW2I! <6 M /M?.I*:="8=IM2&MP'Mc2! m"2< [MI !?=6 : #wI>K!8=>R 2!8=6 #4 E*8=k L<M% :8=F 28=I!#<:"<>R<2> I E*#<& "< DM L<M% :#<F 2#<> I:g= Ro2M/2 Rl2> IC13!?=4~~ B|2> I:A=!┆
0x09800…09900 (9, 0, 8) WangDocumentBody
[…0x7…]
0x0a000…0a100 (10, 0, 0) WangDocumentHead {hdr=WangSectHead {next=(10,0, 1), len=0xff, h3=41126556}, f00=»1265V «, f01=»Rovsing «, f02=»TCA683 «, f03=»TC «, f04=» «, f05=04-23-82 16:11, f06=» «, f07=»01 «, f08=» 15 «, f09=27-04-82 20:57, f10=» «, f11=»09 «, f12=» 65 «, f13=27-04-82 10:35, f14=06-08-82 13:49, f15=»0097K «, f16=» 22 «, f17=» 2 «, f18=»42 «, f19=» 268 «, f20=» 3477 «, f21=» «, f22=» «, f99=020010000110056610110180aaca15050000000000000037035b00df}
0x0a100…0a200 (10, 0, 1) WangDocumentBody
[…0x28…]
0x0ca00…0cb00 (12, 0, 10) Sector 0c0bffdd126456 ┆ ] dV 1 89 ******************** This chapter contains a description of the UNIVAC hos┆
0x0cb00…0cc00 (12, 0, 11) Sector 0c0cff00126456 ┆ dVt interface implementated in ACNC. The basis for the description is the chapters of DCA, CMSll00 and Telcon. Thus the description may be brief, as emphasis is put upon the differences between the concept (DCA), the implementations (CMSll00 and Telco┆
0x0cc00…0cd00 (12, 0, 12) Sector 0c0dffc2126456 ┆ B dVn 3RlB) as described by UNIVAC, and the implementation. The following items will be described: o Sub Architectural Interface (SAI) - channel - trunk (UDLC) o Termination System (TS) - Line Port Multiplexor (LPM) - Port Flow TS/TN Contro┆
0x0cd00…0ce00 (12, 0, 13) Sector 0c0eff3f126456 ┆ ? dVl (PFC) - Data Unit Control (DUC) - Remote Trunk Control (RTC) - Trunk Control (TC) - Communications System User (CSU) - Emulators -- RB2/NTR -- RB2/3780 -- INTl/TTY -- INTl/3270 *** ********************** The channel to the U┆
0x0ce00…0cf00 (12, 0, 14) Sector 0c0f5033126456 ┆ P3 dVNIVAC ll00/xx host is based upon the CR8037D UNIVAC I/F as described in Remote Trunk Control (RTC) o Trunk Control (TC) *** *************************************** The word-channel host interface line module (word-channel line module)┆
0x0cf00…0d000 (12, 0, 15) Sector 0c00ffa1126456 ┆ ! dV 1 90 CSD/005/PSP//052 and CR8079D ┆
0x0d000…0d100 (13, 0, 0) WangDocumentBody
[…0x137…]
0x20800…20900 (32, 0, 8) WangDocumentHead {hdr=WangSectHead {next=(32,0, 9), len=0xff, h3=41126456}, f00=»1264V «, f01=»Rovsing «, f02=»TCA682 «, f03=»TC «, f04=» «, f05=04-23-82 14:44, f06=» «, f07=»01 «, f08=» 6 «, f09=25-06-82 21:31, f10=» «, f11=»04 «, f12=» 200 «, f13=28-04-82 03:35, f14=06-08-82 13:48, f15=»0097K «, f16=» 74 «, f17=» 14 «, f18=»47 «, f19=» 984 «, f20=» 20642 «, f21=» «, f22=» «, f99=021059000110066610110480aaca15050000000000000037034201df}
0x20900…20a00 (32, 0, 9) WangDocumentBody
[…0x12e…]
0x33800…33900 (51, 0, 8) WangDocumentHead {hdr=WangSectHead {next=(51,0, 9), len=0xff, h3=41209341}, f00=»2093A «, f01=»AIR CANADA PROPOSAL «, f02=»ut «, f03=»MEC «, f04=»D III Ch.6.5,6.8-12. «, f05=27-04-82 14:41, f06=» «, f07=»11 «, f08=» 310 «, f09=29-04-82 11:14, f10=» «, f11=»05 «, f12=» 68 «, f13=28-04-82 02:52, f14=05-08-82 19:00, f15=»0097K «, f16=» 64 «, f17=» «, f18=»19 «, f19=» 1104 «, f20=» 431 «, f21=» «, f22=» @ «, f99=643032000110056610110180aaca15050000000000000042035601df}
0x33900…33a00 (51, 0, 9) WangDocumentBody
[…0x6…]
0x34000…34100 (52, 0, 0) Sector 3401ff00209341 ┆4 AE will automatically "echo" the datagram back to the user - the Datagram Text of the echo-datagram is shorten to the first ten bytes of the original datagram. It is expected that the source-user will have enough information within the echo-datagram-┆
0x34100…34200 (52, 0, 1) Sector 3402ff00209341 ┆4 Atext to recognize the returned echo-datagram as being the delivery confirmation on a particular datagram sent previously. DGS will provide eight priority levels. The designated priority is noted in the packet header to ensure that all transit node┆
0x34200…34300 (52, 0, 2) Sector 3403ff00209341 ┆4 As will respect the priority level of the datagram. The priority assigned to a datagram affects the order in which it is transmitted and also the order in which it is processed in the individual nodes. However, the algorithms employed ensure that the┆
0x34300…34400 (52, 0, 3) Sector 3404f500209341 ┆4 u A low priorty traffic does not get completely blocked. DGS provides a test mode services. When in this mode, all datagarams are marked with a user provided mode-indicator. The interpretation and special processing is in the users domain. PORT-NO is┆
0x34400…34500 (52, 0, 4) Sector 3405ff00209341 ┆4 A 1 6.5.2.2.1 Addressing Structure The transport network of CRNET provides a number of Transport Access Ports (TAP) through which the network users can communicate with one another. T┆
0x34500…34600 (52, 0, 5) Sector 3406ff00209341 ┆4 Ahe addressing form reflects the heirarchical structure of the topology. Figure III 6.5.2.2.1-1 illustrate the various address formats used. 1) CC-format: This format is the normal address format used to identify another C-NET user who is known ┆
0x34600…34700 (52, 0, 6) Sector 3407ff00209341 ┆4 Ato be attached to a specific TAP. 2) CN-format: This is an optional address format used by a C-NET user to identify another C-NET user, who is known by a generic name but his specific address (TAP) is unknown to the source user. The format does no┆
0x34700…34800 (52, 0, 7) Sector 3308ff00209341 ┆3 At limit the size of this generic name - however, it is not expected to be greater than 8 bytes. 3) X-format: This is the normal format used by a C-NET user to identify a X-NET user. This format is similar to the CC-format, but has less addressing ┆
0x34800…34900 (52, 0, 8) Sector 3409ff00209341 ┆4 A 1 The Virtual Transport Connection (VTC) service provides enhanced stream oriented services again based on the underlining datagram technology. This provides a means for trasporting ┆
0x34900…34a00 (52, 0, 9) Sector 340a3c00209341 ┆4 < Abulk data. Figure III 6.5.2.1-1 illustrates this. 6.5.1.1 Session-Conversation Management 6.5.1.1.1. Session-Conversation Establishment The purpose of the session-conversation establishment phase is to tie two Session Service ┆
0x34a00…34b00 (52, 0, 10) Sector 340ba000209341 ┆4 A 1 Figure III 6.5.2.1-1 DTrE Structure uest for session-conversation from another SSU, which it can accept, reject or negotiate - be┆
0x34b00…34c00 (52, 0, 11) Sector 340cff00209341 ┆4 A 1 6.5.2.2 Datagram Services (DGS) This service provides a one-to-one mapping on the underlining datagram implementation of the DTrE. The information entities exchanged within the ┆
0x34c00…34d00 (52, 0, 12) Sector 340dff00209341 ┆4 Anetwork are datagrams. A datagram is a data structure of a defined maximum size consisting of a Datagram Header (DH) and Datagram Text (DT). The datagram header contains the source and destination addresses of the datagram. The datagram text is the ┆
0x34d00…34e00 (52, 0, 13) Sector 340eff00209341 ┆4 Aactual data to be transported through the network. This textual data is transparent to the datagram service. The DGS only accepts data in the form of Datagram Texts. Because of the limited size of the datagrams, the service user is expected to spl┆
0x34e00…34f00 (52, 0, 14) Sector 340fff00209341 ┆4 Ait longer data structures into a number of DTs. For ACDN a maximum size of 512 bytes for a DT is suggested. This maximum size will enable the ACDN to transport the majority of its transactions in a single datagram. The DGS provides a fast but not ┆
0x34f00…35000 (52, 0, 15) Sector 3400ff00209341 ┆4 Acompletely reliable service. If for some reason the datagram cannot be delivered the transport network will destroy them. An option is provided whereby the user may request the delivery confirmation of the datagram. In this case, the destination DTr┆
0x35000…35100 (53, 0, 0) Sector 3501ff00209341 ┆5 A 1 6.5.1.1.3 Session-Conversation Termination This allows the SSU to terminate the conversation without loss of data. Either SSU may at any time request the forced termination of the┆
0x35100…35200 (53, 0, 1) Sector 3502ff00209341 ┆5 A conversation, in which case data may be lost. The CUE, optionally, gatheres charging data which is forwarded to the NSE on termination of a conversation. 6.5.2 Data Transmission Environment This environment provides standard interfaces and ┆
0x35200…35300 (53, 0, 2) Sector 3503ff00209341 ┆5 Aservices which form the basic transport facilities in the ACDN. The Transport Service Users (TSU) get access to this facilities by acquiring a Transport Access Port (TAP). The request for a TAP is processed by the Network Services Environment. Onc┆
0x35300…35400 (53, 0, 3) Sector 3504ff00209341 ┆5 Ae a TSU has acquired a TAP, it can communicate with other TSUs and vice versa. Chapter 6.5.2.2.1 expands on the addressing aspects. Notice that TSUs may be identified either explicitly or implicitly in the addressing structure. When a C-PORT-NO is┆
0x35400…35500 (53, 0, 4) Sector 3505ff00209341 ┆5 A used the TSU is identified implicitly via the TAP corresponding to the C-PORT-NO. When the generic name of the TSU is used, the NSE at the destination is requested to identify the TSU. If the explicitly named TSU is known to the destination system ┆
0x35500…35600 (53, 0, 5) Sector 3506ff00209341 ┆5 A(confirmed by directory-lookup), then it, or an incarnation of it, is activated and informed of the incoming information. The activated TSU will then respond to the incoming indication of a session-conversation by contacting the CUE. 6.5.2.1 DTrE┆
0x35600…35700 (53, 0, 6) Sector 3507ff00209341 ┆5 A Services The underlining mechanism by which DTrE communicates is based on datagram technology. The higher level software is provided with basically two types of services. The Datagram Service (DGS) is based directly on the underlining datagram ┆
0x35700…35800 (53, 0, 7) Sector 34085f00209341 ┆4 _ Atechnology. This provides a vechicle to base higher level transaction oriented services. al terminals. The session-conversations are built on the services provided by the Data Transmission Environment. 2#<> I:g= Ro2M/2 Rl2> IC13!?=4~~ B|2> I:A=!┆
0x35800…35900 (53, 0, 8) Sector 3509a800209341 ┆5 ( A 1 Figure III 6.5-1 Communication Environment !f=6 !g=6 !h=6 Ml+M;) RE3C#4: 2i=:g=~ JV3C/4!"<6 #6 MB&! =6 !,<6 :]=2'< AMD MB&!,<6 ! ┆
0x35900…35a00 (53, 0, 9) Sector 350aff00209341 ┆5 A 1 6.5.1.1 Session-Conversation Management 6.5.1.1.1. Session-Conversation Establishment The purpose of the session-conversation establishment phase is to tie two Session Service ┆
0x35a00…35b00 (53, 0, 10) Sector 350bff00209341 ┆5 AUsers (SSU) into a cooperative relationship. To do this the CUE includes the means to: - request a session-conversation to another SSU - receive a request for session-conversation from another SSU, which it can accept, reject or negotiate - be┆
0x35b00…35c00 (53, 0, 11) Sector 350cff00209341 ┆5 A notified of the session-conversation establishment or the rejection of the request - enable the two SSUs cooperatively to determine the values of the session-conversation parameters. These parameters determine: - type of service (stream or d┆
0x35c00…35d00 (53, 0, 12) Sector 350dff00209341 ┆5 Aatagram) - grade of service (reliability, priority etc.) - throughput (blocksize, degree of flow control) 6.5.1.1.2 Session-Conversation Data Transfer This phase of the interaction serves for a controlled exchange of data during the lifetime ┆
0x35d00…35e00 (53, 0, 13) Sector 350eff00209341 ┆5 Aof the conversation. Local flow control is provided by CUE so as not to overload the transport network. This is done by limiting the size of the outbound queue for each conversation. When CUE detects that the queue length for a particular conversa┆
0x35e00…35f00 (53, 0, 14) Sector 350fff00209341 ┆5 Ation exceeds a predetermined number, it indicates this to the Session Service User. The latter is expected to limit the generated output if the ordely exchange is to be maintained. Other services for recovering from a possible failures are provide┆
0x35f00…36000 (53, 0, 15) Sector 35001400209341 ┆5 Ad on request. ┆
0x36000…36100 (54, 0, 0) WangDocumentHead {hdr=WangSectHead {next=(54,0, 1), len=0xff, h3=41209341}, f00=»2093A «, f01=»AIR CANADA PROPOSAL «, f02=»ut «, f03=»MEC «, f04=»DOC III Chap 6.5,... «, f05=27-04-82 14:41, f06=» «, f07=»11 «, f08=» 310 «, f09=29-04-82 11:14, f10=» «, f11=»00 «, f12=» 2 «, f13=28-04-82 02:52, f14=29-04-82 16:26, f15=»0097K «, f16=» 64 «, f17=» «, f18=»14 «, f19=» 1256 «, f20=» 365 «, f21=» «, f22=» @ «, f99=643032000110056610110180aaca15050000000000000042035601df}
0x36100…36200 (54, 0, 1) Sector 36024000209341 ┆6 @ A 6 6 5 5 5 4 4 4 4 3 3 3 3 3 3 3 2 2 1 1 1 0 0 / / / / / / . . - - , , + + + + + * * ) ) ( ( ( ' ' ' & & % % % $ $ # # # " " ! ! ! p/]r: Forfatter: Kommentarer: STATISTIK AKTIVITET DATO TID ANV.TID ANSLAG Oprettet / / : : ┆
0x36200…36300 (54, 0, 2) Sector 3603fb00209341 ┆6 { A 1 CHAPTER 6 Page # DOCUMENT III TECHNICAL PROPOSAL Apr. 29, 1982 .=M2┆
0x36300…36400 (54, 0, 3) Sector 3604ff00209341 ┆6 A 1 6.5 Nodal Switch Software The ACON software is built using layered concepts. The NSS constitutes the lowest three environments: CUE, DTrE and DLE. Each "horizontal" layer consists┆
0x36400…36500 (54, 0, 4) Sector 3605ff00209341 ┆6 A of software schedulable tasks which provide similar services. The packaging of these tasks is done by "vertical" partitioning such that a group of tasks providing the total NSS capability can be included in in functional CR80-processes. In the fo┆
0x36500…36600 (54, 0, 5) Sector 3606ff00209341 ┆6 Allowing description, we concentrate on the functions of the NSS without regard to its packaging. Figure 6.5-1 illustrates this environment. 6.5.1 Communication User Environment (CUE) This environment is primarily concerned with providing an orde┆
0x36600…36700 (54, 0, 6) Sector 3607ff00209341 ┆6 Arly data exchange between two entities in the higher level software. This orderly exchange is provided by establishing session-conversations. This environment is not concerned with the idiosynchrocies of the individual user. The Network Interface ┆
0x36700…36800 (54, 0, 7) Sector 3508d300209341 ┆5 S AEnvironment handles these by providing emulator functions or with implementation of virtual terminals. The session-conversations are built on the services provided by the Data Transmission Environment. 2#<> I:g= Ro2M/2 Rl2> IC13!?=4~~ B|2> I:A=!┆
0x36800…36900 (54, 0, 8) Sector 00000000000000 ┆ ┆
[…0x167…]
