|
DataMuseum.dkPresents historical artifacts from the history of: RegneCentralen RC850 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RegneCentralen RC850 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 64128 (0xfa80)
Types: RcTekst
Names: »VIL1.WP«
└─⟦51ec6abc5⟧ Bits:30005985 Manualer - TELETEX Document Handler
└─⟦this⟧ »VIL1.WP«
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆┆b0┆6.╞ DH PROTOCOL MACHINE↲
↲
╞ ┆84┆The purpose of this chapter is to give a precise definition of the ↓
┆19┆┆89┆┄┄function of the DH, i.e. how it reacts on incoming events from ↓
┆19┆┆89┆┄┄TTXSI and S62CP. A close knowledge of ref. 3 and ref. 4 is nec┄↓
┆19┆┆89┆┄┄cessary for reading this chapter.↲
↲
╞ ┆84┆The description is done by presenting a number of figures con┄↓
┆19┆┆89┆┄┄taining a state diagram. The normal notation used is:↲
↲
╞ ╞ state╞ ╞ state↲
╞ ╞ ╞ or↲
↲
↲
↲
╞ ╞ event╞ event/action↲
↲
↲
↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ╞ new╞ ╞ new↲
╞ ╞ state╞ ╞ state↲
↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆It has, however, sometimes been found convenient to use the nota┄↓
┆19┆┆89┆┄┄tion:↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
╞ ╞ state╞ event╞ action╞ new↲
╞ ╞ ╞ ╞ ╞ state↲
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆A number of times other kinds of "private" notation will be used, ↓
┆19┆┆89┆┄┄but the meaning should (hopefully) be clear from the context.↲
↲
╞ ┆84┆The events and actions in the diagrams will be listed in the ↓
┆19┆┆89┆┄┄various sections, together with a possible abbreviation and a ↓
┆19┆┆89┆┄┄short explanation. To get a full description of the events and ↓
┆19┆┆89┆┄┄actions which are messages to or from other modules, one must ↓
┆19┆┆89┆┄┄refer to ref. 3 and ref. 4.↲
↲
╞ ┆84┆The protocol machine for sessions and packets will be shown in ↓
┆19┆┆89┆┄┄several diagrams because of the great number of states. Because ↓
┆8c┆┆83┆┆d8┆↓
┆19┆┆89┆┄┄there will be state transitions between the diagrams, the fol┄↓
┆19┆┆89┆┄┄lowing is done:↲
↲
╞ ┆84┆A figure can have one or more entry points, notated like this for ↓
┆19┆┆89┆┄┄fig. x.↲
↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
┆81┆╞ ╞ xa╞ ╞ xb↲
↲
↲
↲
↲
╞ state╞ state↲
╞ to enter╞ to enter↲
╞ for entry╞ for entry↲
╞ ╞ xa╞ ╞ xb↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆When one of these entry points , f.ex. xa, is used from another ↓
┆19┆┆89┆┄┄figure, it is shown like this:↲
↲
╞ ----> xa↲
↲
╞ ┆84┆To save space on the figures, only the events and actions im┄↓
┆19┆┆89┆┄┄portant for the state transitions are shown.↲
↲
╞ ┆84┆To cover all possibilities a table is added to each figure. The ↓
┆19┆┆89┆┄┄table has the following format:↲
↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ┆a1┆state ! event ! action ! new state ↲
╞ ! ! !↲
╞ state name ! event name ! action(s) ! new state notation↲
┆a1┆ ! ! !╞ ╞ ↲
↲
╞ -╞ -╞ -╞ -↲
╞ -╞ -╞ -╞ -↲
╞ -╞ - - -↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆"new state notation" stands for either a state name (if the tran┄↓
┆19┆┆89┆┄┄sition is inside the same figure) or an entry point on another ↓
┆19┆┆89┆┄┄figure.↲
↲
╞ ┆84┆If a state-event pair dos not occur on the figures or in the ↓
┆19┆┆89┆┄┄tables, it means that it is either impossible or a DS protocol ↓
┆19┆┆89┆┄┄error.↲
↲
┆8c┆┆83┆┆cc┆↓
╞ ┆84┆Finally a number of footnotes are given to the figures explaining ↓
┆19┆┆89┆┄┄things too complicated to show in the diagrams.↲
↲
╞ ┆84┆The aim of this description is not to give an implementation des┄↓
┆19┆┆89┆┄┄cription, i.e. data formats and buffer handling are not described.↲
↲
╞ ┆84┆It has, however, been necessary to bypass this principle concer┄↓
┆19┆┆89┆┄┄ning the content of TU, packet and session descriptions. Certain ↓
┆19┆┆89┆┄┄of the fields in these are important for the protocol machine, and ↓
┆19┆┆89┆┄┄certain flags are introduced to avoid that the number of states ↓
┆19┆┆89┆┄┄becomes excessive.↲
↲
╞ ┆84┆Also regarding buffer handling, there is some rules concerning ↓
┆19┆┆89┆┄┄buffer clean up against S62CP and TTXSI (document streams). It ↓
┆19┆┆89┆┄┄should be made certain that these rules can be obeyed.↲
↲
↲
┆a1┆┆b0┆6.1╞ TU Handling↲
↲
╞ ┆84┆This section describes the handling of TU's. The state diagram is ↓
┆19┆┆89┆┄┄showed in fig. 12. and in fig. 13.↲
↲
╞ ┆84┆To administer the TU handling, the DH has a number of ┆a1┆TU de┄┆a1┆crip┄↓
┆19┆┆89┆┄┆84┆tions┆e1┆. They contain a state variable and other fields, including ↓
┆19┆┆89┆┄┄the follwing two:↓
↲
╞ number of sessions : ┆84┆number of alive sessions. A session is ↓
┆19┆┆a3┆┄┄regarded as alive as long as the session ↓
┆19┆┆a3┆┄┄cleans up procedure against S62CP is not ↓
┆19┆┆a3┆┄┄totally performed.↲
↲
╞ number of sink sessions : ┆84┆number of sessions where it is possible ↓
┆19┆┆a3┆┄┄that a sink packet can be received + ↓
┆19┆┆a3┆┄┄number of alive sink packets.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆6.1.1╞ TU Events↲
↲
╞ ┆84┆Here is listed the events to the TU protocol machine.↲
↲
╞ DS events:↲
╞ - ┆84┆REQUEST.ACTIVATE, abr REQ.ACT↲
╞ ┆84┆Request for an activation of the TU.↲
↲
╞ - REQUEST.REMOVE, abr REQ.REM↲
╞ ┆84┆A request for a removal of a TU.↲
↲
╞ - REQUEST.DISABLE, abr. REQ.DISA↲
╞ The TU is requested disabled.↲
↲
╞ - REQUEST.ENABLE, abr. REQ.ENA↲
╞ The TU is requested enabled.↲
↲
╞ - REQUEST.REDEFINE, abr. REQ.REDEF↲
╞ ┆84┆A request for redefinition of the TU attributes.↲
↲
╞ - REQUEST.SUSPEND, abr. REQ.SUSP↲
╞ ┆84┆A request for suspension of the TU. This is in fact not a DS, ↓
┆19┆┆8c┆┄┄but a TTXSI event.↲
↲
╞ - REQUEST.RESUME, abr. REQ.RESUME↲
╞ Regrets a suspension of the TU.↲
↲
╞ S62CP events:↲
╞ - answ DEACT TI↲
╞ ┆84┆Answer to a DEACT TI message. The TU is removed at S62CP.↲
↲
╞ - answ SUSP TI↲
╞ ┆84┆Answer to a SUSP TI message. The TU is suspended at S62CP. ↲
↲
╞ Special events:↲
╞ - all sess removed↲
╞ ┆84┆Number of sessions has became zero. This indicates that a DEACT ↓
┆19┆┆8c┆┄┄TI, a REDEF TI or a SUSP TI can be sent to S62CP.↲
┆8c┆┆83┆┆c8┆↓
╞ - ┆84┆no sink sess↲
╞ ┆84┆Indicates that number of sink sessions has became zero. A dis┄↓
┆19┆┆8c┆┄┄abling of the TU can be performed. Note that this event always ↓
┆19┆┆8c┆┄┄occurs before a possible "all sess removed" event.↲
↲
↲
┆a1┆┆b0┆6.1.2╞ TU Actions↲
↲
╞ ┆84┆Here the actions performed are listed:↲
↲
╞ DS actions:↲
╞ - CONFIRMATION.ACTIVATE, abr CONF.ACT↲
╞ ┆84┆Response on a REQ.ACT. Result indicates success or failure.↲
↲
╞ - CONFIRMATION.REMOVE, abr CONF.REM↲
╞ ┆84┆Response on a REQ.REM. Result indicates success or failure.↲
↲
╞ - CONFIRMATION.DISABLE, abr CONF.DISA↲
╞ ┆84┆Indicates, if result=ok, that a disable procedure is carried ↓
┆19┆┆8c┆┄┄through (all sessions terminated). If result=not_proc, the ↓
┆19┆┆8c┆┄┄disabling has been terminated by a new REQ.DISA or a REQ.ENA.↲
↲
╞ - CONFIRMATION.REDEFINE, abr CONF.REDEF↲
╞ Response on a REQ.REDEF. Result tells about success or failure.↲
↲
╞ - CONFIRMATION.SUSPEND, abr CONF.SUSP↲
╞ Inform the TTXSI that the TU is suspended.↲
↲
╞ S62CP actions:↲
╞ - ACTIVATE TI, abr ACT TI↲
╞ ┆84┆Requests S62CP to activate a TI. Hard waiting is performed on ↓
┆19┆┆8c┆┄┄the answer, therefore no "answ ACT TI" event exists.↲
↲
╞ - DEACTIVATE TI, abr DEACT TI↲
╞ ┆84┆Requests S62CP to remove a TU.↲
↲
╞ - REDEFINE TI, abr REDEF TI↲
╞ ┆84┆Requests a redefinition of the TU attributes at S62CP. Hard ↓
┆19┆┆8c┆┄┄waiting is performed on the answer.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ - SUSPEND TI, abr SUSP TI↲
╞ Requests a suspension of the TU at S62CP.↲
↲
╞ - RESUME TI↲
╞ ┆84┆Regrets a suspension. Hard waiting is performed on the answer.↲
↲
╞ Special actions:↲
╞ - TU clean up↲
╞ ┆84┆Performed when a deactivate or a suspend procedure is started ↓
┆19┆┆8c┆┄┄for this TU. The event "TU removed" is generated in all ↓
┆19┆┆8c┆┄┄sessions and all packets for this TU. This will force the ↓
┆19┆┆8c┆┄┄sessions to be ter┄minated as fast as possible.↲
↲
↲
┆b0┆┆a1┆6.1.3╞ TU Protocol Machine↲
↲
╞ This section describes the two figures:↲
↲
╞ fig. 12: TU activation/ removal↲
↲
╞ fig. 13: TU disabling and redefining↲
↲
↲
┆a1┆┆b0┆6.1.3.1 TU activation/ removal.↲
↲
╞ ┆84┆This section describes fig. 12. It shows states concerning ↓
┆19┆┆89┆┄┄activation, removal and suspension.↲
↲
╞ ┆84┆It has the entry points:↲
↲
╞ 12a: REQ.REM received↲
↲
╞ 12b: REQ.SUSP received↲
↲
╞ 12c: return to active state↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ Fig. 12. TU activation and removal.↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
╞ ╞ TU idle↲
╞ ╞ REQ.ACT↲
↲
╞ ╞ ACT.TU↲
╞ CONF.ACT result=busy *1)↲
╞ result=busy↲
╞ ╞ ╞ ╞ ╞ result=ok↲
╞ ╞ result=dupl_fct↲
↲
╞ ╞ ╞ ╞ ╞ CONF.ACT↲
╞ CONF.ACT╞ ╞ ╞ result=ok↲
╞ result=dupl_fct↲
↲
↲
answ DEACT TI/CONF.REM↲
╞ result=ok╞ ╞ ↲
╞ ╞ ╞ ╞ answ SUSP TI/CONF.SUSP↲
↲
↲
↲
╞ ╞ ╞ suspending↲
╞ ╞ ╞ *4)↲
↲
↲
↲
REQ.REM↲
╞ removing╞ ╞ /DEACT TI╞ suspended↲
╞ *4)╞ ╞ ╞ ╞ ╞ ↲
╞ ╞ ╞ all sess↲
╞ ╞ ╞ removed/SUSP TI↲
↲
╞ ╞ ╞ ╞ ╞ REQ.RESUME/RESUME TI↲
╞ ╞ *3)↲
╞ wait↲
╞ ╞ ╞ suspend↲
↲
all sess/DEACT TI↲
removed↲
↲
↲
↲
╞ ╞ REQ.SUSP/TU clean up╞ REQ.DISA╞ 13a↲
↲
↲
╞ wait╞ ╞ ╞ active╞ ╞ ↲
╞ remove╞ ╞ ╞ *2)↲
╞ *3)↲
↲
╞ ╞ REQ.REM/TU clean up╞ REQ.REDEF 13b↲
↲
╞ 12a 12b╞ ╞ ╞ 12c↲
════════════════════════════════════════════════════════════════════════
↓
╞ Table 12↲
↲
╞ ┆a1┆state╞ ╞ event╞ action╞ ╞ new state↲
╞ ╞ ! ! !↲
╞ TU idle╞ ! REQ.REM ! CONF.REM ! -↲
╞ ╞ !╞ !╞ result=unknown rec !↲
┆a1┆┆e1┆ ┆a1┆ ! ! !╞ ↲
! ! !↲
╞ active ! all ! - ! -↲
╞ ╞ ! sess !╞ ╞ !↲
╞ ╞ ! removed ! !↲
┆a1┆ ! ! ! ↲
╞ ╞ ! !╞ ╞ !↲
╞ wait remove ! REQ.SUSP! -╞ ! -↲
╞ ┆a1┆╞ ! !╞ ╞ ! ↲
╞ ╞ ! !╞ ╞ !↲
╞ removing╞ ! REQ.SUSP!╞ -╞ ! -↲
╞ ┆a1┆╞ !╞ !╞ ╞ ! ↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ Fig. 12, footnotes.↲
↲
╞ *1)╞ ┆84┆Because hard waiting is performed this action delivers a ↓
┆19┆┆93┆┄┄result upon which the state transition depends.↲
↲
╞ ╞ ┆84┆The result format_err is an indication that the DS has ↓
┆19┆┆93┆┄┄made a protocol error.↲
↲
╞ *2)╞ ┆84┆Sessions can be activated and packets can exist.↲
↲
╞ *3)╞ ┆84┆If there is no session for this TU, an "all sess re┄↓
┆19┆┆93┆┄┄moved" event is simulated. All incoming SESS START IND ↓
┆19┆┆93┆┄┄messages are in this state kept pending in DH.↲
↲
╞ *4)╞ ┆84┆All incoming SESS START IND messages are answered with ↓
┆19┆┆93┆┄┄the result "not_proc".↓
↲
↲
↲
┆8c┆┆83┆┄↓
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
┆0e┆↓
┆a1┆┆b0┆6.1.3.2 Disabling and redefining.↲
↲
╞ ┆84┆This section describes fig. 13. It contains states for disabling ↓
┆19┆┆89┆┄┄and redefining of a TU. These states can be regarded as substates ↓
┆19┆┆89┆┄┄of the "active" state. Fig. 13 has two entry points:↲
↲
╞ 13a: A REQ.DISA has been received.↲
↲
╞ 13b: A REQ.REDEF has been received.↲
┆0f┆↓
════════════════════════════════════════════════════════════════════════
↓
╞ Fig. 13. disabling and redefining.↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
╞ ╞ 13a╞ ╞ ╞ ╞ 13b↲
↲
╞ ╞ *1)╞ ╞ ╞ *1)↲
╞ ╞ ╞ ╞ REQ.DISA↲
↲
╞ ╞ ╞ ╞ wait↲
╞ disabling REQ.REDEF╞ disable╞ wait redef↲
╞ *5)╞ ╞ redef╞ ╞ *3)↲
╞ ╞ ╞ ╞ *5)↲
↲
╞ REQ.ENA CONF.DISA↲
╞ result=not proc╞ ╞ REQ.ENA CONF.DISA↲
╞ ╞ ╞ ╞ ╞ result=not_proc↲
╞ 12c↲
↲
╞ ╞ no sink CONF.DISA↲
╞ ╞ sess result=ok╞ ╞ all sess↲
╞ ╞ ╞ ╞ ╞ removed↲
↲
↲
↲
↲
↲
↲
↲
╞ ╞ disabled↲
╞ ╞ *2)↲
↲
╞ ╞ REQ.ENA╞ ↲
↲
╞ 12c↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Table 13.↲
↲
↲
╞ ┆a1┆ state╞ ! event╞ ! action╞ ╞ ! new state↲
╞ ╞ !╞ ╞ !╞ ╞ !↲
╞ disabling╞ ! REQ.REM╞ ! TU clean up╞ ! 12a↲
╞ & disabled !╞ ╞ !╞ ╞ !↲
╞ & wait redef !╞ ╞ !╞ ╞ !↲
╞ & wait disable !╞ ╞ !╞ ╞ !↲
redef ! ! !↲
┆a1┆┆e1┆& disable redef !╞ ╞ !╞ ╞ !╞ ↲
╞ ┆a1┆ ! ! ! ↲
╞ !╞ ╞ !╞ ╞ !↲
╞ disabling ! REQ.DISA╞ ! CONF.DISA╞ ! -↲
╞ & wait disable !╞ *4)╞ ! result=not_proc╞ !↲
redef ! ! !↲
┆a1┆┆e1┆& disable redef !╞ ╞ !╞ ╞ !╞ ↲
┆a1┆┆e1┆& disabled ! ! ! ↲
┆a1┆ ! ! ! ↲
╞ ╞ !╞ ╞ !╞ ╞ !↲
╞ wait redef ! REQ.REDEF╞ ! CONF.REDEF╞ !↲
╞ & wait disable !╞ ╞ ! result=not_proc╞ !↲
redef ! ! !↲
& disable redef ! ! !↲
╞ ┆a1┆╞ !╞ ╞ !╞ ╞ !╞ ↲
╞ ╞ !╞ ╞ !╞ ╞ !↲
╞ disabling ! REQ.SUSP╞ ! TU clean up╞ ! 12b↲
╞ & disabled !╞ ╞ !╞ ╞ !↲
╞ & wait redef !╞ ╞ !╞ ╞ !↲
╞ & wait disable !╞ ╞ !╞ ╞ !↲
redef ! ! !↲
╞ ┆a1┆┆e1┆& disable redef !╞ ╞ !╞ ╞ !╞ ↲
┆a1┆ ! ! ! ↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ fig 13, footnotes↲
↲
╞ *1) ┆84┆The text message in REQ.DISA is saved in the TU description.↲
↲
╞ *2) ┆84┆All incoming SESS START IND messages are answered with SESS ↓
┆19┆┆8d┆┄┄START RESP NEG, containing the saved text message. Number of ↓
┆19┆┆8d┆┄┄sink sessions will remain zero in this state.↲
↲
╞ *3) ┆84┆If number of sessions = 0, an all sess removed event is ↓
┆19┆┆8d┆┄┄simulated.↲
╞ ↲
╞ *4) ┆84┆The text message is saved in the TU description, overwriting ↓
┆19┆┆8d┆┄┄the old one.↲
↲
↲
┆8c┆┆83┆┆c8┆↓
┆0e┆↓
┆a1┆┆b0┆6.2╞ Sessions and Packets, Design Considerations↲
↲
╞ ┆84┆When packet communication is in progress the DH will communicate ↓
┆19┆┆89┆┄┄with its surroundings by means of the following entities:↲
↲
╞ 1)╞ ┆84┆Packets. Known by DH and DS, and identified by DS packet ↓
┆19┆┆93┆┄┄no and CU packet no.↲
↲
╞ ╞ ┆84┆They are initiated by REQ.SUBMIT, REQ.REGRET or ↓
┆19┆┆93┆┄┄IND.CREATE and are terminated by CONF.SUBMIT ↓
┆19┆┆93┆┄┄CONF.REGRET, CONF.┄ABORT, IND.DELIVER, or an IND.CANCEL.↲
┆0f┆↓
↲
╞ 2)╞ ┆84┆Document streams. Known by DH and TTXSI (DS) and ident┄↓
┆19┆┆93┆┄┄ified by the u3 buffer attribute.↲
↲
╞ ╞ ┆84┆They are initiated by DH sending a TRANSFER block with ↓
┆19┆┆93┆┄┄Mode = r (read operations) or = w (write operations). ↓
┆19┆┆93┆┄┄Termination begins with a DH stream close from DH and is ↓
┆19┆┆93┆┄┄ended by TTXSI returning it.↲
↲
╞ 3)╞ ┆84┆Sessions. Known by DH and S62CP. Initiated by either a ↓
┆19┆┆93┆┄┄SESSION START IND or a SESSION START REQ. Termination ↓
┆19┆┆93┆┄┄begins with a SESSION CLEARING IND from S62CP and is ↓
┆19┆┆93┆┄┄ended by DH sending a SESSION CLEARING RESP and S62CP ↓
┆19┆┆93┆┄┄answering it.↲
↲
╞ ┆84┆A packet and a session is said to be inside the document level ↓
┆19┆┆89┆┄┄when a DOC START REQ or a DOC CONT REQ has been sent, or a DOC ↓
┆19┆┆89┆┄┄START IND or a DOC CONT IND has been received. They leave the ↓
┆19┆┆89┆┄┄document level when a DOCUMENT END CONF or a DOCUMENT RESYNCH/┄↓
┆19┆┆89┆┄┄DISCARD CONF has been received, or a DOCUMENT END RESP or a DO┄↓
┆19┆┆89┆┄┄CUMENT RESYNCH/DISCARD RESP has been sent.↲
↲
╞ ┆84┆When they are inside the document level session, packets and ↓
┆19┆┆89┆┄┄document streams will of course be closely connected.↲
↲
╞ ┆84┆The problem is how independent they should be otherwise. The fol┄↓
┆19┆┆89┆┄┄lowing problems arises:↲
↲
┆8c┆┆83┆┆d4┆↓
╞ 1)╞ ┆84┆A packet must not be terminated before any document ↓
┆19┆┆93┆┄┄stream used by that packet is fully terminated.↲
↲
╞ ╞ ┆84┆This implies that the packet cannot run independent of ↓
┆19┆┆93┆┄┄the document stream.↲
↲
╞ 2)╞ ┆84┆When a session breaks down while document transmission ↓
┆19┆┆93┆┄┄is in progress there is the following problem concerning ↓
┆19┆┆93┆┄┄buffer clean up:↲
╞ ╞ ┆84┆The STREAM buffers from the document stream can be pend┄↓
┆19┆┆93┆┄┄ing as DATA REQ buffers, and CHECKPOINT buffers as PAGE ↓
┆19┆┆93┆┄┄END REQ buffers. These buffers are not home for certain ↓
┆19┆┆93┆┄┄before the STREAM CLEAR RESP message has been answered ↓
┆19┆┆93┆┄┄by S62CP (see fig. 14).↲
↲
╞ ╞ ┆84┆The closing of the document stream cannot be properly ↓
┆19┆┆93┆┄┄terminated before all these buffers are home. Sessions ↓
┆19┆┆93┆┄┄and document streams are closely connected in this case.↲
════════════════════════════════════════════════════════════════════════
↓
╞ Fig. 14. Session clean up by document transmission.↲
↲
↲
╞ ╞ TTXSI╞ ╞ DH╞ ╞ S62CP↲
↲
╞ ╞ STREAM(1) ↲
╞ ╞ ╞ ╞ DATA REQ(1)↲
↲
╞ ╞ STREAM(2) ↲
╞ ╞ ╞ ╞ DATA REQ(2)↲
↲
↲
╞ ╞ ╞ ╞ ╞ ╞ Session ↲
╞ ╞ ┆a1┆╞ ╞ ╞ ┆e1┆┆a1┆╞ ┆e1┆> break↲
╞ ╞ ╞ ╞ ╞ ╞ down↲
↲
╞ ╞ ╞ ╞ STREAM CLEAR IND↲
↲
↲
↲
↲
╞ ╞ ╞ ╞ STREAM CLEAR RESP↲
↲
↲
↲
↲
╞ ╞ ╞ ╞ answer↲
╞ ╞ ╞ ╞ STREAM CLEAR RESP↲
↲
↲
╞ ╞ ╞ document stream↲
╞ ╞ ╞ can be terminated↲
↲
↲
↲
╞ ╞ The doted lines indicate answers.↓
↲
════════════════════════════════════════════════════════════════════════
↓
╞ 3)╞ ┆84┆When a session breaks down while document receival is in ↓
┆19┆┆93┆┄┄progress the following problem arises:↲
╞ ╞ ┆84┆The DATA IND buffers will be pending at TTXSI as STREAM ↓
┆19┆┆93┆┄┄buffers and the PAGE END IND buffers as CHECKPOINT buf┄↓
┆19┆┆93┆┄┄fers. The session clean up cannot be properly terminated ↓
┆19┆┆93┆┄┄(a STREAM CLEARING RESP sent) before the DH stream close ↓
┆19┆┆93┆┄┄has been answered by TTXSI (see fig. 15.) Document ↓
┆19┆┆93┆┄┄streams and sessions are also in this case closely con┄↓
┆19┆┆93┆┄┄nected.↲
↲
↲
╞ fig. 15. Session clean up by document receival↲
↲
╞ ╞ TTXSI╞ ╞ DH╞ ╞ S62CP↲
↲
↲
╞ ╞ ╞ ╞ DATA IND(1)↲
╞ ╞ STREAM(1)↲
↲
↲
↲
╞ ╞ ╞ ╞ DATA IND(2)↲
╞ ╞ STREAM(2)↲
↲
╞ ╞ ╞ ╞ ╞ ╞ session↲
╞ ╞ ┆a1┆╞ ╞ ╞ ╞ ┆e1┆> break↲
╞ ╞ ╞ ╞ ╞ ╞ down↲
↲
╞ ╞ DH stream close↲
↲
↲
↲
╞ ╞ ╞ STREAM CLEARING RESP↲
╞ ╞ ╞ can be sent↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ 4)╞ ┆84┆The resource handling is easier when there is at most ↓
┆19┆┆93┆┄┄one data stream per session (the maximum number of docu┄↓
┆19┆┆93┆┄┄ment streams equals the maximum number of sessions). ↓
┆19┆┆93┆┄┄This is accomplished by delaying a session removal until ↓
┆19┆┆93┆┄┄a do┄cument stream, which has used the session, is fully ↓
┆19┆┆93┆┄┄terminated.↲
↲
╞ ┆84┆For these reasons it has been decided not to handle document ↓
┆19┆┆89┆┄┄streams independently from packets and sessions, i.e. they are not ↓
┆19┆┆89┆┄┄given their own protocol machine.↲
↲
╞ ┆84┆However, session and packet are still separate entities, because ↓
┆19┆┆89┆┄┄several packets can use a session. This is especially the case in ↓
┆19┆┆89┆┄┄sink states, where the session cannot be said to belong to any ↓
┆19┆┆89┆┄┄packet when it is outside document level.↲
↲
╞ ┆84┆Therefore the following decisions have been made:↲
↲
╞ a)╞ ┆84┆Packets and sessions are regarded as separate entities, ↓
┆19┆┆93┆┄┄each having their own protocol machine. They are, how┄↓
┆19┆┆93┆┄┄ever, guided by the same protocol machine when the docu┄↓
┆19┆┆93┆┄┄ment level is entered and a document stream is opened. ↓
┆19┆┆93┆┄┄In this case they are said to be ┆a1┆connected.↲
↲
╞ b)╞ ┆84┆They loses the connection with each other, are said to ↓
┆19┆┆93┆┄┄be ┆84┆disconnected┆e1┆, in the following cases:↲
↲
╞ ╞ - ┆84┆The document level has been left and the document ↓
┆19┆┆96┆┄┄stream has been closed.↲
↲
╞ ╞ - ┆84┆The session breaks down (ABORT IND or ABORT REQ). The ↓
┆19┆┆96┆┄┄disconnection is only made when it is certain that ↓
┆19┆┆96┆┄┄all involved buffers are home.↲
↲
╞ ┆84┆This scheme cannot be followed in case of TLX service and packet ↓
┆19┆┆89┆┄┄transmitted with charge request. In these cases packets and sessions ↓
┆19┆┆89┆┄┄are connected almost to the end.↲
↲
┆8c┆┆83┆┆c8┆↓
┆0e┆↓
╞ ┆84┆In section 6.3 the session protocol machine is described. Section ↓
┆19┆┆89┆┄┄6.4 contains the handling of packet source states (SUBMIT,REGRET ↓
┆19┆┆89┆┄┄or ABORT), and section 6.5 packet sink states (DELIVER or CANCEL).↲
┆0f┆↓
↲
↲
┆a1┆┆b0┆6.3╞ Session Handling↲
↲
╞ ┆84┆In this section the session handling is specified. A session is ↓
┆19┆┆89┆┄┄either initiated by DH with a SESSION START REQ (a SUBMIT or a ↓
┆19┆┆89┆┄┄REGRET packet is in need for a session) or initiated by S62CP by a ↓
┆19┆┆89┆┄┄SESSION START IND. A session be┄longs to a specific TU.↲
↲
↲
┆b0┆┆a1┆6.3.1╞ Handling of Session Descriptions↲
↲
╞ ┆84┆A session is described by a ┆a1┆session description┆e1┆. The number of ↓
┆19┆┆89┆┄┄sessions which can be alive at the same time are equal to the ↓
┆19┆┆89┆┄┄number of session descriptions.↲
↲
╞ ┆84┆The session descriptions are devided into two pools:↲
↲
╞ 1)╞ ┆84┆Network pool.↲
╞ ╞ ┆84┆These sessions are used for connections against the ↓
┆19┆┆93┆┄┄network, i.e. sessions which via DTE connections com┄↓
┆19┆┆93┆┄┄municate with another entity in the network.↲
↲
╞ ╞ ┆84┆The number of descriptions in this pool is limited by ↓
┆19┆┆93┆┄┄the "no_of_net_conns" process parameter (see section ↓
┆19┆┆93┆┄┄8.5). This number should be equal to the possible number ↓
┆19┆┆93┆┄┄of DTE connections.↲
↲
╞ 2)╞ int_loop_pool.↲
╞ ╞ ┆84┆These sessions are used for internal loops in the CU. ↓
┆19┆┆93┆┄┄The number of session descriptions in the pool equals↲
╞ ╞ ┆84┆max_sess_nu - no_of_net_conns, where "max_sess_nu" is a ↓
┆19┆┆93┆┄┄process parameter. ↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆Whether a session belongs to int_loop_pool is decided in the fol┄↓
┆19┆┆89┆┄┄lowing way:↲
↲
╞ - ┆84┆Outgoing calls: part1 and part2 in the addressee_ti parameter ↓
┆19┆┆8c┆┄┄to SESSION START REQ equals the "cu_na" process parameter.↲
↲
╞ - ┆84┆Incoming calls: part1 and part2 of the calling_ti parameter in ↓
┆19┆┆8c┆┄┄SESSION START IND equals cu_na.↲
↲
╞ ┆84┆It should be noted that max_sess_nu should equal the number of ↓
┆19┆┆89┆┄┄sessions possible in S62CP.↲
↲
↲
┆a1┆┆b0┆6.3.2╞ Content of a Session Description↲
↲
╞ ┆84┆The following fields in a session description are important to the ↓
┆19┆┆89┆┄┄protocol machine:↲
↲
╞ caller : ┆84┆A boolean. = true if the session was initiated by ↓
┆19┆┆9a┆┄┄SESSION START REQ.↲
↲
╞ charge_inf_req : ┆84┆If caller = true, the charge_inf_req parameter. ↓
┆19┆┆9a┆┄┄Otherwise false.↲
↲
╞ change req : ┆84┆a boolean. =true if a PLEASE CHANGE CONTROL IND ↓
┆19┆┆9a┆┄┄has been received, and the request can be ↓
┆19┆┆9a┆┄┄granted.↲
↲
╞ service : ┆84┆TTX or TLX. The service used for the packet which ↓
┆19┆┆9a┆┄┄last used the session.↲
↲
reserved : ┆84┆A boolean = true if a memory reservation has been ↓
┆19┆┆9a┆┄┄performed by this session.↲
↲
╞ called_ti : ┆84┆The corresponding parameter from SESSION START ↓
┆19┆┆9a┆┄┄CONF POS or SESSION START IND.↲
↲
╞ calling_ti : ┆84┆As above.↲
↲
┆8c┆┆83┆┆d4┆↓
╞ add_s_ref : ┆84┆As above. These three parameters are used to con┄↓
┆19┆┆9a┆┄┄struct document identifications.↲
↲
↲
┆a1┆┆b0┆6.3.3╞ Session Events↲
↲
╞ ┆84┆In this section is listed the events to the session protocol ↓
┆19┆┆89┆┄┄machine. Only those which can occur when the session is not ↓
┆19┆┆89┆┄┄connected to a packet is mentioned, however. This excludes ↓
┆19┆┆89┆┄┄document level events.↲
↲
╞ Session events from S62CP:↲
↲
╞ - ┆84┆SESSION START IND, abr. SESS START IND ↲
╞ Remote session call.↲
↲
╞ - ┆84┆SESSION START CONF POS, abr. SESS START CONF POS↲
╞ Positive response to a SESS START REQ.↲
↲
╞ - SESSION START CONF NEG, abr. SESSION START CONF NEG↲
╞ Negative response to a SESS START REQ.↲
↲
╞ - SESSION ABORT IND, abr. SESS ABORT IND↲
╞ Abnormal session break down.↲
↲
╞ - SESSION END IND, abr. SESS END IND↲
╞ ┆84┆Normal session termination, requested from the remote party.↲
↲
┆19┆┆8c┆┄┄Will be ignored by the session protocol machine, because it is ↓
┆19┆┆8c┆┄┄only interesting when a packet is connected in TLX service ↓
┆19┆┆8c┆┄┄mode. ╞ ↲
↲
╞ - PLEASE CHANGE CONTROL IND, abr. PL CH CONTR IND↲
╞ ┆84┆Remote request for change in source/sink relationship.↲
↲
╞ - CHANGE CONTROL IND, abr. CH CONTR IND↲
╞ This side becomes source.↲
════════════════════════════════════════════════════════════════════════
↓
╞ - MEMORY RESERVATION IND, abr. MEM RES IND↲
╞ ┆84┆An amount of memory should be reserved in sink mode.↲
↲
╞ - DOCUMENT START INDICATION, abr. DOC START IND↲
╞ A new document is received. A packet should be created.↲
↲
- ┆84┆DOCUMENT CONTINUE INDICATION, abr. DOC CONT IND↲
┆84┆A continuation of an already partly received document.↲
↲
╞ - CHARGE INF IND, abr. CHARGE IND↲
╞ ┆84┆delivers charge information requested when the call is made.↲
↲
╞ - STREAM CLEARING IND, abr. STREAM CLEAR IND↲
╞ ┆84┆Request from S62CP for start of session clean up procedure.↲
↲
╞ - answ STREAM CLEARING RESP, abr. answ STREAM CLEAR RESP╞ ↲
╞ ┆84┆Answer on a STREAM CLEAR RESP, indicating that the session ↓
┆19┆┆8c┆┄┄clean up is terminated.↲
↲
╞ Events from DS:↲
↲
╞ - CONF.RESERVE, abr. CONF.RES↲
╞ ┆84┆Response on an IND.RES. The memory reservation protocol is a ↓
┆19┆┆8c┆┄┄part of the session protocol machine, because reservation is ↓
┆19┆┆8c┆┄┄done for sessions, not for packets.↲
↲
╞ Special events:↲
↲
╞ - sess allocated↲
╞ ┆84┆This event starts the session handling as caller. A packet, the ↓
┆19┆┆8c┆┄┄initiator, has allocated this session.↲
↲
╞ - sess connected.↲
╞ ┆84┆Posiltive response from a packet on a cont arrived action (see ↓
┆19┆┆8c┆┄┄below). The continuation occured in a legal state (for the ↓
┆19┆┆8c┆┄┄packet), and the packet has performed the action connect sess.↲
════════════════════════════════════════════════════════════════════════
↓
╞ - reject call.↲
╞ ┆84┆Negative reaction on a cont arrived. The packet has performed┄ a ↓
┆19┆┆8c┆┄┄"reset call" action, because the continuation occured in an ↓
┆19┆┆8c┆┄┄illegal state.↲
↲
╞ - turn req.↲
╞ ┆84┆Occurs in sink mode, and indicates that a submit/regret packet ↓
┆19┆┆8c┆┄┄can use the session, provided source/sink relationship is ↓
┆19┆┆8c┆┄┄changed.↲
↲
╞ - doc level exit.↲
╞ ┆84┆Indicates that a connected packet has left the document level ↓
┆19┆┆8c┆┄┄in an orderly manner, and that the packet now is disconnected ↓
┆19┆┆8c┆┄┄from the session. A new packet can be transmitted/received by ↓
┆19┆┆8c┆┄┄means of this session. By normal TTX service this possibility ↓
┆19┆┆8c┆┄┄is used as far as possible.↲
↲
╞ - start sess clear.↲
╞ ┆84┆Indicates that session termination has been requested by a con┄↓
┆19┆┆8c┆┄┄nected packet (f.ex. by SESS END REQ), but SESS CLEAR IND has ↓
┆19┆┆8c┆┄┄not yet been received. No buffers from TTXSI/DH will be pending ↓
┆19┆┆8c┆┄┄at S62CP, and no S62CP buffers are pending at DH/TTXSI. Normal ↓
┆19┆┆8c┆┄┄exit from packet submission with charge request, and ↓
┆19┆┆8c┆┄┄submission┄/receival by TLX service.↲
↲
╞ - term sess.↲
╞ ┆84┆A connected packet has terminated the session completely and is ↓
┆19┆┆8c┆┄┄now disconnected from the session. Normal exit by session break ↓
┆19┆┆8c┆┄┄down inside document level (see section 6.2).↲
↲
╞ - TU removed.↲
╞ ┆84┆A TU removal/suspension procedure is started (the TU has ↓
┆19┆┆8c┆┄┄performed a TU clean up action). The session should be removed ↓
┆19┆┆8c┆┄┄as soon as possible (the memory reservation protocol is ↓
┆19┆┆8c┆┄┄terminated).↲
↲
↲
┆8c┆┆83┆┆bc┆↓
┆b0┆┆a1┆6.3.4╞ Session Actions↲
↲
╞ ┆84┆Here the actions performed by the session protocol machine are ↓
┆19┆┆89┆┄┄listed.↲
↲
╞ Actions against S62CP.↲
↲
╞ - SESSION START REQ, abr. SESS START REQ↲
╞ ┆84┆Request for session establishment from this side.↲
↲
╞ - SESSION START RESP POS, abr. SESS START RESP POS↲
╞ Positive response to a SESS START IND↲
↲
╞ - PLEASE CHANGE CONTROL REQ, abr. PL CH CONTR REQ↲
╞ Request for a change in source/sink relationship.↲
↲
╞ - CHANGE CONTROL REQ, abr. CH CONTR REQ↲
╞ The other side becomes source.↲
↲
╞ - SESSION END REQ, abr. SESS END REQ↲
╞ Request for normal session termination.↲
↲
╞ - SESSION ABORT REQ, abr. SESS ABORT REQ↲
╞ Request for an abnormal session termination.↲
↲
╞ - STREAM CLEARING RESP, abr. STREAM CLEAR RESP↲
╞ Last DH message on a session.↲
↲
╞ - MEMORY RESERVATION RESP, abr. MEM RES RESP↲
╞ Response to MEM RES IND.↲
↲
┆0e┆↓
╞ Actions against DH:↲
↲
╞ - IND.RESERVE, abr. IND.RES↲
╞ Request for a reservation of an amount of memory.↲
┆0f┆↓
↲
╞ - IND.RELEASE↲
╞ Releases a reserved memory pool.↲
↲
↲
┆8c┆┆83┆┆e0┆↓
╞ Special actions:↲
↲
╞ - ┆84┆cont arrived↲
╞ ┆84┆Signals to a packet that a DOC CONT IND, referring to this ↓
┆19┆┆8c┆┄┄packet, has arrived.↲
↲
↲
┆a1┆┆b0┆6.3.5╞ Session Protocol Machine↲
↲
╞ ┆84┆This section describes the following 4 figures:↲
↲
╞ Fig. 16 : Session handling, source states.↲
╞ ╞ ┆84┆Handles session initialization as caller and document ↓
┆19┆┆93┆┄┄source states.↲
↲
╞ Fig. 17 :╞ Session handling, reservation.↲
╞ ╞ ┆84┆Handles receival of session calls and memory reserva┄↓
┆19┆┆93┆┄┄tion.↲
↲
╞ Fig. 18 : Session sink handling.↲
╞ ╞ ┆84┆Handles document sink states.↲
↲
╞ Fig. 19 :╞ Session termination.↲
╞ ╞ Handles session clean up.↲
↲
↲
┆8c┆┆82┆┆b8┆↓
┆0e┆↓
┆a1┆┆b0┆6.3.5.1╞ Session Handling, Source States↲
↲
╞ ┆84┆This section describes the protocol machine shown in fig. 16. It ↓
┆19┆┆89┆┄┄handles states in document source mode.↲
↲
╞ Fig. 16 has the following entry points:↲
↲
╞ 16a :╞ return to session idle state.↲
↲
╞ 16b :╞ CH CONTR IND received in sink mode.↲
↲
╞ ┆84┆In the state "wait call resp" a packet called the initiator is ↓
┆19┆┆89┆┄┄waiting for the session call to be connected. Note that it is not ↓
┆19┆┆89┆┄┄necessarily this packet which eventually gets the session.↲
↲
╞ ┆84┆In the state "packet source con┄nected" the session is connected to ↓
┆19┆┆89┆┄┄a submit/abort packet.↲
┆0f┆↓
════════════════════════════════════════════════════════════════════════
↓
┆84┆Fig. 16. Session handling, source states.↲
↲
↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
16a╞ ╞ ╞ ╞ ╞ SESS START IND 17a↲
╞ ╞ ╞ ╞ ╞ ╞ *12)↲
╞ ╞ ╞ ╞ *1)↲
╞ ╞ ╞ ╞ session↲
╞ ╞ ╞ ╞ idle↲
↲
↲
╞ ╞ ╞ ╞ sess allocated/SESS START REQ↲
╞ ╞ ╞ ╞ *2)↲
↲
↲
╞ ╞ ╞ ╞ wait↲
╞ ╞ ╞ ╞ sess answ↲
╞ answ SESS START REQ↲
╞ result=busy↲
↲
╞ ╞ ╞ ╞ answ SESS START REQ, result=ok↲
↲
↲
╞ ╞ SESS ABORT IND╞ wait ↲
╞ ╞ ╞ ╞ call resp↲
╞ connect initiator↲
╞ transfer event *3)↲
↲
╞ ╞ SESS START CONF NEG↲
↲
╞ ╞ ╞ ╞ SESS START CONF POS↲
↲
term sess╞ ↲
*13)↲
╞ ╞ connected╞ test initiator *4)↲
↲
↲
╞ ╞ ╞ ╞ not connected↲
packet↲
source╞ doc level exit↲
connected╞ ╞ ╞ test busy queue *5) 16b↲
╞ ╞ connected↲
↲
╞ ╞ ╞ ╞ not connected↲
start sess clear╞ ╞ *10↲
*13)↲
╞ ╞ ╞ calling╞ ╞ not calling↲
↲
↲
╞ ╞ ╞ change req CH CONTR REQ↲
╞ ╞ ╞ ╞ *11) *12)↲
↲
╞ ╞ not change req↲
↲
↲
19a╞ SESS END REQ╞ ╞ ╞ 17a↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
┆0e┆↓
╞ Table 16↲
↲
╞ ┆a1┆state ! event ! action ! new state ↲
packet ! ! !↲
╞ source ! PL CH CONTR! test asso-! -↲
┆a1┆connected ! IND ! ciates *6)!╞ ╞ ↲
wait sess ! ! !↲
answ ! TU removed ! *9) - ! -↲
┆a1┆ ! ! !╞ ╞ ↲
wait call ! ! !↲
resp ! TU removed ! SESS ABORT! 19a↲
┆a1┆ ! ! REQ╞ ! ↲
packet ! ! !↲
source ! TU removed ! - ! -↲
┆a1┆connected ! ! *7) *13) ! ↲
packet ! packet ! !↲
source ! source ! transfer ! -↲
┆a1┆connected ! events *8) ! event ! ↲
┆0f┆↓
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆Fig 16, footnotes:↲
↲
╞ *1) ┆84┆Whenever this state is entered, the following should be done:↲
╞ - ┆84┆Number of sessions in the TU descriptor is described with ↓
┆19┆┆8f┆┄┄one. If it becomes zero the event "all sess removed" is ↓
┆19┆┆8f┆┄┄generated in this TU.↲
- ┆84┆If the busy queue is non empty, the first packet in this ↓
┆19┆┆8f┆┄┄queue is removed from it and the event "exit queue" ↓
┆19┆┆8f┆┄┄generated in it.↲
↲
╞ *2) ┆84┆The packet, which generated this event, becomes initiator for ↓
┆19┆┆8d┆┄┄the session. "calling" is set to true.↲
↲
╞ *3) ┆84┆The initiator is connected to the session, and the event, ↓
┆19┆┆8d┆┄┄which caused the transition from "wait call resp" state is ↓
┆19┆┆8d┆┄┄transferred to it.↲
┆84┆The reason this is done is twofold:↲
- ┆84┆The packet should have transferred the event so it can be ↓
┆19┆┆8f┆┄┄encapsulated in the right way.↲
- ┆84┆If the packet is started with charge request the CHARGE IND ↓
┆19┆┆8f┆┄┄should be transferred to it.↲
↲
╞ *4) ┆84┆It is tested if the initiator still can use the sessions. The ↓
┆19┆┆8d┆┄┄pseudo event "not connected" is generated in the following ↓
┆19┆┆8d┆┄┄cases:↲
┆8c┆┆83┆┆d0┆↓
╞ a) ┆84┆There is no indicator anymore. (A REQ ABORT has been re┄↓
┆19┆┆90┆┄┄ceived by the packet).↲
╞ b) ┆84┆There is a packet, A, in the busy queue where "A interrupts ↓
┆19┆┆90┆┄┄initiator" holds.↲
↲
╞ *5) The following is done:↲
┆84┆It is tested that there is a packet, A, in the busy queue ↓
┆19┆┆8d┆┄┄where the following holds (see section 6.4.1 for content of a ↓
┆19┆┆8d┆┄┄packet description):↲
╞ - ┆84┆addressee TI from the packet descriptor should equal called ↓
┆19┆┆8f┆┄┄TI provided called in the session descriptor is true. ↓
┆19┆┆8f┆┄┄Otherwise it should equal calling TI. If check_mnem in the ↓
┆19┆┆8f┆┄┄packet descriptor is false, part4 is not part of the ↓
┆19┆┆8f┆┄┄compare.↲
╞ - ┆84┆service in the packet descriptor should not be TLX, and ↓
┆19┆┆8f┆┄┄charge req should be false. (Otherwise must the packet ↓
┆19┆┆8f┆┄┄initiate a new session by its own).↲
- ┆84┆service in the session descriptor must be TTY.↲
╞ - ┆84┆A and the session should belong to the same TU.↲
╞ - ┆84┆TI in the TU description should equal called TI in the ses┄↓
┆19┆┆8f┆┄┄sion descriptor if calling is false. This ensures that no ↓
┆19┆┆8f┆┄┄invisible switching has occured.↲
┆84┆If such a packet is found, it is removed from the busy queue ↓
┆19┆┆8d┆┄┄and connected to the session. Otherwise no packet will be ↓
┆19┆┆8d┆┄┄connected. (The session should be terminated).↲
↲
╞ *6) ┆84┆If calling is true, then called TI is seacrched in the associ┄↓
┆19┆┆8d┆┄┄ates list (see section 8.1). If found charge req in the ses┄↓
┆19┆┆8d┆┄┄sion descriptor is set to true.↲
↲
╞ *7) ┆84┆This event is ignored here, because "TU removed" also will be ↓
┆19┆┆8d┆┄┄generated in the packet, which will perform "start sess clear" ↓
┆19┆┆8d┆┄┄or "term sess" when the document stream has been removed.↲
↲
╞ *8) ┆84┆The S62CP events mentioned in section 6.4.2.↲
↲
╞ *9) ┆84┆In this state can SESS ABORT REQ not be sent. The event can be ↓
┆19┆┆8d┆┄┄ignored because SESS END REQ will soon be sent anyway. ↓
┆19┆┆8d┆┄┄(All packets inside this TU have been removed).↲
════════════════════════════════════════════════════════════════════════
↓
╞ *10) The "caller" field in the session description is inspected.↲
↲
╞ *11) The "change req" field is inspected.↲
↲
╞ *12) ┆84┆Number of sink sessions in the TU descriptor is creased by ↓
┆19┆┆8e┆┄┄one. turn req is ignored if the state of the TU is one of the ↓
┆19┆┆8e┆┄┄following: disable redef or disabled.↲
┆82┆↲
╞ *13) ┆84┆If calling is false, then number of sink sessions in the TU ↓
┆19┆┆8e┆┄┄descriptor will be decreased with one. If it becomes zero the ↓
┆19┆┆8e┆┄┄event no sink sess is performed in the TU.↲
↲
↲
┆a1┆┆b0┆6.3.5.2 Session Handling, Reservation↲
↲
╞ ┆84┆This section describes fig. 17. session states in sink idle mode. ↓
┆19┆┆89┆┄┄This involves memory reservation if requested from the other side.↲
↲
╞ ┆84┆Entry is done via 17a, when the session is ready to receive a do┄↓
┆19┆┆89┆┄┄cument.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
Fig. 17. Session handling, reservation.↲
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
┆06┆17a↲
↲
↲
↲
DOC START IND ---> 18a↲
wait↲
doc DOC COUNT IND ---> 18b↲
↲
╞ ╞ ╞ ╞ ╞ SESS END IND ---> 19c↲
╞ ╞ ╞ ╞ *2)↲
↲
╞ ╞ ╞ ╞ ╞ CH CONTR IND ---> 16b↲
MEM RES IND *3)↲
↲
↲
↲
↲
not reserved╞ reserved↲
↲
╞ ╞ ╞ ╞ IND.REL↲
↲
╞ IND.RES↓
↲
↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
╞ ╞ ╞ ╞ ╞ RESP.RES MEM RES REQ↲
╞ ╞ ╞ ╞ ╞ result= mem answ=↲
╞ ╞ ╞ ╞ ╞ busy not reserved↲
↲
┆06┆reserving↲
↲
↲
RESP.RES mem res req↲
╞ result<>busy *1↲
════════════════════════════════════════════════════════════════════════
↓
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
┆0e┆↓
╞ Table 17↲
↲
↲
↲
╞ ┆a1┆state ╞ ! event ! action ! new state↲
reserving ╞ ! ! !↲
╞ ! SESS ABORT ! - *2) ! 19a↲
┆a1┆ ╞ ! IND ! ! ↲
╞ ! ! !↲
wait doc ╞ ! SESS ABORT ! ! 19b↲
┆a1┆ ╞ ! IND ! ! ↲
╞ ! TU removed ! SESS !↲
reserving ╞ ! ! ABORT REQ ! 19a↲
╞ ! ! *2) !↲
┆a1┆& wait doc ╞ ! ! ! ↲
↲
↲
┆0f┆↓
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ *1) ┆84┆The "mem answ" parameter will be either req_reserved (if the ↓
┆19┆┆8d┆┄┄whole amount can be reserved) or mem_reserved (otherwise) ↓
┆19┆┆8d┆┄┄reserved in the sesion descriptor is set to true.↲
↲
╞ *2) ┆84┆Number of sink sessions in the TU descriptor is decreased by ↓
┆19┆┆8d┆┄┄one. If it becomes zero the event no sink sess is generated in ↓
┆19┆┆8d┆┄┄the TU.↲
↲
╞ *3) ┆84┆If calling is tru then number of sink session in the TU des┄↓
┆19┆┆8d┆┄┄criptor is decreased by one, as in fotnote *2). This is not ↓
┆19┆┆8d┆┄┄done, however, if calling is false, because sink packets still ↓
┆19┆┆8d┆┄┄can be received on the session when the source/sink relation┄↓
┆19┆┆8d┆┄┄ship is changed later on.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆81┆┆a1┆┆b0┆6.3.5.3 Session Sink Handling↲
↲
┆84┆This section describes fig. 18. It handles sink states after ↓
┆19┆┆89┆┄┄receival of a DOC START IND or a DOC CONT IND.↲
↲
╞ ┆84┆In case of DOC CONT IND, there is the problem that if a packet is ↓
┆19┆┆89┆┄┄found with the right document identification (document linkage can ↓
┆19┆┆89┆┄┄be performed by DH), the packet can, however unlikely, still be ↓
┆19┆┆89┆┄┄connected to another session (the clean up in this session is ↓
┆19┆┆89┆┄┄unfinished).↲
↲
╞ ┆84┆To solve this problem the concept of a waiting session is intro┄↓
┆19┆┆89┆┄┄duced. The session performs the cont arrived action, and waits for ↓
┆19┆┆89┆┄┄the response which is either sess connected or reject call.↲
↲
╞ Fig. 18 has the following entry points:↲
↲
╞ 18a: DOC START IND received↲
╞ 18b: DOC CONT IND received.↲
════════════════════════════════════════════════════════════════════════
↓
╞ Fig. 18. Session sink handling↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
╞ ╞ 18a╞ ╞ ╞ 18b↲
↲
↲
↲
╞ ╞ ╞ ╞ search doc dcr *2)↲
↲
╞ ╞ ╞ ╞ packet not found↲
↲
↲
╞ alloc packet *1)╞ ╞ packet found↲
↲
↲
╞ ╞ packet allocated↲
no packet╞ ╞ ╞ cont arrived *3)↲
description↲
↲
↲
↲
SESS ABORT REQ╞ ╞ ╞ sess↲
╞ ╞ ╞ sess waiting↲
↲
19b╞ ↲
↲
╞ ╞ sess connected bank ╞ reject call *5)↲
╞ ╞ *4) event↲
↲
↲
╞ ╞ ╞ ╞ ╞ SESS ABORT REQ↲
↲
↲
╞ ╞ ╞ ╞ ╞ ╞ ╞ 19b↲
↲
╞ ╞ ╞ packet ↲
╞ ╞ ╞ sink ↲
17a doc level exit connected ↲
╞ ╞ ╞ ╞ ╞ ╞ ╞ 16a↲
↲
↲
↲
↲
╞ start sess clear↲
↲
↲
╞ ╞ ╞ ╞ term sess↲
↲
↲
╞ ╞ ╞ ╞ reserved╞ ╞ not↲
╞ ╞ ╞ ╞ ╞ reserved↲
↲
↲
╞ ╞ ╞ IND.REL↲
↲
╞ ╞ 19c╞ ╞ 16a↲
════════════════════════════════════════════════════════════════════════
↓
┆0e┆↓
╞ Table 18↲
↲
╞ ┆a1┆state ! event ! action ! new state ↲
╞ ! ! !↲
╞ sess waiting ! SESS ABORT ! - ! 19a↲
┆a1┆ ! IND ! !╞ ╞ ↲
! ! SESS ABORT!↲
sess waiting ! TU removed ! REQ ! 19a↲
╞ ╞ !╞ ! remove !↲
┆a1┆ ! ! from queue! ↲
packet sink ! ! PL CH ! ↲
connected ! turn req ! CONTR REQ ! -↲
┆a1┆ ! ! ! ↲
packet sink ! ! !↲
connected ! TU removed ! *6 ! -↲
┆a1┆ ! ! ! ↲
packet sink ! packet sink! !↲
connected ! events *6) ! transfer ! -↲
┆a1┆ ! ! event ! ↲
┆0f┆↓
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ fig. 18, footnotes.↲
↲
╞ *1) ┆84┆A free packet description (state=packet idle) is searched for. ↓
┆19┆┆8d┆┄┄If the search is successful the DOC START IND/DOC CONT IND ↓
┆19┆┆8d┆┄┄will be transferred to the packet.↲
↲
╞ *2) ┆84┆A packet description, belonging to the current TU, is searched ↓
┆19┆┆8d┆┄┄for. The doc_id field in the document description for this ↓
┆19┆┆8d┆┄┄packet should match the parameter from DOC CONT IND.↲
↲
╞ *3) ┆84┆The vent "cont arrived" is generated in the packet.↲
↲
╞ *4) The packet has connected itself to the session.↲
↲
╞ *5) ┆84┆The packet has rejected the call because the state was illegal ↓
┆19┆┆8d┆┄┄for receival of a continuation of the document.↲
↲
╞ *6) ┆84┆Reserved ind, the session descriptor is set to false (to ↓
┆19┆┆8d┆┄┄prevent sending of a IND.REL). Apart from that the event is ↓
┆19┆┆8d┆┄┄ignored (see fottnote *7 to fig.16).↲
↲
╞ *7) the S62CP events mentioned in section 6.5.2.↲
↲
↲
┆8c┆┆83┆┆c4┆↓
┆0e┆↓
┆a1┆┆b0┆6.3.5.4 Session Termination Handling↲
↲
╞ ┆84┆This section describes session termination showed in fig. 19. ↓
┆19┆┆89┆┄┄Either SESS END REQ, SESS END IND, SESS ABORT REQ, or SESS ABORT ↓
┆19┆┆89┆┄┄IND has been performed before entry into fig. 19.↲
↲
╞ ┆84┆The figure has the following entry points:↲
↲
╞ 19a: A SESS CLEAR IND is awaited.↲
╞ 19b: As 19a, but a IND.RES has not been answered by DS yet.↲
╞ 19c: ┆84┆As 19a, but a possible reservation should first be released.↲
┆0f┆↓
════════════════════════════════════════════════════════════════════════
↓
Fig. 19. Session termination handling↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
↲
╞ 19a╞ ╞ ╞ 19c╞ ╞ ╞ 19b↲
↲
↲
↲
╞ ╞ ╞ not↲
╞ ╞ ╞ reserved╞ ╞ reserved↲
↲
↲
╞ ╞ ╞ ╞ ╞ IND.REL↲
↲
↲
↲
╞ wait↲
╞ clear ind↲
↲
╞ ╞ ╞ ╞ ╞ ╞ error↲
╞ ╞ ╞ ╞ ╞ ╞ reserve↲
↲
↲
↲
╞ SESS CLEAR IND/SESS CLEAR RESP RESP.RES/IND.REL↲
↲
↲
╞ ╞ ╞ ╞ RESP.RES SESS↲
╞ ╞ ╞ result=busy CLEAR↲
╞ ╞ ╞ ╞ ╞ RESP↲
╞ wait↲
╞ clear╞ ╞ ╞ ╞ ╞ SESS CLEAR IND↲
╞ resp↲
↲
╞ ╞ ╞ SESS CLEAR RESP↲
╞ ╞ ╞ IND.RELEASE↲
↲
╞ answ SESS CLEAR RESP╞ ╞ ╞ error↲
╞ ╞ ╞ RESP.RES╞ ╞ clear↲
╞ ╞ ╞ result<>busy╞ reserve↲
↲
╞ 16a↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆0e┆↓
╞ Table 19.↲
↲
╞ ┆a1┆state ! event ! action ! new state ↲
╞ wait clear !SESS START CONF POS ! !↲
╞ ind╞ !&SESS START CONF NEG! !↲
& ┆a1┆┆e1┆error !&SESS ABORT IND ! !╞ ↲
reserve !&SESS END CONF ! - ! -↲
!&CH CONTR IND ! !↲
╞ !&PL CH CONTR IND ! !↲
!&CHARGE IND ! !↲
┆a1┆ ! *1) ! ! ↲
! ! !↲
error ! TU removed ! - ! wait clear ind↲
┆a1┆reserve ! ! ! ↲
error ! ! !↲
clear ! TU removed ! SESS CLEAR! wait clear resp↲
┆a1┆reserve ! ! RESP ! ↲
┆0f┆↓
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ fig. 19, footnotes.↲
↲
╞ *1) ┆84┆these messages can pass a SESS ABORT REQ across the interface. ↓
┆19┆┆8d┆┄┄The SESS END CONF is however, a response to a SESS END REQ.↲
↲
↲
┆a1┆┆b0┆6.4╞ Packet Source Handling↲
↲
╞ ┆84┆This section describes the part of the packet protocol machine ↓
┆19┆┆89┆┄┄which handles SUBMIT, REGRET and ABORT. A packet is described by a ↓
┆19┆┆89┆┄┄┆a1┆packet description.↲
↲
╞ ┆84┆As already mentioned, there should exist a socalled busy queue, ↓
┆19┆┆89┆┄┄where packets can be placed when there is no free session ↓
┆19┆┆89┆┄┄descriptions.↲
↲
╞ ┆84┆In section 6.3.1 is stated that there are two pools of session ↓
┆19┆┆89┆┄┄descriptions, int loop pool and net conn pool. From which pool a ↓
┆19┆┆89┆┄┄session description is allocated is for source packets indicated ↓
┆19┆┆89┆┄┄by the addressee TI parameter.↲
↲
╞ ┆84┆For each of these pools there should be a busy queue. When the ↓
┆19┆┆89┆┄┄term "the busy queue" is used in the following, the meaning is the ↓
┆19┆┆89┆┄┄busy queue corresponding to the session pool, from which the ↓
┆19┆┆89┆┄┄packet allocate sessions.↲
↲
┆8c┆┆83┆┆cc┆↓
┆0e┆↓
╞ ┆84┆It should be noted, that the term "queue" is a little misleading. ↓
┆19┆┆89┆┄┄The packets which are in the busy queue, are ordered after the ↓
┆19┆┆89┆┄┄"precedes" function, not in order of arrival.↲
┆0f┆↓
↲
╞ ┆84┆To make the protocol machine more generel (to be prepared for ↓
┆19┆┆89┆┄┄other kind of services), it has been decided to allow for more ↓
┆19┆┆89┆┄┄than one document in a TTX packet.↲
╞ ┆84┆However, this gives a problem concerning handling of a REGRET ↓
┆19┆┆89┆┄┄transaction, which in ref.3 is defined as "discard of already ↓
┆19┆┆89┆┄┄transmitted parts of a packet". Therefore it is decided that a ↓
┆19┆┆89┆┄┄CONF.REGRET only can be processed for the first document in a ↓
┆19┆┆89┆┄┄TTX packet. If this document is fully transmitted, a REQ.REGRET ↓
┆19┆┆89┆┄┄will be answered with the result "pers_err", even if the whole ↓
┆19┆┆89┆┄┄packet is not successfully transmitted.↲
↲
↲
┆a1┆┆b0┆6.4.1╞ Packet Descriptor Content for Source States.↲
↲
╞ ┆84┆The following fields are important for the protocol machine:↲
↲
╞ submit switch : ┆84┆a boolean. =true if a REQ.SUBMIT has been ↓
┆19┆┆99┆┄┄received, and no CONF.SUBMIT sent for this packet.↲
↲
╞ regret switch : ┆84┆a boolean. =true if a REQ.REGRET has been ↓
┆19┆┆99┆┄┄received, and no CONF.REGRET sent.↲
↲
╞ abort switch : ┆84┆a boolean, = true if a REQ.ABORT has been ↓
┆19┆┆99┆┄┄received.↲
↲
╞ service : TTX or TLX.↲
↲
╞ charge req : ┆84┆a boolean. Defines if charge information for the ↓
┆19┆┆99┆┄┄whole packet is requested.↲
↲
╞ check_mnem : ┆84┆a boolean. Defines if part4 of recipient TI ↓
┆19┆┆99┆┄┄should be checked. true if personal=true.↲
════════════════════════════════════════════════════════════════════════
↓
╞ personal╞ : ┆84┆a boolean. Defines that receipient TI should be ↓
┆19┆┆99┆┄┄checked as a whole.↲
╞ ╞ ┆84┆charge_req, check mnem and personal are ↓
┆19┆┆99┆┄┄constructed from the option field in REQ.SUBMIT ↓
┆19┆┆99┆┄┄(or REQ.REGRET).↲
↲
╞ addressee TI : ┆84┆The corresponding parameter from REQ.SUBMIT. The ↓
┆19┆┆99┆┄┄parameters charge_req, check_mnem personal and ↓
┆19┆┆99┆┄┄addressee TI are used when a session should be ↓
┆19┆┆99┆┄┄created to transmit the packet.↲
↲
╞ cur doc dcr : ┆84┆The current document description. For content, see ↓
┆19┆┆99┆┄┄below.↲
┆19┆┆97┆┄┄↲
╞ doc seq no : ┆84┆The sequence number for the current document des┄↓
┆19┆┆99┆┄┄cription inside the packet. The corresponding par┄↓
┆19┆┆99┆┄┄ameter in an IND.WRITE is always set equal to this ↓
┆19┆┆99┆┄┄field.↲
↲
╞ Outstanding ┆82┆:┆81┆ Number of IND.WRITE's which has not been answered↲
╞ writes with a RESP.WRITE from DS yet.↲
↲
╞ outstanding ┆82┆:┆81┆ Number of IND.UPDATE's which has not been answered↲
updates by a RESP.UPDATE yet.↲
┆82┆↲
╞ read seq no : ┆84┆When a IND.READ is pending it contains the se┄↓
┆19┆┆99┆┄┄quence number for the document description being ↓
┆19┆┆99┆┄┄read.↲
↲
╞ no_of_des : ┆84┆Number of document description inside the packet. ↓
┆19┆┆99┆┄┄Defined at packet initalization by sending a num┄↓
┆19┆┆99┆┄┄ber of IND.READ's.↲
↲
╞ error inf : ┆84┆Contains information about which kind of error ↓
┆19┆┆99┆┄┄caused a session break down. It is used to control ↓
┆19┆┆99┆┄┄error recovery. Refer ro chapter 8 for further ↓
┆19┆┆99┆┄┄information.↲
↲
╞ priority : 0 or 1.↲
════════════════════════════════════════════════════════════════════════
↓
╞ sem pages : ┆84┆For a SUBMIT packet it contains the number of ↓
┆19┆┆99┆┄┄pages still not transmitted and acknowledged from ↓
┆19┆┆99┆┄┄the other side. Together with the priority field ↓
┆19┆┆99┆┄┄it is used in the precede function, saee section ↓
┆19┆┆99┆┄┄2.2.4.↲
↲
╞ DH close ┆82┆:┆81┆ = true if a DH stream close has been sent to TTXSI↲
╞ pending for this packet and it has not been returned yet.↲
↲
╞ ╞ ┆84┆A document stream is only fully terminated when DH ↓
┆19┆┆99┆┄┄close pending is false and a DH stream close has ↓
┆19┆┆99┆┄┄been sent earlier.↲
↲
╞ retry timer ┆82┆:┆81┆ The accumulated time the packet has been↲
╞ sum encapsulated.↲
↲
╞ ┆84┆The document description (transferred to and from DS in IND.WRITE ↓
┆19┆┆89┆┄┄and RESP.READ), has the content:↲
↲
╞ document no.: ┆84┆identifies the document file to which the document ↓
┆19┆┆97┆┄┄stream connection should be made.↲
↲
╞ S62 document↲
id : ┆84┆The S.62 identification of the document.↲
↲
╞ checkpoint ↲
no. : ┆84┆The number of the checkpoint last acknowledged from ↓
┆19┆┆97┆┄┄the receiver.↲
↲
╞ finished : ┆84┆= true if DOCUMENT END REQ has been sent and ↓
┆19┆┆97┆┄┄acknowledged.↲
↲
╞ no of pages : Number of pages in the document.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆6.4.2╞ Packet Source Events↲
↲
╞ ┆84┆Here the events to the packet source protocol machine is listed:↲
↲
╞ Document level events from S62CP:↲
↲
╞ - CAPABILITIES CONF POS abr. CAP CONF POS↲
╞ ┆84┆Positive response to a CAP REQ.↲
↲
┆0e┆↓
╞ - CAPABILITIES CONF NEG abr CAP CONF NEG.↲
╞ Negative response to a CAP REQ.↲
┆0f┆↓
↲
╞ - DOCUMENT START CONF abr. DOC START CONF↲
╞ ┆84┆ A response to DOC START REQ, delivering the document ref. no.↲
↲
╞ - PAGE END CONF↲
╞ ┆84┆ Positive response to a PAGE END REQ.↲
↲
╞ - DOCUMENT END CONF, abr DOC END CONF↲
╞ ┆84┆Positive response to a DOC END REQ. All buffers with document ↓
┆19┆┆8b┆┄┄level commands for this packet have been returned from S62CP.↲
↲
╞ - EXCEPTION IND↲
╞ ┆84┆Interruption of the document transfer.↲
↲
╞ ┆84┆- DOCUMENT RESYNCH/DISCARD CONF, abr DOC RESYNC-DISC CONF↲
╞ ┆84┆Responsed to a DOC RESYNC REQ or a DOC DISC REQ. All buffers ↓
┆19┆┆8b┆┄┄with document level primitives for this packet have been re┄↓
┆19┆┆8b┆┄┄turned from S62CP.↲
↲
╞ Session level event from S62CP:↲
↲
╞ ┆84┆These events are also session events (see section 6.3.4), but ↓
┆19┆┆8b┆┄┄are transferred to the packet when it is connected.↲
↲
╞ - SESSION ABORT IND abr. SESS ABORT IND↲
╞ ┆84┆An abnormal session break down.↲
════════════════════════════════════════════════════════════════════════
↓
╞ - CHARGE INF IND, abr CHARGE IND↲
╞ ┆84┆Delivers the charge information after a session termination or a ↓
┆19┆┆8b┆┄┄session break down.↲
↲
╞ - STREAM CLEARING IND abr. STREAM CLEAR IND↲
╞ ┆84┆Last message from S62CP in a session.↲
↲
╞ - answ STREAM CLEAR RESP↲
╞ ┆84┆Answer from S62CP on a STREAM CLEAR RESP message. All buffers ↓
┆19┆┆8b┆┄┄pending at S62CP for this packet are home.↲
↲
╞ Events from DS:↲
↲
╞ - REQUEST SUBMIT, abr. REQ.SUBMIT↲
╞ ┆84┆Request for packet transmission. Submit switch is set on (not ↓
┆19┆┆8b┆┄┄shown on the figures or in the tables).↲
↲
╞ - REQUEST.REGRET, abr. REQ.REGRET↲
╞ ┆84┆Request for transmission of a discard for the document Regret ↓
┆19┆┆8b┆┄┄switch is set on..↲
↲
╞ - REQUEST.ABORT, abr. REQ.ABORT↲
╞ ┆84┆The packet transmission should be terminated as fast as ↓
┆19┆┆8b┆┄┄possible. abort switch is set on.↲
↲
╞ - RESPONSE.READ, abr. RESP.READ↲
↲
╞ - RESPONSE.WRITE, abr RESP.WRITE↲
↲
╞ - RESPONSE.UPDATE, abr. RESP.UPD↲
╞ ┆84┆Packet termination is not allowed before all IND.UPD's have been ↓
┆19┆┆8b┆┄┄answered by RESP.UPD.↲
↲
╞ Document stream events:↲
↲
╞ - REPLY OK↲
╞ ┆84┆Response to a TRANSFER (read). Contains the capabilities for the ↓
┆19┆┆8b┆┄┄document.↲
↲
┆8c┆┆83┆┆d4┆↓
╞ - REPLY NOT OK↲
╞ ┆84┆Indication from DS that a protocol error has occurred.↲
↲
╞ - STREAM↲
╞ ┆84┆Contains an amount of document data.↲
↲
╞ - CHECKPOINT↲
╞ ┆84┆A checkpoint in the document stream↲
↲
╞ - STREAM END↲
╞ Indicates end of a document stream.↲
↲
╞ - TTXSI stream close↲
╞ ┆84┆A request from TTXSI for an immediate termination of the ↓
┆19┆┆8b┆┄┄document stream.↲
↲
╞ - answ DH stream close↲
╞ ┆84┆Answer on a DH stream close message. The document stream is ↓
┆19┆┆8b┆┄┄fully terminated from DH's point of view. "DH close pending" in ↓
┆19┆┆8b┆┄┄the packet description is set to false (not shown in the ↓
┆19┆┆8b┆┄┄diagrams).↲
↲
╞ Special events:↲
↲
╞ - packet connected↲
╞ ┆84┆Indicates that the session has connected the packet which is ↓
┆19┆┆89┆┄┄either initiator for the session or resides in the busy queue.↲
↲
╞ - stream protocol err↲
╞ ┆84┆A protocol error has occurred on a document stream (document ↓
┆19┆┆8b┆┄┄stream events in an illegal state, block format error or the ↓
┆19┆┆8b┆┄┄like.↲
↲
╞ - prio break↲
╞ ┆84┆A request from another packet for the current to terminate its ↓
┆19┆┆8b┆┄┄use of the session as fast as possible.↲
════════════════════════════════════════════════════════════════════════
↓
╞ - TU removed↲
╞ ┆84┆Indicates that the TU to which the packet belongs, is being ↓
┆19┆┆8b┆┄┄removed. The packet will be disconnected from the session (if ↓
┆19┆┆8b┆┄┄connected) and will return to idle state as fast as possible. ↓
┆19┆┆8b┆┄┄This can however, first be done after a possible document stream ↓
┆19┆┆8b┆┄┄has been closed.↲
↲
↲
┆a1┆┆b0┆6.4.3╞ Packet Source Actions↲
↲
╞ ┆84┆Document level actions against S62CP:↲
↲
╞ - CAPABILITIES REQ, abr CAP REQ↲
╞ Request for document capabilities.↲
↲
┆0e┆↓
╞ - DOCUMENT START REQ, abr DOC START REQ↲
╞ Start of a document transmission.↲
┆0f┆↓
↲
╞ - DOCUMENT CONTINUE REQ, abr DOC CONT REQ↲
╞ Continuation of a document transmission↲
↲
╞ - DATA REQ↲
╞ An amount of document data.↲
↲
╞ - PAGE END REQ↲
╞ A document data checkpoint.↲
↲
╞ - PAGE END CONF RESP↲
╞ ┆84┆Signifies to S62CP that receival of a PAGE END CONF have been ↓
┆19┆┆8b┆┄┄noted in the document description in DS.↲
↲
╞ - DOCUMENT END REQ, abr DOC END REQ.↲
╞ ┆84┆End of a document transmission.↲
↲
╞ - DOCUMENT DISCARD REQ, abr DOC DISC REQ↲
╞ ┆84┆Cancelling of the already transmitted part of the document at ↓
┆19┆┆8b┆┄┄the receiver.↲
↲
╞ - DOCUMENT RESYNCHRONIZE REQ, abr DOC RESYNC REQ↲
╞ ┆84┆Temporary interruption of a document transmission.↲
════════════════════════════════════════════════════════════════════════
↓
╞ Session level actions against S62CP:↲
↲
╞ - SESSION END REQ, abr SESS END REQ↲
╞ ┆84┆Normal termination of a session. Used by the packet when ↓
┆19┆┆8b┆┄┄service=TLX or charge req=true.↲
↲
╞ - SESSION ABORT REQ, abr SESS ABORT REQ↲
╞ ┆84┆Abnormal termination of a session. Used by the packet when a TU ↓
┆19┆┆8b┆┄┄removed is received, but also to execute a REQ.REGRET when ↓
┆19┆┆8b┆┄┄service=TLX.↲
↲
╞ - STREAM CLEARING RESP, abr STREAM CLEAR RESP↲
╞ Response to a STEAM CLEAR IND from S62CP.↲
↲
╞ Actions against DS:↲
↲
╞ - CONFIRMATION.SUBMIT, abr. CONF.SUBMIT↲
╞ ┆84┆End of packet transmission. submit switch is set off (not shown ↓
┆19┆┆8b┆┄┄in the figures or in the tables).↲
↲
╞ - CONFIRMATION.REGRET, abr. CONF.REGRET↲
╞ ┆84┆Signifies success or failure of a document discard transaction. ↓
┆19┆┆8b┆┄┄regret switch is set off.↲
↲
╞ - CONFIRMATION.ABORT, abr CONF.ABORT↲
╞ ┆84┆A REQ.ABORT has been executed. (Or attempted so). abort switch ↓
┆19┆┆8b┆┄┄is set off.↲
↲
╞ - INDICATION.UPDATE, abr. IND.UPD↲
╞ ┆84┆Updates the packet description at DS. This action is only per┄↓
┆19┆┆8b┆┄┄formed when a change in DS packet state occurs but it also can ↓
┆19┆┆8b┆┄┄contain user info and charge information.↲
↲
╞ - INDICATION.READ, abr IND.READ↲
╞ Reads the current document description from DS.↲
↲
╞ - INDICATION.WRITE, abr IND.WRITE↲
╞ Writes the current document description at DS.↲
↲
┆8c┆┆83┆┆d4┆↓
╞ Document stream actions:↲
↲
╞ - TRANSFER (READ)↲
╞ ┆84┆A transfer block with mode=R. Opens a document stream.↲
↲
╞ - DH stream close↲
╞ ┆84┆Request for close for the document stream. DH close pending is ↓
┆19┆┆8b┆┄┄set on.↲
↲
╞ - DH stream break↲
╞ ┆84┆Stands for a REPLY NOTOK followed by a DH stream close.↲
↲
╞ - answ TTXSI stream close↲
╞ ┆84┆Answer on a TTXSI stream close message. All TTXSI buffers on ↓
┆19┆┆8b┆┄┄this stream have been returned.↲
↲
┆0e┆↓
╞ Special actions:↲
↲
╞ - doc level exit↲
╞ ┆84┆The packet disconnects itself from the session, after the ↓
┆19┆┆8b┆┄┄document level is left. The event with the same name is ↓
┆19┆┆8b┆┄┄generated in the ses┄sion, which can be used by another packet.↲
┆0f┆↓
↲
╞ - start sess clear↲
╞ ┆84┆The packet disconnects itself from the session when a STREAM ↓
┆19┆┆8b┆┄┄CLEAR IND is awaited from S62CP.↲
↲
╞ - term sess↲
╞ ┆84┆The session stream has been completely terminated under packet ↓
┆19┆┆8b┆┄┄control.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆6.4.4╞ Packet Source, Protocol Machine↲
↲
╞ ┆84┆In this section the handling of SUBMIT,REGRET and ABORT is shown ↓
┆19┆┆89┆┄┄by fig. 20-28, one subsection for each figure.↲
↲
╞ ┆84┆It should be noted that the term "regret possible" in these fig┄↓
┆19┆┆89┆┄┄ures are used as shorthand for the condition "doc seq no = 1 or ↓
┆19┆┆89┆┄┄service = TLX", i.e. that a REQ.REGRET can be executed, see the ↓
┆19┆┆89┆┄┄remarks in the beginning of section 6.4.↲
↲
↲
┆a1┆┆b0┆6.4.4.1╞ Packet Initialization, Source↲
↲
╞ ┆84┆This section describes the protocol machine showed in fig. 20. It ↓
┆19┆┆89┆┄┄handles preparation for packet connection to a session after re┄↓
┆19┆┆89┆┄┄ceival of a REQ.SUBMIT or a REQ.REGRET. This includes communica┄↓
┆19┆┆89┆┄┄tion of rem pages, which influences the priority algorithm.↲
↲
╞ fig. 20 has the following entry points:↲
↲
╞ 20a: return to packet idle state↲
╞ 20b: ┆84┆session allocation is repeated. A packet returns here after ↓
┆19┆┆8e┆┄┄an encapsulation.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ fig. 20. Packet initialization, source↲
╱04002d440c00060000000002014b310000000000000000000000000000000000000000000000000006101a242e38424b555f69737d87ffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ 20a╞ packet↲
╞ ╞ idle↲
↲
╞ ╞ ╞ ╞ REQ.REGRET↲
╞ ╞ REQ.SUBMIT↲
↲
╞ ╞ IND.READ (first doc dcr)↲
╞ ╞ ╞ *1)↲
╞ ╞ ╞ ╞ ╞ RESP.READ╞ ╞ *5)↲
╞ ╞ ╞ ╞ ╞ result=failed *3) 24b↲
╞ ╞ ╞ packet↲
╞ ╞ ╞ scan↲
╞ RESP.READ↲
╞ result=ok↲
╞ service=TLX↲
╞ *12) *13)↲
↲
╞ ╞ ╞ ╞ ╞ RESP.READ *13)↲
╞ ╞ ╞ ╞ ╞ service=TTX↲
╞ ╞ ╞ RESP.READ &result=ok↲
╞ ╞ ╞ service=TTX &finished=false *4)↲
╞ ╞ ╞ &result=ok↲
╞ ╞ ╞ &finished=true *4)↲
↲
╞ ╞ IND.READ *2)↲
╞ ╞ (next doc des)↓
╞ ╞ ╞ ╞ ╞ RESP.READ↲
╞ ╞ ╞ ╞ ╞ result=ok *17)↲
╞ ╞ ╞ page↲
╞ ╞ ╞ accum↲
↲
╞ ╞ RESP.READ↲
╞ ╞ result=failed *18)╞ RESP.READ *18)↲
╞ ╞ &abort switch off result=failed 27b↲
╞ ╞ ╞ ╞ ╞ &abort switch on↲
↲
╞ ╞ ╞ ╞ regret switch on↲
╞ ╞ ╞ ╞ & checkpoint=0╞ ╞ 27a↲
╞ ╞ ╞ ╞ regret possible *14)↲
↲
╞ ╞ ╞ regret switch off↲
╞ ╞ ╞ or checkpoint<>0↲
╞ ╞ ╞ or regret↲
╞ ╞ ╞ not possible↲
↲
╞ ╞ ╞ alloc session↲
╞ ╞ ╞ *15)╞ ╞ ╞ ╞ 20b↲
↲
╞ ╞ no sess/enter busy queue*6)╞ sess allocated↲
↲
╞ exit queue╞ packet╞ ╞ ╞ packet↲
╞ *7)╞ ╞ busy╞ not╞ enter╞ initiator↲
╞ ╞ ╞ ╞ connected busy↲
╞ ╞ ╞ ╞ *8)╞ queue *6)↲
↲
╞ ╞ packet connected *10)╞ ╞ packet connected *9)↲
↲
╞ ╞ ╞ ╞ 21a↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b310000000000000000000000000000000000000000000000000006101a242e38424b555f69737d87ffff04╱
↓
↲
╞ Table 20↲
↲
↲
┆0e┆↓
╞ ┆a1┆state ! event ! action ! new state ↲
╞ ! ! ! ↲
╞ packet scan! REQ.ABORT ! - ! -↲
╞ & page !╞ !╞ !↲
╞ accum ! ! !↲
packet ! ! !↲
┆a1┆ initiator! ! ! ↲
╞ ╞ !╞ ! !↲
╞ packet idle! REQ.ABORT ! CONF.ABORT ! -↲
╞ ┆a1┆╞ !╞ ! result=ok ! ╞ ↲
╞ ╞ !╞ !╞ !↲
╞ packet scan! REQ.REGRET ! -╞ ! -↲
╞ & page ╞ !╞ ! *16) !↲
┆a1┆ accum !╞ !╞ ! ↲
! ! !↲
packet scan! TU removed ! - ! packet idle↲
╞ & packet╞ !╞ !╞ !↲
┆e1┆┆e1┆ ┆a1┆┆e1┆ initiator! ! ! ↲
& page ! ! !↲
┆a1┆accum ! ! ! ↲
packet busy! REQ.REGRET ! ! ↲
& packet ! report not ! - !↲
initiator! possible or! !↲
┆a1┆ !checkpoint<>! !╞ ↲
packet busy! REQ.REGRET ! exit busy !↲
! regret ! queue !↲
╞ ! possible ! *11) !↲
!& checkpoint! !↲
! =0 ! ! 27b↲
┆a1┆ ! *14) ! ! ↲
packet ! REQ.REGRET ! !↲
initator ! regret ! !↲
! posible ! - ! 27b↲
!& checkpoint! !↲
! =0 ! !↲
╞ ┆a1┆ ! *14) ! ! ↲
! !┆82┆ exit busy┆81┆ ! ↲
packet busy! TU removed !┆82┆ queue *11)┆81┆ ! packet idle↲
┆a1┆ ! ! ! ↲
! ! !↲
packet busy! REQ.ABORT !┆81┆ exit busy┆82┆ ! 27a↲
┆a1┆┆e1┆ ! !┆81┆ queue *11)┆82┆ ! ↲
┆a1┆ ! ! ! ↲
╞ ╞ !╞ !╞ !↲
packet ! answ *9) ! ! ↲
initiator ! START SESS ! term sess ! 27b↲
! REQ ! !↲
┆a1┆ ! result=busy! ! ↲
packet ! SESS START ! !↲
initiator ! CONF NEG ! start sess ! 27b↲
┆a1┆ ! *9) ! clear ! ↲
packet ! *9) ! !↲
initiator ! SESS ABORT ! start sess ! 27b↲
┆a1┆ ! IND ! clear ! ↲
════════════════════════════════════════════════════════════════════════
↓
┆0f┆↓
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
╞ fig. 20, footnotes.↲
↲
╞ *1) ┆84┆The read seq no field in the packet descriptor is set to 1. ↓
┆19┆┆8e┆┄┄The doc.seq.no parameter in the IND.READ is, as in all fol┄↓
┆19┆┆8e┆┄┄lowing IND.READ and IND.WRITE, set equal to this field.↲
↲
╞ *2) ┆84┆The read seq no field in the packet description is increased ↓
┆19┆┆8e┆┄┄with 1.↲
↲
╞ *3) ┆84┆The result parameter from the RESP.READ. There are no more ↓
┆19┆┆8e┆┄┄document descriptions in the packet. If read seq no =1, it is ↓
┆19┆┆8e┆┄┄a protocol error.↲
↲
╞ *4) ┆84┆The finished field from the document description delivered in ↓
┆19┆┆8e┆┄┄RESP.READ. The document has been fully transmitted earlier.↲
↲
╞ *5) ┆84┆The whole packet has been transmitted earlier. A break down ↓
┆19┆┆8e┆┄┄of the communication with the DS must have occurred before ↓
┆19┆┆8e┆┄┄the DS received a CONF.SUBMIT with result=OK.↲
↲
╞ *6) ┆84┆Every time a packet enters the busy queue, the following is ↓
┆19┆┆8e┆┄┄done:↲
↲
╞ a) ┆84┆It is tested if there is a session where the following ↓
┆19┆┆91┆┄┄hold:↲
↲
a1) ┆84┆session state = packet source connected.↲
↲
a2) ┆84┆"current packet interrupts connected" holds.↲
↲
╞ ┆84┆If this is the case, the event "prio break" is generated ↓
┆19┆┆91┆┄┄in the connected packet. The packet in question will leave ↓
┆19┆┆91┆┄┄the session in an orderly manner, but as fast as possible.↲
↲
╞ ┆84┆If several such packets are found, the one with the lowest ↓
┆19┆┆91┆┄┄priority is selected.↲
↲
╞ b) ┆84┆If no packet is found to generate prio break in, it is ↓
┆19┆┆91┆┄┄testet if there is a session where:↲
↲
┆8c┆┆83┆┆e0┆↓
╞ b1) ┆84┆session state=packet sink connected↲
↲
╞ b2) ┆84┆the conditions mentioned in footnote *5) to fig 16. ↓
┆19┆┆95┆┄┄(session handling, source states) should be fulfilled.↲
↲
╞ ┆84┆If such a session is found, the event turn_req is gener┄↓
┆19┆┆91┆┄┄ated in it. If source/sink relationship later is changed, ↓
┆19┆┆91┆┄┄the current packet can use the session.↲
↲
╞ ┆84┆Finally is an IND.UPD sent with state = waiting for trans┄↓
┆19┆┆91┆┄┄mission (regret switch off or regret not possible) or re┄↓
┆19┆┆91┆┄┄gret waiting.↲
↲
╞ *7) ┆84┆A session has entered the session idle state.↲
↲
╞ *8) ┆84┆The packet was not connected to the session. (A packet exists ↓
┆19┆┆8e┆┄┄in the busy queue which can interrupt the current).↲
↲
╞ *9) ┆84┆The packet has been connected to the session.↲
↲
*10) ┆84┆An already existing session has connected the packet to ↓
┆19┆┆8e┆┄┄itself.↲
↲
*11) ┆84┆The packet is removed from the busy queue.↲
↲
*12) ┆84┆The checkpoint field in the document description is set to 0, ↓
┆19┆┆8e┆┄┄and is set to false.↲
↲
*13) The packet is connected.↲
↲
*14) ┆84┆checkpoint=0 indicates for TTX packets either that the docu┄↓
┆19┆┆8e┆┄┄ment already is discarded, or no pages has been acknowledged. ↓
┆19┆┆8e┆┄┄In the latter case the document should be regarded as dis┄↓
┆19┆┆8e┆┄┄carded according to S.62, and session allocation is not ↓
┆19┆┆8e┆┄┄necessary.↲
↲
╞ ┆84┆For TLX packets, checkpoint=0 & doc seq no=1 always holds ↓
┆19┆┆8e┆┄┄here.↲
↲
┆8c┆┆83┆┆d4┆↓
*15) This stands for the following action:↲
╞ ┆84┆A free session description is searched for. If such a de┄s┄↓
┆19┆┆8e┆┄┄cription is found, the packet becomes initiator for the ses┄↓
┆19┆┆8e┆┄┄sion (the pseudo event "sess allocated"). The event "sess al┄↓
┆19┆┆8e┆┄┄located" is generated in the session. If no session is allo┄↓
┆19┆┆8e┆┄┄cated, the packet enters the busy queue.↲
↲
*16) ┆84┆Note that regret switch is set on.↲
┆0e┆↓
↲
╞ *17) ┆84┆The no of pages field in the document description read is ↓
┆19┆┆8e┆┄┄added to rem pages. Note that the current dosument descrip┄↓
┆19┆┆8e┆┄┄tion is left unchanged.↲
↲
╞ *18) ┆84┆no of des can now be defined. rem pages is now fully defined ↓
┆19┆┆8e┆┄┄so that the priority algorithm can function correctly.↲
↲
↲
┆a1┆┆b0┆6.4.4.2╞ Capability Handling↲
↲
╞ ┆84┆This section describes opening of the document stream and capa┄↓
┆19┆┆89┆┄┄bility negotiation in packet source mode. Fig. 21 shows this. ↲
╞ Fig. 21 has the entry point:↲
↲
╞ 21a: ┆84┆A document is ready to be transmitted and the document ↓
┆19┆┆8d┆┄┄description has been read from DS. The packet has been ↓
┆19┆┆8d┆┄┄connected to a session.↲
↲
↲
┆0f┆↓
════════════════════════════════════════════════════════════════════════
↓
╞ Fig. 21 Capability handling↲
╱04002d440c00060000000002014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
↲
╞ ╞ ╞ 21a↲
↲
↲
↲
↲
╞ ╞ ╞ IND.UPDATE *6)↲
↲
↲
↲
↲
↲
╞ ╞ ╞ wait↲
╞ ╞ ╞ reply ok↲
↲
↲
↲
↲
╞ ╞ ╞ REPLY OK/CAP REQ↲
↲
╞ ╞ ╞ ╞ ╞ STREAM↲
↲
↲
╞ ╞ ╞ wait↲
╞ ╞ ╞ cap resp╞ STREAM END *2)↲
↲
╞ ╞ CAP CONF NEG↲
↲
25d╞ ╞ ╞ ╞ ╞ CHECKPOINT↲
*3)↲
↲
↲
↲
╞ ╞ ╞ CAP CONF POS↲
↲
↲
↲
╞ regret switch on╞ regret switch off↲
╞ & regret possible or regret not possible↲
↲
↲
╞ ╞ 25d╞ ╞ ╞ 22a↲
↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆1a┆┆1a┆┆1a┆ssible or regret not possible↲
↲
↲
╞ ╞ 25d╞ ╞ ╞ 22a↲
↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
↓
┆1a┆
════════════════════════════════════════════════════════════════════════
┆01┆
════════════════════════════════════════════════════════════════════════
┆03┆
════════════════════════════════════════════════════════════════════════
┆05┆
════════════════════════════════════════════════════════════════════════
┆07┆
════════════════════════════════════════════════════════════════════════
╞
════════════════════════════════════════════════════════════════════════
┆0b┆
════════════════════════════════════════════════════════════════════════
←
════════════════════════════════════════════════════════════════════════
┆0f┆