tyt01fi.htm

快速学习TCP/IP协议

<BR>

<P>Confusing? Believe it or not, after a while you will begin to feel more comfortable with these terms. The important ones to know now are that a layer provides a set of entities through a service access point to the next higher layer, which is called the service user<I>.</I> The data is sent in chunks called service data, made up of service data units.

<BR>

<BR>

<A ID="E69E26" NAME="E69E26"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Queues and Connections</B></FONT></CENTER></H4>

<BR>

<P>Communication between two parties (whether over a telephone, between layers of an architecture, or between applications themselves) takes place in three distinct stages: establishment of the connection, data transfer, and connection termination.

<BR>

<P>Communication between two OSI applications in the same layer is through queues to the layer beneath them. Each application (more properly called a service user) has two queues, one for each direction to the service provider of the layer beneath (which controls the whole layer). In OSI-speak, the two queues provide for simultaneous (or <I>atomic</I>) interactions between two N-service action points.

<BR>

<P>Data, called <I>service primitives,</I> is put into and retrieved from the queue by the applications (service users). A service primitive can be a block of data, an indicator that something is required or received, or a status indicator. As with most aspects of OSI, a lexicon has been developed to describe the actions in these queues:

<BR>

<P>A <I>request primitive</I> is when one service submits a service primitive to the queue (through the N-SAP) requesting permission to communicate with another service in the same layer.

<P>An <I>indication primitive</I> is what the service provider in the layer beneath the sending application sends to the intended receiving application to let it know that communication is desired.

<P>A <I>response primitive</I> is sent by the receiving application to the layer beneath's service provider to acknowledge the granting of communications between the two service users.

<BLOCKQUOTE>

<BLOCKQUOTE>

<P>A <I>confirmation primitive</I> is sent from the service provider to the final application to indicate that both applications on the layer above can now communicate.

<BR>

</BLOCKQUOTE></BLOCKQUOTE>

<P>An example might help clarify the process. Assume that two applications in the presentation layer want to communicate with each other. They can't do so directly (according to the OSI model), so they must go through the layer below them. These steps are shown in Figure 1.9.

<BR>

<P><B><A HREF="01tyt09.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/01tyt09.gif">Figure 1.9. Two applications communicate through </B><B>SAPs using primitives.</A></B>

<BR>

<P>The first application sends a request primitive to the service provider of the session layer and waits. The session layer's service provider removes the request primitive from the inbound queue from the first application and sends an indication primitive to the second application's inbound queue.

<BR>

<P>The second application takes the indication primitive from its queue to the session service provider and decides to accept the request for connection by sending a positive response primitive back through its queue to the session layer. This is received by the session layer service provider, and a confirmation primitive is sent to the first application in the presentation layer. This is a process called <I>confirmed service</I> because the applications wait for confirmation that communications are established and ready.

<BR>

<P>OSI also provides for <I>unconfirmed service,</I> in which a request primitive is sent to the service provider, sending the indication primitive to the second application. The response and confirmation primitives are not sent. This is a sort of &quot;get ready, because here it comes whether you want it or not&quot; communication, often referred to as <I>send and pray.</I>

<BR>

<P>When two service users are using confirmed service to communicate, they are considered connected. Two applications are talking to each other, aware of what the other is doing with the service data. OSI refers to the establishment and maintenance of <I>state information</I> between the two, or the fact that each knows when the other is sending or receiving. OSI calls this <I>connection-oriented</I> or <I>connection-mode</I> communications.

<BR>

<P><I>Connectionless</I> communication is when service data is sent independently, as with unconfirmed service. The service data is self-contained, possessing everything a receiving service user needs to know. These service data packets are often called <I>datagrams.</I> The application that sends the datagram has no idea who receives the datagram and how it is handled, and the receiving service users have no idea who sent it (other than information that might be contained within the datagram itself). OSI calls this <I>connectionless-mode.</I>

<BR>

<P>OSI (and TCP/IP) use both connected and connectionless systems between layers of their architecture. Each has its benefits and ideal implementations. All these communications are between applications (service users) in each layer, using the layer beneath to communicate. There are many service users, and this process is going on all the time. It's quite amazing when you think about it.

<BR>

<BR>

<A ID="E68E9" NAME="E68E9"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Standards</B></FONT></CENTER></H3>

<BR>

<P>People don't question the need for rules in a board game. If you didn't have rules, each player could be happily playing as it suits them, regardless of whether their play was consistent with that of other players. The existence of rules ensures that each player plays the game in the same way, which might not be as much fun as a free-for-all. However, when a fight over a player's actions arises, the written rules clearly indicate who is right. The rules are a set of standards by which a game is played.

<BR>

<P>Standards prevent a situation arising where two seemingly compatible systems really are not. For example, 10 years ago when CP/M was the dominant operating system, the 5.25-inch floppy was used by most systems. But the floppy from a Kaypro II couldn't be read by an Osbourne I because the tracks were laid out in a different manner. A utility program could convert between the two, but that extra step was a major annoyance for machine users.

<BR>

<P>When the IBM PC became the platform of choice, the 5.25-inch format used by the IBM PC was adopted by other companies to ensure disk compatibility. The IBM format became a de facto standard, one adopted because of market pressures and customer demand.

<BR>

<BR>

<A ID="E69E27" NAME="E69E27"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Setting Standards</B></FONT></CENTER></H4>

<BR>

<P>Creating a standard in today's world is not a simple matter. Several organizations are dedicated to developing the standards in a complete, unambiguous manner. The most important of these is the International Organization for Standardization, or ISO (often called the International Standardization Organization to fit their acronym, although this is incorrect). ISO consists of standards organizations from many countries who try to agree on international criterion. The American National Standards Institute (ANSI), British Standards Institute (BSI), Deutsches Institut fur Normung (DIN), and Association Francaise du Normalization (AFNOR) are all member groups. The ISO developed the Open Systems Interconnection (OSI) standard that is discussed throughout this book.

<BR>

<P>Each nation's standards organization can create a standard for that country, of course. The goal of ISO, however, is to agree on worldwide standards. Otherwise, incompatibilities could exist that wouldn't allow one country's system to be used in another. (An example of this is with television signals: the US relies on NTSC, whereas Europe uses PAL&#151;systems that are incompatible with each other.)

<BR>

<P>Curiously, the language used for most international standards is English, even though the majority of participants in a standards committee are not from English-speaking countries. This can cause quite a bit of confusion, especially because most standards are worded awkwardly to begin with.

<BR>

<P>The reason most standards involve awkward language is that to describe something unambiguously can be very difficult, sometimes necessitating the creation of new terms that the standard defines. Not only must the concepts be clearly defined, but the absolute behavior is necessary too. With most things that standards apply to, this means using numbers and physical terms to provide a concrete definition. Defining a 2x4 piece of lumber necessitates the use of a measurement of some sort, and similarly defining computer terms requires mathematics.

<BR>

<P>Simply defining a method of communications, such as TCP/IP, would be fairly straightforward if it weren't for the complication of defining it for open systems. The use of an open system adds another difficulty because all aspects of the standard must be machine-independent. Imagine trying to define a 2x4 without using a measurement you are familiar with, such as inches, or if inches are adopted, it would be difficult to define inches in an unambiguous way (which indeed is what happens, because most units of length are defined with respect to the wavelength of a particular kind of coherent light).

<BR>

<P>Computers communicate through bits of data, but those bits can represent characters, numbers, or something else. Numbers could be integers, fractions, or octal representations. Again, you must define the units. You can see that the complications mount, one on top of the other.

<BR>

<P>To help define a standard, an abstract approach is usually used. In the case of OSI, the meaning (called the semantics) of the data transferred (the abstract syntax) is first dealt with, and the exact representation of the data in the machine (the concrete syntax) and the means by which it is transferred (transfer syntax) are handled separately. The separation of the abstract lets the data be represented as an entity, without concern for what it really means. It's a little like treating your car as a unit instead of an engine, transmission, steering wheel, and so on. The abstraction of the details to a simpler whole makes it easier to convey information. (&quot;My car is broken&quot; is abstract, whereas &quot;the power steering fluid has all leaked out&quot; is concrete.)

<BR>

<P>To describe systems abstractly, it is necessary to have a language that meets the purpose. Most standards bodies have developed such a system. The most commonly used is ISO's Abstract Syntax Notation One, frequently shortened to ASN.1. It is suited especially for describing open systems networking. Thus, it's not surprising to find it used extensively in the OSI and TCP descriptions. Indeed, ASN.1 was developed concurrently with the OSI standards when it became necessary to describe upper-layer functions.

<BR>

<P>The primary concept of ASN.1 is that all types of data, regardless of type, size, origin, or purpose, can be represented by an object that is independent of the hardware, operating system software, or application. The ASN.1 system defines the contents of a datagram protocol header&#151;the chunk of information at the beginning of an object that describes the contents to the system. (Headers are discussed in more detail in the section titled &quot;Protocol Headers&quot; later in this chapter.)

<BR>

<P>Part of ASN.1 describes the language used to describe objects and data types (such as a data description language in database terminology). Another part defines the basic encoding rules that deal with moving the data objects between systems. ASN.1 defines data types that are used in the construction of data packets (datagrams). It provides for both structured and unstructured data types, with a list of 28 supported types.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>

<IMG SRC="note.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/note.gif" WIDTH = 75 HEIGHT = 46>Don't be too worried about learning ASN.1 in this book. I refer to it in passing in only a couple of places. It is useful, though, to know that the language is provided for the formal definition of all the aspects of TCP/IP.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<BR>

<A ID="E69E28" NAME="E69E28"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Internet Standards</B></FONT></CENTER></H4>

<BR>

<P>When the Defense Advanced Research Projects Agency (DARPA) was established in 1980, a group was formed to develop a set of standards for the Internet. The group, called the Internet Configuration Control Board (ICCB) was reorganized into the Internet Activities Board (IAB) in 1983, whose task was to design, engineer, and manage the Internet.

<BR>

<P>In 1986, the IAB turned over the task of developing the Internet standards to the Internet Engineering Task Force (IETF), and the long-term research was assigned to the Internet Research Task Force (IRTF). The IAB retained final authorization over anything proposed by the two task forces.

<BR>

<P>The last step in this saga was the formation of the Internet Society in 1992, when the IAB was renamed the Internet Architecture Board. This group is still responsible for existing and future standards, reporting to the board of the Internet Society.

<BR>

<P>After all that, what happened during the shuffling? Almost from the beginning, the Internet was defined as &quot;a loosely organized international collaboration of autonomous, interconnected networks,&quot; which supported host-to-host communications &quot;through voluntary adherence to open protocols and procedures&quot; defined in a technical paper called the Internet Standards, RFC 1310,2. That definition is still used today.

<BR>

<P>The IETF continues to work on refining the standards used for communications over the Internet through a number of working groups, each one dedicated to a specific aspect of the overall Internet protocol suite. There are working groups dedicated to network management, security, user services, routing, and many more things. It is interesting that the IETF's groups are considerably more flexible and efficient than those of, say, the ISO, whose working groups can take years to agree on a standard. In many cases, the IETF's groups can form, create a recommendation, and disband within a year or so. This helps continuously refine the Internet standards to reflect changing hardware and software capabilities.

<BR>

<P>Creating a new Internet standard (which happened with TCP/IP) follows a well-defined process, shown schematically in Figure 1.10. It begins with a request for comment (RFC). This is usually a document containing a specific proposal, sometimes new and sometimes a modification of an existing standard. RFCs are widely distributed, both on the network itself and to interested parties as printed documents. Important RFCs and instructions for retrieving them are included in the appendixes at the end of this book.

<BR>

<P><B><A HREF="01tyt10.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/01tyt10.gif">Figure 1.10. The process for adopting a new </B><B>Internet standard.</A></B>

<BR>

<P>The RFC is usually discussed for a while on the network itself, where anyone can express their opinion, as well as in formal IETF working group meetings. After a suitable amount of revision and continued discussion, an <I>Internet draft</I> is created and distributed. This draft is close to final form, providing a consolidation of all the comments the RFC generated.

<BR>

<P>The next step is usually a <I>proposed standard,</I> which remains as such for at least six months. During this time, the Internet Society requires at least two independent and interoperable implementations to be written and tested. Any problems arising from the actual tests can then be addressed. (In practice, it is usual for many implementations to be written and given a thorough testing.)

<BR>

<P>After that testing and refinement process is completed, a <I>draft standard</I> is written, which remains for at least four months, during which time many more implementations are developed and tested. The last step&#151;after many months&#151;is the adoption of the standard, at which point it is implemented by all sites that require it.

<BR>

<BR>

<A ID="E68E10" NAME="E68E10"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Protocols</B></FONT></CENTER></H3>

<BR>

<P>Diplomats follow rules when they conduct business between nations, which you see referred to in the media as protocol. Diplomatic protocol requires that you don't insult your hosts and that you do respect local customs (even if that means you have to eat some unappetizing dinners!). Most embassies and commissions have specialists in protocol, whose function is to ensure that everything proceeds smoothly when communications are taking place. The protocol is a set of rules that must be followed in order to &quot;play the game,&quot; as career diplomats are fond of saying. Without the protocols, one side of the conversation might not really understand what the other is saying.

<BR>

<P>Similarly, computer protocols define the manner in which communications take place. If one computer is sending information to another and they both follow the protocol properly, the message gets through, regardless of what types of machines they are and what operating systems they run (the basis for open systems). As long as the machines have software that can manage the protocol, communications are possible. Essentially, a computer protocol is a set of rules