|
|
Networking Technologies
Chapter 9: The OSI Transport Layer
Objectives:
Chapter 9 is the fourth chapter about OSI model layers. The objectives
important to this chapter are on page 9-1:
- Understanding the overall purpose of this layer.
- Understanding the two address/name resolution methods.
- Understanding the addresses used at the Transport layer.
- Understanding segment development.
- Understanding connection services used at the Transport.
Concepts:
The overview of the chapter on page 9-2 shows that the Transport
Layer is concerned with segment development and moving data
to specific processes or services in a reliable way. Note
the "certified letter" metaphor in the picture. Associate this layer with
the words "reliable" and "dependable".
The topics and methods for this layer are on page 9-3:
- Transport - This layer has 4 topics and is associated with
Segments
- Address/name Resolution
- Addressing
- Segment Development - breaking large messages into segments,
combining small messages into segments
- Connection Services
No hardware is particularly associated with the Transport layer.
This is the fourth chapter on ISO Model layers. The first topic,
Address/Name Resolution, concerns learning the actual addresses
that correspond to more memorable names that a human being
can remember. Most actual addresses of services are alphanumeric
strings that computers can use, remember and look up more easily than
humans can. The shorter names are often used instead of the
longer names/addresses, which means that each entity must have access
to a method for using the short name without knowing the longer address.
When an entity on the network knows only the short name and needs
to know the address of another entity, whether a service or a physical
device, it can learn it in three ways. For now, Novell wants
you to know about the second and third methods in this
list:
- Directory Server (Name Server) - a specific device on
the network can keep track of all name/address combinations, and
supply that information to requesters. This is like using a telephone
directory. This method will come into play later on.
- Service-Requester-Initiated Method - the entity requesting
a service sends a packet to the network that asks all entities who
match the packet to respond. The packet can request a match on a
name, an address or a service type. This is like the card game "Go
Fish", in which players ask each other who has certain cards.
- Service-Provider-Initiated Method - the providers of services
send advertising packets to the network, announcing their availability
to everyone. The packet included its name, address and the service
being advertised. This is like the card game "Pit", in which players
shout out what cards they have, entreating other players to trade
with them.
The next topic, Addressing, brings up the fact that an entity
may have several conversations going on at the same time, some
of which are with the same service provider. For instance, we may
wish two servers to communicate with each other, providing file access
to users on various workstations. Each workstation's request for files
is identified as part of an individual conversation. In this way,
the servers can keep track of multiple conversations (requests for
files, for example) going on with a specific process (a file transfer
service/process/socket/port, for example). Conversations between the
servers and their clients are also identified in this way.
Two methods are used to identify conversations:
- Connection Identifier - This can also be called a connection
ID, socket or port. It is a tag that identifies
an individual conversation between an entity and a service provider.
It is used for any number of requests and responses in a single,
ongoing conversation.
- Transaction Identifier (Transaction ID) - This is an identifier
that tags a request/response pair. It is more individual
than the connection identifier and is mainly used in Apple specific
networks.
Segment Development concerns the division or combination
of messages to fit into message clusters of a specific size, called
segments. If a message is too big to fit a segment, it is divided
into pieces small enough to fit into segments. If a message is too
small to fill a segment, it can be combined with other messages or
message fragments to fill a segment. This is done so we can send segments
that are all the same size, and reduce overhead.
The last topic is our old friend Connection Services. We
are using the same three types of connection services as in previous
chapters, just doing different things with them. The three types are:
- Unacknowledged Connectionless Services - no flow, error or packet
sequence control. No guarantee of delivery.
- Connection-oriented Services - flow, error and packet sequence
control. Guaranteed delivery.
- Acknowledged Connectionless Services - uses acknowledgments for
flow and error control. No sequence control needed, because of the
point-to-point style transmission.
The connection services used here have three purposes:
- Segment Sequencing - segments can be received out of order,
so segments are numbered by the sender, and can be re-sequenced
(reordered) by the receiver
- Error Control - Errors can be controlled at this level
three ways, often called end-to-end error control:
- Use only Virtual Circuits. This may also mean only
one for each session.
- Use unique segment numbers.
- Use time-outs. This means that we drop any packet that takes
too long to reach the recipient.
- End-to-End Flow Control - this phrase means that network
units between the sender and receiver do not participate
in flow control, only the sender and the receiver do. The receiver
may send an ACK (acknowledgment) or a NAK (negative acknowledgment).
It may also send a "go back n (number)" message to the sender
to advise the sender that the message was received, not received,
or please go back n messages, and continue from there. The
last possibility is that the recipient may send a selective repeat
acknowledgment, which asks for specific packets to be resent.
|