31.07.2015 Views

network protocols handbook.pdf

network protocols handbook.pdf

network protocols handbook.pdf

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

250Protocols GuideISO Protocols - Application LayerProtocol NameISO RTSE: Reliable TransferService Element Protocolminor errors occurring, and can be resumed later. In the case ofmore severe errors, such as loss of the application associationitself, the activity may need to be discarded and in this case thetransaction will start again from scratch at a later time, in a newactivity.Protocol DescriptionReliable Transfer Service Element (RTSE), an ISO applicationlayer protocol, provides for the reliable transfer of bulk data bytransforming the data into a string of octets, then breaking thestring into segments and handing each segment to the PresentationLayer for delivery. Checkpoints are established betweensegments. Through the services of the Presentation Layer, RTSEuses the activity management services of the Session Layer tomanage the transfer of the collection of segments that makes upthe bulk data. Activity and minor synchronization facilities of theSession Layer support interruption and possible resumption ofdata transfer if the underlying <strong>network</strong> connection is lost.Protocol StructureRTSE Service SummaryServiceRT-OPENRT-CLOSERT-TRANSFERRT-TURN-PLEASERT-TURN-GIVERT-P-ABORTRT-U-ABORTTypeConfirmedConfirmedConfirmedNon-confirmedNon-confirmedProvider-initiatedNon-confirmedRTSE is used in the X.400 Message Handling Service (MHS)and is available for use by ROSE when remote operations requirereliable transfer. Because of its use in X.400, RTSE iswidely available.Typically the Transport layer is supposed to ensure reliable deliverybut this is insufficient for two reasons: 1) No class of transportprotocol will recover from a failure of the underlying <strong>network</strong>,which results in the required QOS (Quality of Service) not beingmet. Under these circumstances, the underlying connection willbe lost. 2) For historical reasons, MHS was designed to operateover TP0 which provides no recovery at all from signalled errors(including X.25 resets). In the event of either an X.25 reset or adisconnect, TP0 terminates the underlying connectionRelated <strong>protocols</strong>ISO-SP, ISO-PP, ROSE, ACSE, X.400Sponsor SourceRTSE is defined in ISO (www.iso.org) documents 9066 and ITU(www.itu.org) documents X.228 and X.218.Referencehttp://www.doc.ua.pt/arch/itu/rec/product/X.htmX.218: Reliable Transfer: Model and service definitionX.228: Reliable Transfer: Protocol specificationRTSE is required to re-establish the underlying failed connectionand to repeat the transmission attempt, transparently to theuser. However, RTSE cannot guarantee delivery if success cannotbe achieved within a given time, RTSE will report failure.This may occur if there is a catastrophic failure either of the underlying<strong>network</strong> or of the peer application, which clearly neitherRTSE nor any other ASE (Application Service Element) can doanything positive about.RTSE is not viable on its own. RTSE has no knowledge of thecontext of the PDU which it is attempting to deliver, nor indeedwould it have anything to deliver. There must be an ‘RTSE user’which understands what RTSE is being used for, typically aMHS service element using ROSE.RTSE uses Session Layer Activities for the following reasons:Each PDU (e.g. message) and the response confirming (or otherwise)its successful delivery are encapsulated within dialogueunits (major synchronisation points). RTSE may also insert minorsynchronization points at suitable intervals during the activity,as it sees fit. An activity may be interrupted in the event of

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!