Error Control is a mechanism which is used to detect the invalid or corrupted or damaged segments and correction is also the part of error control but it is much better to control the errors than that of its correction i.e. let the error to occur and then we correct it is not the right choice .In that case if the segment which we have send is not delivered to the host system, we are using the same channel for retransmission there is loss of time ,loss of channel for other purposes, loss of bandwidth so we can say that if we have already controlled the error upto the extent where we can have it it is better for the data communication because we can not say that there will be no error in transmission whether we have done error control of the data, but there are still chances of error to occur but if we have controlled the error than there are less chances to get errors there are three different methods of error control and these are:-
As the above diagram shows that client is sending only the acknowledgement to server as it has nothing for piggybacking i.e. Ack:5001, Ack:7001.but the very first one is piggybacked where with the acknowledgement there is also sequence of data. Now the server is sending the ack:1401 that it has received everything upto 1400 and it demands for 1401 and also the segment sequence from 4001-5000.Now client has to wait for 500 ms before sending the acknowledgement to the server it waits for 500 ms and then sends the acknowledgement now server sends the segment with acknowledgement but within next 500 ms it receives another segment and it finally sends the acknowledgement that it has received everything upto 7000. It is normal Operation of transmission.
There are some scenarios where we need retransmission and these are as follows:
Lost Segment
Upto the acknowledgement 701 everything is fine, but when the segment 701-800 is lost the RTO is running for a particular time to receive the acknowledgement of seq:701-800 .In the mean time it receives the seq:801-900 but it again gives the ack for Seq:601-700. Now when the timer expires it retransmits the Seq:701-800 it then receives the acknowledgement that it has received everything upto 900.Here RTO plays important role.
Fast retransmission
In this case upto sequence number 201-300 all is right . Now the next sequence is lost but sender is sending the data continuously with seq number 401-500,501-600,601-700 but receiver will send the ack only for 301 that it has received upto 300 now when there are three acks the sender will again retransmit the segment which is just next to the seq:201-300 i.e.301-400 then the receiver will send the ack that it has received everything upto 701. It does not wait for the RTO to expire.
Delayed Segment
Duplicate Segment
A Continous stream of bytes is expected when a segment arrives which carry sequence number less than the previously acknowledged it is treated as duplicate.
Automatically corrected Lost Ack
In this lost acknowledgement is not given priority because if any ack is lost it is automatically corrected by the next one as in this case 701 is lost but 901 is delivered which means that that upto 700 is also delivered.
Quote examples in terms of Computer Networks, focusing on the concept of Uni, Multi & Broadcasting.
Unicast
In computer networks the unicast means the data which is meant for host to host i.e. the data is sent from host to host only. Let take the example that the system a sends the data which is meant for system d which is connected to router 4 while the system a with router 1 is not directly connected to the router 4 i.e the data will move from router 1 to router 4 through the router 2 and router 3 and will reach the router 4 and router 4 will send it to the system d only .
Multicast
In multicasting the no of destinations are more than that of one. The source address is the unicast address but the destination addresses are the group of addresses. Group address defines the members of the group. In multicasting router may forward the packet through various interfaces as in the unicast it is just the single interface. Here G1 is the Group which has more than one destination. The type of relationship is one to many.
Broadcasting
Broadcasting means a single source but the destination is all the systems connected to it that is it is one to all communication in computer networks .Router forwards packets through various interfaces.
Enlighten upon the various trees/ procedures used in Multicast Routing. Diagrammatic representation of all of them is a must.
Tree has roots and leaves here in computer networks in multicast routing we are taking the roots as source and the leaves as the desired destinations and there are different trees and procedures
Optimal Routing: Shortest Path Trees
Shortest path trees are successful in case of unicast routing because in unicast routing The domain has table containing the shortest path to the desired destinations. In multicast routing the case is different because it is possible that the destinations may be in different networks. If we have x groups then we need x shortest paths, this problem can be resolved with the help of two types of trees which are used in multicast routing and these are:
Source-Based Tree
Group-Shared Tree
Source-Based Tree
In source based tree each router has to maintain the shortest path for each group. As we can see in the diagram that the router table for R1 is defined and it shows that G1 is in four groups and if the destination is G1 than it will choose the shortest path of router R2 and R4 similarly for G2,G3,G4,G5 is defined. In this case the complexity is more as each router has to remember the shortest path for every group .
Group-Shared Tree
In this case instead of each router having the shortest path for each group a single core router is used which has the responsibility of distributing the multicast traffic.The core router contains all the shortest paths the rest other routers contains no record of shortest path for the group.
PART-B
Mention a few points in favour of DHCP in comparison to Static Host Configuration & BOOTP. Take a sample network and write down the step by step procedure of allocating IP to a host dynamically. All settings of host and server should be mentioned.
Static Ip addressing
DHCP has various advantages rather than providing the static ip address to the clients and advantages may be defined as follows:-
If the client is configured with WINS configuration and if by any cause the WINS configuration gets corrupted then ipconfig demands the reregistration to the WINS server, but if we are using DHCP configuration it will reregister automatically.
If we are using static ip addressing then we have to restart the system in order to reregister but if we are using DHCP it will reregister itself automatically.
Bootp
In bootp configuration each client or host is provided a single ip address and that address is only usable for that client only no one othercan use it. We have to do the one-one mapping in case of bootp configuration but in DHCP we don't need to do mapping for one-one.DHCP dynamically provide the ip to the client and it will be for that machine until we delete the address reservation.
DHCP uses the same ports which are meant for BOOTP configuration i.e.
Port 67 for sending data to the client
Port 68 for sending data to the client
DHCP communications are connectionless in nature. In order to provide an ip to a host dynamically there are four different steps involved and these are:-
DHCP discovery
DHCP offer
DHCP request
DHCP acknowledgement
DHCP discovery
The client broadcasts to find out the available dhcp servers. Client implements the udp packet with the broadcast destination 255.255.255.255 or the specific subnet broadcast address. Client can also request for the last ip address if it is not provided to some other client in between that period of time. An authoritative server will deny the request while non-authoritative will deny the request.
DHCP offer
It reserves an IP address for the client and extends an IP lease offer by sending the message to the client "DHCPOFFER". It contains the client's MAC address ,the ip address that server is offering to the client, Subnet mask, lease duration, and also the ip address of the DHCP server. Server determines the configuration as given in the "CHADDR".
DHCP request
Client can receive DHCP offers from various servers , But it will accept only one DHCP offer .Servers are informed that whose request has been accepted by the client. Other servers than discard their offers . DHCP request is broadcast instead of being unicast to a particular server.
DHCP acknowledgement
It involves sending a "DHCPACK" packet to the client. This includes lease duration and other information which has been requested by the client. At this point the IP address configuration has been completed.
Mention a few points in favour of using DNS in comparison to WINS or using IP addresses. Take a sample network and write down the step by step procedure of resolving an IP to URL and vice versa. All settings of host and server should be mentioned.
Name the various name servers and locate the location where entries of root servers is made in a particular host.
The following is the default list of root hints.
A.root-servers.net. 198.41.0.4
Los Angeles, CA, US; New York, NY, US *; Frankfurt, DE *; Hong Kong, HK; Palo Alto, CA, US *; Ashburn, VA, US *
B.root-servers.net. 192.228.79.201
C.root-servers.net. 192.33.4.12
Herndon, VA, US; Los Angeles, CA, US; New York, NY, US; Chicago, IL, US; Frankfurt, DE; Madrid, ES
D.root-servers.net. 128.8.10.90
College Park, MD, US
E.root-servers.net. 192.203.230.10
Mountain View, CA, US
F.root-servers.net. 192.5.5.241
Ottawa, Canada *; Palo Alto, CA, US *; San Jose, CA, US; New York, NY, US *; San Francisco, CA, US *; Madrid, ES; Hong Kong, HK; Los Angeles, CA, US *; Rome, Italy; Auckland, NZ *; Sao Paulo, BR; Beijing, CN; Seoul, KR *; Moscow, RU *; Taipei, TW; Dubai, AE; Paris, FR *; Singapore, SG; Brisbane, AU *; Toronto, CA *; Monterrey, MX; Lisbon, PT *; Johannesburg, ZA; Tel Aviv, IL; Jakarta, ID; Munich, DE *; Osaka, JP *; Prague, CZ *; Amsterdam, NL *; Barcelona, ES *; Nairobi, KE; Chennai, IN; London, UK *; Santiago de Chile, CL; Dhaka, BD; Karachi, PK; Torino, IT; Chicago, IL, US *; Buenos Aires, AR; Caracas, VE; Oslo, NO *; Panama, PA; Quito, EC; Kuala Lumpur, Malaysia *; Suva, Fiji; Cairo, Egypt; Atlanta, GA, US; Podgorica, ME; St. Maarten, AN *
G.root-servers.net. 192.112.36.41
Columbus, OH, US; San Antonio, TX, US; Honolulu, HI, US; Fussa, JP; Stuttgart-Vaihingen, DE; Naples, IT
H.root-servers.net. 128.63.2.53
Aberdeen Proving Ground, MD, US *
I.root-servers.net. 192.36.148.17
Stockholm, SE *; Helsinki, FI; Milan, IT; London, UK; Geneva, CH; Amsterdam, NL; Oslo, NO; Bangkok, TH; Hong Kong, HK; Brussels, BE; Frankfurt, DE; Ankara, TR; Bucharest, RO; Chicago, IL, US; Washington, DC, US; Tokyo, JP; Kuala Lumpur, MY; Palo Alto, CA, US; Jakarta, ID; Wellington, NZ; Johannesburg, ZA; Perth, AU; San Francisco, CA, US; Singapore, SG; Miami, FL, US; Ashburn, VA, US; Mumbai, IN; Beijing, CN; Manila, PH; Doha, QA; Colombo, LK; Vienna, AT; Paris, FR; Taipei, TW; Porto Alegre, BR; Yerevan, AM
J.root-servers.net. 192.58.128.30
Dulles, VA, US (2 sites);
Dulles, VA, US (1 sites); Ashburn, VA, US *; Miami, FL, US; Atlanta, GA, US; Seattle, WA, US; Chicago, IL, US; New York, NY, US *; Honolulu, HI, US; Mountain View, CA, US (1 sites); Mountain View, CA, US (1 sites); San Francisco, CA, US (2 sites) *; Dallas, TX, US; Amsterdam, NL; London, UK; Stockholm, SE (2 sites); Tokyo, JP; Seoul, KR; Beijing, CN; Singapore, SG; Dublin, IE; Kaunas, LT; Nairobi, KE; Montreal, CA; Perth, AU; Sydney, AU; Cairo, EG; Cairo, EG; Warsaw, PL (2 sites); Brasilia, BR; Sao Paulo, BR; Sofia, BG; Prague, CZ; Johannesburg, ZA; Toronto, CA; Buenos Aires, AR; Madrid, ES; Fribourg, CH; Hong Kong, HK (2 sites); Turin, IT; Mumbai, IN; Oslo, NO; Brussels, BE; Paris, FR (2 sites); Helsinki, FI; Frankfurt, DE *; Riga, LV; Milan, IT; Rome, IT; Lisbon, PT; San Juan, PR; Edinburgh, UK; Tallin, EE; Taipei, TW; New York, NY, US *; Palo Alto, CA, US *; Anchorage, US; Moscow, RU; Manila, PH; Kuala Lumpur, MY; Luxembourg City, LU; Guam, GU, US; Vancouver, CA; Wellington, NZ
K.root-servers.net. 193.0.14.129
London, UK *;
Amsterdam, NL *;
Frankfurt, DE *;
Athens, GR *;
Doha, QA; Milan, IT *;
Reykjavik, IS *;
Helsinki, FI *;
Geneva, CH *;
Poznan, PL *;
Budapest, HU *;
Abu Dhabi, AE;
Tokyo, JP *;
Brisbane, AU *;
Miami, FL, US *;
Delhi, IN;
Novosibirsk, RU;
Dar es Salaam, TZ
L.root-servers.net. 199.7.83.42
Ankara, TR *;
Atlanta, GA, US *;
Brisbane, AU *;
Cape Town, ZA *;
Chicago, IL, US *;
Crete, GR *;
Copenhagen, DK *;
Culpeper, VA, US *;
Dammam, SA *;
Denver, CO, US *;
El Segundo, CA, US *;
Istanbul, TR *;
Istanbul, TR *;
Jeddah, SA *;
Johannesburg, ZA *;
Lyon, FR *;
Marseille, FR *;
Melbourne, AU *;
Miami, FL, US *;
Paris, FR *;
Perth, AU *;
Philadelphia, PA, US *;
Prague, CZ *;
Riyadh, SA *;
San Jose, CA, US *;
Santiago de Chile, CL *;
Sydney, AU *;
Toronto, CA *
M.root-servers.net. 202.12.27.33
Tokyo, JP (3 sites) *;
Seoul, KR; Paris, FR *;
San Francisco, CA, US *
