530 lines
27 KiB
Plaintext
530 lines
27 KiB
Plaintext
|
||
_______________________________________________________________________________
|
||
|
||
An Introduction to Packet Switched Networks Part II
|
||
Written by Blade Runner on 08/20/88
|
||
|
||
A Telecom Computer Security Bulletin File
|
||
_______________________________________________________________________________
|
||
|
||
|
||
This is Part II of the TCSB "Introduction to Packet Switched Networks".
|
||
Without Part I you are going to be very lost. So, if you are without it
|
||
you had best go find it and download it. Now on with Blade Runner's tab-
|
||
le of the control field headers:
|
||
|
||
|
||
+----------------------------------------+
|
||
| bits |
|
||
+------+-------------+-----+-------------+
|
||
Control Field | 1st | 2nd 3rd 4th | 5th | 6th 7th 8th |
|
||
+-----------------------+------+-------------+-----+-------------|
|
||
| Header I | 0 | N(S) | P/F | N(R) |
|
||
|-----------------------+------+-------------+-----+-------------|
|
||
| Header S | 1 | 0 S | P/F | N(R) |
|
||
|-----------------------+------+-------------+-----+-------------|
|
||
| Header U | 1 | 1 M | P/F | M |
|
||
+-----------------------+------+-------------+-----+-------------+
|
||
|
||
|
||
N(S): number of sended sequence
|
||
N(R): number of sequence we looking for receive
|
||
S : supervisioning commands
|
||
M : not numbered sequence commands
|
||
P : Poll bit (sended as command)
|
||
F : Final bit (sended as answer)
|
||
|
||
|
||
From what we can observe, N(R) and N(S) will take at maximum the value
|
||
of 7 (starting from 0) therefore they are composed at maximum with 3 bits
|
||
|
||
2nd 3rd 4th N(S)
|
||
6th 7th 8th N(R)
|
||
|
||
Therefore a counter exits a loop, before the sending of the 4th header
|
||
will reset the N(S) and N(R).
|
||
|
||
Supervision commands (S) occupy the 3rd and 4th position of control
|
||
string and we can therefore assume that the 4 header is coupled to 2 bit
|
||
(the C.25 will consider only 3):
|
||
|
||
RR = Receive Ready (00)
|
||
REJ = Reject (01)
|
||
RNR = Receive Not Ready (10)
|
||
|
||
The RR header can be used to indicate that a station is ready to
|
||
receive an information header or to give the confirmation that it has
|
||
received a number of headers thru N(R) - 1 (where N(R) is the header we
|
||
are looking to receive).
|
||
|
||
The REJ header can be sent as request for the retransmission of a header
|
||
starting from header N(R) and until we have understood transmission can
|
||
not be resent with the same header.
|
||
|
||
The RNR header can be used to mark a busy case due (e.g. from a
|
||
temporary impossibility to receive data).
|
||
|
||
The non-numbered headers don't have, as already stated, transmitting or
|
||
receiving counters and will therefore provide a 5 bit (called modifiers)
|
||
that allow 32 particular functions.
|
||
|
||
Between these we can consider some examples:
|
||
|
||
SARM header (Set Asyncronous Responde Mode)
|
||
|
||
in which a syncronization between two running stations is requested in
|
||
ARM (Asyncronous Response Mode), typical of LAP procedures; this command
|
||
will reset all counters.
|
||
|
||
SABM header (Set Asyncronous Balanced Mode)
|
||
|
||
that is a synchronicity request between two running stations running in
|
||
ABM (Asyncronous Balanced Mode), typical of LAPB procedures. The receiving
|
||
of this command will reset all counters.
|
||
|
||
The remote station answers these commands with UA header (Un-numbered
|
||
Acknowledgement) to confirm the right synchronicity.
|
||
|
||
The DM header (Disconnect Mode) is also used in ABM mode. It is used to
|
||
mark the station that should answer is not connected.
|
||
|
||
The FMRM commands (Frame-reject response) or CRMR (Command-reject
|
||
Response) are sent when a correct CRC header is received, but with an
|
||
unrecoverable error with a repeated header (e.g. not a sequenced header).
|
||
The receiving station must re-initialize the connection procedure.
|
||
|
||
The following table fully describes the level 2 functions:
|
||
|
||
----------------------------------------------------------------------
|
||
| | |
|
||
Header type | Commands | Answers | bits of control field
|
||
------------+--------------+--------------+---------------------------
|
||
Information | I | | 0 N(S) | P | N(R)
|
||
------------+--------------+--------------+---------+-----+-----------
|
||
| RR | RR | 1 0 0 0 | P/F | N(R)
|
||
Supervising | RNR | RNR | 1 0 1 0 | P/F | N(R)
|
||
| REJ | REJ | 1 0 0 1 | P/F | N(R)
|
||
------------+--------------+--------------+---------+-----+-----------
|
||
| SARM | DM | 1 1 1 1 | P/F | 0 0 0
|
||
|--------------+--------------+---------+-----+-----------
|
||
| SABM | | 1 1 1 1 | P | 1 0 0
|
||
Not |--------------+--------------+---------+-----+-----------
|
||
Numbered | DISC | | 1 1 0 0 | P | 0 1 0
|
||
|--------------+--------------+---------+-----+-----------
|
||
| | UA | 1 1 0 0 | F | 1 1 0
|
||
|--------------+--------------+---------+-----+-----------
|
||
| | CMDR | 1 1 1 0 | F | 0 0 1
|
||
| | FMRM | | |
|
||
----------------------------------------------------------------------
|
||
|
||
The very last important function of level 2 is the frame window: this
|
||
will indicate the number of headers that can be sent without recieving
|
||
confirmation from the remote station. It assumes a value from 1 to 7.
|
||
|
||
Every time a sequence is sent a time-out starts that is reset every
|
||
time an acknowledgement is received (basically, a successful recieve). If
|
||
this acknlowledgment is not received by the end of counting, an automatic
|
||
of the message with the (P) poll but taken to logical level 1 starts. This
|
||
is to request an immediate response from the remote station. The reply
|
||
will be followed by the (F) final bit raised to logical level 1 and the
|
||
adequate answer to the command was recieved (e.g., RR with F bit set to 2
|
||
if regarding answer with I header with P bit to 1).
|
||
|
||
5. LEVEL 3 - Packet level
|
||
|
||
The level 3 or X.25 recomendation allows the multiplexing timing
|
||
functions because it transforms the single connection or logical channel
|
||
provided from level 2 in a greather number of logical channels. It enables
|
||
independant control of the data flow of each channel. Some error recovery,
|
||
re-initialization or others, may be recovered on the logical channel or
|
||
single or in a more complete manner on all channels. The packet level
|
||
also provides the capability to insert some interrupt procedures that allow
|
||
the DTE to send information that allows exit from the normal data flow and
|
||
has high priority on the flow.
|
||
|
||
The features of this level can be listed in the following groups:
|
||
|
||
1) The multiplexing of n logical channels on one logical channel of
|
||
connection;
|
||
|
||
2) The control of the flow locally routed into DTE and DCE
|
||
interfaces (not between DTE and DTE);
|
||
|
||
3) Guarantee the sequence of packet numbering;
|
||
|
||
4) The capability to send interrupt requests;
|
||
|
||
5) Recovery from errors (as bad counts) by reinitialization or reject
|
||
of packets;
|
||
|
||
6) Virtual switched circuits between two DTE (that are equal to
|
||
switched lines);
|
||
|
||
7) Virtuals permanent circuits between two DTE (that are equal to
|
||
dedicated lines);
|
||
|
||
The info field at level 3 is in the header at level 2 into the field
|
||
we have defines as information.
|
||
|
||
Each information header will contain a single packet, that is
|
||
structured as is in following table.
|
||
|
||
|
||
Information field (level 2)
|
||
__________________________/\________________________________
|
||
/ \
|
||
+---------------------+----------+-----------+----------+......
|
||
| : : | | | |
|
||
| Q : format: logical | logical | packet | info |
|
||
| : : group | channel | identif. | field |
|
||
| : : | | | |
|
||
+---------------------+----------+-----------+----------+......
|
||
: : : :
|
||
:<------------------->:<-------->:<--------->:<----------------
|
||
: 8 bit : 8 bit : 8 bit : => 0
|
||
|
||
Note that the information is divided into octettes taking therefore a
|
||
structure as shown above:
|
||
|
||
|
||
bit -> | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | octetts
|
||
+-----+-----+-----+-----+-----+-----+-----+-----+ |
|
||
| | | | V
|
||
| Q D | 0 1 | LCG | 1
|
||
|-----------+-----------+-----------------------|
|
||
| |
|
||
| LC | 2
|
||
|-----------------------------------------------|
|
||
| |
|
||
| Packet identifier | 3
|
||
|-----------------------------------------------|
|
||
| length of address of | length of address of |
|
||
| calling DTE | called DTE | 4
|
||
|-----------------------------------------------|
|
||
| |
|
||
| adresses of DTE calling and called |
|
||
| |
|
||
|...............................................|
|
||
|
||
Level 3 allows 16 groups (LCG=Logical channel group) of 256 logical
|
||
channels (LC=logical channels) between each DCE and DTE. That information
|
||
is contained at the start of the packet in a 4 bit + 8 bit field (called
|
||
LCG and LC into upon table), that allow to obtain thru 4,096 logical
|
||
channels (from 0 to 4,095).
|
||
|
||
DCE and DTE use the same logical channel to understand a connect.
|
||
Locigal channels are used to provide bi-directional associations between
|
||
two DTE: these associations are called virtual circuits and can have a
|
||
different numeration from the logical channel, therefore, as we can observe
|
||
from the next table, X.25 newtork nodes can be busy from any of several
|
||
things than a specific logical channel that is on one of both ends of a
|
||
network, between two DTE, can be already busy from another wire. From
|
||
here the presence of a unique virtual circuit between A and B with two
|
||
different logical channels.
|
||
|
||
A is simultaneously connected with B and C.
|
||
|
||
|
||
+-------+ Lc 5 Lc 5 +---------+
|
||
| DTE B |----------- --------------| DTE C |
|
||
+-------+ | | +---------+
|
||
| |
|
||
| |
|
||
| |
|
||
| |
|
||
+-------------------------------+
|
||
| | DCE Y| | DCE Z| |
|
||
| |______| |______| |
|
||
| |
|
||
| X.25 |
|
||
| |
|
||
| |
|
||
| ____________________ |
|
||
| | | |
|
||
| | DCE X | |
|
||
+-------------------------------+
|
||
| |
|
||
+-------+ Lc 4 A,B | | Lc 5 +---------+
|
||
| DTE A |----------- --------------| DTE D |
|
||
+-------+ Lc 5 A,C +---------+
|
||
|
||
|
||
The virtual circuit between A and B uses Lc4 between A and X and Lc5
|
||
between Y and B; logical channel 5 between A and X was already busy from
|
||
DTE C who has requested the line before B did.
|
||
|
||
DCE X can use a Lc5 on DTE A wire and Lc5 on DTE D wire.
|
||
|
||
THIS WOULD SIGNIFY THAT LOGICAL CHANNELS MUST ME KNOWN AS DEDICATED
|
||
LINES BETWEEN DTE AND DCE, WHILE VIRTUAL CIRCUITS AS EQUIVALENTS TO
|
||
DEDICATED LINES BETWEEN TWO DTE.
|
||
|
||
Packets function and formats
|
||
|
||
There are several types of packet identifiers, as shown in the next
|
||
table. The relative format to those is shown in next tables.
|
||
|
||
|
||
-------------------------------------------------------------------------
|
||
packet type and his | third byte bit
|
||
identificator +--------------------+---------------------------
|
||
| DCE to DTE | DTE to DCE | 87654321
|
||
------------------------+--------------------+-----------------+---------
|
||
| incoming call | call request | 00001011
|
||
|--------------------+-----------------|
|
||
| completed call | accepted call | 00001111
|
||
call and interrupt |--------------------+-----------------|
|
||
packets | disconnect indicat | disconnect req | 00010111
|
||
------------------------+--------------------+-----------------|
|
||
| data from DCE | data from DTE | xxxxxxx0
|
||
data packets and |--------------------+-----------------|
|
||
interrupt | Interrupt from DCE | interr from DTE | 00100011
|
||
|--------------------+-----------------|
|
||
| interrupt confirm | interr confirm | 00101111
|
||
------------------------+--------------------+-----------------|
|
||
| ready to receive | Ready to receive| xxx00001
|
||
| (RR) | (RR) |
|
||
|--------------------+-----------------|
|
||
| not ready to rec. | not ready to rec| xxx00101
|
||
data flow packet and | (RNR) | (RNR) |
|
||
reset |--------------------+-----------------|
|
||
| | re xmit req | xxx01001
|
||
| | (RJR) |
|
||
|--------------------+-----------------|
|
||
| reset indication | reset confirm | 00011011
|
||
|--------------------+-----------------|
|
||
| reset confirm | reset confirm | 00011111
|
||
------------------------+--------------------+-----------------|
|
||
| restart indication | restart req | 11111011
|
||
re-initialization |--------------------+-----------------|
|
||
packets | restart confirm | restart confirm | 11111111
|
||
----------------------------------------------------------------
|
||
|
||
bit -> | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | octets
|
||
+-----+-----+-----+-----+-----+-----+-----+-----+
|
||
| | | | | |
|
||
| 0 | X | 0 | 1 | LCG |
|
||
|-----------+-----------+-----------------------|
|
||
| |
|
||
| LC |
|
||
|-----------------------------------------------|
|
||
| |
|
||
| Packet identifier |
|
||
| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 |
|
||
+-----+-----+-----+-----+-----+-----+-----+-----+
|
||
| length of address of | length of address of |
|
||
| calling DTE | called DTE |
|
||
|-----------------------------------------------|
|
||
| |
|
||
: adresses field :
|
||
: ________________________:
|
||
| | | | | |
|
||
| | 0 | 0 | 0 | 0 |
|
||
| | | | | |
|
||
|-----------------------------------------------|
|
||
| | | |
|
||
| 0 | 0 | lenght of optional feautures |
|
||
| | | field |
|
||
|-----------------------------------------------|
|
||
| |
|
||
: optional features field :
|
||
: :
|
||
|-----------------------------------------------|
|
||
| |
|
||
| user data field |
|
||
| |
|
||
+-----------------------------------------------+
|
||
|
||
|
||
bit -> | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | octets
|
||
+-----+-----+-----+-----+-----+-----+-----+-----+ |
|
||
| | | V
|
||
| Q D 0 1 | LCG | 1
|
||
|-----------------------+-----------------------|
|
||
| |
|
||
| LC | 2
|
||
|-----------------------------------------------|
|
||
| | | | |
|
||
| P(R) | M | P(S) | 0 | 3
|
||
|-----------------------------------------------|
|
||
| |
|
||
: User data :
|
||
: :
|
||
+-----------------------------------------------+
|
||
|
||
bit -> | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | octets
|
||
+-----+-----+-----+-----+-----+-----+-----+-----+ |
|
||
| | | V
|
||
| Q D 0 1 | LCG | 1
|
||
|-----------------------+-----------------------|
|
||
| |
|
||
| LC | 2
|
||
|-----------------------------------------------|
|
||
| | |
|
||
| P(R) | 0 0 0 0 1 | 3
|
||
+-----------------------------------------------+
|
||
|
||
Connect and deconnect procedure
|
||
|
||
When a user (DTE A) asks for a virtual connection to other DTE B end
|
||
then the deconnection, it will follow these next phases:
|
||
|
||
DTE A DCE DTE B
|
||
call request -------> incoming call ---------------------->
|
||
|
||
call connected <----- call accepted <----------------------
|
||
|
||
data ----------------------------------------------------->
|
||
|
||
data ----------------\ /-------------------------- data
|
||
\ /
|
||
X
|
||
/ \
|
||
<---------------/ \------------------------------>
|
||
|
||
--- clear indication <----- clear request <-------------------
|
||
| |
|
||
| |------------------> clear confirmation
|
||
|
|
||
|
|
||
--- clear confirmation --------------------------------------->
|
||
|
||
Previously we showed a table is not written, but is obvious as told in
|
||
before paragraph, that the appearing information, from A to B, will travel
|
||
on the same virtual circuit but can also have different logical channels.
|
||
|
||
The data packet identification field is recognized thanks to the first
|
||
bit of octet is a zero, in opposition to other identificators, that has a
|
||
bit set to 1 as first octet bit.
|
||
|
||
Next octed bit, seen in next table, will take following mean:
|
||
|
||
bit -> | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|
||
+-----+-----+-----+-----+-----+-----+-----+-----+
|
||
| | | | |
|
||
| P(R) | M | P(S) | 0 |
|
||
+-----------------------------------------------+
|
||
|
||
P(S) (bit 2, 3, 4) is the packet number in transmission (0 < P(S) < 7)
|
||
P(R) (bit 6, 7, 8) is the packet number that terminal is waiting for
|
||
(0 < P(R) < 7 .
|
||
|
||
M (bit 5) (More bit) will signal if packet contains complete
|
||
information (M=0) or an information that need more packets to be completed
|
||
to be ended (M=1).
|
||
|
||
The number of the packet terminal is waiting for is also contained in
|
||
the identifier of the control packet of flow control (bit 8, 7, 6).
|
||
|
||
As in levels 2 level 3 also provide a transmission window known as the
|
||
maximum number of packets that can be sendt without receiving the good
|
||
receive signal. This window is decided at the time of wiring as function
|
||
of speed and can assume values from 1 to 7.
|
||
|
||
The other two bits are Q and D.
|
||
|
||
The Q bit, as 8th bit of first octet of data exchange packet, can be
|
||
considered as the second logical channel generator within the same channel,
|
||
in the way of, when it is equal to zero, it points to a certain data
|
||
flow, when it is set to one, it will individualize another totally indep-
|
||
endent flow of data, in the same logical channel.
|
||
|
||
The X.29 recomendation uses this bit to send "information" between two
|
||
devices that are making the usual data flow exchange between two users.
|
||
|
||
The D bit is used when a particular network is so complex that we want
|
||
to have the confirmation about the receiving of a message from a remote
|
||
terminal to which we are logically connected, before erase from our memory
|
||
the sent information.
|
||
|
||
6. X RECOMENDATION APPLICATIONS
|
||
|
||
The X.25 Recomendation, as told at start, considers the interface
|
||
between DTE and DCE. Actual users have a start-stop terminal usage or
|
||
synchronous type that is not appropriate to be directly connected to the
|
||
PSS World, but we have do to some protocol convertions done by PADs (Packet
|
||
Assembly-Disassembly).
|
||
|
||
By the use of these devices, it is possible build networks as shown:
|
||
|
||
+----------+ +----------+
|
||
| CPU X.25 |-------- --------------| DTE X.25 |
|
||
+----------+ | | +----------+
|
||
| |
|
||
| |
|
||
| |
|
||
| |
|
||
+-------------------------------+
|
||
| |
|
||
| |
|
||
| |
|
||
| X.25 |
|
||
| |
|
||
| |
|
||
| |
|
||
| |
|
||
| |
|
||
+-------------------------------+
|
||
| |
|
||
| |
|
||
/ \ / \
|
||
/ \ / \
|
||
/_PAD_\ /_PAD_\
|
||
| | | | | |
|
||
| | | | | |
|
||
start/stop +----------+
|
||
users | not X.25 |
|
||
| CPU |
|
||
+----------+
|
||
|
||
In the table shown above we can observe as the X.25 type terminals and
|
||
the X.25 terminals connect directly to the X.25 world.
|
||
|
||
CCITT has provided some recomendations for these kinds of devices:
|
||
|
||
X.3 recomandation - Features for PAD interfacing with a public network.
|
||
|
||
X.28 recomandation - DTE/DCE interface for start/stop terminals
|
||
connected to a PAD which is connected to a PSS in same country.
|
||
|
||
X.29 recomandation - Procedures to control the information exchange
|
||
between a PAD and a DTE X.25 or another PAD.
|
||
|
||
Those three recomandations and X.25 can be showed as follows:
|
||
|
||
|
||
: X.29 : :
|
||
:<-------------------------->:<------------------>:
|
||
: : :
|
||
: : :
|
||
|\ : : +---------+
|
||
| \ +-----+ +----------------+ RS 232 | |
|
||
| | X.3 | | | PAD|----------| terminal|
|
||
| P | | | X.25 +----|....... +---------+
|
||
| | par |\__________| | !
|
||
| A | ame |/ | network | !
|
||
| | ter | | | ! X.29
|
||
| D | s | | | !
|
||
| / +-----+ +----------------+ !
|
||
|/ : | !
|
||
: | ..........!
|
||
: | :
|
||
: | :
|
||
: | : /|
|
||
: | +-----+ / |
|
||
: | | X.3 | |
|
||
: | | | P | +---------+
|
||
: |__/| par | | RS 232 | |
|
||
: \| ame | A |---------| terminal|
|
||
: | ter | | +---------+
|
||
: | s | D | :
|
||
: +-----+ \ | :
|
||
: : \| :
|
||
: X.29 : X.28 :
|
||
:<-------------------------->:<-------------------->:
|
||
|
||
|
||
Thus concludes the TCSB "Introduction to Packet Switched Networks". We do
|
||
hope that you enjoyed this file. Look out for more PSS Network files soon.
|
||
|
||
_______________________________________________________________________________
|
||
$ |