Browse Prior Art Database

X.25 Over an SNA Network: Call Regulation System

IP.com Disclosure Number: IPCOM000039323D
Original Publication Date: 1987-May-01
Included in the Prior Art Database: 2005-Feb-01
Document File: 4 page(s) / 32K

Publishing Venue

IBM

Related People

Monnet, M: AUTHOR

Abstract

This disclosure refers to X.25 packet switching over a System Network Architecture (SNA) network. The SNA network is built from communication controllers (CCs), running appropriate programs, linked through a set of Transmission Groups, and managed from host computers. Moreover, the CC performing X.25 functions (X.25 Data Terminal Equipment (DTE) attachment and/or intermediate X.25 switching) must also include specific functions pertaining to X.25 packet switching. The call regulation system depicted below is one of these specific functions. Basically, X.25 packets flow on SNA sessions pre-established in the SNA network between the communication controllers. Sessions set-up is achieved thanks to regular SNA routing mechanisms (Virtual Routes and Explicit Routes) and is activated at network initiation time.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 4

X.25 Over an SNA Network: Call Regulation System

This disclosure refers to X.25 packet switching over a System Network Architecture (SNA) network. The SNA network is built from communication controllers (CCs), running appropriate programs, linked through a set of Transmission Groups, and managed from host computers. Moreover, the CC performing X.25 functions (X.25 Data Terminal Equipment (DTE) attachment and/or intermediate X.25 switching) must also include specific functions pertaining to X.25 packet switching. The call regulation system depicted below is one of these specific functions. Basically, X.25 packets flow on SNA sessions pre-established in the SNA network between the communication controllers. Sessions set-up is achieved thanks to regular SNA routing mechanisms (Virtual Routes and Explicit Routes) and is activated at network initiation time. More than one Virtual Call can use the same SNA session at a given time, and the multiplexing function makes use of a number of Logical Channels between X.25 communication controllers. The routing of X.25 packets is determined on a per call basis. All the packets pertaining to a Virtual Call will use the same route; the route is completely determined in the communication controller which attaches the calling DTE. This function is achieved without advocating a centralized directory (distributed routing tables). The hierarchization of the addressing scheme of X.25 DTEs permits the minimization of the size of the routing tables in communication controllers. In order to comply with CCITT Recommendations X.135 and X.136, the communication controller monitors the throughput class and the transit delay of Virtual Calls on the SNA network. Two specific concepts are used by the present call regulation system. Virtual Circuit Support (VCSU) and VC-path (Virtual circuit- path). VCSU defines the "pipe" between two X.25 communication controllers. Basically, a VCSU is a SNA session. A VCSU can also be an High Level Data Link Control (HDLC)-like medium dedicated to X.25 traffic. A VCSU is mainly characterized by: its available bandwidth for X.25 traffic, a figure

defined at system generation time, and

its transit delay which is a fixed statistical figure. A VC-path is a sequence of VCSUs (possibly reduced to one VCSU) between a pair of communication

controllers permitting the establishment of Virtual

Calls between DTEs attached to these communication

controllers, and ensuring a given Quality Of Service

(QOS) to Virtual Calls. The QOS parameters of a VC-path

are:

its throughput range which defines the throughput

classes that the VC-path will be allowed to support,

and

its transit delay which is the sum of the transit

delays of the underlying VCSUs. Between a given pair of communication controllers, more than one VC-path can be defined so as to support: different transit delays,

1

Page 2 of 4

different throughput ranges,

traffic overflows, and

alternate routings. A given VC-path in a SNA network is...