Other Upper-Layer Protocols
Various other upper-layer protocols play an important role in the success of the TCP/IP protocol suite as a flexible, well-rounded, self-contained group of protocols:
- UDP
- SMB
- AFP
- ICS
Hotspot Mikrotik 777
Technology has been used Bootstrap Compatible Mobile.
Design Hotspot-12 beautiful Server Mikrotik
Design Hot Spot Mikrotik Free
Hotspot login server free
Hotspot login server free.
Merge 2 lines in server Pfsense?
Merge 2 lines in server Pfsense server free.
setup squid cahce in Ubuntu
How to setup squid cahce in Ubuntu ?
Saturday, November 30, 2013
Other Upper-Layer Protocols
Other Upper-Layer Protocols
Various other upper-layer protocols play an important role in the success of the TCP/IP protocol suite as a flexible, well-rounded, self-contained group of protocols:
Line Printer Remote (LPR)
Line Printer Remote (LPR)
When using pure TCP/IP printing (as with UNIX workstations or when used for cross-platform printing), the LPD/LPR pairing is used most often. The Line Printer Daemon (LPD) is installed
on the print device and manages the printer as well as the print jobs. The Line Printer Remote (LPR) software is the printing client that sends the print jobs to the LPD via TCP/IP.
Internet Group Management Protocol (IGMP)
Internet Group Management Protocol (IGMP)
The Internet Group Management Protocol (IGMP) is a TCP/IP protocol that is used to manage IP multicast sessions. It uses special IGMP messages to learn the layout of the multicast groups
and which hosts belong to which groups. Additionally, the individual hosts in an IP network use IGMP messages to join and leave a multicast group. IGMP messages help keep track of group
membership and active multicast streams. IGMP is in its second version, as specified in RFC 2236, with a third version (RFC 3376), currently proposed.
Friday, November 29, 2013
Network Time Protocol (NTP)
Network Time Protocol (NTP)
Network Time Protocol (NTP), originally developed by Professor David Mills at the University of Delaware, is used to synchronize (or set) computer clocks to some standard time source, which is
usually a nuclear clock. This protocol (along with synchronization utilities) keeps all computers on a network set to the same time. Time synchronization is important because many transactions
are time and date stamped (in a database, for example). If the time on a server is out of synchronization with the time on two different computers, even by just a few seconds, the server will get confused. For example, one computer can seemingly enter a transaction, but the server will indicate that it occurred before it actually did. Because this time problem will crash the database server, it is important that these servers (and workstations) use NTP.
Hypertext Transfer Protocol Secure (HTTPS)
Hypertext Transfer Protocol Secure (HTTPS)
Hypertext Transfer Protocol Secure (HTTPS), also referred to as Secure Hypertext Transfer Protocol (which you will see abbreviated as SHTTP or S-HTTP), is a secure version of HTTP that provides a variety of security mechanisms to the transactions between a web browser and the server. HTTPS allows browsers and servers to sign, authenticate, and encrypt an HTTP message.
Hypertext Transfer Protocol (HTTP)
Hypertext Transfer Protocol (HTTP)
Hypertext Transfer Protocol (HTTP) is the command and control protocol used to manage communications between a web browser and a web server. When you access a web page on the
Internet or on a corporate intranet, you see a mixture of text, graphics, and links to other documents or other Internet resources. HTTP is the mechanism that opens the related document
when you select a link, no matter where that document is actually located.
Secure Shell (SSH)
Secure Shell (SSH)
The Secure Shell (SSH) protocol is used to establish a secure Telnet session over a standard TCP/IP connection. It is used to run programs on remote systems, log in to other systems, and move
files from one system to another, all while maintaining a strong, encrypted connection. It replaces such utilities as rsh and rlogin as well as Telnet.
Telnet
Telnet
Telnet is a terminal emulation protocol that provides a remote logon to another host over the network. It allows a user to connect to a remote host over a TCP/IP connection as if they were sitting
right at that host. Keystrokes typed into a Telnet program will be transmitted over a TCP/IP network to the host. The visual responses are sent back by the host to the Telnet client to be displayed.
Network File System (NFS)
Network File System (NFS)
UNIX systems are unique in the way they access files and are actually fairly elegant. The Network File System (NFS) Application layer protocol was originally designed to allow shared file
systems on UNIX servers to appear as local file systems on UNIX clients.
Line Printer Daemon (LPD)
Line Printer Daemon (LPD)
Another TCP/IP upper-layer service that is in widespread use is the Line Printer Daemon (LPD). It resides on a network printer or print server and responds to TCP/IP printing requests from the printing clients (known as LPR clients). It was developed as the printing services for UNIX. But, because of the tight marriage between UNIX and TCP/IP, the LPD service became the default
print service used with TCP/IP.
Note:
A daemon is a program that acts like a terminate and stay resident (TSR) application
by loading into memory and lurking there for any trigger that calls upon its services.
Internet Message Access Protocol, Version 4 (IMAP4)
Internet Message Access Protocol, Version 4 (IMAP4)
Internet Message Access Protocol (IMAP) allows users to download mail selectively, look at the message header, download just a part of a message, store messages on the e-mail server in a hierarchical structure, and link to documents and Usenet newsgroups. Search commands are also available so that users can locate messages based on their subject, header or content. IMAP has strong authentication features and supports the Kerberos authentication scheme originally developed at MIT. The current version of IMAP is version 4.
Lightweight Directory Access Protocol (LDAP)
Lightweight Directory Access Protocol (LDAP)
In large networks, most administrators have set up some kind of directory that keeps track of users and resources (e.g., NDS, Active Directory). In order to have a standard method of accessing
directories, the Lightweight Directory Access Protocol (LDAP) was developed. It allows clients to perform object lookups with a directory using a standard method. LDAP was originally
specified as RFCs 1487 (version 1) and 1777 (version 2), with RFC 3377 proposing the more commonly used third version, which fixes a number of shortcomings in the protocol.
Post Office Protocol (POP)
Post Office Protocol (POP)
Post Office Protocol (POP) provides a storage mechanism for incoming mail; the latest version of the standard is known as POP3. When a client connects to a POP3 server, all the messages
addressed to that client are downloaded; there is no way to download messages selectively. Once the messages are downloaded, the user can delete or modify messages without further interaction with the server. In some locations, POP3 is being replaced by another standard, IMAP.
Secure Copy Protocol (SCP)
Secure Copy Protocol (SCP)
While FTP is easy to use to transfer files, it has a major security problem in that the username and password are sent along with the file request in clear text (i.e., not encrypted). It would be a relatively simple matter for someone to intercept that information and use it for other purposes.
Secure Copy Protocol (SCP) was designed to overcome this limitation. It uses SSH to establish and maintain an encrypted connection between hosts. The file transfer can then take place
without fear of password or data interception.
Simple Mail Transfer Protocol (SMTP)
Simple Mail Transfer Protocol (SMTP)
Simple Mail Transfer Protocol (SMTP) allows for a simple e-mail service and is responsible for moving messages from one e-mail server to another. The e-mail servers run either Post Office
Protocol (POP) or Internet Mail Access Protocol (IMAP) to distribute e-mail messages to users.
Thursday, November 28, 2013
Network News Transfer Protocol (NNTP)
Network News Transfer Protocol (NNTP)
The Network News Transfer Protocol (NNTP) is the TCP/IP protocol used to access Usenet news servers. Usenet news servers contain thousands of individual message boards known as
newsgroups. Each newsgroup is about a particular subject (cars, dating, computers, etc.). Chances are, if you have an interest, there is a newsgroup about it. The details of the NNTP protocol
are specified in RFC 977.
Note:
Because of the relative complexity involved in configuring a news reader program,
there are many websites (including google.com) that have made newsgroup
access available through the Web.
Secure File Transfer Protocol (SFTP)
Secure File Transfer Protocol (SFTP)
Secure File Transfer Protocol (SFTP) is used when you need to transfer files over an encrypted connection. It uses an SSH session (more on this later) which encrypts the connection. The SFTP
protocol then is used to transfer files over this encrypted connection. Apart from that, it functions exactly as the FTP protocol does: It is used to transfer files between computers.
Trivial File Transfer Protocol (TFTP)
Trivial File Transfer Protocol (TFTP)
Trivial File Transfer Protocol (TFTP) is a “stripped down” version of FTP, primarily used to boot diskless workstations and to transfer boot images to and from routers. It uses a reduced feature set (fewer commands and a smaller overall program size). In addition to its reduced size, it also uses UDP instead of TCP, which makes for faster transfers but with no reliability.
File Transfer Protocol (FTP)
File Transfer Protocol (FTP)
File Transfer Protocol (FTP) provides a mechanism for single or multiple file transfers between computer systems; when written in lowercase as “ftp,” it is also the name of the client software used to access the FTP server running on the remote host. The FTP package provides all the tools needed to look at files and directories, change to other directories, and transfer text and binary files from one system to another. FTP uses TCP to actually move the files.
Note:
We’ll look at how to transfer files using FTP in detail in the next chapter.
Simple Network Management Protocol (SNMP)
Simple Network Management Protocol (SNMP)
Simple Network Management Protocol (SNMP) allows network administrators to collect information about the network. It is a communications protocol for collecting information about
devices on the network, including hubs, routers, and bridges. Each piece of information to be collected about a device is defined in a Management Information Base (MIB). SNMP uses UDP
to send and receive messages on the network.
Wednesday, November 27, 2013
The Application Protocols
The Application Protocols
Application layer protocols are built on top of and into the TCP/IP protocol suite and are available on most implementations. The following list includes such protocols:
SNMP FTP
TFTP SFTP
SMTP POP3
IMAP LPD
NFS Telnet
SSH HTTP
HTTPS NTP
NNTP SCP
LDAP IGMP
LPR
Tuesday, November 26, 2013
Routers and Routing
Routers and Routing
As you already know, routing is the process of getting your data from point A to point B. Routing datagrams is similar to driving a car. Before you drive off to your destination, you determine
which roads you will take to get there. And sometimes along the way, you may change your mind and alter your route.
The IP portion of the TCP/IP protocol inserts its header in the datagram, but before the datagram can begin its journey, IP determines whether it knows the destination. If it does, it sends
the datagram on its way. If it doesn’t know and can’t find out, IP sends the datagram to the host’s default gateway.
Note:
One key to understanding some of the original Internet documents, as well as some of the legacy terminology, is to realize that every router in the Internet was once referred to as a gateway. Therefore, a default gateway is really a default router.
Each host on a TCP/IP network can have a default gateway, an off-ramp for datagrams not destined for the local network. They’re going somewhere else, and the router’s job is to forward
them to that destination if it knows where it is. Each router has a defined set of routing tables that tell the router the route to specific destinations.
Because routers don’t know the location of every IP address, they have their own default gateways that act just like any TCP/IP host. In the event that the first router doesn’t know the
way to the destination, it forwards the datagram to its own default gateway. This forwarding, or routing, continues until the datagram reaches its destination. The entire path to the destination is known as the route.
Datagrams intended for the same destination may actually take different routes to get there. Many variables determine the route. For example, overloaded routers may not respond in a
All TCP/IP Devices Route
Technically, end devices and routers both work similarly when deciding what to do with an IP packet. In fact, any packet that leaves one of these devices toward a destination does so because the transmitting device knew what to do with it, even if it is sent out to the default gateway address. The default gateway is actually a statically or dynamically learned route entry, just like every other entry in the routing table. Any potential destination address is ANDed (ANDing is a Boolean algebra operator that produces a 0, unless two 1s are ANDed) with each route entry’s mask, the result compared to the entry’s network address. All matches are then
compared for the longest prefix length, which means the most 1s in the mask, which is the one chosen when more than one match is found. Since the default gateway’s entry always has a prefix length of 0, it will only be chosen when no other match is found, leading to the use of the word default. Therefore, even when the default gateway is used, it is because the destination is “known.” Any packet whose destination address produces no matches with the route entries in the routing table is dropped.
timely manner or may simply refuse to route traffic and so they time out. That time-out causes the sending router to seek an alternate route for the datagram.
Routes can be predefined and made static, and alternate routes can be predefined, providing a maximum probability that your datagrams travel via the shortest and fastest route.
Note:
If you configure the TCP/IP settings for a computer on a LAN that has a router through which the Internet is accessible, there are certain settings that must be made and others that just make life easier but without which reliable Internet access cannot be achieved. These are an IP address for the computer, a common subnet mask for the LAN, a default gateway IP address for the local router interface, and the address of a DNS server. While the last two settings are not technically mandatory, it’s easier to consider these four parameters as requirements than it is to explain the extra and meticulous configuration that must be made to get around the last two settings, which includes manual routing table manipulation and the use of hosts files.
Address Resolution Protocol (ARP) and Reverse ARP (RARP)
Address Resolution Protocol (ARP)
The Network layer protocol, ARP, associates the physical hardware address of a network node to its already known IP address. Using ARP, an IP process constructs a table (known as the ARP cache) that maps logical addresses to the hardware addresses of nodes on the local network. When a node needs to send a packet to a known IP address on the local subnet, it first checks the ARP cache to see if the physical address information is already present. If so, that address is used and network traffic is reduced; otherwise, a normal ARP request is made to determine the address.
Note:
See Chapter 4, “TCP/IP Utilities,” for more on ARP.
Reverse ARP (RARP)
is nothing more than ARP packets with different codes in the header, indicating to devices receiving RARP packets that these are requests by the source device for its own IP configuration, meaning RARP replies should be handled by a RARP server and that any device not fulfilling this role need not process these requests any further. If, however, the receiving device is a RARP server, it is incumbent upon that device to find the requesting device’s MAC address in a configured list (RARP is an older, manual process, unlike DHCP). The server sends the IP address it finds associated with the requesting MAC address back to the requesting device. RARP was adequate for diskless workstation initial IP configuration but fell short as an be-all, end-all supplier of detailed IP-related information, which is why DHCP has supplanted
RARP for supplying network-based IP configuration in most modern networks.
Internet Control Message Protocol (ICMP)
Internet Control Message Protocol (ICMP)
ICMP works at the Network layer and provides the functions used for Network layer management and control. Routers send ICMP messages to respond to undeliverable datagrams by placing
an ICMP message in an IP datagram and then sending the datagram back to the original source. The ping command—used in network troubleshooting and described in Chapter 5,
“Major Network Operating Systems”—uses ICMP.
The Internet Layer Protocols
The Internet Layer Protocols
The Internet layer of the DoD model is made up of various protocols, with the three main protocols being the Internet Protocol (IP), the Internet Control Message Protocol (ICMP), and the
Address Resolution Protocol (ARP). The following sections introduce these three protocols and provide more detail. And no discussion of things layer 3 would be complete without mentioning
routers and the process of routing.
The Internet Protocol
The Network layer portion of the DoD model is called the Internet layer. Not surprisingly, the main protocol at this layer is the Internet Protocol (IP). IP is what actually moves the data from point A to point B, a process that is called routing. IP is considered connectionless; that is, it does not swap control information (or handshaking information) in order to establish an end-to-end connection before starting a transmission. This is also known as best effort transmission. Additionally, if a packet is lost in transmission, IP must rely on TCP to determine if the data did not arrive successfully at its destination and, if not, to retransmit the entire segment, which could be more data than was carried by the lost packet
if IP had to fragment the segment. IP’s only job is to route the data to its destination. In this effort, IP inserts its own header in the datagram once it is received from TCP (or UDP or another
higher-layer protocol). The main contents of the IP header are the source and destination addresses, the protocol number, and a checksum.
Note:
IP is considered unreliable. This is because it contains no error detection or recovery capability, not because it is ndependable. For these reasons, UDP is also an unreliable protocol. Conversely, TCP is considered reliable.
Without the header provided by IP, intermediate routers between the source and destination— originally called gateways in the RFCs—would not be able to determine where to route the datagram. Figure 3.3 shows the layout of the datagram with the IP header in place, followed by the upper-layer header and data, which IP sees as just upper-layer information.
FIGURE 3 . 3 A datagram with TCP and IP headers
The fields in the IP header include the following:
Version Defines the IP version number. Version 4 is the current standard. IP version 6 is currently supported by the newest equipment and may quickly become the new standard.
IHL (Internet Header Length) Defines the length of the header information. The header length can vary; the standard header is five 32-bit words, and the sixth and subsequent words are for options and padding.
TOS (Type of Service) Originally, these eight bits were broken into four fields in the first six bits, with 0s in the last two bits. The first three bits are called the precedence bits and allow the specification of eight levels of priority, with 0 being lowest and 7 being highest. The next three bits specify normal or low delay, normal or high throughput, and normal or high reliability, depending on values of 0 or 1, respectively, meaning 0 is normal for each field. Note that a value of 1 for each of these bits would be preferred. In some implementations, the first six bits are collectively used for prioritization of traffic. When used for this purpose, the first six bits are called Differentiated Services Code Point (DSCP) bits. In still other implementations, the last two bits can be used to give TCP the ability to communicate congestion details, in which case they are
referred to as Explicit Congestion Notification (ECN) bits.
Note:
While all of this detail is pertinent to the TOS field, only a basic understanding is necessary for Network+ proficiency.
Total Length Specifies the total length of the datagram, which has no specified minimum but should be supported in all implementations up to 576 bytes. Being 16 bits, the length field can
specify a maximum packet length of 65,535 bytes.
Identification An identifying number that the receiving system can use to reassemble fragmented datagrams. Each fragment produced from the same datagram will bear the same identifying number in this field.
Flags When set to 1, the second flag bit specifies that the datagram should not be fragmented and must therefore travel over subnetworks that can handle the size without fragmenting it; the
third flag bit being set indicates that the packet is the last of a fragmented segment. When reset to 0, these two flags have the opposite meanings. The first flag bit is not used and always must
be set to 0.
Fragmentation Offset Indicates, in units of 8 octets (64 bits), the original position of the fragmented data and is used during reassembly. The first fragment of a set of fragmented packets
or non-fragmented packets have a value of 0 in this field, as you might expect.
Time to Live (TTL) Originally, the time in seconds that the datagram could be in transit; if this time was exceeded, the datagram was considered lost. Now interpreted as a hop count and
usually set to the default value of 32 (for 32 hops), this number is decremented by each router through which the packet passes. The router that decrements this field to 0, which is known as the executioner, drops the packet and sends an ICMP time exceeded message back to the original source of the packet.
Protocol Identifies the protocol whose header and data follow the IP header, allowing the interleaving or multiplexing of multiple protocols. For example, a value of 6 indicates TCP, a
value of 17 indicates User Datagram Protocol (UDP), and a value of 1 indicates ICMP. Multiplexing of upper-layer information means that one protocol, such as TCP, does not need to finish
its transmission before another, such as UDP, begins using the services of IP. Without the use of such a field, only one protocol could be used in any given implementation of IP.
Header Checksum An error-checking value that is recalculated at each packet processing point (for example, each router). Recalculation is necessary because certain IP header fields change, such as TTL. The checksum is computed only on the bits of the IP header, with the checksum field initially set to all 0s before the computation.
Source Address The 32-bit IP address of the original transmitting device. Note that this value can change along the path of transmission if certain technologies, such as Network Address
Translation (NAT), are in use.
Note:
NAT is the process of converting between the IP addresses used on a corporate intranet or other private network and Internet IP addresses. This process makes it possible to use a large number of addresses within the private network without depleting the limited number of available registered IP addresses. NAT is
usually performed within a router or firewall.
Destination Address The 32-bit IP address of the original destination device. This address can be altered along the transmission path in the same way as noted for the source address.
Options and Padding IP options are a set of variable fields that may or may not be present in each IP packet. While the presence of options is not mandatory, the support of all possible IP
options is required by each IP implementation. This means that if an IP host includes an option, all IP devices will understand it. Examples of standards-based options are Security, Record
Route, and Internet Timestamp. If any options are included in the IP header, it is necessary to verify that the IP header ends on a 32-bit boundary. If not, it is necessary to pad with 0s at the end of the last option, until the total length of the IP header is a multiple of 32 bits.
Upper-Layer Information The header and user data handed down by a protocol, such as TCP. The header will not appear for non-initial IP fragments. The data in the packet immediately follows this header information, which may correspond to a complete TCP segment, UDP datagram, or other IP-supported PDU or to a portion thereof when fragmentation has occurred.
Monday, November 25, 2013
The Transmission Control Protocol
The Transmission Control Protocol
TCP is the Transport layer of the protocol and serves to ensure a reliable, verifiable data exchange between hosts on a network. TCP breaks data into pieces, wraps the pieces with the information needed to identify it as a piece of the original message, and allows the pieces to be reassembled at the receiving end of the communications link. The wrapped and bundled pieces are called datagrams. Datagrams are also referred to as segments for TCP due to the way it often splits the original data into more manageable chunks. The most important information in the header includes the source and destination port numbers, a sequence number for the datagram, and a checksum.
The source port number and the destination port number ensure that the data is sent back and forth to the correct application process running on each computer. The sequence number allows the datagrams to be rebuilt in the correct order in the receiving device, and the checksum allows the protocol to check whether the data sent is the same as the data received. It performs this last feat by running the bits of the segment through a complex polynomial expression and inserting the resulting number in the header. This is when IP enters the picture. Once the header is on the datagram, TCP passes the datagram to IP to be routed to its destination. The receiving device then performs the same calculation, and if the two calculations do not match, an error has occurred somewhere along the line and the datagram is silently discarded by the destination device and resent by the source device after its timer expires waiting for a positive acknowledgment that never arrives.
Figure 3.2 shows the layout of the datagram with the TCP header in place.
In addition to the source and destination port numbers, the sequence number, and the checksum, a TCP header contains the following information:
Acknowledgment Number Indicates that the data was received successfully. If the datagram is damaged in transit, the receiver throws the data away and does not send an acknowledgment
back to the sender. After a predefined time-out expires, the sender retransmits the data for which no acknowledgment was received. Only positive forward acknowledgments are sent in TCP. Positive means that only successful transmissions are acknowledged. Forward means that the acknowledgment number represents the next sequence number the destination device expects to receive.
Offset Specifies the length of the header in 32-bit chunks.
Reserved This field specifies variables that are set aside for future use. This field must contain zeros.
Flags These are six one-bit fields that indicate various things, such as whether this segment is the end of the higher-layer message, that the acknowledgment number is significant, that the sender is requesting that a virtual circuit with the receiver be established or torn down, or that the data in the segment is urgent.
Window Provides a way to increase the number of segments transmitted before the sender expects an acknowledgment, which improves efficiency in data transfers. Conversely, decreasing
the value of this field can indicate that network problems endanger the integrity of the data so more segments need to be acknowledged until conditions improve.
Urgent Pointer Gives the location in the segment where the urgent data ends, assuming the urgent data begins at the beginning of the segment. This allows out-of-band transmission of special
data, signifying to the receiving device that this data should be pushed ahead of any other that it has received but has not yet processed. Special data could include keyboard break sequences in
a Telnet session, which should immediately be processed by the receiving device in order to discontinue potentially harmful processing of previously received data. In light of this use, it makes
sense that the transmitting device would place such critical control information at the beginning of a new, emerging segment.
in the first segment during connection establishment. Later RFCs specify additional options. The latest list of TCP options can be found on the web site for the Internet Assigned Numbers Authority (www.iana.org/assignments/tcp-parameters).
Padding Ensures that the header ends on a 32-bit boundary so that the offset field makes sense as a whole number.
The data in the segment immediately follows this header information.
The Actual Use of TCP Communications
The following list summarizes the TCP process:
- Flow control allows two systems to cooperate in datagram transmission to prevent overflows and lost segments.
- Acknowledgment lets the sender know that the recipient has received the information.
- Sequencing ensures that segments arrive in the proper order.
- Checksums allow easy detection of corrupted segments.
- Retransmission of lost or corrupted segments is managed in a timely way.
TCP/IP and the OSI Model
TCP/IP and the OSI Model
As you learned in Chapter 2, “The OSI Model,” the OSI model divides computer-to-computer communications into seven connected layers; TCP/IP uses the Department of Defense (DoD)
model, which describes communications in only four layers, as Figure 3.1 shows. Each successively higher layer builds on the functions provided by the layers below.
Note:
The DoD model has fewer layers than the OSI model has, but that does not mean that it has less functionality. We draw the models to the same height because all data communications functionality is there. The DoD model simply combines the functionality of those layers into “larger” layers whose protocols perform all related functions of the equivalent OSI layers. Remember, that’s part of the OSI reference model’s success. Even though the original protocols never really caught on, the model itself is at once generic in its description of
protocol functionality and specific in its separation of communications tasks into more layers than just about any other model.
FIGURE 3 . 1 A comparison of the seven-layer OSI model, the four-layer DoD model, and how TCP/IP maps to each model
As you may remember from Chapter 2’s discussion of the OSI model, the layers are as follows:
Application Layer The highest layer; defines the manner in which applications interact with the network—including databases, e-mail, and terminal-emulation programs using Application layer protocols similar to Lightweight Directory Access Protocol (LDAP), Simple Mail Transfer Protocol (SMTP), and Telnet.
Presentation Layer Defines the way in which data is formatted, presented, converted, and encoded.
Session Layer Coordinates communications and maintains the session for as long as it is needed—performing security, logging, and administrative functions.
Transport Layer Defines protocols for structuring messages and supervises the validity of the transmission by performing error checking.
Network Layer Defines data-routing protocols to increase the likelihood that the information arrives at the correct destination node.
Data Link Layer Validates the integrity of the flow of the data from one node to another by synchronizing blocks of data and controlling the flow.
Physical Layer Defines the mechanism for communicating with the transmission medium and the interface hardware.
Note:
Although no commercially available networking protocol suite follows the OSI model exactly, most perform all the same functions.
In the DoD model, the four layers are as follows:
Process/Application Layer The highest layer; applications such as FTP, Telnet, and others interact through this layer. Corresponds to the top three layers of the OSI model.
Host-to-Host Layer TCP and UDP add transport control information to the user data. Corresponds to the Transport layer of the OSI model.
Internet Layer Adds IP information to form a packet. Corresponds to the Network layer of the OSI model.
Network Access Layer Defines the mechanism for communicating with the transmission medium and the interface hardware. Corresponds to the bottom two layers of the OSI model.
Each layer adds its own header and, in the case of Data Link protocols, trailer control information to the basic data structure and encapsulates the protocol data unit (PDU) from the layer
above. On the receiving end, this header and trailer information is stripped, one layer at a time, until the equivalent of the original data arrives at its final destination.
Note:
PDU is a generic term used to describe the end product of a protocol. It can be thought of as the entire data structure handed down by that protocol to the protocol at the next lowest layer, or the information placed on the network media by the Physical layer. A PDU will consist of the original user data and any upper-layer control information (headers and trailers) imposed by upper-layer protocols encapsulated by the control information of the protocol creating the PDU.
Now let’s look at how TCP and IP work together.
TCP/IP Design Goals
TCP/IP Design Goals
When the U.S. Department of Defense began to define the TCP/IP network protocols, their design goals included the following:
- TCP/IP had to be independent of all hardware and software manufacturers. Even today, this is fundamentally why TCP/IP makes such good sense in the corporate world: It is not tied to IBM, Novell, Microsoft, DEC, or any other specific company.
- It had to have good built-in failure recovery. Because TCP/IP was originally a military proposal, the protocol had to be able to continue operating even if large parts of the network suddenly disappeared from view, say, after an enemy attack.
- It had to handle high error rates and still provide completely reliable end-to-end service. It had to be efficient and have a low data overhead. The majority of IP packets have a simple, 20-byte header, which means better performance in comparison with other networks. A simple protocol translates directly into faster transmissions, giving more efficient service. It had to allow the addition of new networks without any service disruptions.
As a result, TCP/IP was developed with each component performing unique and vital functions that allowed all the problems involved in moving data between machines over networks
to be solved in an elegant and efficient way. Before looking at both TCP and IP individually, you should understand where TCP/IP fits into the broader world of network protocols and, particularly,
how it compares to the theoretical reference model published by the International Organization for Standardization (ISO) as the OSI model.
The popularity that the TCP/IP family of protocols enjoys today did not arise just because the protocols were there, or even because the U.S. government mandated their use. They are popular because they are robust, solid protocols that solve many of the most difficult networking problems and do so in an elegant and efficient way.
The Internet, an internet, an intranet, and an extranet
The title of this sidebar may be a bit confusing and look a bit informal with the odd capitalization, but it’s for a very good reason. While internet is a truncated version of internetwork, a lot of play has come from the root of these words. Let’s examine the word internetwork first, just to make sure we understand where all the variants come from. As you know, a network is a conglomeration
of devices tied together with a common technology. Well, once you establish two or more of these networks, work can be started on bringing them together. The interconnection and intercommunication between these autonomous networks is known as an internetwork or just internet. We know we have an internet when we use routers or other layer 3 devices to interconnect the networks. What kind of fun can we have with these words?
First of all, just by capitalizing the word internet to form Internet, we get the proper name of the global commercial internetwork that is tied together by TCP/IP (actually, all of these entities are)
and that has a scope of the planet we call home. If those Mars rovers have IP addresses, the scope suddenly gets a bit grander. That’s the flexibility of TCP/IP for you. What if we analyze the
meaning of inter? An internet is connectivity and communication across network boundaries. Does that mean, then, that an intranet is connectivity and communication within a network?
Gotcha. An intranet is more an opposite of the Internet, in terms of scope. If the Internet spans many administrative boundaries, encompassing many disparate networks, then an intranet,
while often an internet (how’s that for a catch?), encompasses only networks under a single administrative domain, a large corporation’s internal internetwork. Did you catch that? An intranet can be an internet, but not the Internet. Fun, huh?
Well, then, that just leaves extranet. Think of an extranet as an intranet becoming a very controlled Internet. That is, if an intranet is made up of all networks under a single administrative control, then an extranet is the expansion of that to include one, two, or just a few additional outside networks. Said differently, an extranet is an intranet interconnected and intercommunicating with networks that are under separate administrative control. This isn’t nearly as
unruly as the Internet, because this interconnectivity arose from some sort of partnership or affiliation between the parties. Let’s say, for instance, that a manufacturing company wants to have a vendor monitor its inventory so that whenever materials that the vendor supplies reach a minimum threshold, an order can be generated automatically, without personnel from the manufacturing company getting involved. That would require some sort of limited vendor access to internal manufacturing company resources. While the manufacturing company wants the vendor to have access to all that they need to help automate the supply process, they don’t want the vendor accessing sensitive financial, personnel, or possibly engineering information. By tweaking the firewalls just so, the vendor’s trusted network assets can be allowed access to the manufacturing company’s inventory control system but nothing else. That’s an extranet. While there’s a big difference between them all, they are all very similar. They are all generally TCP/IP internetworks.
Benefits of Using TCP/IP over Other Networking Protocols
There are several benefits to using the TCP/IP networking protocol:
- TCP/IP is a widely published open standard and is completely independent of any hardware or software manufacturer.
- TCP/IP can send data between different computer systems running completely different operating systems, from small PCs all the way to mainframes and everything in between.
- TCP/IP is separated from the underlying hardware and will run over Ethernet, Token Ring, and X.25 networks, to name a few, and even over dial-up telephone lines.
- TCP/IP is a routable protocol, which means it can send datagrams over a specific route, thus reducing traffic on other parts of the network.
- TCP/IP has reliable and efficient data-delivery mechanisms.
- TCP/IP uses a common addressing scheme. Therefore, any system can address any other system, even in a network as large as the Internet. (We will look at this addressing scheme in the section “Understanding IP Addressing” later in this chapter.)
A Brief History of TCP/IP
A Brief History of TCP/IP
The first Request for Comments (RFC) was published in April 1969, laying the groundwork for today’s Internet, the protocols of which are specified in the numerous RFCs monitored,
ratified, and archived by the Internet Engineering Task Force (IETF). TCP/IP was first proposed in 1973 and was split into separate protocols, TCP and IP, in 1978. In 1983, TCP/IP
became the official transport mechanism for all connections to ARPAnet, a forerunner of the Internet, replacing the earlier Network Control Protocol (NCP). ARPAnet was developed by
the Department of Defense’s (DoD’s) Advanced Research Projects Agency (ARPA), formed in 1957 in response to the Soviet Union’s launch of Sputnik and later renamed the Defense Advanced Research Projects Agency (DARPA), which was split into ARPAnet and MILNET in 1983 and disbanded in 1990.
Much of the original work on TCP/IP was done at the University of California, Berkeley, where computer scientists were also working on the Berkeley version of UNIX (which eventually grew into the Berkeley Software Distribution [BSD] series of UNIX releases). TCP/IP was added to the BSD releases, which in turn was made available to universities and other institutions for the cost of a distribution tape. Thus, TCP/IP began to spread in the academic world, laying the foundation for today’s explosive growth of the Internet and of intranets as well.
During this time, the TCP/IP family continued to evolve and add new members. One of the most important aspects of this growth was the continuing development of the certification and
testing program carried out by the U.S. government to ensure that the published standards, which were free, were met. Publication ensured that the developers did not change anything or
add any features specific to their own needs. This open approach has continued to the present day; use of the TCP/IP family of protocols virtually guarantees a trouble-free connection
between many hardware and software platforms.
Introducing TCP/IP
Introducing TCP/IP
Because TCP/IP is so central to working with the Internet and with intranets, you should understand it in detail. We’ll start with some background on TCP/IP and how it came about and then move on
to the descriptions of the technical goals defined by the original designers. Then you’ll get a look at how TCP/IP compares to a theoretical model, the Open Systems Interconnect (OSI) model.
Sunday, November 24, 2013
TCP/IP Fundamentals Network+ Chapter 3
Network+™
"Quoting one of e-books"
Chapter 3 :
TCP/IP Fundamentals
*************
"Quoting one of e-books"
